Discussion :

[Invité]

Indirectement, la conséquence de l'activité un peu frénétique de Boost ces derniers temps est que les compilateurs qui ne sont pas supportés correctement (c'est à dire tous sauf VC++ et gcc, malgré la liste des compilateurs dits "supportés", qui se contentent de sous-ensembles plus ou moins minuscules) ont de moins en moins de chance de survie. Dommage pour Embarcadero... faudra vivre avec rien que Delphi, ou bien supporter Boost franchement nettement mieux.

Bah, ca me rappelle un de mes patrons, qui en 1998 annonçait la mort imminente de Borland, et pronait le passage sous Visual. 10 ans plus tard, l'environnement existe toujours, mais le produit concerné, lui, n'a pas survécu à cette indispensable migration...

Sérieusement, dans un très grand nombre d'entreprises, la compatibilité Boost (et surtout la compatibilité "dernière version") est assez bas dans la liste des priorités, tout comme le respect des nouvelles fonctionnalités du standard. Embarcadero a fait un geste en intégrant une version pas trop ancienne de Boost dans 2009 et 2010, je ne crois pas que ses utilisateurs en demandent davantage.

Embarcadero/Codegear/Borland n'est pas choisi parce qu'il respecte la norme (ca n'a a peu près jamais été le cas) mais parce qu'il permet de faire de l'interface rapidement, en C++ (et pour rester compatible avec de l'existant). Cela fait quelques années qu'on annonce sa disparition, et quelques années qu'on a tort. Et puis, on a connu une époque où c'était Visual qui respectait mal la norme...

A mon avis, ce qui compromet la survie de ces outils, c'est plutôt leur coût, le fait que les versions récentes n'étaient pas toujours bonnes, et l'apparition d'alternatives à la RAD "à la Delphi" pour le développement d'interface... Boost, je ne crois pas.

Francois

[ac_wingless]

Attention, BCB prétend supporter la version 1.39, ce qui serait excellent et totalement satisfaisant pour la majorité des entreprises ... si seulement c'était vrai. Chez nous par exemple, je me contenterais même de 1.35, qui est l'état validé actuellement dans nos lignes de code VC++. Je vois mal une entreprise être à la pointe et suivre Boost à 2 mois près, ça n'a pas beaucoup de sens.

La vraie raison de la demande de Boost dans les environnements de création RAD est la compatibilité avec le code non-UI qui, lui, profite largement et naturellement de Boost, ce qui n'est évidemment pas le cas du code UI.

Malheureusement, quand le cœur de métier n'est pas l'UI, c'est le support de Boost qui va faire la différence: si l'environnement RAD n'est pas capable d'avoir du code en commun avec les lignes de code principales, alors c'est l'environnement RAD qui est remis en question, pas Boost. Bien évidemment, utiliser du C++/CLI avec Winform pose ses propres problèmes: nous n'envisageons toujours pas d'utiliser VC++ seul. Il est vrai qu'une fois qu'on a gouté à la productivité exceptionnelle de BCB, on se voit mal revenir sous MFC ou Winforms.

Dans l'état actuel, le support catastrophique de Boost 1.39 (pourtant présenté comme une avancée de la dernière version BCB 2010 dans les prospectus de Embarcadero) est en train de nous faire arrêter complètement l'environnement BCB pour le futur, après pourtant de nombreuses années d'utilisation satisfaisante voire très rentable (on retrouve des projets sous BCB datant de Juillet 1996).

La réalité est qu'on ne peut se permettre d'avoir un appel client nous disant qu'il a une erreur d'appel d'une fonction virtuelle pure dans Boost::serialization. On ne peut pas gérer à faible cout des centaines d'erreurs de compilation dont la description ne tient même pas dans la longueur attribuée pour le message d'erreur, dans du code qui ne vient pas de chez nous. On ne peut pas assurer une transition entre BCB 2009 et 2010 en ré-écrivant à taton les parties utilisant Boost pour compenser l'ineptitude d'Embarcadero. Il a fallu attendre presque 8 mois pour un support (un peu) moins mauvais pour Boost 1.35 dans BCB 2009 par mise à jour, combien faut-il attendre pour qu'ils s'aperçoivent que des librairies aussi fondamentales que call_traits, regex ou serialization ne sont pas juste optionnelles pour les puristes? Boost, c'est un peu plus que shared_ptr.

Et encore... si au moins ils avaient annoncé qu'ils ne supporteraient jamais Boost correctement, au moins aurions nous fait plus attention à isoler complètement Boost en dehors du code visible par l'UI, quitte à perdre en efficacité de développement. Mais le support semi-pourri qu'on voit depuis à peu près 2 ans et demi est pire que tout. Bref, la sortie de BCB 2010, que nous attendions avec impatience pour son supposé meilleur support du standard et de Boost, a fait déborder le vase, et nous amène à rechercher activement et dès maintenant une porte de sortie. Avec beaucoup de regret, car il faut reconnaitre que coté RAD, BCB est encore ce qui a été fait de mieux pour le C++.

