Discussion :

[phpdev]

Bonjour,

J'utilise C++Builder 5 pour une trés grosse application (20 millions de lignes (certes avec les headers)). Les promesses de Embarcadero Xe2 sont interessantes. Les discussions que j'ai pu lire à ce sujet rejoigne la pub beaucoup de points positifs (accès base de données, comptabilité Win Mac etc... Xe3 ou Xe4 proposera même peut-être un compilateur 64bits!...)

Juste un petit oubli cependant. Le code source créé sous C++Builder 5 ne peut plus être compilé sous Xe2 à cause de la compatiblilité UNICODE pour les Strings. Il faut le dire, je l'ai dit à Embarcadero (4 mails à M LABORDE tous resté sans réponse).
Dommage, cela aurait été un plus par rapport à Visual Studio....

Quelqu'un a une solution ou dois-je créer un programme qui mette à jour mes programmes (si tant est que le seul blocage soit les String, peut être y-en-t-il d'autres mais je n'ai pas eu de réponse à ce sujet...)

[Andnotor]

Le problème ne vient certainement pas des strings pour lesquelles l'évolution à toujours été bien gérée, mais plutôt des fonctions utilisées. Appeler la versionA à la place de la générique par exemple

[ShaiLeTroll]

Ce n'est pas nouveau, depuis 2009, l'Unicode est présent !
Ce n'est pas un oubli ! il est vrai qu'en C++Builder, la migration peut être plus délicate que celle en Delphi à ce niveau : Activation des applications C++ pour Unicode

C'est un mal bien connu, c'est justement tout l'enjeu depuis 2 ans, oser passer le pas !
Il n'y a pas que cela qui a changé, mais aussi l'intégration ATL\COM par exemple !

Si tu reprends un ancien projet, normalement le mappage reste en char, pour un nouveau projet, il passe en wchar_t, c'est surtout pour les API qui passe de version A (ansi) à version W (wide)
Personnellement, comme j'utilise des AnsiString et du char, depuis 1 an, même en 2007, j'utilise explicitement les variantes A, en prévision de la migration vers XE2 !
Effectivement, on ne cherche pas a passer en Unicode, on a choisi de rester Ansi car le code contient partout des char* et AnsiString, et que tout changer, c'est hors de question, on rend juste le code compilable et fonctionnel !

