Discussion :

[free07]

Bonjour

J'espère que je pose ma question sur le bon forum ( car je suis sur Builder C++ avec RAD Studio XE2 update 4 )
Voila, j'ai un problème de compil lorsque je cible l'OSX.
Le compilo me dit qu'il ne trouve pas vector.h, est ce que cette librairie n'est pas utilisable pour le mac ?
J'ai fait des recherches sur le net et j'ai trouvé qu'un lien qui en parle et qui utilise la librairie vector, mais il a juste un problème de lien, en compilation ça passe et il est en update 1 :
http://stackoverflow.com/questions/7...for-os-x-fails
J'ai fait maintes recherches dans la doc d'embarcadero, ils précisent que l'on peut utiliser la rtl ou plutôt les rtl ( c et delphi ) et si je vais voir dans $(BDS)\include\osx\crtl, effectivement, il n'y a plus de vector.h !?

J'utilise les vecteurs pour gérer des listes d'objets, peut être qu'il va falloir que j'utilise plutôt les TList car c'est multi-plateformes, n'est ce pas ?

[ShaiLeTroll]

Quel est le type de données ?
Pense que la RTL de C++Builder contient des conteneurs spécifiques plus facile à manipuler si coupler avec FMX ou la VCL

Pour tout ce qui est TObject, il y a les TObjectList par exemple !
J'ai pour ma part, fait un mini template basée sur la TObjectList pour m'éviter le transtypage des Items

Attention en XE2, il y a celle de Boost et Dinkumware
J'ignore totalement la différence !

En mettant ton include comme ceci #include <vector> et en ayant défini correctement les fichiers d'inclusion dans les options de projet, il choisi la variante la plus approprié (selon directive, c'est franchement tordu le code de la STL)

[free07]

Quel est le type de données ?
Pense que la RTL de C++Builder contient des conteneurs spécifiques plus facile à manipuler si coupler avec FMX ou la VCL

Pour tout ce qui est TObject, il y a les TObjectList par exemple !
J'ai pour ma part, fait un mini template basée sur la TObjectList pour m'éviter le transtypage des Items

Les données sont des structures ou des classes que j'ai crée, il me faut gérer dynamiquement des listes sur ces structures ou ces objets, il n'y a rien qui est dérivé de TObject.

Attention en XE2, il y a celle de Boost et Dinkumware
J'ignore totalement la différence !

En mettant ton include comme ceci #include <vector> et en ayant défini correctement les fichiers d'inclusion dans les options de projet, il choisi la variante la plus approprié (selon directive, c'est franchement tordu le code de la STL)

j'ai bien mis #include <vector>, je vais regarder du côté des options du projet, j'y ai pensé puis j'ai zappé...
Merci pour ton aide Shai

[ShaiLeTroll]

il n'y a rien qui est dérivé de TObject.

Pourquoi utiliser C++Builder et FMX si tu ne te conformes pas à la RTL C++ Builder entièrement basé sur le TObject !

Surtout que tu perds la propriété Objects de la TStrings donc dans les Combo, List, Grid ... qui permet de simplifier la gestion de l'IHM en associant des objets (métier ou middleware) qui garantissent un comportement stable et rigoureux !

95% de mes objets héritent du TObject !
Déjà, parce que je suis développeur Delphi à la base, et que je peux ainsi exploiter la RTTI Delphi pour mon OR Persistence, la VMT de TObject à place de celle du C++, la zéro init implicite du TObject...


Après, j'ai effectivement des sous-types privés struct ou class, que je couple avec surtout avec map (type manquant dans la RTL Delphi en 2007 et les génériques Delphi semblent pas franchement compatible C++) ainsi que des vector, en plus je bénéficie ainsi du RAII des mes TCriticalSection pour mes membres en allocation statique

[DjmSoftware]

Hello
je suis un peu étonné par cette déclaration:

Pourquoi utiliser C++Builder et FMX si tu ne te conformes pas à la RTL C++ Builder entièrement basé sur le TObject !

