Je rencontre un problème dans l´implémentation d´une classe modèle ( template).
Le but de celle ci est de permettre l´instanciation d´objets ressemblant à des tableaux, permettant le stockage de données de n´importe quel type.
En outre, celle ci doit croitre dynamiquement au fur et à mesure de l´ajout de nouvelles données.
Cette action est effectuée par la fonction membre suivante :

template < class tableType >
bool AutoTable<tableType>::add( const tableType & )
{
int loop;
tableType *temp = NULL;

temp = new tableType[nbElements];
assert( temp ! = NULL ) ;

/ / Copie du tableau existant
for( loop = 0 ; loop < nbElements ; loop++ )
temp[loop] = memory[loop];

if( memory ! = NULL )
delete [] memory;
memory = new tableType[nbElements];
assert( memory ! = NULL ) ;

for( int loop = 0 ; loop < nbElements ; loop++ )
memory[loop] = temp[loop];

delete [] temp;
memory[nbElements++] = value;
return true;
}

Or celle ci plante à l´exécution ( pas de problème de compilation ) .
Quelqu´un pourrait il m´en expliquer la cause ?

memory représentant l´ensemble des éléments au sein de la classe ( tableau ) , nbElements le nombre d´éléments contenus dans memory.

tu pe simplifiez ta kestion svp

Sans vouloir te vexer; je ne suis pas sûr que tu puisses me répondre
C´est assez poussé...
Si ca ce trouve j´ai fait une erreur idiote, mais bon...

J´ai lu rapidement mais j´avoue pas vraiment comprendre pourquoi tu alloue 2 zones memoires.

De plus la nouvelle que tu alloue, fait comme taille nbElements alors que tu ecris un element de plus.

Je pense que memory[nbElements++] est hors du tableau.

Pour ce genre de fonction, une seul reallocation est necessaire, puis tu copie tout dedans.

Le mieux etant d´allouer par tranche de 10 par exemple, ca t´evite de faire 10 realloc et 10 recopie memoire ( ce qui peut etre lent).

pourquoi faire deux boucles quand un memcpy suffit ? . . enfin là n´est pas la question.
ça serait possible que tu pastes un petit truc complet compilable ( genre un main, la classe template) qu´on puisse facilement importer/indenter, ça serait pratique pour mieux t´aider
sinon, si c´est dans un but " éducatif", tant mieux, sinon y´a les std::vector<> qui font ça tres bien

J´ai trouvé ( quel idiot ) c´est :

memory = new tableType[nbElements+1];

Sinon pourquoi y en a 2 ?
Pour faire un copie de memory avant de le désallouer, de remmettre tout bien et de rajouter l´élément nécessaire ( pas de realloc en C++ )
memset, je l´avais viré car je pensais que le problème venait de là et j´ ai pas pris la bonne version a poster sur le forum.
Sinon c´est certes à but éducatif et aussi parce que la classe est très simpl ( 6 membres en tout ) : vector, elle, en a plein qui me sont inutiles

Tu voulais dire meset à la place des for ?
Ah non ils sont nécessaires ici car ils assurent la copie.
J´en utilisait un avant pour l´initialisation du temp, mais il était inutile.

soit, mais je veux dire : après
delete [] memory;

pourquoi réallouer, et copier à nouveau dans memory, tu fais juste :
delete [] memory;
memory = temp;
return true;

et ça marche aussi bien

sinon, essaye de trouver une convention de nommage ( pour distinguer les membres de classes, les var. de piles, les paramètres, etc.), ça aide à la compréhension quand qqun d´autre lit ton code ; )

et je ne parlais pas de memset mais de memcpy ; au lieu de faire un for, tu fais un gros memcpy de toute la zone, et ça te sort en ASM un gros REP MOVSQ ( avec qq SD, SB selon la multiplicité de la taille), ça dépotera beaucoup plus que la copie individuelle de tous les éléments

dernier point, si on regarde les containers std:: ils ont la bonne de croitre exponentiellement, pour limiter le nombre de manipulations mémoires : si les perfs sont ta préoccupation, il serait bon de s´en inspirer

dans tous les cas, bon code !

Oui j´ai pas pensé au memcopy c´est vrai que c´est bien plus rapide.
J´irais jeter un oeil dur les containers également merci

