BC++5.02 et OWLnext

[jibe74]

Bonjour,

Je dois faire évoluer une application écrite sous BC++5.02/OWL qui tourne encore sur un poste W98 (!!!) afin qu'elle puisse fonctionner sous les versions actuelles de Windows.

Je pensais remplacer OWL par OWLnext, mais j'ai quelques difficultés avec des .h d'owl qui n'ont pas été installés avec OWLnext, et je ne trouve pas de tuto expliquant comment migrer d'OWL à OWLnext. J'hésite à prendre les .h d'OWL pour les utiliser avec OWLnext...

Si quelqu'un connait, j'aimerais :
1 - Savoir si les .h qui me manquent sont dûs à une mauvaise installation (j'ai pourtant suivi le wiki d'OWLnext) ?
2 - Savoir comment effectuer cette migration.

S'il y a une autre alternative évitant de réécrire une bonne partie du code, je suis preneur également.

Merci.

[adanteny]

Bonjour,

le thread étant un peu vieux...y'a t-il eu une réponse?

[chris384421]

bonjour,

je tombe sur ce message par hasard, de plus il est un peu ancien, mais mon expérience en la matière peut aider d'autres personnes, ayant réalisé récemment la mutation d'une application OWL5 vers OWLNext de BC5.02 vers MSVC9

voici donc quelques conseils :
-surtout ne pas mixer les .h ou .cpp entre OWL5 et OWLNext, chaque reference a un ancien .h peut etre accepté comme le nouveau .h : le seul ajout peut être d'inclure (dans les cpp) un "using namespace std"
-il n'est pas nécessaire de réécrire tout le code cependant quelques retouches sont à faire : la variable globale "Module" se nomme désormais "gModule" (il est question dans les prochaines versions de OWLNext de faire machine arrière...), les points d'entrée des bibliothèques se nomment différemment (DllMain/DllEntryPoint),...et quelques autres détails
-Un point IMPORTANT est la STL qui même si il est prévu une émulation, est carément à réécrire (quelques lignes de templates font l'affaire et se substitue (sauf si on a fait un usage de nombreuses et diverses structures avec des allocateurs différents...etc)
-LE POINT le plus important est le problème des flux qui sous BC5 se comportent différemment du standard actuel et constitue de ce fait le point d'achoppement : les flux avaient des comportements différents suivant le type de flux (fichier, chaine...), ce n'est plus le cas (heureusement) avec le nouveau standard, par ex la base par defaut était 0 (style C) alors qu'elle est à 10 maintenant...
-LE SECOND POINT important est le problème des "string" qui était une classe également différente de la nouvelle classe "string" : deux solutions : soit rectifier les fonctions qui différent, soit substituer au code ancien "owl_string" à la place de "string"

Enfin, le compilateur BC5 était trés ancien (93), et les "const" n'étaient pas pris correctement en charge, ni les exceptions (et autres) ce qui suppose pas mal de corrections lors du passage, et les différences entre compilateurs (MS/BC/GNU) existent toujours et sont toujours sujettes à générer de nombreuses erreurs.

En conclusion, il faut vraiment souspeser le pour et le contre lors d'une telle opération, ou avoir envie de patauger dans les tréfonds des compilateurs, de nettoyer tout en apprenant beaucoup sur les + et les - de chaque compilateur.

bon courage!

[jibe74]

Salut,

Je retombe par hasard sur ce fil que j'avais oublié depuis longtemps !

J'avais fini par trouver réponse à mes questions, et je pense que chris384421 résume assez bien la situation.

Envoyé par chris384421

En conclusion, il faut vraiment souspeser le pour et le contre lors d'une telle opération, ou avoir envie de patauger dans les tréfonds des compilateurs, de nettoyer tout en apprenant beaucoup sur les + et les - de chaque compilateur.

Tout à fait ! Dans mon cas, c'était une application assez complexe et cette migration s'est avérée payante. Mais pour une application plus simple, j'aurais certainement eu avantage à la ré-écrire !

A noter que j'ai bien apprécié l'aide efficace que j'ai obtenue sur le newsgroup d'OWLNext.

[bcag2]

ce lien peut éclairer avec explications en 6 étapes
http://owlnext.sourceforge.net/old/article14.htm