Discussion :

[Invité]

Bonjour,

J'ai une application développée avec CBuilder 6, qui doit, à la fin du mois, être réécrite et améliorée sur une période courte. En gros on se donne six semaines à deux développeurs pour refaire entièrement une application d'environ 40 000 lignes de code (dense), et lui ajouter un certain nombre de modules et de fonctionnalités.

L'interface actuelle utilise les composants VCL standard (avec quelques dérivés maison) et un composant externe Virtual Treeview, de SoftGems, dont nous faisons une consommation importante. L'idée est de conserver ces éléments d'interface (apprendre un autre framework prendrait trop de temps), mais de limiter l'utilisation des composants non visuels de Borland, en leur préférant la STL (STLPort autant que possible) et Boost (à des fins d'évolution future). Par ailleurs, la question de la traduction du logiciel en des langues exotiques (unicode ou utf) est posée, et nous serons certainement amenés à éliminer au maximum le recours aux AnsiString dans les données...

J'ajoute que le logiciel n'utilise pas de base de données (il fait quelques requêtes à une base MS SQL externe), mais effectue des calculs lourds sur de gros fichiers binaires. Pour optimiser ces calculs, nous utilisons aujourd'hui AQTime 3.

Dans ce contexte, quelle version utiliser? CBuilder 6, Borland 2007 ou Borland 2009.

1- CBuilder 6, présente l'avantage d'être utilisé aujourd'hui, il n'y a donc rien à apprendre de neuf. En revanche, la VCL ne gère pas les langues multioctets, elle intègre une STL ancienne, mais des pans entiers de Boost ne fonctionnent pas (par exemple le lambda calcul, ou les regexp), et il est possible qu'on 'rate' certaines améliorations des versions suivantes

2- Borland 2007 semble assez proche de CBuilder 6, mais supporte mieux boost (est ce vrai?), même si elle utilise la STL de Dinkumware (peut on la remplacer?) Apparemment, elle présente assez peu de changements par rapport à Builder 6.

3- Borland 2009 est apparemment plus compatible avec Boost, et gére mieux les langues exotiques. Mais la conversion d'un projet CBuilder 6 n'est elle pas difficile? Quid de la portabilité de Virtual Treeview? Et puis, ca vient de sortir, est ce stable?

Question subsidiaire : quid du profiler? AQTime 3 suffit, une version plus moderne?

Voila, je suis à la pêche aux idées... Que feriez vous à ma place?

Merci d'avance
Francois

[Crayon]

Si ton projet risque de continuer de se développer au courant des années, je te suggère d'aller avec la version la plus récente. Éventuellement tu va sans doute avoir besoin d'utiliser des composants Vista car malheureusement de plus en plus de gens l'utilisent. Windows 7 va sans doute partager beaucoup de d'élément avec Vista. En plus, sans doute que la prochaine version ou révision va supporté le 64 bit, est-ce important pour vous si votre application fait beaucoup de calcul?

Il est certain qu'il y aura plus de modifications avec 2009, mais je pense que sa vaut la peine d'investir ce temps.

[Invité]

Merci beaucoup, Crayon,

Pour Vista, les utilisateurs sont en majorité de grosses entreprises, qui ont décidé de rester en XP. Avec la crise et la sortie annoncée de Windows 7, je pense que la plupart d'entre elles ne passeront pas à Vista. Donc, l'utilisation de composants Vista, je pense que ce sera pour la version suivante...

Le 64 bits, il faut y réfléchir, je ne sais pas dans quelle mesure cela va accélérer les calculs. En fait, je me souviens que lors du dernier "passage" (de 16 à 32) les moteurs de calcul ont souvent été les derniers éléments 16 bits des programmes, souvent parce qu'ils utilisaient des astuces liées à la représentation des nombres, ou des données stockées sous des formats liés à ces représentations. Dans mon cas, je vois une fonction de calcul qui gagnerait certainement à être refaite en 64 bits (un codeur arithmétique), mais c'est malheureusement une des fonctions les plus délicates de l'appli, et donc une de celle qu'on touchera en dernier (de peur de tout casser...)

Mais je retiens que si l'on change de version, il vaut mieux sauter 2007 et passer directement à 2009...

Il me reste trois semaines pour nous faire une religion, et bâtir la boîte à outils... Après, on oublie le débat et on assume.

Mais d'ici là, je suis preneur de tout autre avis...

Les utilisateurs de 2009, des bons points, des mauvais points, des souffrances, par rapport à Builder 6??

Francois

[say]

De mon côté, je suis également sous BCB 6, avec la volonté de migrer vers 2009....on a testé...et on a abandonné.

Beaucoup de nos composants tiers n'étant pas supporté. Je me souviens plus si c'était le cas du virtual TV que nous utilisons également.

Le plus simple, c'est quand même de tester,
1 - l'install des composants
2- la compatibilité du projet qui ne me semble pas tellement problématique.

De notre côté, pour migrer, nous allons devoir changer de composants dans certains cas...comme l'interface avec Crystal reports (qui a décidé d'abandonner la VCL....)

