Discussion :

[ShaiLeTroll]

RAD Studio C++ 2007
Je débute avec les templates !
Je sais qu'à partir de 2009, avec l'ajout des génériques en Delphi, il est possible d'utiliser une TList<T> (generics.collection) qui reprend les méthodes de la TList habitudelle (classes)

J'ai cru comprendre qu'utiliser les génériques Delphi par des Header de Template C++, cela semblait pas être très très joli !

Que pensez vous de la STL list<> (Dinkumware) ?
Quelle la différence entre std::list et std::vector, juste la possibilité d'utiliser [] ?

en fait, j'ai pas envie d'écrire ce genre d'horreur : TfrmMain::ShowContacts() et la vilaine répétition de reinterpret_cast
une petite surcharge de "void* Items[]" en "struct* Items[]" et cela inclue le cast dans l'accesseur !

j'ai cru comprendre que la list provoquait la libération des éléments (voir la doc de la méthode erase : "Erasing N elements causes N destructor calls"), cela ne fonctionne que sur les classes ? est-ce cela supporte les struct ? les TObject ?
Je ne veux pas libérer mes items, je veux juste stocker des struct*, et lorsque je vide la liste, je veux juste qu'il les oublie (ces struct* viennent d'ailleurs dans le code, tout est déjà nickel à ce sujet)

EDIT : D'après mes Tests, cela n'appel le destructeur si <class*>, cela appel le constructeur de copie et le destructeur sur <class>

Rien que trouver qu'il fallait écrire "std::list" et pas juste list tout court, j'ai bien du chercher une bonne minute !

Enfin, migration sur XE prévue, j'aimerais prévoir le coup et remplacer rapidement std::vector par TList<> (logique autant utilisé la VCL, sinon inutile d'être sous RAD Studio)
Pour le moment, je pars sur une TList + Accesseurs, par ceque la std::list ne me convient pas mais j'aimerais connaitre le ressenti à ce sujet des experts C++ Builder !

Idem avec DynamicArray<> par rapport à la TList ou TList<> ?

[yarp]

Je ne connais pas bien std::list puisque j'utilise TList en général, mais ça m'étonnerait que erase appelle les destructeurs. TList ne le fait pas non plus. A vérifier bien sur.

La grande différence entre list et vector est que list est une liste chainée tandis que vector est un tableau (array). Chaque fois que tu ajoute un nouvel element dans vector le tableau est reconstruit (d'ou l'interêt de la methode reserve pour pré-allouer de la mémoire).
De plus l'ajout/supression des elements d'un vector est optimisé quand on ajouter en fin de tableau, tandis que list permet les insertions.

Donc utilise vector pour des listes finies et stables et list pour des listes plus dynamiques.

> logique autant utilisé la VCL, sinon inutile d'être sous RAD Studio

ça se discute. Pas mal de gens préfèrent utiliser les classes de la STL pour des questions de portabilité et d'homogénéité du code. Perso je considère que la VCL a un grand interêt pour concevoir les fenêtres mais pour le reste c'est moins évident.

[ShaiLeTroll]

Merci de ta réponse Yarp

Pour la destruction par erase de la std::list, j'ai testé :
<class*> = pas de libération, heureusement
<class> = constructeur de copie et le destructeur de la copie, ne touche pas à l'original, donc parfait !

voir la doc de la méthode erase : "Erasing N elements causes N destructor calls", est peut-être un peu flou !

vector est donc plus proche de TList, reserve étant l'équivalent de Capacity

Pour une liste finie, autant prendre directement un tableau
J'ai utilise la TList, mon prédecesseur a utilise massivement la TList et des struct*


Se préoccuper de la portabilité d'un code avec RAD Studio, cela me fait bien rigoler !
Faudrait donc cloisonner son code,
une partie avec les strict standards C++ sans jamais aucune directive de RAD Studio,
une autre partie pour les IHM à base de TForm ...

Cela fait juste un code peu harmonieux, en fait pas du tout homogène, c'est de la perte d'énergie et de temps à mon avis !
Je suis développeur Delphi, en fait la VCL est la seul lib par défaut dans Delphi et je suis curieux de ton avis sur

mais pour le reste c'est moins évident.

c'est quoi le reste ?

[yarp]

> Pour une liste finie, autant prendre directement un tableau

Pas tout à fait. La différence entre un vector et un tableau est que vector est un tableau dynamique.
Si par exemple tu lis un fichier pour charger ton vector. Avec un tableau tu dois lire le fichier d'abord pour compter les éléments, puis relire une 2ème fois pour initialiser le tableau. Tandis qu'avec un vector tu fais tout en une seule opération.

> Se préoccuper de la portabilité d'un code avec RAD Studio, cela me fait bien rigoler

C'est vrai. Mais ce que je voulais dire c'est que ça permet plus facilement de partager des classes entre plusieurs projets. J'ai des projects CBuilder et Visual Studio, et les classes que j'utilise pour les 2 ont std::vector pour les collections et CString au lieu de AnsiString.

