Migration d'un projet Borland Builder 5 C++ vers Qt ou VS

Bonjour !

Je souhaiterais faire migrer un projet développé sous borland Builder 5 C++ vers un autre IDE (Qt ou VS), aussi avoir vos avis sur la faisabilité ainsi que les différentes phases que vous pourriez me conseiller
j'ai commencé à me focaliser sur la conversion de borland c++ à Qt, dans un premier temps la VCL --> Ui(Qt), déjà essayé un outil DFM2QT, mais convertit 1/4 de l'ensemble des fichiers Dfm en fichiers Ui--QT.
Je viens à vous pour me proposer des outils existants, aussi vos opinions, idées, expériences ...

Merci d'avance !! :)

Bonjour,

je ne savais pas qu'il existait des convertisseurs.

Je vous résume mon expérience personnelle et mes conclusions qui ne prétendent pas être transposables. Le parcours de chacun dans ce genre de situation, l'expérience sont en effet déterminants. J'ai regardé un peu la chose et rapidement abandonné (le portage mais pas l'utilisation de Qt :P). Mon cheminement était le suivant Delphi/Lazarus -> C++ Builder -> Qt
La partie la plus facile fut la transposition Delphi/C++ Builder. Mêmes objets, même VCL, mêmes événements et même ordonnancement (du traitement des) méthodes.

"Malheureusement" Qt demande un raisonnement (et une conception des projets) de type asynchrone. C'est très bien expliqué dans le bouquin de Tristan Israël "Maîtrisez Qt5". Pour un Pascalien comme moi, cela a été une véritable prise de tête et parfois l'est encore. J'écris "malheureusement" dans la situation où je me trouvais... parce que désormais l'approche Qt me semble présenter de nombreux avantages au point que j'ai beaucoup de mal à m'en passer, qu'on m'entend souvent pester sur ce sujet à l'encontre de mon Delphi.... auquel je me refuse à renoncer tant qu'il continue à évoluer et permet de faire aussi bien (sous Windows :() même si c'est souvent au détriment de la facilité de développement et que cela devient vraiment fastidieux. J'utilise actuellement les 2 environnements avec au final, un degré de satisfaction équivalent, même si ces satisfactions (et insatisfactions) ne sont pas identiques d'un environnement de développement à l'autre.

Donc pour en revenir à notre sujet, l'approche est très différente et je considère avec le recul que d'être passé par C++ Builder pour aborder Qt a été une erreur de ma part. Je pense même que d'aborder le C++ avec C++ Builder en est une autre. C++ Builder, c'est un portage de Delphi en "C++" et évidemment ce dernier ne renie pas son ascendance. Pour rester "compatible", il a oublié un peu d'évoluer, plus exactement, a manqué de la liberté d'évoluer. Bref, que ce soit l'IDE (Qt Creator), les paramétrages de QMake, l'utilisation naturelle de la méthode asynchrone qui a fluidifié immédiatement mes programmes (un gros soucis sous Delphi/Lazarus qui réclame la programmation de nombreux threads pour résoudre le problème), l'utilisation des objets notamment graphiques de Qt, la (non-)gestion des exceptions (enfin pas telle qu'elle existe sous Delphi/C++ Builder), à mon avis, une large part des programmes est à réécrire aussi bien pour pour ne pas être déçu par le résultat, que pour... ne pas perdre de temps... si telle est votre volonté de basculer de l'environnement Embarcadero vers celui de Qt. Ceci dit, je me demandais pourquoi vous désirez réaliser cette migration ? Passage obligé vers Linux ? Vers Os X ?

Salut !

Je suis vraiment désolé de n'avoir pas pu vous répondre rapidement pour la simple raison que je croyais que j'aurais une notification de votre réponse par e-mail de façon automatique, hélas non :?
bon revenons à notre sujet, pour la raison du souhait de la migration, c'est que l’éditeur Borland C++ devient vieux, malgré qu'il marche bien, nous souhaitons faire migrer l'application vers un éditeur récent, toujours sous Windows.

Nous voulons à tout pris éviter de repartir à zéro, création des interfaces graphiques, fichiers sources, dlls, ..., et minimiser le plus possible les modifications à la main, il y'en aura beaucoup sans aucun doute, bref si ça peut nous gagner du temps car la taille de l'application de l'entreprise est grande (DLLs, Libs, c++/h fichiers, ...)

merci encore ! ;)