on pourrait alors égalememet se poser la question suivante (en étant un tantinet provocateur):
pourquoi utiliser C++ Builder alors que Delphi permet de faire les mêmes choses?

j'ai pour ma part une autre approche : C++ Builder à la différence de Delphi permet également d'utiliser d'autres bibliotèques standard du C++ (STL,BOOST,....)
de part la structure même du langage il est également possible de faire de l'héritage multiple rendu uniquement possible en delphi comme en C# d'ailleurs de part l'utilisation d'interface.

je ne saurais conseillé à free07 que si son problème persiste d'ouvrir un case chez embarcadero (Quality Central).

cdlt

[ShaiLeTroll]

Désolé, free07, ton sujet va être détourné !

Pourquoi utiliser C++Builder et FMX si tu ne te conformes pas à la RTL C++ Builder entièrement basé sur le TObject !

Disons, que si l'on utilise C++Builder c'est pour profiter principalement de l'IDE, la VCL et la RTL Delphi !
Le code que l'on écrit s'oriente forcément vers les objets du Framework comme les plus classique TForm ou TDataSet

Par contre, pour certains passages, il se peut que cela soit plus approprié d'utiliser la STL car la RTL Delphi ne fourni pas ce qu'il faut ou est moins performant par rapport au classique map ou vector

L'un n’exclut pas l'autre !

[MODE TROLL ON]

pourquoi utiliser C++ Builder alors que Delphi permet de faire les mêmes choses?

Je te le confirme, je me pose la même question, pourquoi mon employeur a choisi C++Builder !

également possible de faire de l'héritage multiple rendu uniquement possible en delphi comme en C# d'ailleurs de part l'utilisation d'interface.

Tu es un vrai provocateur , tu oses nous sortir l'argument du "Héritage multiple"


Tient c'est un argument que mon responsable a utiliser pour le choix de C++Builder !
Un argument qui ne tient pas, vu la méthode de programmation non objet qu'il pratique !
Car dans le projet que je maintiens qu'il n'y a très peu d'objet, encore moins d'héritage alors si en plus il était multiple ...
Et lorsqu'il y a un peu d'abstraction, cela hérite d'une TForm du coup, plus d'héritage multiple !

En Delphi, il y a la Délégation, faut-il rappeler que l'héritage multiple ne fait pas parti des Design Pattern !
L'héritage multiple est le plus court chemin pour l'anti-pattern : Objet Divin


Mais effectivement, C++Builder a un avantage, c'est de pouvoir inclure de nombreuses lib parce que les Headers manquent en Delphi !


Perso, je n'arrive même pas à y penser, je fais même l'inverse, je divise des objets pour découpler au max les dépendances !
J'ai justement un TODO pour séparer la "OR Persistance" actuellement lié à la DB en une persistance plus générique (Ini, XML ou binaire)
Et donc, je vais justement "déléguer" la sérialisation à un objet abstrait (avec plusieurs implémentations possibles)

En même, temps, j'utilise pas mal les interfaces depuis un an pour un système ultra générique de gestionnaire de périphérique !

[MODE TROLL OFF]

Cela sera ma dernière intervention dans ce sujet

[free07]

Hello

je ne saurais conseillé à free07 que si son problème persiste d'ouvrir un case chez embarcadero (Quality Central).

cdlt

Bonjour DjmSoftware

Je crois que je vais effectivement ouvrir un case car j'ai vérifié les options des chemins d'inclusion et cela m'a l'air correcte, dans outils options, il y a les chemins de boost et dimkumware et osx...
Dans les options du projet, les chemins ont la case 'hériter' de coché. Bien que l'aide est trés sommaire, je ne vois pas ce qu'il manque comme chemin

[free07]

Pourquoi utiliser C++Builder et FMX si tu ne te conformes pas à la RTL C++ Builder entièrement basé sur le TObject !

Surtout que tu perds la propriété Objects de la TStrings donc dans les Combo, List, Grid ... qui permet de simplifier la gestion de l'IHM en associant des objets (métier ou middleware) qui garantissent un comportement stable et rigoureux !

