Discussion :

[Luc Hermitte]

C'est un dbus où on se limite aux appels asynchrones donc ? ACE_Task et autres message queues étendues aux process ?

[gl]

J'avais hésiter un instant à faire une réponse détaillé, quitte à redonner des arguments déjà évoqués plusieurs fois par divers intervenant.

Visiblement j'aurais du.

jamais on pensera a faire cette démarche et tant pis c'est pas grave d'avoir N librairie pour un même besoin, ça engendre des jobs en plus pour maintenir ou migrer ou refactorer.

Mais si, on pense à faire ces démarches. Ce n'est pas pour rien si dans la plupart des langages il existe des spécifications d'API rédigés par des entreprises, des consortiums ou des comités de normalisation ou des bibliothèques et framework génériques et réutilisables.

La question que tu te poses visiblement est "pourquoi n'y a-t-il pas une unique spécification ?". Il y a plusieurs raisons à cela:

• Certains préfèrent tout refaire plutôt que réutiliser [1]. Une nouvelle spécification, même normalisée, ne résoudra certainement pas ce problème.
• L'historique : si l'API n'est pas disponible à un instant, les entreprises qui en ont besoin vont développer de quoi répondre à ce besoin de leur côté et, vu le coût et les risques de remplacer cette implémentation par une bibliothèque standard, cette bibliothèque va probablement continuer à vivre voire à être utiliser dans de nouveaux développement (afin de ne pas avoir deux bibliothèques à gérer) pendant longtemps.
• L'API standard ne correspond pas à ce qui est recherché. La cause peut être multiple : fonctionnalité non présente, matériel/logiciel/protocole/format non supporté, mauvaise intégration avec le reste du projet, compromis (conso mémoire/flexibilité/robustesse/performance/etc.) choisi par l'API standard qui ne correspond pas aux critères retenus pour le projet, nouveauté/évolution de la norme/matériel sous-jacent non pris en compte, etc. A moins de satisfaire tous ces besoins, ce qui ne me semble pas possible, plusieurs bibliothèques cohabiteront forcément.
• Des volontés politiques ou stratégiques.

Certes certains langages sont moins concernés par ce problème que d'autres, entre autre les langages :

• Récents (moins d'historique à se trainer, moins d'évolutions des normes sous-jacentes).
• Dont l'évolution est maitriser par un groupe très restreint (évolution plus rapide du langage).
• Dont les usages, et donc l'importance des différents critères, sont plus homogènes.

Le C++ est effectivement particulièrement touché mais je ne connais pas de langage massivement utilisé qui ne rencontre pas ce problème d'existence de multiples bibliothèques incompatibles.

d'ailleurs de quoi je me mêle, que c++ soit compliqué ou pas ne présente en aucun cas un probléme , les experts le maitrise bien et les jeunes développeurs ne le font même plus, donc finalement c'est un faux probléme

Oui le C++ est compliqué et c'est un vrai problème. Mais, de mon point de vue, la complexité ne réside pas dans la coexistence de plusieurs APIs incompatibles (j'irais presque jusqu'à dire que ce n'est qu'un détail) mais plutôt dans :

• Son caractères multi-paradigme qui est pourtant également une de ses principales richesses. Même si rien n'oblige à forcément utiliser tous les paradigmes du langage.
• Les subtilités et les comportements indéterminés du langage, ainsi que la verbosité de certaines constructions.
• La difficulté de diagnostiquer correctement certains problèmes à la compilation.

Globalement, l'évolution du langage va plutôt dans le bon sens concernant ces difficultés.

Quant à la phrase "Vas-y je t'en prie.", ce n'était pas du tout une attaque de ma part. Ce n'est certainement pas en te plaignant sur un forum que tu feras changer les choses, par contre en proposant quelque chose de viable tu as un petit peu plus de chance.



[1] Ce qui est, à mon avis, une très mauvaise raison.

[Issam_Lahlali]

Quant à la phrase "Vas-y je t'en prie.", ce n'était pas du tout une attaque de ma part. Ce n'est certainement pas en te plaignant sur un forum que tu feras changer les choses, par contre en proposant quelque chose de viable tu as un petit peu plus de chance.

t'inquiète je n'est pas considéré ça comme attaque, t'a proposer pas mal d'arguments avant et lorsque je parlais d'attaque ça te concernais pas du tout

et si juste on retient de cette discussion le réflexe d'avoir un framework fait maison qui fait abstraction au maximum a la couche technique c'est déjà pas mal.