Actuellement je travaille avec Embarcadero xe (et le xe6 chez moi) en C++ pour une application IHM sous Windows (avec VCL)

Et en 3 mois, moi aussi je voudrais faire virer C++ Builder :mrgreen: parce que 1) Il n'y a pas de logs à part OputDebugString 2) Il n'y a pas de gestion de mémoire (utilisation, fuite mémoires, ...) gratuite et en C++ 3) Je commence en avoir marre de toutes les exceptions jetées par la VCL (mais cela c'est plus le code m*rdik que je dois maintenir :aie:)

La migration vers Qt (voire une autre bibliothèque) sans réécrire du code me semble impossible (*) :aie:.
Les raisons:

• VCL est une grosse surcouche de la bibliothèque win32, avec des tables de messages, des images BMP RGB, ... Qt c'est de l'objet partout :mrgreen: même les événements avec le moc
• VCL est une grosse surcouche de la bibliothèque win32. Qt c'est plus une approche avec des layouts partout (et en plus Qt te force à mettre des layouts partout jusqu'à en :vomi:). Rien que cela, c'est 100% de tes fenêtres à refaire.
• VCL c'est plus une classe par fenêtre dans laquelle on code tout notre bazar. Peut-être que tu as fais un peu de conception (des singletons, des managers, ...) mais C++ Builder tend plus vers du C++ dit "C with classes". Qt c'est de l'objet partout :mrgreen:
• J'ai du mal avec la notion d'ui de Qt (équivalent des fichiers DFM pour C++ Builder), parce que ta fenêtre c'est une classe ui qui est soit héritée soit mise en attribut (agrégation/ composition). Donc par rapport au code C++ Builder et si tu adoptes cette notion d'ui de Qt, il faudra découper en 2 toutes tes classes :mrgreen:
• VCL c'est du Delphi. Va adapter du Delphi en C++/ moc :mrgreen:

* -> Impossible à moins que tu aies isolé/ cloisonné/ séquestré (<- :mrgreen:) le code C++ Builder et que toutes les classes C++ Builder ne contiennent que les éléments graphiques (boutons, labels, zones d'éditiion, ...) et que tu les utilises via l'héritage.
En gros :mrgreen: ton code C++ Builder est pris en sandwich entre le code "bas niveau" (style des singletons, des managers, ...) et le code "'IHM" avec la logique métier/ IHM

Merci Foetus :ptdr: de m'avoir répondu !

Pour ce qui est de la conversion des dfm en ui, ça s'est plutôt bien passé ;), il faudrait juste apporter quelques modifications à l'outil,
J'ai aussi réussi à générer le fichier .h correspondant grâce à l'outil uic de Qt, après question signaux/slots ça va se compliquer puisque borland C++ utilise les events
je voudrais savoir si embarcadaero sur lequel tu travaille prend en charge la bibliothèque VCL ?
si oui, serait ce plus facile de migrer un projet sous borland c++ 5 builder vers son successeur :roll:

j'ai aussi lu que des bibliothèques VCL payantes déstinées à être intégrées dans microsoft visual c++ comme JVCL, TMC softwares

Encore merci :P

J'ai oublié aussi la relique du passé et qui pollue ton code C++ Builder :mrgreen:: les __fastcall :vomi:

Citation:

---

Envoyé par fouad122

je voudrais savoir si embarcadaero sur lequel tu travaille prend en charge la bibliothèque VCL ?

---

La bibliothèque VCL est livrée avec Embarcadero xe et xe6

Après est-ce que la bibliothèque VCL est gratuite? Elle est livrée avec un logiciel payant :mrgreen:

Citation:

---

Envoyé par fouad122

si oui, serait ce plus facile de migrer un projet sous borland c++ 5 builder vers son successeur :roll:

---

Je ne connais pas cette antiquité :mrgreen:

Citation:

---

Envoyé par fouad122

JVCL

---

Il me semble que tu confonds :whistle:. Avec Embarcadero sont livrées au moins les 2 bibliothèques VCL et FireMonkey

Mais il y a une énorme bibliothèque qui s'appelle la Jedi (<- lien :mrgreen:) et qui est composée de 2 bibliothèques: JVCL et JCL

Salut !

oui tu as raison en ce qui concerne les __fastcall, c'est un vrai problème, surtout si on veut faire migrer des dlls dans d'autres éditeurs

déja que tu me dit que la VCL existe dans les versions récentes d'embaradero, c'est une bonne nouvelle malgré que c'est payant, puisque la boite se projette vers n'importe quelle autre éditeur (Embarcadaero, Visual, Qt, ...), pourvu que la migration se passe sans problèmes majeurs, mais je laisse cette option pour la fin.

Là je me tourne sur l'étude de la solution microsoft VC++,j'ai trouvé encore une fois :lol: un outil permettant de convertir les *.DFMs en fichiers ressources *.RC, génére aussi un fichier *.hpp et *.cpp

Je ne suis pas trop à l'aise avec visual c++ :?, surtout une application de type win32 API, du coup, est ce que tu as une idée comment générer une exécutable à partir de ces fichiers ?
, et surtout les fichier *.RC, j'ai inspecté le code du fichier, il contient les ids bouton, boite dialogue ..., j'arrive pas à bien comprendre son fonctionnement

Merci encore !!

AhAHAh les fichiers .RC, ces antiquités ressurgis de la préhistoire :mrgreen: :mrgreen:

Je dis cela, mais actuellement j'utilise des fichiers .RC pour mettre les VERSIONINFO :mrgreen:
Tout cela parce que Embarcadero C++ Builder met les champs qu'il veut dans l'exécutable :evilred: Et aussi avec la version xe6 on doit les mettre 3 à 6 fois (32 bits et 64 bits, Release ou Debug ou Toutes configurations)

Sinon les .RCs comme les .DFMs ne sont pas fait pour être codés à la main: il faut utiliser l'outil WYSIWYG de Microsoft inclus dans Visual pour créer ces ressources et ensuite ils sont écrit dans l'exécutable.

Lis les tutoriaux sur Internet ;)

C'est vrai, la manipulation win32Api avec RC ça sera chaud quand même :aie:, déjà que l'outil de conversion en RC ne fait pas la conversion comme il faut, peut être que c'est à cause des DFMs en ma possession qui sont trop complexes, mais bon, si je pouvais trouver un truc qui me permettra de convertir en windows form c++ (Framework .Net), ça serait idéal ;)

je continue mes recherches là dedans en ce moment, si j'avance bien, je n'hésiterai pas à revenir :mouarf:

Merci à tout le monde ! :)

Bonjour Fouad122 et Foetus,

Fouad, je pensais que vous souhaitiez rendre votre plateforme multi OS. Visiblement votre objectif est le bon vieux Win32/64.

Alors dans ce cas, je ne suis pas d'accord avec beaucoup des argumentations employées et comme j'aime porter la contradiction :

Citation:

---

Envoyé par fouad122

déja que tu me dit que la VCL existe dans les versions récentes d'embaradero, c'est une bonne nouvelle malgré que c'est payant, puisque la boite se projette

---

C'est à mon sens erroné. Si on prend un contrat commercial (au mois), le prix de revient de Qt est équivalent à celui de XE7 architecte même avec l'achat de la solution de mise à jour.

Mais si on utilise la version gratuite de Qt 5, quelques points mérite d'être étudiés :

1. Développer en Qt linkage dynamic (seule solution non payante) est parfois délicat à cause d'un manque de portabilité entre versions Windows.
2. Il faut diffuser toutes les lib Qt. Ce problème n'existe pas avec XE7.