Sinon pour les conventions de noms, il est vrai que je devrait affiner.
La mienne est trop général : Classes/types commencant par une majuscule et le reste en minuscule
Mais sans tomber dans l´excès de la notation hongroise...

Perso, j essaye de ne jamais stocker des objets, mais plutot leurs pointeurs => moins de mem, plus rapide a la copie que d utiliser le constructeur par copie, et surtout, que se passe t´il avec l heritage..
Ex:
class Base { / * . .. */ };
class Extend : public Base { / * . .. */ };

class Test : public AutoTable<Base> { / * . .. */ };

/ * . .. */

Test test;
Base base;
Extend extend;
test.add( base ) ;
test.add( extend ) ;

. ..

sizeof( Base ) ! = sizeof( Extend ) ...

ben moi je trouve que c´est pas mal comme c´est fait : vu que c´est un template, quand tu veux stocker des pointeurs, tu stockes des pointeurs, quand tu veux stocker des objets, du stockes des objets ; et ça apparait explicitement dans ton code ; quand t´as :

container<type> c;
container<type *> c;

indépendement de l´implémentation qu´il y a derriere, tu sais ce qui se passe ; enfin, mon point de vue

Voila à quoi ca ressemble maintenant :

template < class tableType >
bool AutoTable<tableType>::add( const tableType & )
{
tableType *temp = NULL;

temp = new tableType[nbElements];
assert( temp ! = NULL ) ;

memcpy( temp, memory, sizeof( tableType ) *nbElements ) ;

if( memory ! = NULL )
delete [] memory;
memory = new tableType[nbElements+1];
assert( memory ! = NULL ) ;

memcpy( memory, temp, sizeof( tableType ) *nbElements ) ;

delete [] temp;
memory[nbElements++] = value;
return true;
}

voilà comment je l´écrirai :

template < type T>
bool AutoTable<T>::add(const T &)
{
T *p_t = new tableType[m_nNbElements + 1];
if ( !p_t)
return FALSE;

if ( m_nNbElements > 0)
{
memcpy(p_t, m_pData, m_nNbElement*sizeof(T));
delete [] m_pData;
}

m_pData = p_t;
m_pData[++m_nNbElements] = rValue;

return true;
}

apres, chacun ses préférences ; )
mais ce qui me genait, c´était surtout le " if ( memory == NULL)" , à froid, dans le code, c´est pas forcément plus explicite ; juste en faisant la meme condition mais sur le nombre d´élements, ça me parait plus intuitif... enfin, s´il y avait une manière universelle de coder, ça se saurait LOL

Et pourquoi ne pas tout simplement faire un realloc ?

template < class tableType >
bool AutoTable<tableType>::add( const tableType & )
{
_memory = realloc(_memory, sizeof(tableType)*(nbElements++)) ;
memory[nbElements] = value;
return true;
}

C´est a peu près ca non ? C´est meme possible d´utiliser un step a la reallocation pour eviter de le faire a chak fois. Bon apres, c´est pas le plus rapide mais c´est assez sympa j´trouve

ben lag-it avait dit qu´il ne voulait pas utiliser le realloc ^^^^ mais c´est clair que c´est exactement ce que fait le code. Et comme tu dis, avec le step à la realloc, on peut peut recréer le processur d´expansion exponentielle de la capacité ( != de la taille) mentionnée plus haut sur les std::vector ( entre autres).

Ah d´accord, mais j´ai pas tou lu ^^
ben pourquoi po de realloc ? j´comprend pas, on peut l´utiliser meme si on est en C++

en relisant, je me rend compte que j´avais moi-meme mal compris sa phrase ; j´avais pensé qu´il ne voulait pas l´utiliser. Mais l´affirmation " pas de realloc en C++" est bien évidemment fausse

lgv: oui, d accord a moitie.. Disons je pense qu´avoir la possibilite de faire une erreur en stockant des objets qui n´ont pas la meme taille est pas tres propre a mon gout. Forcer le pointeur resolve le probleme. Et qui veut recopier des objets ( avec ou sans memcpy/realloc) alors que les pointeurs c bcp plus petit en general?

on vient d´avoir une discussion interessante sur la question, avec kUfa ; on paste le log des fois que ça interesse qqun, ou si qqun souhaite exprimer un point de vue