et crois moi faire abstraction a la couche technique a énormément d'avantages, par exemple pour COM si on laisse trainer les types BSTR,SAFEARRAY,CComPtr,.. dans tout le code ça engendre une complexité phénoménale, après lorsqu'on pense a isoler tout ce qui concerne COM dans des classes qui ne montre que des types natifs ou STL c'est le paradis tout devient facile, pas besoin de chercher des gurus COM, le dev devient très rapide.

juste un conseil isoler cette foutu couche technique le plus possible, sinon si vous voulez avoir le chaos au niveau code c'est un choix ou il faut assumer les complexités.

et pour les specs certainement c'est trop tard, on ne peut qu'apprécier les dégâts mais le plus grave est de ne pas voir l'utilité et ne pas pratiquer cette démarche au niveau de nos projets quitte a consacrer un peu de temps au framework qui fait abstraction.

et idéalement on doit avoir une équipe qui se concentre juste sur la couche technique et ne développe aucun metier, cette equipe a comme but de proposer une façade simple avec des types natifs ou STL a toutes les autres équipes.

comme ça comme developpeur métier je m'en fous des complexités techniques et je me concentre sur le métier, donc au lieu que tout le monde doit faire gaffe et maitriser ces incompatibilités et complexités , ça sera concentrer a un seul endroit qui se focalise plus sur ce probléme.

[Alp]

L'un des problèmes du C++, c'est qu'à cause de l'API Win32, des MFC, qui étant donnée l'utilisation de Windows en majorité, on s'est retrouvé avec des programmeurs "C/C++" qui connaissait les 34320 (au moins ) types faits maison de MS. Et si par isoler la couche technique, tu voudrais dire dans ce cas que ces bibliothèques fournissent une interface basée sur des types de la bibliothèque standard, alors je suis d'accord à 200%

Ce que j'apprécie d'ailleurs chez Qt, c'est que pour pas mal de choses, même s'ils n'utilisent pas directement les types de la bibliothèque standard, ils proposent des fromStdString, toStdString et autres fonctions de ce genre, c'est déjà ça de pris.

[3DArchi]

L'un des problèmes du C++, c'est qu'à cause de l'API Win32, des MFC, qui étant donnée l'utilisation de Windows en majorité, on s'est retrouvé avec des programmeurs "C/C++" qui connaissait les 34320 (au moins ) types faits maison de MS.

Il y a un historique aussi. Les MFCs sont sorties et ont été utilisés avant que la STL et le C++ ne soit normés. Donc, ils ont générés beaucoup d'existant.

[Alp]

Il y a un historique aussi. Les MFCs sont sorties et ont été utilisés avant que la STL et le C++ ne soit normés. Donc, ils ont générés beaucoup d'existant.

Oui oui. J'en connais les raisons. Mais le fait est que la situation actuelle est délicate pour standardiser toutes ces choses. Seulement, aucune boite ne prendra la responsabilité de casser l'interface de leurs API pour les beaux yeux du comité.

[Médinoc]

Il y a un historique aussi. Les MFCs sont sorties et ont été utilisés avant que la STL et le C++ ne soit normés. Donc, ils ont générés beaucoup d'existant.

C'est vrai. C'est ce qui a donné des trucs affreux comme la gestion d'exceptions MFC...