Je suis désolé d'utiliser les références d'un autre forum concurrent à developpez.net, mais il m'a précieusement aidé au début de ma quête Qt. Aussi n'activerai-je pas les liens. La non-utilisation du forum Qt de developpez.net reposait sur le titre totalement abusif (et trompeur) de Membre Expert que déjà je ne revendique pas en Delphi... alors débutant en Qt à l'époque... Je n'avais pas le droit d'ouvrir 2 comptes à cause de la Charte, et il n'y avait pas de solution simple pour enlever cette "qualification" liée aux points. C'est un forum professionnel. Il faut être sérieux. Donc je suis allé ailleurs comme "Débutant" sur un autre forum, le temps d'étoffer un peu mes connaissances. Bref, cet affublement dans ce forum n'est toujours pas pertinent mais je ressens moins le ridicule. Donc je participe.

Votre Delphi/C++ (je parle d'XE7) est vieux. Oui et non. C'est Windows qui est vieux. Le Win RT est un gadget. Ce qui fonctionne, c'est le bon vieux Win32 (porté en 64) avec ses API qu'on le nomme XP, Seven ou 8.1. Rien de neuf depuis longtemps. D'ailleurs mes programmes compilés en Delphi 7 (pas XE 7, mais bien l'antique Delphi 7) fonctionnent toujours sur mon Seven 64 bits et mon 8.1 sans aucune recompilation. Mais par contre, il est vrai que la conception est ancienne, que les composants sont parfois - parfois ! - limités : J'ai été épaté quand avec Qt, j'ai vu que nativement (avec des delegates) on pouvait afficher du HTML dans l'équivalent des Edits, Memos, Grids, TreeView... Mais TMS Software pour les add-on Delphi tient le bon bout !

Maintenant, j'exprime toujours une réserve : Les événements (Delphi/C++) et les Signaux/Slots (Qt) sont philosophiquement incompatibles. Est-ce qu'une des approches est meilleure que l'autre ? A mon avis, non. Evidemment un Pascalien comme je suis est consterné puis séduit par la simplicité qu'apportent les mécanismes de l'approche Qt... Mais je sais faire aussi bien en Delphi : j'utilise des threads et comme tout est fait "main", je fais ce que je veux. Le système automatique de Qt est plus simple SAUF quand on veut quelque chose de très particulier. Et là, c'est la galère... enfin il faut être un spécialiste.

Pour les layouts : match nul Delphi/Qt. Le système intelligent, ce sont les Lazarusiens qui l'ont élaboré.

Par contre, la factorisation du code et sa réutilisation sont également un point essentiel en terme de productivité. Lazarus/Delphi/C++ sont grands vainqueurs. Les Qtiens sont totalement dépassés: il est ridiculement compliqué et atroce de réaliser et même de dériver des composants pour l'installer sur la "palette" de Qt Creator ! Ils ont inventé un palliatif : la promotion... un concept interne aux projets, très inférieure à l'usage des composants de Borland.

Vous ne développez que sous Windows ? Donc, le fait que XE7 permettent de cross-compiler vers OS X, Androïd, iOS mais pas Linux alors que Qt le fait sans cross-compilation en OS X et Nux n'intervient pas dans votre choix. Cependant pour avoir testé sous Androïd, les 2 environnements, quel plaisir pour un non-spécialiste comme moi d'utiliser Delphi. Comme la gestion de l'HTML avec Qt, Androïd avec Delphi m'a épaté. Ce point n'a aucun impact dans votre décision.

Alors techniquement, compte tenu des motivations formulées, je ne pense pas que Delphi soit dépassé surtout si on lui adjoint les composants nécessaires et innovants (TMS Software, Dev Express...). Au niveau de la productivité, même si mon niveau Qtien n'atteint pas celui de Delphi, je suis persuadé que penser que le premier est capable d'atteindre celui du second est pour moi une plaisanterie !

Question puissance (voire solidité), aucune suspiscion ne peut être émise à l'encontre de Delphi/C++ sous Win32/64 puisqu'il peut utiliser les API de Windows.