[00:04 14/05/2004] kUfa ~ LGV: chui que moyennement d accord avec ton post sur jv
[00:04 14/05/2004] kUfa ~ mais j ai repondu pour expliquer
[00:05 14/05/2004] LGV ~ ok ok, allons voir ça
[00:06 14/05/2004] LGV ~ => kUfa : je saisi pas comment tu pourrais stocker des objets qui n´ont pas la meme taille ? => polymorphisme par ex tu

veux dire ?
[00:06 14/05/2004] kUfa ~ bon dans son truc tu peux faire ca:
[00:07 14/05/2004] kUfa ~ class Test : public Autobase<Base> { };
[00:07 14/05/2004] kUfa ~ le truc si tu ajoute un Extend, ca couille
[00:07 14/05/2004] kUfa ~ et donc soit tu indique ca dans la doc
[00:07 14/05/2004] kUfa ~ personne va la lire
[00:07 14/05/2004] kUfa ~ et boom
[00:08 14/05/2004] LGV ~ je saisi pas ton exemple ^^^^ . .. moi je verrai un truc comme ça :
[00:08 14/05/2004] kUfa ~ en plus de ca, si ta classe a une taille non divisible par 4, avant que le compilo rajoute de l espace, ben tu va

perdre plein de mem en faisant ca
[00:09 14/05/2004] LGV ~ . ... attends, moi je vois ça comme ça :
[00:09 14/05/2004] kUfa ~ ( au passage regarde aussi pkoi je trouve pas ca beau:
[00:09 14/05/2004] LGV ~ si t´as un autotable<Object> tu peux que foutre des Objet dedans, point.
[00:09 14/05/2004] kUfa ~ ben nan
[00:10 14/05/2004] LGV ~ sinon tu peux faire autotable<Object *> et utiliser le polymorphisme
[00:10 14/05/2004] kUfa ~ pkoi tu pourrais pas mettre des objets qui herites?
[00:10 14/05/2004] kUfa ~ s = nt
[00:10 14/05/2004] kUfa ~ ce que je veux dire c est que la restriction est pas evidente pour celui qui utilise ca
[00:10 14/05/2004] kUfa ~ et donc source d erreur, non detectables a la compil
[00:11 14/05/2004] LGV ~ ben faut que ce soit des pointeurs pour exploiter le polymorphisme ; dans tous les cas le codeurs doit savoir ce qu´il

fait, donc je suis partisan de laisser la possibilité, avec template<> et template<*>
[00:11 14/05/2004] kUfa ~ moi je suis partisant de pas avoir de code succeptible de planter
[00:11 14/05/2004] kUfa ~ et je suis partisant d eviter les copies de memoire inutiles
[00:12 14/05/2004] LGV ~ aussi oui, mais ça PEUT etre utile de pas utiliser des pointeurs : genre si tu veux un std::vector en mem. partagée par

exemple
[00:12 14/05/2004] LGV ~ il faut que les deux possibilités subsistent ; alors soit fournir deux containers, avec * et sans *, ou alors laisser le

template
[00:13 14/05/2004] kUfa ~ nan je trouve ca moche de toute facon
[00:13 14/05/2004] kUfa ~ pkoi copier un objet ( et forcer l existence d un constructeur par default et par copie)
[00:14 14/05/2004] LGV ~ dans la TRES grande majorité des cas, je fais comme toi, des container<*>, mais la possibilité de copier les instances

DOIT exister
[00:14 14/05/2004] LGV ~ et le template permet de le faire, je vois pourquoi ce serait moche
[00:14 14/05/2004] LGV ~ mais apres c´est question de point de vue
[00:15 14/05/2004] kUfa ~ pour moi c moche dans le sens que 1. c lent et pas utilise, ou enfin tres peu 2. ca porte des restrictions sur le type

d objet passe
[00:16 14/05/2004] LGV ~ ben c´est utilisé ; je prenais l´ex. de la mem partagée car justement je m´en suis servi durant mon stage, des data été

éparpillées sur plusieurs machines, on été bien content d´utiliser des containers qui copient
[00:16 14/05/2004] LGV ~ par contre je vois pas la restriction sur l´objet passé, à part qu´il doit avoir un ctor par copy
[00:16 14/05/2004] kUfa ~ un par defautl si tu utilise new []
[00:17 14/05/2004] kUfa ~ et tu peux pas ajouter de classes qui derivent, enfin ca depends, mais en general non
[00:18 14/05/2004] LGV ~ je suis ok pour les classes qui dérivent, mais le coder utilera naturellement des * :/ enfin, moi je vois ça comme ça
[00:18 14/05/2004] LGV ~ ^^^^ ça c´est valable pour TOUS les objets , le ctor par def. avec new []
[00:18 14/05/2004] LGV ~ à moins de faire operator new + placement new
[00:18 14/05/2004] kUfa ~ je suis d accord, mais pkoi ne pas forcer le * dans le template alors?
[00:18 14/05/2004] kUfa ~ ^^^^ oui, enfin je crois que tu peux passer des arguments a ce new
[00:19 14/05/2004] kUfa ~ mais j essaye de ne JAMAIS utiliser new[]
[00:19 14/05/2004] kUfa ~ sauf quand c vraiment utile
[00:19 14/05/2004] LGV ~ parceque tu peux vouloir copier l´objet ( mais alors faudra pas utiliser d´objet dérivés, donc là oui , je suis ok c´est

chiant
[00:19 14/05/2004] LGV ~ )
[00:20 14/05/2004] kUfa ~ si tu veux copier l objet, c que tu en as deja une copie, et je pense pas que dans ce cas c tres utile d en refaire une

copie pour le mettre dans un container, je pense
[00:20 14/05/2004] kUfa ~ le truc je suis sur que si je fais ca, un coder, disons lucas, mettra une classe derivee dedans ; )
[00:20 14/05/2004] LGV ~ SI pour le mettre à disposition d´autres threads/machines par exemple, qui n´ont PAS acces à ton segment de mem
[00:21 14/05/2004] LGV ~ enfin, ça se discute tout ça, mais à mon avis c´est plus question de pref. personnelle que de réelle restriction