Par contre, je trouve leurs conteneurs templates mieux faits que ceux de la STL. (Edit: J'ai rien dit. Je pensais pouvoir correctement stocker des types non-copiables dedans grâce au fait que l'interface permette de spécifier le type de paramètre en plus du type de stockage, mais c'est implémenté à la barbare : arraylist qui fait un memcpy(), sérialisation dangereuse...)

[Issam_Lahlali]

L'un des problèmes du C++, c'est qu'à cause de l'API Win32, des MFC, qui étant donnée l'utilisation de Windows en majorité, on s'est retrouvé avec des programmeurs "C/C++" qui connaissait les 34320 (au moins ) types faits maison de MS. Et si par isoler la couche technique, tu voudrais dire dans ce cas que ces bibliothèques fournissent une interface basée sur des types de la bibliothèque standard, alors je suis d'accord à 200%

en fait le but est la, c'est de minimiser au maximum les types utilisés par la majorité des développeurs d'un projet, c'est sur que MS ne va pas faire cet effort d'ailleurs comme tout autre fournisseur de librairie qui crée leur propres types redondants mais il y a la solution de développer en interne dans l'entreprise un framework technique qui fait façade a tout ce qu'on utilise comme couche technique et ne laisse que les types natifs et STL visible pour tous les autres développeurs.

ça peut paraitre énorme comme boulot mais finalement c'est juste des redirections et du marshaling.

finalement même pour le recrutement on ne cherche pas des profils qui maitrise tel ou tel techno ou librairie, il suffit un developpeur C++ qui connait STL.

on peut dire que ça apporte rien cette démarche , mais pour les moyens et grands projets ça accélère énormément le dev et ça minimise les complexités et les bugs.

en tout cas en ayant pratiquer cette approche j'ai découvert un nouveau C++ simple et basique.

[3DArchi]

finalement même pour le recrutement on ne cherche pas des profils qui maitrise tel ou tel techno ou librairie, il suffit un developpeur C++ qui connait STL.

Mon expérience m'a montré que les boîtes qui ont des applis MS avec MFC cherchent d'abord des développeurs connaissant les MFC et les outils Visual plutôt que des experts STL/C++ normé. Mine de rien, le temps d'apprentissage du framework n'est pas négligeable et sous Windows il est quasiment un standard de fait dès lors qu'on développe avec la panoplie Microsoft. En revanche, il est clair que les soft pro Windows se font de moins en moins avec C++/MFC et que ce sont par conséquent des profils moins recherchés.

[Issam_Lahlali]

Mon expérience m'a montré que les boîtes qui ont des applis MS avec MFC cherchent d'abord des développeurs connaissant les MFC et les outils Visual plutôt que des experts STL/C++ normé. Mine de rien, le temps d'apprentissage du framework n'est pas négligeable et sous Windows il est quasiment un standard de fait dès lors qu'on développe avec la panoplie Microsoft. En revanche, il est clair que les soft pro Windows se font de moins en moins avec C++/MFC et que ce sont par conséquent des profils moins recherchés.

pour tout ce qui est interface graphique j'avoue qu'on peut rien y faire, si MFC est utilisé il faut la maitriser mais n'empêche de faire abstractions a tous les autres aspects de MFC autres que la partie graphique.

par contre pour tout autre librairie non graphique on peut suivre la démarche d'abstraction, par exemple ATL ou la technologie COM en général ou on sait que rare ceux qui sont a l'aise avec cette techno et on trouve que c'est très compliqué, alors pourquoi ne pas cacher toute cette techno.

et pour y arriver c'est simple on développe nos classes qu'avec des types natif et STL et on n'oublie ATL et a la fin on peut faire des wrappers autour de ces classes par une seule personne qui maitrise COM, pas besoin que toute l'équipe la maitrise.

finalement on libère la majorité de développeurs de toute complexité, incompatibilité engendré par les librairies ou technos utilisés.

[white_tentacle]

D'un autre côté... si le dev n'arrive pas à comprendre des trucs comme COM ou les MFC, je ne suis pas sûr d'en vouloir dans mon équipe (ceci étant valable aussi s'il dit que les MFC sont géniales ).

La complexité, c'est aussi une mesure de la capacité d'un dev. En C#, où beaucoup de choses sont plus simples, on voit des spécialistes où spécialiste est à prendre dans le même sens que dans ouvrier spécialisé. Ça fait malheureusement peur à voir.

En C++, des types comme ça n'ont effectivement aucune chance. Pas forcément un mal. En C# ou java, ils font illusion un temps, et pour rattraper derrière c'est pas la joie.

Les SSII, dont le métier consiste quand même à vendre cher des hommes/jour, peu importe la compétence, ont clairement choisi : mieux vaut faire illusion. Mais pour faire du vrai boulot...

[Issam_Lahlali]

D'un autre côté... si le dev n'arrive pas à comprendre des trucs comme COM ou les MFC, je ne suis pas sûr d'en vouloir dans mon équipe (ceci étant valable aussi s'il dit que les MFC sont géniales ).

en fait le but n'est pas d'avoir des développeurs incompétents loin de la , le but est de les liberer au maximum de la couche technique pour ce concentrer plus sur le metier et avoir plus de temps pour faire la conception.

on sait que toute librairie a ces astuces, ces complexités et ces incompatibilités et on a 2 choix:

- soit les utiliser directement dans le code, et dans ce cas chaque developpeur sans exception doit faire attention aux astuces et complexités de toutes les librairies techniques utilisés pour ne pas avoir énormément de bugs.