[Invité]

Malheureusement, quand le cœur de métier n'est pas l'UI, c'est le support de Boost qui va faire la différence: si l'environnement RAD n'est pas capable d'avoir du code en commun avec les lignes de code principales, alors c'est l'environnement RAD qui est remis en question, pas Boost. Bien évidemment, utiliser du C++/CLI avec Winform pose ses propres problèmes: nous n'envisageons toujours pas d'utiliser VC++ seul. Il est vrai qu'une fois qu'on a gouté à la productivité exceptionnelle de BCB, on se voit mal revenir sous MFC ou Winforms.

En fait, il me semble que le coeur de métier n'est jamais l'UI. Mais, ce qui coute cher (et parfois ce qui fait la différence) c'est la réactivité sur le developpement d'interface, l'UI donc...

Alors, on se retrouve dans la situation que tu évoques, avec quelques alternatives
1- ne pas utiliser boost (ou seulement les parties qui marchent)
2- tout basculer vers VS+ Qt ou un truc comme ca
3- séparer code non interface (encapsulé dans des DLL ou des objets liés statiquement, et compilé sous VS s'il le faut) du code interface

Des trois solutions, la seconde est à mon avis la plus coûteuse. La première, ca dépend (je pense que les cas où boost fait gagner énormément dans du code existant sont somme toute assez rares, même pour les regexp, il y a des alternatives), mais c'est probablement la plus courante.

La troisième solution est la plus raisonnable, d'autant plus que le prix des compilateurs tend à baisser (sauf BCB) et que les incompatibilités entre formats tendent à se réduire...Il y a un investissement préalable (de découplage des modules, et de mise en place de la solution double), mais il reste nettement inférieur à celui d'un abandon pur et simple de UI.

Ceci évidemment, pour des gens qui ont de l'UI Borland...

Francois

[3DArchi]

La troisième solution est la plus raisonnable

D'autant que étant celle qui demande le plus de réfléchir à son architecture logicielle et en général pour son bien. Les effets induits sont :
-> évident : plus d'indépendance avec le framework IHM utilisé donc plus 'rapidement' portable vers un autre framework.
-> 2 pour le prix d'une : avec une architecture + solide, on diminue les coûts de maintenance et d'évolution.
Mais cette solution a un coût : celui de l'abstraction. Difficile de trouver un expert sur son abstraction alors que les experts MFC/Qt/BCB courent les rues.

[ac_wingless]

Merci de nous épargner les évidences... le code UI est toujours séparé du code non UI, c'est une pratique banale qui n'a pas trop de rapport avec Boost.

L'intérêt d'utiliser un RAD C++ par rapport à, disons, un RAD Delphi, est la diminution du cout d'encapsulation du code non-UI si celui-ci est en C++. Recommander d'isoler le code non-UI sous forme de DLL est juste un choix de méthode d'isolation, et pas forcément le meilleur du point de vue du cout global d'un projet. Une alternative plus intéressante serait, par exemple, d'utiliser le langage C++ lui-même pour délimiter le code UI du code non-UI. C'est en particulier comme cela que BCB1, 3, 5, 6, 2007 ont rencontré leur succès: ils permettaient de pallier au manque de productivité UI des environnements VC++, en s'interfaçant proprement avec les programmes C++ qui nécessitaient des compilateurs autres que BCB, par exemple pour des device drivers, pour l'utilisation de DirectX, etc. On peut ensuite porter du BCB sous Winforms sans effort, par exemple: l'indépendance du framework est assurée par le respect du langage.

A partir du moment où Boost prends de la place dans l'univers des programmeurs C++ (et c'est une bonne chose), pour poursuivre ce modèle d'isolation il faut que l'environnement RAD continue à proposer le même niveau de délimitation, c'est à dire ajouter au support historique de C++ le support plus récent de Boost. Or, ce n'est pas le cas. Se pose alors la question de la ligne de découpage entre le code UI et non-UI: doit-on passer au niveau DLL? C'est clairement un cout de productivité déraisonnable pour la plupart des entreprises. Doit-on garder C++ mais isoler Boost? C'est un cout non nul, mais qui a été assumé par de très nombreuses sociétés dans le passé (jusqu'à BCB 2009, il n'était même pas question d'un support décent de BCB).
Mais maintenant que Boost prouve de plus en plus son utilité au niveau industriel, doit-on vraiment perdre de la productivité d'un coté du code en travaillant à l'isoler, pour espérer la récupérer du coté du code UI?

C'est une question à laquelle différentes entreprises auront différentes réponses, et les généralisations avancées dans les posts ci-dessus semblent bien audacieuses.

Pour prendre l'exemple de ma société, ils ont clairement utilisé la solution 1 avant mon arrivée. Depuis, nous sommes restés à 1 après évaluation très approfondie de 2 il y a deux ans.
Enfin, la solution 3 n'en est pas une: "séparer code non interface (encapsulé dans des DLL ou des objets liés statiquement, et compilé sous VS s'il le faut) du code interface" combine dans la même phrase un but évident ("séparer code non interface ... du code interface") et une implémentation déraisonnablement couteuse en termes de productivité tant que C++ ne dispose pas d'ABI digne de ce nom ("(encapsulé dans des DLL ou des objets liés statiquement, et compilé sous VS s'il le faut)"). Très clairement, si C++ avait une ABI aussi bien supportée que les DLLs, la question ne se poserait même pas: on isolerait par "pimple" les classes ayant un header Boost, et paf le chien: VC++ et BCB cohabiteraient sans souci dans leurs domaines de prédilection respectifs.

Une petite remarque sur le prix de BCB: je n'ai jamais vu que le prix d'un compilateur ait une influence mesurable sur le cout d'un projet industriel. A 900-1300€ la journée facturée, on se doit d'évaluer les outils sans trop prendre en compte quelques centaines ou milliers d'euros d'écart.

[3DArchi]

Merci de nous épargner les évidences... le code UI est toujours séparé du code non UI, c'est une pratique banale qui n'a pas trop de rapport avec Boost.

Ben c'est pas si évident que ça. J'ai vu beaucoup de projets où le code non UI était truffé de CString, CMap, CList, etc. Et je suis sur qu'avec Qt, beaucoup d'applications utilisent Qt pour plus de l'UI avec les même QString, QMap, QList etc. Et l'un dans l'autre, on finit par retrouver un framework qui mange complètement une application. Et du coup on se retrouve avec du code métier dépendant de framework UI

[Invité]

(remarque liminaire :si un modérateur voulait bien mettre ceci sur un fil séparé... @Alp, note cependant que ce n'est pas du tout indépendant de boost : ce qui fait qu'une librairie est ou non utilisée par une majorité, ce sont des contraintes bassement pratiques comme celles dont nous parlons, et c'est l'intérêt de boost en particulier, et du C++ en général, que ces contraintes soient minimales...)

Merci de nous épargner les évidences... le code UI est toujours séparé du code non UI, c'est une pratique banale qui n'a pas trop de rapport avec Boost.

C'est vrai jusqu'à un certain point. Une grosse partie de l'UI est complètement isolable. Mais on trouve presque toujours, au centre de l'appli, un ou deux élément d'UI qui sont en prise directe avec le métier, et où la vitesse de calcul est cruciale. C'est là qu'on va laisser à l'UI des attributions qui relèvent normalement du moteur (par exemple dans un tableau, des sous totaux, des mises en formes, ou des recalculs simples, qui compliqueraient inutilement le code du moteur), et parfois confier au moteur des choses qui relèvent de l'UI (par exemple dans le cas de tris de données demandant des calculs lourds, ou de calculs compliqués pour des survols de composants d'UI)