tehcnique selon moi
[00:22 14/05/2004] kUfa ~ si tu veux mon avis, par soucis de stabilite, je prefererai faire un template avec *, et faire SI necessaire une classe

a part pour les objets
[00:22 14/05/2004] LGV ~ ouais, par exemple fournir plusieurs containers selon ce qu´on en fait, ça peut résoudre le soucis ; mais va savoir si

là encore le coder fera bien la distinction entre les deux ; ) dur dur
[00:23 14/05/2004] kUfa ~ hehe c clair
[00:23 14/05/2004] LGV ~ dans un cas comme dans l´autre, y´a des limitations : avec toi, impossible de copier, meme si on veut, avec moi on peut

faire des trucs pas catholiques :/
[00:23 14/05/2004] LGV ~ bref... à adapter selon chaque projet
[00:23 14/05/2004] kUfa ~ c clair
[00:24 14/05/2004] LGV ~ bon, plus qu´à paster le log sur JV LOL ; )
[00:24 14/05/2004] kUfa ~ disons je me sens plus en securite si je sais que mon projet ne plantera de facon non deterministe
[00:24 14/05/2004] LGV ~ voui, ça se défend
[00:25 14/05/2004] kUfa ~ et puis beark forcer un cstr par defaut/cpy ; )
[00:25 14/05/2004] kUfa ~ ex lucas:
[00:25 14/05/2004] kUfa ~ ( moi je peux pas faire de template)
[00:25 14/05/2004] kUfa ~ ( et pis c est en c)
[00:25 14/05/2004] kUfa ~ j ai une structure vector
[00:26 14/05/2004] kUfa ~ initialisee avec deux pointeurs fonctions, si necessaire, un appele lors de l ajout, l autre lors de la destruction
[00:26 14/05/2004] LGV ~ ( mais tu peux faire container.add(Object(12, 34)); si tu veux, donc il faut un ctor de cpy, mais pas forcément pas def.)
[00:26 14/05/2004] kUfa ~ vu que je l utilise en c++, tu peux appele un autodelete
[00:26 14/05/2004] kUfa ~ ^^ pas si tu fais un new[]
[00:26 14/05/2004] LGV ~ un new [] sur quoi ? sur l´objet ou sur le container ? . ..
[00:27 14/05/2004] kUfa ~ qui appelle juste delete sur le void * passe en parametre
[00:27 14/05/2004] LGV ~ fini ton ex ; )
[00:27 14/05/2004] kUfa ~ hehe ok
[00:27 14/05/2004] kUfa ~ ma fonction d ajout ressemble a :
[00:27 14/05/2004] kUfa ~ int8 addElementBefore( Vector *vector, void *data, VectorPosition *pos )
[00:28 14/05/2004] kUfa ~ un truc dans le style
[00:28 14/05/2004] kUfa ~ ajoute au vecteur vector, avant la position pos, la donnee data
[00:28 14/05/2004] kUfa ~ donc la tout va bien, tu peux rajouter ce que tu veux
[00:28 14/05/2004] LGV ~ ok, je suis
[00:29 14/05/2004] kUfa ~ lucas a ajoute un ( int32*) m_i32Position
[00:29 14/05/2004] kUfa ~ donc la ca passe
[00:29 14/05/2004] kUfa ~ sauf que le vecteur etait construit avec une fonction autodelete
[00:29 14/05/2004] LGV ~ vi, mais il a du raler s´il faut caster le void * à la récup
[00:29 14/05/2004] kUfa ~ nan la il a l habitude ; )
[00:30 14/05/2004] kUfa ~ donc lors de certains free, pas tous ( c est le plus marrant), ben ca merde normal
[00:30 14/05/2004] LGV ~ bah forcément, si on fout du autodelete... :/ je suis pas fan, à la mano on sait ce qui se passe
[00:30 14/05/2004] kUfa ~ vi, mais un ctrlc/v, et pis voila
[00:30 14/05/2004] kUfa ~ pas de documentation, et zou des jolis bugs
[00:30 14/05/2004] kUfa ~ mais bon c est en C mixe avec du c++
[00:31 14/05/2004] LGV ~ mais je crois qu´on peut trouver des exemples pour argumenter dans tous les cas qu´on a cité :/ faut vraiment des SD