On peut faire remarquer que Delphi/C++ FMX (celui utilisé pour OS X et les mobiles) est moins complet que le vieux Delphi/C++ VCL. Certes, mais c'est parce qu'il est jeune et franchement pratiquement presque toute la couche métier est portable de l'un à l'autre, et une partie des composants...

Je n'utilise pas C++( Builder) ou très peu... mais beaucoup Delphi pour lequel je n'ai pas toujours la dent tendre. Je suppose que les 2 permettent la même chose. J'ai 2 reproches à faire à Delphi.

• L'environnement graphique Linux ne lui est pas accessible.
• Je n'aime pas -mais vraiment pas la cross-compilation- dans les OS Desktop. Que ce soit Lazarus ou Qt, le fait que l'IDE existe dans les 3 OS est d'un confort incomparable.

Reste la perrenité de Delphi/C++ Builder... et celle de Win32/64. Pour le premier, cet IDE représente une niche sur le marché. Il n'y a ce niveau aucune certitude en effet... mais malgré de nombreuses péripéties, il est encore vivant. Et pour le second, on attend le successeur de feu Win RT 8-)

Question VS, je ne connais pas du tout.

Cordialement. Gilles

C'est justement ce que je reproche à Embarcadero (en plus de la vieillissante Win32 qui a certes une énorme compatibilité ... en attendant Windows 10 :whistle:)

Par défaut c'est de la m*rd* (*) et il faut ACHETER EN PLUS 1 ou 2 énormes "machines de guerre" :aie: :aie: ... et ceci en plus de tous les petits trucs gratuits: Jedi, MadExcept, ...
Et encore, il y a aussi AQTime qui semble ne pas être mal mais vu le prix :aie:

Style, ton vélo ne te suffit pas pour aller au travail, prends un Antonov An-225 :ptdr: :ptdr:


* -> Le nombre de fois par jour que Embarcadero C++ Builder fige quelques secondes parce qu'il est mono threadé :roll:.

Rebonjour,

Lourd, léger, machine de guerre ? Est-ce que VS 2013 est léger... L'installation est longue....et encore je n'ai installé que la version Express sur un un Windows 8.1 neuf. Plus Qt derrière... Mais Delphi, c'est long aussi. Windev, moins long et l'installation la plus rapide est celle de Lazarus :roll: C'est la seule certitude sur lourd/léger que j'arrive à formuler. C'est plus ou moins lent en fonctionnement ou à la compilation (génération pour Windev) des projets, mais dans tous les cas acceptables. On peut aussi éventuellement parler de la compilation de l'IDE : géniale et rapide pour Lazarus, longue, difficile et périlleuse pour l'environnement Qt, non nécessaire pour Delphi/C++ Builder et Windev. Et à mon avis, ce sont toutes de bonnes "machines" de développement avec leurs points forts et leurs limites.... mais ils sont connus et annoncés. Il ne faut pas non plus oublier à ce niveau l'incidence des modes et des besoins de renouvellements paraît-il "obligatoires"... mais non nécessaires à mon avis en ce qui concerne Windows qui comme je l'ai écrit a peu évoluer en réalité au niveau des APIs.

Je ne dis pas que Qt est intrinsèquement inférieur, ou VS... ou que Delphi/C++ est inférieur. L'objectif de production est une variable déterminante.

Pour Windows 10, on verra. Mais peut-on imaginer Microsoft se séparer d'un seul coup de Win 32 ? Ce serait un suicide commercial. Il n'y a pas de problème de pérennité de Win32. La valeur d'un PC, ce n'est pas que son OS. D'ailleurs, il ne représente qu'un coût modique ; mais ce sont tous les logiciels qui tournent sous cet OS qui lui confèrent son utilité. Alors demain vous rendez inutilisables (incompatibles) tous les CRM qui fonctionnent sous Win32, je me demande combien de clients vont acheter le nouvel OS incompatible.