[Fbartolo]

Oui un des plus gros problème est bien sur la taille de certaines variables pour l'unicode mais ça vient assez vite et se corrige bien.
le second PB de taille est la compatibilté de certains composants tiers, non migrés ou migrés avec une syntaxe différente...
ça se fait bien mais peut être assez long, et il faut redérouler les tests de non régression.
Pour l'instant sur un projet moyen, nous comptons 1 semaine/homme de migration/tests.
pour l'instant la version la plus productive pour moi BCB6, la plus sympa RAD 2009.

Dans ton cas fait déja un tests sur les erreurs de compilation corrige certaines ligne ça te dira globalement combien de temps de correction.
mais je pense que 2009 est la bonne solution pour reconstruire ton projet, il faut "juste" estimer le temps supplémentaire maintenant pour gagner demain.

[Invité]

Merci beaucoup pour les réponses...

Je pense qu'on va jouer la sécurité, dans un premier temps... En gros, on se prépare à redévelopper en Builder6, tout en continuant de tester 2009.

Apparemment, la version d'essai ne permet pas de compiler facilement VT, le seul composant externe que nous utilisions, et l'idée de payer une version neuve juste pour voir si ca marche ne m'enchante pas (même si c'est mon entreprise qui paye). Y sont pas futés chez embarcadero...

Francois

[Invité]

Après quelques tests il semble qu'on s'oriente finalement vers une "non migration"...

Pour 2009, il semble effectivement que la version Trial ne permette pas l'installation de Virtual Tree View. Mais j'ai lu sur les newsgroups que ca marchait.

En revanche, nous avons effectué des tests sur 2007 (Pro, on en a une version). VT s'installe très facilement (la dernière version, du moins, après pas mal d'années d'absence, il semble que quelqu'un se soit décidé à reprendre la maintenance, et c'est une drôlement bonne idée!). L'environnement n'est pas mal : assez proche de Builder 6 pour n'être pas trop déroutant, la STL est passée de STLPort à Dinkumware (mouais... à des fins de "compatibilité Microsoft, allez comprendre!), pas l'ombre d'un Boost à l'horizon (en fait un certain nombre de librairies "header" fonctionnent, certaines ne marchent pas, et on peut compiler certaines des compilées...).

Ce qui manque, c'est un peu les trucs en plus... (en dehors de la compatibilité .NET, dont je me moque: c'est comme la CLX dans Builder 6, ça...) Il y a bien des classes supplémentaires dans la VCL, et des améliorations des composants existants, mais la doc sur le sujet est étrangement absente...

Là où ca se corse, c'est quand on veut porter un projet existant... D'abord, si mon cher Virtual TreeView compile bien dans les deux versions, il faut, en fait, utiliser un package différent en 2007 et en Builder 6... Oui mais... moi j'ai des composants maisons, dont un qui dérive de VT... Ah ben alors faut refaire le paquet...

Jusque là rien de grave... Sauf que... quand on refait le paquet et qu'on recompile l'application, ce bon 2007 prend note que certains composants VCL, dont dérivent mes composants, ont changé, et met à jour les formes en conséquence, en ajoutant de nouvelles valeurs par défaut des propriétés... et alors, forcément, ca ne compile plus sur Builder 6... L'application ainsi portée, et les composants maison qu'elle utilise sont maintenant séparés des autres apps maison (qui sont encore en Builder 6)

A l'inverse, une (grosse) application "pur Borland" sans composants maison, se porte en quelques minutes...

En pratique, ceci signifie (pour nous au moins) que passer en 2007 (ou 2009, je doute que ce soit différent) implique une rupture au niveau des composants maison (qui se mettent à exister en 2 version, suivant les programmes qui les utilisent).

La conclusion de tout ca : c'est qu'on va probablement démarrer sous Builder 6, en testant la nouvelle application sur 2007 au cas où... On n'a pas vraiment un meilleur produit sur 2007, et on perd la compatibilité (et la possibilité de réutiliser) avec les applications et composants maison builder 6...

Francois