Bonjour,
 
Dans le projet sur lequel je travaille il existe des classes gérant des tableaux, des vecteurs, et autres classes de stockage. Hors je ne vois pas l'intérêt de ces classes à part de se passer de la STL. Je pense qu'à l'époque où elles ont été écrites le code de la STL ne compilait pas sur certaines machines HP ou IRIX. Mais aujourd'hui toutes les plateformes sur lesquelles je compile acceptent la STL.
 
A votre avis, dois-je continuer à utiliser ces classes pour rester homogène avec le reste du projet?
 
Question subsidiaire : serait-il intéressant d'encapsuler la STL dans des classes à moi?
 
 
Voilà un extrait de code pour que vous voyiez de quoi je parle:
 
 

bof, j'espère que le constructeur de recopie et l'opérateur d'assignement traine plus bas.
virtual dans une template générique ? wtf ?
 
y'a qu'une seule raison pour ne pas utiliser la STL: c'est d'être sûr d'aller vraiment plus vite avec sa propre implémentation. et 99% du temps ce n'est pas justifié (je sais j'ai déjà fais le con moi aussi).
 
vu le reallocTab, bof t'as la même pénalité à la réallocation qu'un vector (deuxième séquence d'objets et recopie), en plus ça doit être foireux de temps en temps (vu memcpy, si l'objet crée des dépendences à son adresse à la création qu'il libère à la destruction, assignement, là ça foirera là le std::vector conservera la logique objet).
 

 
Des objets de l'appli héritent de cette classe pour avoir les méthodes d'un tableau.
 
 
Après tout ce que tu me dis confirme mon sentiment. Merci.

 
Autant un objet qui contient un tableau je veux bien, autant une classe qui est un tableau, ca reste restreint. En outre, avec un template, il vaut mieux se rapatrier sur des solutions types static olymorphism (via le Barton-Nackmann trick) ou stratégies templates.

 
j'imagine que ça puisse être utile, mais il doit y avoir moyen de passer une classe intermédiaire en principe.

 
Je déteste ce genre de classes utilitaires "maison". Je sais, c'est pas un argument, disons que je parle d'expérience   Si tu développes un module de ton projet à partir de rien, tu ferais mieux d'utiliser la STL. A ta place même dans un code existant j'abandonnerais l'utilisation de ces classes pour tous les ajouts que je ferais (sans aller jusqu'à remplacer par la STL même dans le code existant, après tout si personne n'a jamais signalé de bug...).
 

 
J'ai un collègue qui a fait ses propres map pour un composant d'optimisation discrète, il m'assure qu'elles vont bcp + vite que celles de la STL made by Microsoft. Mais bon, il est vraiment fort et il a un besoin très particulier je pense.

 
oui voilà si il a benché son implémentation.

A priori ça n'a pas été écrit dans un souci d'optimisation, donc comme effectivement je fais un module indépendant je vais utiliser la STL.
 
Merci pour le Barton-Nackman trick, je ne connaissais pas.

C'est ultra mauvais en plus comme implémentation, surtout si T n'est pas un POD, ça fout tout en l'air avec ces memcpy. Et y a surtout aucune protection contre la copie, toussa, ça doit faire du joli toi qui cherche les double free
 
Tu peux pas la réimplémenter en héritant private de std::vector<> ?
et définir des constructeur de copie / operator= privé aussi et voir ce que ça donne. Si ça compile pas, tu trouveras immédiatement des copie ?
et vyrre tout ces trucs inline aussi.

 
Qu'est-ce que je risque à remplacer les memcpy par des std::copy ?
 
 

 
Je pourrais le faire en me faisant une batterie de tests unitaires, mais j'ai un peu peur d'injecter ça dans tout le projet si ça doit le rendre instable... Si y'a des merdes dans cette implémentation, peut-être qu'elles sont rattrapées ailleurs, du coup mon passage à la stl sera foireux
 

 
trouver des copies indésirables/foireuses tu veux dire?
 

 
pourquoiiiii?    

1) parceque memcpy, ça copie des octets, pas des objets
2) pas forcément. vu le travail que ça demande, ça vaut le coup de faire un essai. l'implémentation avec un std::vector<> est très simple. t'as moyen de diviser le volume du code par 4 et donc de bug. tout en gardant la même interface exacte.
3) oui, et des double delete surtout
4) parce que ça sert à rien d'inliner tout ça, sauf à bloater ton binaire et a pourir ton cache
5) je peux pas viendre travailler avec toi ?

1) ma question était dans l'autre sens : est-ce que je peux remplacer les memcpy par des std::copy sans risque?
[2,4]) ok ça me botte d'essayer
5) ok mais c'est moi qui porterais la culotte.

1) oui. et surtout simplifier ce genre de bétises
#
    for ( i = 0 ; i < _Size ; i++ )
#
      memcpy(NewValues+i,_Values+i,DataSize);  
 
5) OK. Y a peut etre meme une prime à la cooptation

4) le truc c'est sur tout d'avoir :
- un .h avec la définition de la classe et des trucs inline
- un .tpp avec les définitions des fonctions membre pas inline. mais comme c'est des template, bah il faut #include à la fin du .h. ça te permet de quand meme avoir une séparation logique.

roger wilco

let me know as soon as your code and you're ready