spécifiques à un pb donné
[00:31 14/05/2004] kUfa ~ normal
[00:31 14/05/2004] LGV ~ revenons à ton new [] si tu veux bien
[00:31 14/05/2004] kUfa ~ c pour ca que je suis contre permettre une sd generique qui puisse planter
[00:31 14/05/2004] kUfa ~ vi
[00:31 14/05/2004] LGV ~ ^^^^ ouais, ça se défend
[00:32 14/05/2004] LGV ~ je ne vois pas comment tu veux utiliser le new [] pour dire qu´il faut un ctor par def. des objet à ajouter ?
[00:33 14/05/2004] kUfa ~ class Test {
[00:33 14/05/2004] kUfa ~ public:
[00:33 14/05/2004] kUfa ~ Test( int a ) { }
[00:33 14/05/2004] kUfa ~ private:
[00:34 14/05/2004] kUfa ~ Test() { }
[00:34 14/05/2004] kUfa ~ };
[00:34 14/05/2004] kUfa ~ . .
[00:34 14/05/2004] kUfa ~ Test a[10]; / / erreur
[00:34 14/05/2004] LGV ~ sur
[00:34 14/05/2004] LGV ~ et quel rapport avec le container ?
[00:34 14/05/2004] LGV ~ parce que tu peux faire ça :
[00:35 14/05/2004] LGV ~ Test *a = reinterpret_cast<Test*>(::operator new(10*sizeof(a)));
[00:35 14/05/2004] LGV ~ for ( ......) new ( offset) Test(2);
[00:35 14/05/2004] kUfa ~ ( je parlais par rapport a l ex du mec sur jv qui faisait plein de new[])
[00:35 14/05/2004] LGV ~ aaaah, ok ok
[00:35 14/05/2004] LGV ~ container.add(a);
[00:36 14/05/2004] LGV ~ je croyais que tu voyais une faille du mecanisme d´add avec le new[]
[00:36 14/05/2004] LGV ~ bon ben alors je sais
[00:36 14/05/2004] LGV ~ i
[00:36 14/05/2004] kUfa ~ ok mais maintenant si tu as 3 constructeurs differents, super, c pas tres generique comme container
[00:37 14/05/2004] LGV ~ ben c´est pas au container de construire l´objet !
[00:37 14/05/2004] kUfa ~ si tu as pas de cstr par default
[00:37 14/05/2004] LGV ~ c´est à l´user de le construie AVANT de l´ajouter
[00:37 14/05/2004] kUfa ~ je suis d accord, mais donc c interdire les new[]
[00:37 14/05/2004] kUfa ~ ce qui me derange pas plus que ca vu que c moche
[00:38 14/05/2004] LGV ~ dans tous les cas, container ou pas : dflt ctor non public => on interdit le new [] ; donc c´est pas spécifique au