- soit donner juste une façade a tous les développeurs trés minimalistes, basique et surtout bien structuré avec les namespaces, dans ce cas toute complexité technique est isolé et meme si on doit regler une erreur qu'on a fait c'est facile puisque c'est centralisé , et mieux que ca si on veut changer de librairie parcequ'il ya un pb de performance ou autre seul ce framework technique sera impacté, bref que du bonheur


donc finalement le but est de libérer au maximum les développeurs pour ce concentrer sur le métier a implémenter , on lui proposant une boite a outil simple et basique.

[gl]

et si juste on retient de cette discussion le réflexe d'avoir un framework fait maison qui fait abstraction au maximum a la couche technique c'est déjà pas mal.

et crois moi faire abstraction a la couche technique a énormément d'avantages, par exemple pour COM si on laisse trainer les types BSTR,SAFEARRAY,CComPtr,.. dans tout le code ça engendre une complexité phénoménale, après lorsqu'on pense a isoler tout ce qui concerne COM dans des classes qui ne montre que des types natifs ou STL c'est le paradis tout devient facile, pas besoin de chercher des gurus COM, le dev devient très rapide.

juste un conseil isoler cette foutu couche technique le plus possible, sinon si vous voulez avoir le chaos au niveau code c'est un choix ou il faut assumer les complexités.

J'ai du mal à voir le rapport entre cette conclusion et le reste de la discussion. J'ai la vague impression que tu essaies de traiter de manière unique deux (voire trois) questions distinctes:

• Doit-on isoler le code technique (et de manière générale doit-on découper le code en modules clairement définis) ?
• Est-il possible/souhaitable d'avoir une spécification unique par composant technique ?
• Et la question subsidiaire : doit-on réutiliser du code tierce partie ou tout réécrire soit même ?

Mais ça reste des questions clairement distinctes. On peut concevoir et architecturer correctement un soft et utiliser des bibliothèques existantes qui répondent à nos besoins et contraintes sans pour autant une vision unique et arbitraire d'une couche technique.

[Issam_Lahlali]

J'ai du mal à voir le rapport entre cette conclusion et le reste de la discussion. J'ai la vague impression que tu essaies de traiter de manière unique deux (voire trois) questions distinctes:

• Doit-on isoler le code technique (et de manière générale doit-on découper le code en modules clairement définis) ?
• Est-il possible/souhaitable d'avoir une spécification unique par composant technique ?
• Et la question subsidiaire : doit-on réutiliser du code tierce partie ou tout réécrire soit même ?

.

le probléme de base est simple:

comment un developpeur C++ va se concentrer plus sur le code metier?

la solution est de lui faire abstraction le plus possible de la couche technique, et lorsque je dis abstraction je ne veux pas dire tout réécrire, mais juste proposer une façade simple et basique qui redirige vers les libs existantes donc la troisième question que t'a évoqué on peut l'enlever.

revenant a la deuxième question pour la spec unique, le but est le même cad de simplifier la couche technique pour ne laisser qu'une façade simple exploitable par toute la communauté C++ mais puisque c'est une mission impossible on revient a la première question ou le but est de faire cette démarche mais a l'échelle de l'entreprise ou on propose aux développeurs un framework technique qui simplifie au maximum l'utilisation des librairies techniques.

donc finalement le but est simple :

comme developpeur C++ je ne dois pas être bloqué par n'importe quelle problématique technique, dés que j'ai un besoin technique je balance a l'équipe framework qui me propose une façade avec des types basiques et je continue mon dev même en parallèle avec l'équipe technique.

je sais qu'au départ on se demande a quoi ça sert une telle démarche, mais crois moi j'ai déjà assister a des projets sans et avec cette démarche et la différence est énorme, avec le framework technique je me sentais libre et soulagé de tout le fardeau technique et je me concentre plus sur le métier et la conception.

et ce framework sera utilisé bien sur par tous les projets futurs de l'entreprise,et rapidement on aura un framework homogène basique et simple.

et c'est l'objet de toute la discussion: quelle approche suivre pour donner au developpeur plus de temps pour la conception?

[white_tentacle]

Si je résume ta problématique, c'est, "comment faire pour que des nuls puissent utiliser C++", non ?

Tu dois être chef de projet en SSII .

[bacelar]

Quand je pense que je me suis fais chier pendant un an à faire un Framework PROGRESSIF pour ASP.NET.

Si tout les problèmes étaient simplifiable de manière générique et quelque soit l'environnement, je serais et je pense que nous serions au chômage (ou en Inde -> SSII).

