Cyberboy2054
Messages postés173Date d'inscriptionjeudi 20 décembre 2001StatutMembreDernière intervention22 août 2008
-
27 avril 2004 à 17:58
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 2004
-
29 avril 2004 à 19:57
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 29 avril 2004 à 19:57
oui c'est vrai, mais ca depend
par exemple, la je suis entrain de regarder les carray (equivalent MFC de std::vector)
la c'est plutot
template<...>
class x
{
void method();
...
};
// definition methode inline
...
// definition methode out of line
template<...> x::methode()
{
...
}
mais dans tt les cas c'est la meme chose, sauf que c'est d'autant plus clair a regarder ainsi
en tt cas merci de m'avoir fait remarquer mes erreurs
BlackGoddess
Messages postés338Date d'inscriptionjeudi 22 août 2002StatutMembreDernière intervention14 juin 2005 29 avril 2004 à 19:08
(oublié le ; a la fin)
BlackGoddess
Messages postés338Date d'inscriptionjeudi 22 août 2002StatutMembreDernière intervention14 juin 2005 29 avril 2004 à 19:08
la plupart des implémentations de templates que j'ai vu allient déclarations et définitions :
template < ... >
class x
{
void methode()
{
...
}
}
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 28 avril 2004 à 19:50
ben pour les destructeur virtuel, j'ai choisi de ne pas faire d'interfce virtuel pour ces classes, c'est le cas de std::vector entre autre
oui le __fastcall n'est pas standard mais la c'est pas le but, je vois mal comment allié code standard + perf
pour l'operateur [], en effet je verifie pas pour pas perdre de temps, par contre je le fait avec la methode ind, std::vector fait la meme avec la methode elementAt
pour la version const, je vais l'ajouter, merci
aussi j'ai foutu les definition dans des .cpp et c'est une erreurs, quoi qu'il en soit tu a raison, ca doit se trouver dans un fichier entete, mais pas forcement l'entete meme de la classe du moment qu'il est inclu
pour la forme je dirai qu'il est plus propre de faire genre
stack.h ==> declaration
stack.tpl ==> definition des methode, le fichier doit etre inclus (ala fin de stack.h par ex)
en fait comme on ferait la meme chose avec les fichier .inl pour mettre la definition des methodes inline
BlackGoddess
Messages postés338Date d'inscriptionjeudi 22 août 2002StatutMembreDernière intervention14 juin 2005 28 avril 2004 à 11:50
il me semblait qu'une classe template devait être définie (et pas seulement déclarée) dans chaque unité de compilation ?
il est conseillé de mettre tes destructeurs virtuels si tu veux permettre de dériver tes classes
__fastcall n'est pas standard
sinon, pour stack :
element devrait p-e être déclaré en privé dans stack ?
pour tableau :
inline Type& __fastcall operator [] (int ind)
{
return m_Ttab[ind];
}
>> pas de vérification de dépassement ???? c'est pourtant un des interêts majeurs d'une telle classe
et la version const ?
const Type & operator [] (int ind) const;
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 27 avril 2004 à 19:50
oui c'est vrai, c'est a completé (c'etait just l'idee)
toi aussi tu a vu que ca valais le coup de recoder ces classes de la stl
si ca t'interresse et que ta vc++, regarde les sources des carray des mfc, c assez bien foutu au niveau optimisation
d'accord pour les string, difficile de faire mieux de meme pour les allgorithme de la stl
Cyberboy2054
Messages postés173Date d'inscriptionjeudi 20 décembre 2001StatutMembreDernière intervention22 août 2008 27 avril 2004 à 17:58
Manque juste quelques fonctions genre algo de tri, mais j aime bien ta source lol, moi aussi j ai recodé ce genre de classes (ya que std::string que j aime dans la stl...)
29 avril 2004 à 19:57
par exemple, la je suis entrain de regarder les carray (equivalent MFC de std::vector)
la c'est plutot
template<...>
class x
{
void method();
...
};
// definition methode inline
...
// definition methode out of line
template<...> x::methode()
{
...
}
mais dans tt les cas c'est la meme chose, sauf que c'est d'autant plus clair a regarder ainsi
en tt cas merci de m'avoir fait remarquer mes erreurs
29 avril 2004 à 19:08
29 avril 2004 à 19:08
template < ... >
class x
{
void methode()
{
...
}
}
28 avril 2004 à 19:50
oui le __fastcall n'est pas standard mais la c'est pas le but, je vois mal comment allié code standard + perf
pour l'operateur [], en effet je verifie pas pour pas perdre de temps, par contre je le fait avec la methode ind, std::vector fait la meme avec la methode elementAt
pour la version const, je vais l'ajouter, merci
aussi j'ai foutu les definition dans des .cpp et c'est une erreurs, quoi qu'il en soit tu a raison, ca doit se trouver dans un fichier entete, mais pas forcement l'entete meme de la classe du moment qu'il est inclu
pour la forme je dirai qu'il est plus propre de faire genre
stack.h ==> declaration
stack.tpl ==> definition des methode, le fichier doit etre inclus (ala fin de stack.h par ex)
en fait comme on ferait la meme chose avec les fichier .inl pour mettre la definition des methodes inline
28 avril 2004 à 11:50
il est conseillé de mettre tes destructeurs virtuels si tu veux permettre de dériver tes classes
__fastcall n'est pas standard
sinon, pour stack :
element devrait p-e être déclaré en privé dans stack ?
pour tableau :
inline Type& __fastcall operator [] (int ind)
{
return m_Ttab[ind];
}
>> pas de vérification de dépassement ???? c'est pourtant un des interêts majeurs d'une telle classe
et la version const ?
const Type & operator [] (int ind) const;
27 avril 2004 à 19:50
toi aussi tu a vu que ca valais le coup de recoder ces classes de la stl
si ca t'interresse et que ta vc++, regarde les sources des carray des mfc, c assez bien foutu au niveau optimisation
d'accord pour les string, difficile de faire mieux de meme pour les allgorithme de la stl
27 avril 2004 à 17:58