> Faudrait donc cloisonner son code
> c'est de la perte d'énergie et de temps à mon avis

je trouve que plus il y en a a l'exterieur de ces monstreux CPP/DFM et mieux c'est.
Si tu as une fiche avec un TTreeView et un TDrawGrid le logique interne de chaque composant ne regarde en général pas l'autre.Mais c'est vrai que ça demande du travail. Je ne le fais que pour les composants importants.

> c'est quoi le reste ?

Il y a des tas de composants non graphiques qui peuvent être remplacés par des librairies C++ ou du code maison.
En vrac: composants SMTP, common dialogs, TTimer, Themes, XML, TImage, TImageList, TBitBtn, le Custom Draw, TThread,...

[ShaiLeTroll]

Si par exemple tu lis un fichier pour charger ton vector.

On n'a pas la même définition de liste finie ! Dans ton exemple, la liste n'est pas finie, c'est une liste dynamique !
C'est pas grave, j'ai très bien compris ta remarque, et j'ai bcp bossé en Delphi sur l'anticipation d'allocation mémoire pour éviter les réallocations mais depuis FastMem inclu en 2007 qui a réduit le temps réallocations par 1000, cela n'a plus grand intérêt !

J'ai des projects CBuilder et Visual Studio !

Ah oui tu es courageux !
Personnellement, je préfère alors faire une DLL ou Objet COM, bcp moins de risque de faire des erreurs dans les sources partagées !
Mais je n'ai jamais mélangés deux environs de développement "compatible", en général, j'avais Delphi+Java ou Delphi+PHP donc utilisation des technologique appropriés comme les WebServices !

je trouve que plus il y en a a l'exterieur de ces monstreux CPP/DFM et mieux c'est.

On est d'accord, je dois maintenir un projet dont 95% est du code est dans le CPP/DFM, c'est horrible, ils n(ont jamais entendu parlé de la séparation des couches de Présentation et Métier (peut-être pas aussi extrème qu'un MVC mais quoi que !)
Même quand je codais tout en procédural, je faisais des unités séparées pour les types, les procédures de traitement et les TForm, je faisais une archi objet sans le savoir, je m'en suis rendu compte que bien plus tard !

Il y a des tas de composants non graphiques qui peuvent être remplacés par des librairies C++ ou du code maison.
En vrac: composants SMTP, common dialogs, TTimer, Themes, XML, TImage, TImageList, TBitBtn, le Custom Draw, TThread,...

Euh dans ta liste, il y a bcp de composants Graphiques ...

Pour moi RAD Studio c'est aussi pour son énorme VCL, je ne vois vraiment aucun intérêt de l'acheter pour ne pas utiliser sa librairie intégrée !

En même temps, je ne vois aucun intérêt à utiliser C++Builder * !
Autant utiliser Delphi directement, le langage est plus simple, la VCL a été écrite pour et avec Delphi, le seul soucis, c'est le manque de header ... qui avec les versions très récente de RAD Studio ne sera (n'est ?) plus un problème, on pourra inclure un .h C++ dans un projet Delphi et peut-être même un fichier .lib (il n'y a un équivalent en Delphi, il faut le header)

Je me suis amusé a intégrer une unité Delphi dans un Projet C++ 2007, c'est rigolo, cela génère le .h automatiquement !

*Lorsque j'ai fait cette remarque, pourquoi choisir C++Builder plutôt que Delphi, la réponse fut : "le modèle objet de Delphi est trop limitatif"
lol !
1- Ils n'utilisent pas d'objet !
2- Ils n'utilise pas la STL mais la VCL donc se limite au modèle objet de Delphi
3- En fait, Visual C++ était trop pénible pour les IHM, c'est la seule vraie raison valable !

J'ai failli bossé dans une boite où il codait les fenêtres en Visual Basic qui utilisait des DLL codées en Visual C++ !
Tout ça pour éviter WinForm je suppose !

[yarp]

> Personnellement, je préfère alors faire une DLL ou Objet COM, bcp moins de
> risque de faire des erreurs dans les sources partagées !

C'est un peu ce que je fais. J'ai des dialogues écrites en ATL/WTL dans des DLL que j'appelle depuis l'exe CBuilder. C'est comme ça que je gére les common dialogs par exemple.

> Euh dans ta liste, il y a bcp de composants Graphiques

Oui, aussi

> En même temps, je ne vois aucun intérêt à utiliser C++Builder

L'interêt c'est que le compilateur supporte le Pascal, le C++ et les librairies Microsoft (MFC & ATL) ce qui permet d'utiliser un grand nombre de librairies tierces qui sont pour la plupart natives C ou C++.
Composants Pascal, STL, ATL, WTL, libjpeg (je travail dans l'image),... c'est vraiment très souple.

> Je me suis amusé a intégrer une unité Delphi dans un Projet C++ 2007,
> c'est rigolo, cela génère le .h automatiquement

Oui, c'est ça qui est génial. On a un compilateur qui traite le Pascal et le C++ en même temps, c'est vraiment super.

Et puis je suis plus à l'aise avec le C++ qu'avec le Pascal.