Pour développer spécifiquement du Win32/64, je préfère (encore) Delphi (c'est vrai, je bénéficie du prix modique d'une licence Education) à Qt (mais je pense toujours que Qt Community est entre autre un bon produit d'appel pour les futurs Clients de Digia)... et j'apprécie également beaucoup Windev (là, je paye plein tarif). Qt, j'ai commencé avec Qt 4.8 et sa QFtp... obsolète dans Qt 5, mais "bidouillable". C'est extrêmement chronophage. Ce n'est pas le seul problème rencontré. J'en ai déjà évoqué d'autres de manière non exhaustive. Malgré tout, j'apprécie beaucoup. En usage professionnel, comment rétablit-on la productivité ? On peut penser qu'un développeur Qt est aussi rapide et productif qu'un développeur Delphi... à ancienneté égale. Le problème c'est que passer de C++ Builder à Qt, n'induit pas le transfert des connaissances. Déjà, utiliser des utilitaires de conversions est à mon sens un mauvais signe... quand on écrit ses propres programmes et j'estime que c'est une perte de temps à terme. On va vite au début, mais la conversion est approximative. Réécrire un UI avec plein de layouts imbriqués sous Qt Creator, c'est certainement pas si facile et immédiat que cela. Je ne parle pas du couple signal/slot qui est imposé nativement. Donc dans la configuration de Fouad, je perçois une antinomie : visiblement, il est pressé, et tout aussi visiblement, il est imprégné des automatismes qu'imposent l'environnement Borland qui sont vraiment totalement différents de ceux de Qt. J'en ai fait l'expérience. C'est très instructif, enrichissant... et pénible. Le "passage" de Delphi à Qt m'a permis d'accepter... FMX:mouarf: et évidemment Qt (et le C++). Et j'ai pris conscience également qu'en développement multiOS, Lazarus était très en retard au niveau des objets graphiques même si j'estime que son environnement est aussi pertinent -même plus- que celui de Qt/C++.

Ce n'est pas l'un ou l'autre des environnements qui est lourd. Il répond à des contraintes différentes. Je trouve inappropriée cette affirmation que Embarcadero est lourd : mes projets fonctionnent tous sur Delphi, Windev et Qt avec leurs particularités évidemment (pas de Nux avec Delphi, gestion incomplète du HTML, des incompatibilités avec Qt entre versions Qt ou entre compilateurs utilisés, Windev que Windows et des limitations dans le SQL...). Le problème abordé ici c'est le passage de l'un à l'autre. Que fait Qt ou VS que ne pourrait pas faire Delphi ? Rien. Le portage de C++ Builder à C++/Qt est-il envisageable ? Oui. Avec peu de connaissance Qt ? Pas rapidement, il va falloir les étoffer. Cela sera chronophage parce que très différent et donc pendant ce temps-là la production sera limitée, probablement approximative au départ...

C'est très rassurant d'entendre les différents avis et expériences de vos part, ça ma permis d'en apprendre plus sur le sujet ;)

je partage ton point de vu gilles, les outils d'automatisation, c'est une mauvaise idée:calim2: et ne permettent pas de convertir tous les *.dfm en *.UI, et ceci sans problèmes :roll:, mais, je serai amené au moins d'en utiliser un qui me permettra de faire le travail partiellement, car le projet à convertir contient des milliers de fichiers *.dfm, et créer un par un le gui, et tout seul ! (Ui pour QT par ex) serait fastidieux, donc j'ai répertorié un ensemble de composants VCL non convertis afin de de les inclure lors de la modification du code source du programme de conversion (autorisation de l'auteur biensur :D), ainsi relancer la conversion

Je me tourne aussi vers d'autres éditeurs du marché, car, je suis amené à faire une étude lors de mon stage, qui dans un premier temps, d'avoir un aperçu de la faisabilité, s'il existe des outils permettant de faciliter la conversion, migration des DLLs aussi, ...

C'est vrai que je ne me préoccupe pas trop sur les avantages en terme de prix ..., car tout simplement, c'est de loin de mes compétences :ptdr:, je n'y connais rien :ptdr:, pour ça il faut que je consulte des personnes compétentes pour ça, comme vous, maître de stage, forums.

Là actuellement, je suis dans une phase de recherche, où chaque piste est prise en compte :)