C'est un dbus où on se limite aux appels asynchrones donc ? ACE_Task et autres message queues étendues aux process ?
Version imprimable
C'est un dbus où on se limite aux appels asynchrones donc ? ACE_Task et autres message queues étendues aux process ?
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.
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.Citation:
Envoyé par Issam_Lahlali
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.
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 :Citation:
Envoyé par Issam_Lahlali
- 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.
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 :)Citation:
Envoyé par 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.
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.
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 :aie:) 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% :aie:
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.
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.Citation:
Envoyé par Alp
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é.Citation:
Envoyé par 3DArchi
C'est vrai. C'est ce qui a donné des trucs affreux comme la gestion d'exceptions MFC...Citation:
Envoyé par 3DArchi
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...)
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.Citation:
Envoyé par Alp
ç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.
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.Citation:
Envoyé par Issam_Lahlali
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.Citation:
Envoyé par 3DArchi
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.
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...
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.Citation:
Envoyé par white_tentacle
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.
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:Citation:
Envoyé par Issam_Lahlali
- 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.
le probléme de base est simple:Citation:
Envoyé par gl
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?
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 ;).
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.Citation:
Envoyé par bacelar
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.
on a pas beaucoup avancé dans ce "débat" j'ai l'impression.
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.Citation:
Envoyé par Issam_Lahlali
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...
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
Je vois au moins deux intérêts à une façade :Citation:
Envoyé par fcharton
- Encapsuler une API bas niveau dans une API de plus haut niveau, probablement plus simple à utiliser (peut-être est-ce ce que tu entends par "l'API d'une librairie tierce est une façade").
- Encapsuler une bibliothèque A dans une couche présentant l'API de la bibliothèque B afin de pouvoir facilement intervertir les deux bibliothèques (ou plus généralement présenter une API unique pour plusieurs implémentations différentes). Les raisons de cette manœuvre peuvent être multiple : remplacement au pied levé de B par A avec un impact nul ou minimal dans le code, choix d'une implémentation parmi plusieurs, système de plug-in, etc.
Pour revenir au sujet initial :
D'un autre côté, C++ reste un langage de bas niveau, même s'il est assez haut par rapport aux autres langages bas niveau... Se dissocier de la technique, ou des performances, c'est simplement s'être planté de langage : si tu n'as aucun besoin spécifique de performances et/ou de proximité avec le matériel / OS, tu as bien d'autres choix que C++ qui seront largement plus pertinents, notamment en ce qui concerne le temps de développement...Citation:
Envoyé par Issam_Lahlali
Viens bosser dans l'embarqué, tu apprendras à fuir la STL, Boost et à implémenter à l'ancienne, à la barbare, avec le clavier entre les dents et le fer à souder sur l'oreille... :mrgreen:Citation:
Envoyé par Issam_Lahlali
Pour ma part, je sais que dans ma boîte, c'est un peu le contraire : on a toujours du mal à trouver de "bons" développeurs C++ bas niveau, c'est à dire des gens qui ne passent pas la moitié du temps à regretter un framework Java ou à chercher une librairie toute faite (qui sera poussive et pèsera 40 Mo dans le code, mais ils te diront de mettre un CPU plus puissant et plus de RAM...).
Tout dépend du type de travail que tu fais, et du type d'applications réalisées. Encore une fois, on peut actuellement presque tout faire avec presque tous les langages, mais certains choix sont au mieux malheureux (IHM de haut niveau très complexe en C++/MFC "de base"), au pire stupides (programme bas niveau en Java avec trois tonnes de JNI pour assurer les fonctions).
Qui te dit qu'on ne conçoit pas ? Concevoir n'est pas synonyme de "chercher un beau framework tout prêt", c'est aussi s'adapter aux contraintes matérielles et logicielles, tenir les performances exigées et, si c'est possible, les délais de développement... Tout dépend si tu as une obligation de moyens ou une obligation de résultats !!Citation:
Envoyé par Issam_Lahlali
Si c'est une obligation de résultats, tenir les performances n'est pas une option ou un but théorique, ça DOIT être la réalité... Peu importe les délais ou presque, d'où l'importance d'un bon chiffrage à la base et le fait de savoir que, pour le client, les performances sont cruciales.
Et je la finis en Delphi/C++ Builder largement avant le développeur C#... En Delphi, le code sera même plus robuste qu'en C#, voire peut-être même plus performant car le code est natif : est-ce un critère absolu de mérite ou de "puissance" ?Citation:
Envoyé par Issam_Lahlali
WPF est dédié à remplacer les MFC, et franchement, ce n'est pas un mal (ça en avait besoin)... Toutefois, c'est encore loin de la puissance de RAD comme Delphi, qui ont leur contrepartie aussi : même si c'est parfois difficilement mesurable, ils sont un peu plus lents que du C++/MFC, et s'interfaçent un peu moins bien avec le système d'exploitation et les DLL C++.
Encore une fois, cela dépend de tes besoins, et ces besoins conditionnent le choix de la plate-forme, du langage et des frameworks à utiliser. C++ n'est pas adapté à tout, et ce n'est pas un problème de conception que de ne pas l'utiliser dans un domaine où il n'est pas très adéquat... Et le domaine où il l'est particulièrement requiert, justement, de parfois péter les conceptions type framework au profit d'un code plus efficace.
Tu apprends aussi parfois à revoir tes conceptions "haut niveau" pour avoir des choses tout aussi modulaires et souples, mais adaptées au bas niveau... Cela demande à savoir où s'arrêter dans la généricité, et à savoir où poser les couches d'abstraction pour permettre la modularité du code sans plomber les performances. C'est tout un art, qui s'apprend sur le tas à force de se planter en faisant soit des usines à gaz poussives, soit du code "en dur" inmaintenable et non évolutif...
N'est ce pas, suivant l'objectif, soit le pattern adaptateur, soit le pattern pont? Ceux là sont tournés "vers le bas", servant à isoler les particularités d'API des bibliothèques de bas niveau (A et B).Citation:
Envoyé par gl
J'ai l'impression que façade, dans l'esprit de ses inventeurs, proposait autre chose, je cite "fournir une interface unifiée à l'ensemble des interfaces d'un sous système".
Oui, quelque part, c'est ce que font les wrappers de pas mal de framework, qui camouflent une API système parfois un peu velue sous quelques appels standards et simples. Mais là encore, je ne suis pas certain de comprendre la spécificité du pattern facade, par rapport à d'autres...Citation:
Envoyé par gl
Pas mieux! A mon avis le principal avantage de Builder et de Delphi sera moins la rapidité de l'interface produite (en interface, la machine passe son temps à attendre les réactions horriblement lentes de l'utilisateur, la vitesse est un détail), que la possibilité d'appeler des fonctions "bas niveau" (C ou C++ compilé) qui, elles, auront été optimisées...Citation:
Envoyé par Mac LAK
Par exemple, même si la gestion d'un glisser déplacer est lente, on va pouvoir lui affecter, très naturellement, un recalcul en C extrèmement rapide.
Actuellement, j'ai l'impression que C# ne fait pas le poids (trop lent encore), ni MFC (trop complexe à manipuler, pas assez haut niveau). Pour Qt je ne sais pas, si quelqu'un peut en parler, je suis preneur...
Francois
Ça tient effectivement peut-être plus de l'adaptateur.Citation:
Envoyé par fcharton
Cependant la frontière entre les deux, au moins dans mon esprit, n'est pas forcément très nette et réside essentiellement dans l'intention.
C'est exactement ce qui me travaille depuis que j'ai lu le livre du Gang of Four...Citation:
Envoyé par gl
Les pattern design partent d'un bon sentiment, et certains (le composite, le proxy) sont tout à fait bien vus. D'autres comme tous ces "adaptateurs" semblent des variations autour d'un même thème, pas finis...
Francois
A mon avis, il y a deux grandes familles de design pattern où les frontières entre éléments de la famille sont assez floues :Citation:
Envoyé par fcharton
- La famille façade/adaptateur/pont
- La famille fabrique abstraite/fabrication
C++ est un langage bas niveau, mais qui dispose de fonctionnalités d'abstraction qui permettent d'en faire un environnement de programmation aussi haut-niveau qu'on le désire.Citation:
D'un autre côté, C++ reste un langage de bas niveau, même s'il est assez haut par rapport aux autres langages bas niveau...
Il y a plusieurs cas ou on peut faire une abstraction a une librairie:Citation:
Envoyé par fcharton
- Librairie très performante mais non intuitive au niveau de l'utilisation, et j'ai l'impression que la majorité des librairies C++ ne sont pas intuitives :)
- Librairie trop générique et se caracterise par un niveau trés bas de granularité au niveau methodes, cad qu'au lieu d'appeller une methode pour faire le travail on est obligé d'appeller une sequence de methodes a chaque fois, et dans ce cas le mieux est de faire l'abstraction pour eviter les copier/coller.
- Librairie qu'on identifie au départ comme librairie a risque dans le sens ou elle peut pénaliser les perfs, par exemple si un projet fait bcp de XSL sur des XML volumineux il est fort recommandé de passer par une abstraction pour pouvoir facilement changer la librairie sans trop impacter le projet.
- dans le cas d'utilisation de librairie ou techno trop intrusif par exemple dans le cas de COM ou dans la majorité des projets utilisant COM on trouve les types COM qui trainent dans tout le projet.
Heu... Il est "léger" à ce sujet par rapport à d'autres langages nettement plus haut niveau que lui, tu sais ? C++ possède surtout l'avantage d'être le plus haut des langages bas niveau (ou le plus bas des langages "haut niveau" si tu préfères), mais cela ne veut pas dire qu'il soit parfait à tous les étages !Citation:
Envoyé par loufoque
Delphi l'enterre déjà rapidement rien qu'avec ses propriétés côté haut niveau, et ça reste un langage "comparable" en terme de génération. Ada permet des choses au moins aussi abstraites si ce n'est plus, et est très largement plus fiable en terme de code produit, et là encore on est dans un langage de la même génération et du même type.
Si on commence à taper dans les langages de très haut niveau, notamment fonctionnels et/ou formels, C++ ne tient plus la route côté temps de développement ou niveau d'abstraction : il n'y a plus QUE en terme de performances qu'il se défend.
Alors ces perfs peuvent être bien entendu une demande cruciale du développement, et donc imposer le C++ comme unique choix ou presque, mais vu les questions générales soulevées dans le topic, ça m'étonnerait quand même pas mal que ce soit le cas...
Là, je suis assez opposé à l'idée de fabriquer une abstraction... D'abord, "intuitif" cest vraiment une question de culture, des choses intuitives pour moi ne le seront pas pour toi.Citation:
Envoyé par Issam_Lahlali
Ensuite, si le problème est le vocabulaire de la librairie, on est typiquement dans le domaine d'application du préprocesseur. Mais bon, une librairie performante que les utilisateurs ont du mal à utiliser, cela dénote un problème, soit au niveau de la librairie soit à celui des utilisateurs....
Mais dans ce cas, je découragerais une facade, qui ajouterait du code qui ne sert qu'à simplifier la vie du programmeur.
Je suis d'accord sur ce point, même si je pense qu'il s'agit davantage de créer une interface à la librairie que de faire une facade dans l'application. Enfin, bon...Citation:
Envoyé par Issam_Lahlali
Ca, c'est typiquement le cas où l'on utilise un adaptateur ou un pont... Ceci dit, j'avoue avoir du mal à comprendre. Une librairie identifiée comme "à risque", c'est la première chose qu'on va tester, non? Et là c'est simple: soit ca passe, et le problème ne se pose pas, soit ca ne passe pas, et le problème ne se pose pas non plus...Citation:
Envoyé par Issam_Lahlali
Sur celui là, je ne vois pas le rapport.Citation:
Envoyé par Issam_Lahlali
Francois
il y a des cas ou on ne peut pas avoir le vrai environnement de production dés le départ ou l'interaction entre modules peut nous sortir des surprises.Citation:
Envoyé par fcharton
au départ on ne peut tester que d'une manière isolé mais qui t'assure qu'a l'intégration finale on a pas des surprises.
c'est le cas ou on utilise une librairie sous forme de composants COM, le mieux est de cacher la logique COM pour simplifier l'utilisation, et dans le monde microsoft on utilise beaucoup des librairies composés de composants COM que je trouve intéressante d'ailleurs comme techno, d'ailleurs le monde unix ont eu du mal a proposer une techno similaire qui dépasse les frontières du langage et propose des composants binaire mais bon c'est un autre sujet ou il faut un topic specifique :).Citation:
Envoyé par fcharton
Comme je l'ai dit, C++ peut être aussi haut niveau qu'on le souhaite, la preuve étant qu'on peut créer n'importe quel langage de domaine spécifique embarqué au sein de C++ grâce à la technique des expression templates, qui définissent alors un AST sous la forme d'un type, qu'on peut ensuite évaluer comme on veut avec de la méta-programmation.Citation:
Heu... Il est "léger" à ce sujet par rapport à d'autres langages nettement plus haut niveau que lui, tu sais ?
L'association du bas-niveau et des fonctionnalités de création aussi haut-niveau qu'on le veut, c'est ça qui en fait l'un des langages les plus intéressants.
Tout à fait. J'ai toujours été fasciné par cet aspect là du C++ d'ailleurs. Ca ne vaut pas Haskell ou autre, mais on est quand même bien content de pouvoir faire un DSEL qui va générer le code à notre place, facilitant énormément les choses pour le développeur qui se sert de notre code.Citation:
Envoyé par loufoque
Dans le GoF, ils sont séparés en 3 grandes catégories, selon ce qu'ils font. Adapteur et façade sont proches, mais l'un travaille sur une classe, l'autre travaille sur plusieurs classes.Citation:
Envoyé par gl
C'est pour ça que les tests de performances doivent être envisagés dès le début sur des jeux de données réalistes. On fait ça pour tous les projets où c'est critique.Citation:
Envoyé par Issam_Lahlali
Et C++ enterre Delphi côté généricité ou autres artéfacts comme boost.unit.Citation:
Envoyé par Mac LAK
Le niveau ne va pas dans un seul axe haut bas. C'est révolu depuis bien longtemps cette dichotomie.
OK, mais il est très loin des langages fonctionnels à ce niveau, les templates complexes rendent le code absolument intraçable en cas de bug, et C++ n'est pas le seul langage à permettre ce genre de chose (cf. Ada et ses packages par exemple).Citation:
Envoyé par loufoque
Les templates, c'est bien joli et tout et tout, mais quand tu te retrouves avec des dizaines de templates imbriqués entre eux et que tu as une boulette dedans, en général, t'es nettement moins convaincu. C'est exactement comme les macros en C : cela permet des choses extrêmement puissantes, mais en abuser est rarement une excellente idée côté maintenabilité du code.
Pour ma part, côté génération de code C++, je passe par un métalangage plutôt que par des templates... Nettement plus maintenable à long terme.
Bien que n'étant pas du tout fan de ces langages, j'ai au moins l'honnêteté de reconnaître que cela reste ridicule par rapport à de vrais langages de haut niveau comme ML, Haskell, Lisp, etc. qui sont, eux, taillés "exprès pour".Citation:
Envoyé par loufoque
Comme je disais dans mon premier message, "on peut actuellement presque tout faire avec presque tous les langages, mais certains choix sont au mieux malheureux, au pire stupides.".
Je ne dénigre pas le C++ en tant que tel, attention, j'en bouffe au quotidien. Mais il faut arrêter de croire qu'il existe un "langage-panacée-adapté-à-tout" : chaque langage possède un domaine où il explose les autres, et le C++ n'est pas en tête de podium partout.
Par contre, il l'est dans le bas niveau, notamment et surtout le bas niveau juste au dessus de la machine, avant d'arriver aux éléments "humains" (IHM) ou trop haut niveau. Mais plus tu "montes" dans le niveau de conception, et plus tu vas entrer en concurrence avec des langages comme C#, Java, Python pour le côté framework / modularité, ou Haskell, ML, Caml pour le côté généricité / abstraction.
Et, encore une fois, en fonction de ce que tu fais et du projet en cours, C++ n'en sort pas vainqueur.
Côté points forts, par contre, C++ est difficilement détrônable au bas niveau (il n'y a guère que le C et l'ASM à pouvoir rivaliser), tout en permettant une abstraction relativement élevée. Or, la conception à ce niveau de développement n'a pas grand-chose à voir avec la conception basée sur frameworks et librairies tierces à outrance, d'où l'impression d'être focalisé sur la technique plutôt que la conception pour quelqu'un qui arrive du "haut niveau".
Et n'oublions pas qu'il ne pourrait pas y avoir de programmes de haut niveau avec des performances correctes s'ils ne tournaient pas sur un bas niveau réellement performant, ce qui explique aussi pourquoi le C/C++ ne dégringolent pas réellement dans la liste des langages les plus utilisés.
Mais, encore une fois, ça ne veut pas dire qu'ils sont adaptés à faire tout et n'importe quoi : à partir d'un moment, la complexité du code est trop grande (ou les temps de compilation trop longs) pour envisager la moindre maintenance, si l'on "exagère" en poussant le langage trop loin...
Bonjour,
je suis très intéressé par votre discutions.
Je suis actuellement développeurs C++ en société de service et j'ai à mon actif plusieurs projet développer en C-- et quelques un en C++. Et j'avoue que j'en ai était fort déçut jusqu'à me demander s'il y avait un avenir dans ce langage !
Mon analyse est la suivante. La plupart des développeurs que j'ai croisé dans le monde du service étaient pour la grande partie soit des débutant ayant une formation très faible en C++ c'est à dire une connaissance du C et quelques Geeks très difficile à gérer et peu pédagogue !
Si on revient au contenue des projets, que dire ... :
- J'ai du expliqué trop souvent l'intérêt de placer en "protected" ou "private" les attributs d'une classe.
- J'ai vu souvent des "memcpy" à la place du constructeur par copie.
- j'ai vu des gens cracher sur la STL et préférer le tableau natif ...
- j'ai vu des gens hurler devant l'usage de template !
- j'ai vu des gens proposer des implémentation assembleur pour gagner en vitesse sur la conversion de type du C++ qui avait été vendu plus rapide que du VB et qui donnait des performances moindre !
etc etc ...
et de toute façon ce qui intéressait les chefs c'est que le projet soit livrable en temps et en heure !
Les 2 seuls expériences qui m'ont fait vraiment adorer ce langage que je trouve extrêmement intéressant ont eu lieu soit chez un éditeur de logiciel soucieux de la qualité du code avec une équipe expérimenté et un projet qui commençait avec une équipe de jeune développeur très motivé par la conception et le C++.
Pour moi le C++ parait trop un langage pour une élite ou des geeks ce qui rebute la plupart de mes collègues ! il faut investir beaucoup de temps personnel pour acquérir un niveau correcte, faire des efforts pour trouver des sources d'information dispersé et souvent ardu à appréhender seul ...
Alors la question est pour moi:
dois-je faire comme mes collègues et me diriger vers des langages qui semble prendre de plus en plus de part de marcher ou continuer a subir une majorité de projet médiocre dans notre cher langage ?! :roll:
Tu dois t'intéresser aux autres langages, clairement. Pour deux raisons :Citation:
dois-je faire comme mes collègues et me diriger vers des langages qui semble prendre de plus en plus de part de marcher ou continuer a subir une majorité de projet médiocre dans notre cher langage ?!
- une connaissance généraliste est toujours un plus, il y a du bon et du moins bon dans tous les langages, en connaître un de plus est toujours une bonne expérience
- ça t'offrira plus d'opportunités, et quand il faut manger c'est toujours bon à prendre :).
Pour le reste, c'est avant tout une question de plaisir que toi tu y prends. Si tu prends plus de plaisir à faire des projets en c++ médiocre qu'en c# médiocre, la réponse est assez claire...
c'est vrai si on maitrise tout dés le depart et on sait exactement ce qui est demandais et ca ne changera jamais par le client, mais encore une fois ca n'existe que dans un monde ideale.Citation:
Envoyé par Matthieu Brucher
dans un monde réel on peut avoir des changements dans les specs a tout moment même a la fin du dev :)
c'est pour cela qu'il faut se protéger par le couplage faible si on juge utile,pour s'adapter aux changements d'une manière souple et flexible, un projet fortement couplé avec les librairies techniques est un projet rigide qui ne tolère pas les changements des specs chose qu'on a quasiment tout le temps dans notre métier :)
en tout cas en ce qui me concerne dans les projets ou j'ai assistés , pour N raison a un moment il fallait soit changer de librairie, soit proposer une alternative parce que le client voulait utiliser une librairie payante mais performante, donc on peut avoir plusieurs librairies techniques pour le même besoin.
c'est pour cela que suis pour un couplage faible avec les librairies techniques, dans la réalité ça sert toujours mais effectivement c'est pas obligatoire dans les conditions idéales.