Le fait de faire un Framework progressif est de simplifier les choses bien définies mais de permettre des scénarios d'utilisations bien moins mûr ou complexe.

On ne peut pas tout simplifier d'un coup de baguette magique.

[Issam_Lahlali]

Quand je pense que je me suis fais chier pendant un an à faire un Framework PROGRESSIF pour ASP.NET.

Si tout les problèmes étaient simplifiable de manière générique et quelque soit l'environnement, je serais et je pense que nous serions au chômage (ou en Inde -> SSII).

Le fait de faire un Framework progressif est de simplifier les choses bien définies mais de permettre des scénarios d'utilisations bien moins mûr ou complexe.

On ne peut pas tout simplifier d'un coup de baguette magique.

juste pour être d'accord que pour un projet avec une équipe totale ne dépassant pas 10 personnes, on peut dire que c'est pas grave.

Mais pour les moyens et grands projets ça devient primordial, au lieu que 100 développeurs perdent leur temps sur la même chose répétitif, on la donne a une équipe de 3 personnes et c'est réglé, et chacun se concentre comme il faut sur ces taches spécifiques.


ce que je te dis la c'est pas la théorie , c'est la pratique ou dans des projets de 300 personnes on perdra pas mal de temps sur les mêmes conneries techniques, même si t'installe un wiki au niveau de l'entreprise pour mettre toute la base de connaissance des développeurs et leurs problèmes techniques, ça fera pas l'affaire , il y a une perte phénoménale de temps si on l'a multiplie par le nombre de développeurs impliqués.

je comprends l'inutilité de telle démarche pour ceux qui travaille dans des petits projets mais pour les moyens et grands projets le gain est énorme.

Et encore une fois le but est ne pas tout refaire , mais juste faire une abstraction qui redirige vers les librairies existantes déjà mais cache les subtilités et les types redondants.

et quoi dire aussi si au dernier moment pour un grand projet on découvre qu'une librairie a des lacunes et il faut la changer, dans ce cas je te raconte pas la galère ou il faut retoucher tout le code pour le faire au lieu de modifier juste une partie du framework technique.

[nikko34]

on a pas beaucoup avancé dans ce "débat" j'ai l'impression.

[_skip]

Et encore une fois le but est ne pas tout refaire , mais juste faire une abstraction qui redirige vers les librairies existantes déjà mais cache les subtilités et les types redondants.

et quoi dire aussi si au dernier moment pour un grand projet on découvre qu'une librairie a des lacunes et il faut la changer, dans ce cas je te raconte pas la galère ou il faut retoucher tout le code pour le faire au lieu de modifier juste une partie du framework technique.

Je voudrai pas polluer ce débat de ma bêtise et/ou de mon inexpérience relative en c++ mais dans les projets dans lesquels j'ai participé sur d'autres technos, il m'a semblé constater que le rajout systématique de couche d'abstraction avait aussi des inconvénients, principalement dans le développement multi-tiers.

J'ai pu constater ceux-ci :

-Sur une librairie tierce simple, rajouter de l'abstraction via une façade peut n'être que de la pure plomberie, c'est à dire rajouter du code mais peu de fonctionnalités. Par exemple copier à la pogne les objets des types de la librairie dans des objets du type utilisé par l'application juste pour garder une indépendance toute relative, ça se voit souvent (pattern DTO notamment).

-Il n'est pas toujours facile de proposer une façade simple tout en gardant la puissance et le contrôle fin de ce qui est dessous. On se retrouve parfois à devoir complexifier une façade simple parce que soudainement une optimisation requiert de disposer de plus de maîtrise sur les fonctionnalités spécifiques de l'API originale, dans le pire des cas on se retrouve dans la situation décrite précédemment, c'est à dire ou l'on paraphrase une API sans véritable gain si ce n'est du code en plus et on perd l'indépendance en se créant des outils trop *proches* des frameworks/libs sous jacentes.

C'était mes 5 centimes...

[Invité]

Normalement, l'API d'une librairie tierce est une façade, devoir en ajouter une par dessus indique soit qu'il vaudrait mieux changer de librairie, soit que les utilisateurs l'emploient mal...

Je n'ai probablement rien compris, mais j'ai souvent l'impression que le pattern façade est une supercherie... Soit les fonctions utilisées par la façade sont bien faites, et la façade est inutile, soit elle sont inadaptées, et la facade est un cache misère...

Francois