Dans nos projets, nous utilisions le type AnsiString ou char* à 99% du temps pour les paramètres ou variables locales, le truc pas pratique surtout que souvent on a une AnsiString, on passe le c_str() en paramètre à la fonction, qui le recopie dans une AnsiString locale (souvent implicitement lors d'un passage de paramètre à une fonction VCL ou l'affectation à une propriété d'un objet)
Typiquement, toutes lectures de BDR est via les API avec du char* alors qu'il aurait été tellement plus simple d'utiliser un TRegistry et String du coup, on se traine du char* partout et personnellement, ça me gave un peu !

Effectivement C++Builder dans tous ces HPP utilise AnsiString, par habitude mes prédécesseurs ont utilisé le type AnsiString et non String, j'ignore si c'était la bonne chose à faire !
Mais vu la possibilité de changer le Mapping Ansi\Wide dans les options de projets, je pense que c'est une problèmatique classique en C++Builder !

En Delphi, le problème ne se pose pas, tous changent de A à W implicitement, si l'on a pas fait un code supposant la taille du Char, cela ne pose pas de problème !

En conservant l'ancien mapping, cela ne pose que peu de problème, juste quelques cast à ajouter pour manipuler les Caption, et remplacer AsString par AsAnsiString pour la DB
Idem, des milliers de fichiers, mon responsable a traqué les Erreurs et Warnings sur le type AnsiString
Avec quelques macros, on peut se débrouiller pour avoir un code compilable dans les deux versions (nous c'est 2007 et XE2, mais avec la 5 ça doit être possible aussi)
Je ne sais que mon responsable a migrer le code à sa façon, il y a plein de chose que je n'aurais pas migrer comme il a fait !
Typiquement les Application->MessageBoxA(Chaine.c_str(), ...) que j'aurais remplacé par MessageDlg(Chaine, ...)Pourquoi utiliser une variante char* et c_str(), alors qu'il existe une fonction String dans la RTL !

Il y a plein de code du genre où l'on utilise pas vraiment la RTL\VCL que mes collègues ne connaissent pas vraiment car ils sont développeur Visual C++ à la base et on continuer leurs pratiques MS et non Borland !
Moi avec mes 10 ans de Delphi dans les pattes ça me choquent un peu de se prendre la tête avec un code compliqué alors qu'une fonction Delphi le fait plus simplement !

Maintenant, si tu as utilisé dans du code C++builder les alias Char, PChar et String au lieu de char, char* et AnsiString, je ne peux pas me prononcer, là où je travaille ces types ne sont pas utilisés !
Leur changement implicite de A vers W doit effectivement te poser problème, peut-être que dans ce cas, tu devrais passer au Mapping wchar_t


Un autre point délicat, les conversions implicite depuis un AnsiString !
Par exemple, le TDateTime ne fourni plus de constructeur AnsiString mais UnicodeString, du coup, on a plus de conversion implicite
toutes les astuces syntaxiques du C++ doivent être remplacé par un code façon Delphi avec des fonctions de conversion explicite comme StrToDate !


D'ailleurs, même un code qui compile peu ne plus fonctionner, c'est ce que l'on a pour plusieurs de nos projets, des petits dépassement mémoire ou des troncatures sur le 1er 00 rencontré !

[phpdev]

Un grand merci pour toutes ces précisions. Mais n'oublie pas que cette application qui utilise c++Builder 5 est très volumineuse. Elle est née en 2000 (d'où l'utilisation de cette version). Elle a évolué dans le même contexte car impossible de prévoir quoi que ce soit dans les 10 ans à venir. Il me parait aussi difficile de la retoucher à chaque nouvelle version de c++Builder !
Je ne reproche pas à Embarcadero d'imposer de nouvelles normes qui font partie de l'évolution normale et très rapide de l'informatique. Le seul reproche est qu'il me semble légitime quand on impose une nouvelle norme, de faire en, sorte que les classes, fonctions ou procédures de la VCL soient compatibles d'une version à l'autre ce qui semble le cadet des soucis de Embarcadero (et de Microsoft aussi parait-il pour Visual Studio). Alors on peut trouver cela normal et faire en sorte de prévoir ces évolutions, c'est une idée compatible avec de petites applications où le temps de transcodage est réduit mais ce temps perdu existe quand même que l'appli soit grosse ou petite... Qui peut se payer le luxe aujourd'hui de perdre son temps ? Tous les développeurs aujourd'hui sont confrontés au même constat, il y a ceux qui acceptent et il y a les autres qui pensent que Embarcadero a une carte à jouer par rapport à sa féroce concurrence...

[ShaiLeTroll]

Eh bien, celle que je maintiens existe depuis C++Builder 6 aussi, il y a eu un passage en 2007 et aujourd'hui XE2 !
Plus de 50 Exe, 80 DLL et plusieurs serveurs DCOM ! Sans compter l'interaction avec des périphériques que l'on fabrique via RS232-COM, RS422, USB ou RJ45, tu te doute bien que l'on a pas changé nos protocoles 8 ou 7 bits !
En Delphi, inversement c'est plus embettant, comme le type Char est devenu WideChar, du code qui devait rester 8 Bits passe en 16Bits, il faut donc revenir pour forcer du AnsiChar !
En C++Builder, le char est resté 8 bits, c'est un soucis que l'on a pas !
Tu n'es pas le premier qui a du corriger et re-tester tout son code !

En fonction de la complexité du code, la migration est coût, ça fait presque 4 ans que l'on en parle avant même la sortie de la 1ère version Unicode, tout le monde savait que cela serait un challenge, je l'avais déjà mentionné en 2008 : Stratégie suite à changement d'OS et décisions à prendre
Tu sembles être un professionnel, tu réagis un peu tard ! non ?

Justement, plus l'on attend pour changer de version de l'IDE, plus cela devient difficile ! Je dirais même que ne pas suivre les évolutions c'est comme se tirer une balle dans le pied !

la VCL est compatible, le passage en UNICODE se fait généralement sans trop de douleur ! Justement, comme je le disais dans le sujet TFileStream et caractères bizarres, les fonctions comme StringToWideChar ou AnsiCompareText sont passé en UnicodeString, cela semble idiot au Départ mais justement cela permet de ne pas devoir remplacer tous les appels à cause d'une conversion implicite de Unicode vers ANSI !
Il y a eu des aménagements de ce style un peu partout !

En C++Builder comme le développeur peut écrire du code C++ ne respectant pas les normes Borland\Embarcadero, il n'est pas surprenant qu'il soit nécessaire de mettre le code au norme Delphi !
Je le vois où je suis actuellement, le code C++Builder ne respecte pas les règles du code Delphi, et comme par hazard, tous les code non conformes sont ceux qui doivent être corrigé !

[chaplin]

Tu sembles être un professionnel, tu réagis un peu tard ! non ?

Justement, plus l'on attend pour changer de version de l'IDE, plus cela devient difficile ! Je dirais même que ne pas suivre les évolutions c'est comme se tirer une balle dans le pied !

[TryExceptEnd]

C'est pour ça qu'une majorité de développeurs Delphi sont encore sous la version 7 ?
Je crois plutôt que c'est Borland qui c'est tiré une rafale dans les pieds avec les versions Delphi 8 est suivantes et maintenant Embarcadero est obligé de rattraper le temps perdu mais pour les développeurs le saut se fait dans la douleur.

[ShaiLeTroll]

C'est pour ça qu'une majorité de développeurs Delphi sont encore sous la version 7 ?

Je suis bien d'accord, 5 ans de perdu avec le .NET de m***e

Chez mon ancien employeur, cela reste LA dernière version de Delphi, il n'y aura jamais de migration ! Les logiciels seront migrés en PHP module par module !
Rien qu'achetez Licence IDE + Licence des bibliothèques tiers, ça faisait 10K€, Cela ne comptait pas le temps pour remplacer certaines lib comme HyperStr codé en ASM qui ne fonctionnerait plus en Unicode !
Si l'on rajoutait en plus, la correction des applications elle-même, cela montait !
Sachant que certaines applis était en 5, 6 et 7, chacune avec un Framework interne ayant évolué chacun de leur côté (selon l'humeur des Dev et des CP), tout plein de machine virtuelle pour générer telle ou telle application car une application ne pouvait compiler qu'avec une version précise de l'environnement (IDE, lib externe, lib interne, type de DB...)

C'est pourquoi j'en suis parti, pas d'avenir pour le client lourd chez eux !
Là où je suis avec la forte dépendance avec du matériel électronique, il y aura toujours une partie serveur bien sympa à gérer !

@phpdev, je te souhaite un bon courage, mon responsable travaille sur la migration depuis quelques mois, on a eu des surprises sur DBExpress, ça faisait presque 10 ans que l'on exploitait une DB censé être en cp863 mais qui ne l'était pas (en fait, j'étais le seul à l'avoir vu car j'utilisais le Viewer Sybase alors que mes collègues utilisent l'Explorateur SQL qui passait par ODBC)
On doit prévoir un outil de migration pour le recodage du CharSet de notre DB Sybase !
Tout ça parce que DBExpress\Sybase n'accepte plus un DSN ODBC mais réclame un vrai nom de DB !
L'Unicode n'est qu'un aspect de la migration, il y a d'autres surprises !

Perso, je n'ai pas encore récupéré le code migré pour XE2, mon autre collègue en chie trop ! j'attends d'avoir un code qui fonctionne bien en 2007 puis je migrerais !

Je peux même te dire que C++Builder XE2 est encore une Beta selon nous, il y avait des templates pour les objets COM qui ne compilaient pas (ça c'est grave, le code des templates était carrément faux !)
Quand tu dépenses 6K€ de Licence, tu l'as un peu mauvaise !
Il restait encore des soucis sur les Exceptions selon l'utilisation ou pas de la RTL dynamique et des paquets !
La Update3 ne corrige pas encore toutes les défaillances du genre !

Par contre, le C++ a subi de belle évolution dont celle du C++0x et des bugs corrigés comme Interface dont l'implémentation est réparti dans plusieurs classes
Un gros Bug dans la gestion de la VMT du TObject lors d'une utilisation d'Interface (class abstraite pure) a été corrigé en XE !
On peut saluer ce genre d'effort !
En 2007, j'ai du me taper des codes intermédiaires bien pourri (comme dans le TInterfacedObject avec les variantes _ des méthodes) pour compenser cela ! En XE2, je pourrais m'en débarrasser !

[chaplin]

C'est pour ça qu'une majorité de développeurs Delphi sont encore sous la version 7 ?
Je crois plutôt que c'est Borland qui c'est tiré une rafale dans les pieds avec les versions Delphi 8 est suivantes et maintenant Embarcadero est obligé de rattraper le temps perdu mais pour les développeurs le saut se fait dans la douleur.

Tout dépend comment sont gérés les projets, l'ouverture d'esprit des développeurs. Tous les projets évoluent quelque soit le langage. J'ai vu un projet PHP 4.X que mon prédécesseur ne voulait pas faire évoluer.

Si les types programment comme des cochons, le langage n'y est pour rien. D'ailleurs, à mon dernier entretien, la SSII voulait massivement migrer des projets écrit en Java en .NET, donc il n'y a pas de règle.

A celà, on ajoute les développeurs qui intégrent n'importe quel bibliothèque VCL pour enrichir sa culture professionnelle en ajoutant des technos.

Ces derniers, qui n'arrivent plus à gérer le merdier sont les premier à dire il faut migrer vers le langage du moment.

Ensuite, il y a les directions radines qui ne veulent pas investir dans les licenses mais qui sont prêts à mettre le paquet sur la table pour migrer et puis le projet version 2 prend du retard, coûte du fric parce que les gars qui disent de migrer ne sont pas meilleur CP ou développeur sur le nouveau projet. Je parle de vécu.

Il ne s'agit pas d'accuser un tel, juste un constat.

PS: ensuite, quand on arrive dans l'entreprise et que tout le monde se tire à boulet rouge, on fait ce qu'on peut, mais comme la catastrophe de Fukushima, le mal est fait et on cherche le premier bouc émissaire pour se déresponsabiliser.

[Andnotor]

Un peu facile de mettre la faute sur Embarcadero!

Ce serait en effet l'idéal de pouvoir simplement recompiler le projet et qu'il "s'adapte" de lui-même aux évolutions. Plus rien à faire à part empocher
Soyons sérieux! XE2 n'est pas un problème, le 64 bits l'est! Mais qui a réellement besoin du 64 bits?

[chaplin]

Ensuite, c'est une question de moyen, il faut faire auditer le code pour voir quelles sont les impacts lors de la migration et en profiter pour faire un "toilettage". Donner un avis sans savoir ce qui est dans le programme, c'est également se tirer un balle dans le pied.

En général, les directions mettent le strict minimum pour maintenir un programme et dépense sans compter dans un nouveau projet avec des rapports de 1 à 10 pour le dernier projet que j'ai vu, bref il y a de quoi être dégouté à la fin.

[Kristo2]

Vu que "Ne pas suivre les évolutions c'est comme se tirer une balle dans le pied!", j'ai pour projet de passer de C++ Builder 6 à la version XE2.
J'ai téléchargé la version d'essai, et mon plus gros problème c'est que je n'ai pas réussi à installer le composant ComPort, afin d'utiliser la liaison série RS232-COM.
Avez-vous réussi?
ShaiLeTroll, tu dis utiliser ce périphérique, peux-tu me dire comment tu as fais?
Merci

[ShaiLeTroll]

Tu sors un peu du sujet !
Je t'ai répondu dans TComPort pour CodeGear Rad Studio 2009, je rappelle que c'était une utilisation "One Shot", comme juste ce projet utilisera TComPort (je l'ai fait pour le découvrir, je ne l'avais encore jamais utilisé), je n'allais pas installer un paquet qui encombrerait inutilement mon IDE, j'ai donc fait une inclusion manuelle, facile en 2007, plus pénible en XE2 et même pas lié à l'Unicode mais surtout au compilateur Pascal dans C++Builder qui semble avoir changer !

D'ailleurs, il y a quelques mois, mon responsable au eu un probème de création d'un Package C++ Builder utilisant des Sources Delphi comme c'est le cas pour TComPort !
Mon poste et celui de mon collègue n'a que C++Builder d'installé, celui de mon responsable C++ et Delphi, il a donc construire BPL, BPI et LIB via un projet DPK Delphi que l'on intègre en C++Builder !

[Nono40]

Je suis bien d'accord, 5 ans de perdu avec le .NET de m***e

Je suis bien d'accord avec toi, là on je suis D6 est resté la version officielle très longtemps. D7 n'apporte rien et on se foutait royalement de .NET.

Nous sommes passés à D2010 car nous avons eu besoin de l'unicode pour certains clients. Dont un en Chine. Nous n'utilisons que peu de bibliothèqyes tierces, le passage D6->D2010 s'est fait sans trop de souci. Pour nos logiciels de gestion on était que peu lié au Char/String. le passage en Unicode est passé comme une lettre à la poste. Ce n'est pas toujours compliqué de migrer.

Coté logiciel de supervision, on en a profité pour tout refaire de toute façon, pour d'autres raisons : nouveau design, nouvelle fonctionnalités, BDE->DBX etc.

Tu parles aussi des communications RS/Ethernet. C'est aussi notre cas. La partie communication est dans un programme à part avec une interface maison avec les applications de supervisions. Et bien pour le moment la partie driver est restée en Delphi 6. Je sais que si je reprend cette partie je vais certainement en chier en peu plus .
Mais franchement pour le moment ce n'est pas utile, que les drivers de com restent en D6 ça ne pose aucun soucis. J'ai juste adapté la version de notre interface coté Delphi 2010.
PS : je n'utilise pas TComPort mais les API windows directement.