container
[00:39 14/05/2004] kUfa ~ je suis pas sur, je pense que tu peux faire un truc du style new Test[10] ( 5);
[00:39 14/05/2004] kUfa ~ a verifier
[00:39 14/05/2004] kUfa ~ en tout cas ya un truc similaire avec les std::vector
[00:39 14/05/2004] * kUfa test
[00:39 14/05/2004] LGV ~ aaah vi, en effet, ça me parle aussi
[00:40 14/05/2004] LGV ~ mais moi je dissocie vraiment la construction de l´objet ( tache de l´user) de son ajout ( le container s´en branle de la

construction)
[00:41 14/05/2004] LGV ~ donc je vois pas plus de limitation que ce existe naturellement en C++ : ctor avec ou sans param, etc.
[00:43 14/05/2004] kUfa ~ oui mais la t OBLIGE d avoir un ctr par copie, ce qui est moyennement genant
[00:43 14/05/2004] LGV ~ ça, je te l´accorde
[00:44 14/05/2004] LGV ~ mais est-ce vraiment un soucis :-? à part pour certains objets particuliers ( singletons, dépendant d´une interface,

etc.), la plupart des objets doivent etre copiables
[00:44 14/05/2004] LGV ~ ( LOOOOL, c´te pur dialogue d´informaticiens ; ) )
[00:44 14/05/2004] kUfa ~ ( hahaha c clair ; )
[00:45 14/05/2004] kUfa ~ non par ex: File, etc..
[00:45 14/05/2004] LGV ~ comme dirait Dilbert " je comprends pas qu´on aie pas d´amis en dehors du boulot" LOOOL
[00:45 14/05/2004] kUfa ~ des instances qui doivent etre unique yen a un paquet tout de meme
[00:45 14/05/2004] LGV ~ ^^^^ bah, un File, c´est qu´un acces à un fichier, la copie de l´objet est faisable selon moi, quitte à foutre un mutex
[00:45 14/05/2004] kUfa ~ celle qui prennent des locks etc
[00:45 14/05/2004] LGV ~ loool, quand on parle de mutex ; )
[00:45 14/05/2004] kUfa ~ ^^^^ hahahaha
[00:46 14/05/2004] LGV ~ on en revient donc au bon adage : démerde toi, mais faut que ça marche
[00:47 14/05/2004] kUfa ~ lol oui
[00:48 14/05/2004] LGV ~ d´où apres les bonnes doc bien foutues : " ne prend qu´un objet si c´est un pointeur sur une classe de base à moins que

la classe dérivées ait un ctor par copy bien formé" :D
[00:48 14/05/2004] LGV ~ ( cf. note 4 annexe B pour le détail) ; )
[00:48 14/05/2004] kUfa ~ te pis si tu passe un const&, est-ce rellement bien de vouloir en faire une copie et deferencer le const
[00:49 14/05/2004] kUfa ~ hahaha
[00:49 14/05/2004] kUfa ~ ou alors un truc terrible:
[00:49 14/05/2004] LGV ~ ben ça dépend... si t´as un container<const *> pourquoi pas :/ sinon c´est dégueulasse, vi
[00:49 14/05/2004] kUfa ~ c clair
[00:51 14/05/2004] kUfa ~ #define protect_add(base,ctr,elt) { assert ( sizeof(base)==sizeof(elt))&&"Cannot add this element"; ctr.add( elt ) ;
[00:52 14/05/2004] LGV ~ ZE truc pas chiant et facile d´utilisation : sizeof(base) == sizeof(elt)
[00:52 14/05/2004] LGV ~ mais bon, si on veut limiter , on peut ; )
[00:53 14/05/2004] kUfa ~ c clair, mais c pas propre non plus
[00:53 14/05/2004] kUfa ~ ou faire un test avec le rtti
[00:53 14/05/2004] LGV ~ pas propre ? ?? . .. bof, au milieu du reste de notre code, ça passe je suis sur
[00:53 14/05/2004] kUfa ~ quoique c pas dis que ca passe
[00:53 14/05/2004] kUfa ~ lol