Dans le cas de boost, il me semble que certaines de ses bibliothèques (la sérialisation, mais aussi les lambdas) sont en fait très utile dans des domaines qui relèvent de l'UI (sauvegarde de données ou de paramètres pour le premier, encapsulation de "petit code jetable" juste sous la surface de l'UI.

Comme souvent, le diable est dans les détails...

Pour prendre l'exemple de ma société, ils ont clairement utilisé la solution 1 avant mon arrivée. Depuis, nous sommes restés à 1 après évaluation très approfondie de 2 il y a deux ans.

Il me semble qu'entre 1 et 2, c'est presque toujours 1 qui gagne... Le risque lié à un changement de framework est énorme, ca peut réellement tuer un soft. Un manque de productivité, c'est seulement désagréable.

En ce sens ton expérience est assez caractéristique...

Très clairement, si C++ avait une ABI aussi bien supportée que les DLLs, la question ne se poserait même pas: on isolerait par "pimple" les classes ayant un header Boost, et paf le chien: VC++ et BCB cohabiteraient sans souci dans leurs domaines de prédilection respectifs.

Ce n'est effectivement pas aussi simple que cela, notamment parce que ces sujets (la collaboration entre compilateurs concurrents) sont mal documentés par les éditeurs. Mais cela reste faisable, moyennant un investissement de départ.

Une petite remarque sur le prix de BCB: je n'ai jamais vu que le prix d'un compilateur ait une influence mesurable sur le cout d'un projet industriel. A 900-1300€ la journée facturée, on se doit d'évaluer les outils sans trop prendre en compte quelques centaines ou milliers d'euros d'écart.

En fait, l'influence est indirecte, mais réelle. Le prix d'achat du compilateur fait qu'on trouve moins jeunes connaissant la VCL que Qt, ou même MFC. Il faut donc former ces personnes, et cela a un cout.

L'autre influence, c'est dans l'autre sens, n'importe quelle PME qui programme dans le monde windows a un licence entreprise de Microsoft, qui inclut VS quasi gratuitement, et installer GCC n'est plus la galère que c'était il y a encore 5 ans. BCB, pour l'avoir, il faut avoir décidé de l'acheter...

Francois