Cela demande réflexion et je ne vois pas à quoi sert la propriété Object de TStrings, si tu a un exemple ou un tuto qui en parle, n'hésites pas à me le signaler, merci

[ShaiLeTroll]

Cela dépend énormément de ton style de programmation mais aussi du
volume de Données

Je fais souvent de l'OR Persistence, c'est à dire qu'un objet me permet d'accéder à mes données, il veille à la cohérence lors de l'enregistrement ...

Si petit volume (moins de 1000), tu peux te permettre de créer un objet par enregistrement, en recopiant les données dans les objets
Si volume moyen (1000 à 10000), là, vaut mieux stocker un ID ou un Bookmark
Si volume important (>10000 à plusieurs millions), il évident qu'il est impossible d'afficher autant de données d'un coup, il faut scinder (on en revient à un volume moyen voir petit)

Pour le volume moyen ou important, j'utilise le même objet qu'en petit volume mais comme curseur, il n'a pas de données interne et encapsule un TDataSet
Je n'ai qu'un seul objet, c'est le déplacement dans la TDataSet qui me fourni les données
Ainsi, j'ai une DBGrid, je sais que mon objet est en phase avec le DataSet, je peux directement invoquer des méthodes de l'objet qui utiliseront les données en cours

Pour la Propriétés Objects[] de TStrings !
J'ai toujours trouvé qu'il manquait une propriété Data, simple void* plus ouvert que TObject et Tag integer pour éviter ce genre d'astuce pratique mais dégueux : Combobox - renvoyer une valeur pour stocker un ID

Donc, cela te permet pour une Combo d'associer à chaque ligne, un objet contenant par exemple une chaine (code dans une DB) ou un integer (PK de la DB)

Evidemment, il existe la TDBLookupComboBox permettant d'avoir un DataSet de donnée et un DataSet de liste !
Mais quand ce n'est pas possible de l'utiliser, il faut se débrouiller autrement !

Idem pour chaque Cells d'un TStringGrid !
Tu remplis une TStringGrid depuis un fichier ou une DB, tu affiches un texte mais pour chaque cellule, tu peux mémoriser un Bookmark vers la DB ou vers un offset dans le fichier

Idem pour un TTreeView, cette fois c'est Data void* car c'est une fonctionnalité qui vient directement de l'API Windows !
Même principe, tu remplis ton TTreeView, dans le data tu mets un struct contenant un ID et d'autres info !

La plupart du temps, cela t'évite d'avoir un vector ou une TList que tu dois boucler pour associer la Caption pour retrouver les données que tu as besoin pour faire fonctionner ton programme

Objets[] est souvent peut utiliser, j'ai souvent vu des codes avec une TListBox, TComboBox ... couplé à une ou plusieurs TStringList ou int[] utilisant les mêmes index !
Avec des listes, cela complique les tris, il faut s'assurer soit même que l'on a bien mis les listes dans le même ordre que le Items de TListBox
Avec Objects[], si l'on tri avec un TListBox.Sorted, cela reste cohérent, les Objects[] restent associés avec leur Strings[]

[free07]

Bonjour à tous,

J'ai eu la réponse d'embarcadero en fait, l'utilisation de #include <vector.h> est obsolète pour fmx ( multi-plateforme ), il faut utiliser #include <vector> à la place !

[ShaiLeTroll]

obsolète ? Ah bon ! seulement ?
Je pensais qu'il était obligatoire d'utiliser #include <vector> !
Je ne fais du C++ que depuis 18 mois, j'ai suivi tout simplement la Comment créer et utiliser un tableau avec std::vector ?

En fait, j'avais donné la bonne réponse et son explication dès le début

[free07]

En fait, j'avais donné la bonne réponse et son explication dès le début

Ha oui !!! j'avais même pas remarqué que tu n'avais pas mis le '.h' sur l'include

C'est comme ce matin, je viens de me rendre compte que l'on peut pas développer pour l'iOS avec Builder C++, c'est apparement réservé à Delphi et cela fait 20 ans que je n'ai pas programmé en pascal ou pascal objet, s'il faut que je me mette à Delphi, c'est du boulot !!!