Discussion :

[Invité]

Y a quand même une sacrée différence entre la littérature et la réalité dans le monde du C++

C'est vrai dans tous les domaines. Dans les livres, les programmes sont simples, utilisés à bon escient, écrits justes du premier coup... Dans la vraie vie, c'est tout le contraire. Mais bon, je pense qu'on est quelques uns a préférer la vraie vie (c'est probablement mon côté goret, mais parfois, patauger dans du code un peu sale...)

Sur ce sujet de la théorie et de la pratique, je conseille le livre suivant :

How to solve it. Modern Heuristics
Michalewicz et Fogel, Springer Verlag 1998 (2eme ed 2000)

Le début est dispo là... avec des vrais problèmes de niveau collège, sur lesquels les matheux se cassent généralement les dents...

http://books.google.com/books?id=RJb...age&q=&f=false

Qui explique, par la pratique (et autour de problèmes de maths faciles), pourquoi le bagage théorique ne permet généralement pas de résoudre des problèmes simples, et comment il faudrait s'y prendre...

Francois

[Issam_Lahlali]

Autre détail qui a son importance. Tu disais qu'en Ruby et en Python, la couche technique était formalisée. Il y a une bibliothèque standard plus étoffée, disons comme C++ + Boost. Mais au niveau graphique, rien n'est formalisé par exemple. wxPython et PyQt n'ont rien à voir entre eux et rien à voir avec tkinter. Rien n'est réutilisable pour les UI. Ca pourrait être utile de créer une couche technique pour eux, et il y a des outils qui font des sous-ensembles de wxPython et PyQt, mais dans les faits, on ne peut pas faire la même chose avec les deux, il y a des hacks et du monkey-patching pour modifier le comportement, ... C'est utile, mais ce n'est pas gérable de faire une couche commune.

si tu lis très bien ce que je dis a chaque fois, on aura pas 36 000 posts qui servent a rien, N fois j'ai dis que c'est mission impossible pour l'interface graphique, et je parlais des autres aspects techniques database,xml,...

[JolyLoic]

http://books.google.com/books?id=RJb...age&q=&f=false

Qui explique, par la pratique (et autour de problèmes de maths faciles), pourquoi le bagage théorique ne permet généralement pas de résoudre des problèmes simples, et comment il faudrait s'y prendre...

Amusant. Le problème du puits, je l'ai trouvé en 2-3 minutes, par contre, celui du triangle, j'ai plus de mal...

[Matthieu Brucher]

si tu lis très bien ce que je dis a chaque fois, on aura pas 36 000 posts qui servent a rien, N fois j'ai dis que c'est mission impossible pour l'interface graphique, et je parlais des autres aspects techniques database,xml,...

C'était un exemple...
Même en Python, il y a régulièrement de nouveaux modules, par exemple pour XML justement. On avait SAV et DOM, maintenant on a elementTree, un autre bien connu est BeautifulSoup, chacun qui a des spécificités, et pas d'interface identique.

[Issam_Lahlali]

C'était un exemple...
Même en Python, il y a régulièrement de nouveaux modules, par exemple pour XML justement. On avait SAV et DOM, maintenant on a elementTree, un autre bien connu est BeautifulSoup, chacun qui a des spécificités, et pas d'interface identique.

dans n'importe quel langage il y a différence entre SAX et DOM c'est normal,c'est 2 approches sont différentes dans la manière de traiter XML.

le probléme de base c'est qu'en C++ on est déboussolé, on parle de C++ moderne mais en réalité on l'a pas, on parle a chaque fois de Boost et encore une fois en réalité c'est pas trop utilisé, et même STL n'est pas beaucoup utilisé comme on croit, il y a encore et toujours les char* qui traine et N façon pour faire une fonctionnalité technique donc comment se retrouver dans cette jungle ou on plus on rattrape vite la shkizophrenie entre ce qu'on trouve dans les livres et qu'est ce qui existe réellement, c'est vrai pour les autres langages mais c'est flagrant en C++, me sortir a chaque fois Boost c'est tout simplement on connait pas bien ce qui se passe dans la réalité et la je peux te sortir aussi le mot magique et passe partout "Manque d'expérience"

et si tu relis bien toute la discussion tu découvre rapidement une grande contradiction ou on parle un moment de STL,Boost,POCO lorsque le contexte de la réponse le permet et d'un autre coté en parle que la réalité est autre chose est que ces librairies ne sont pas trop utilisés.

et sincèrement il fallait dés le départ bien cerner les conditions générales et réels ou on bosse avec les données de la réalité, on aura éviter pas mal de pages

et on peut pas nier qu'on passe trop de temps dans la couche technique en C++, c'est un fait ce qui explique ma réflexion sur la manière de simplifier cette couche, et changer de librairie pour utiliser Boost est une solution utopique qui marche pas en entreprise,c'est pour cela que j'ai proposer une solution intermédiaire:

on va pas changer de librairie et on va pas laisser trop de trucs compliqués trainés non plus, et il faut avoir le réflexe de simplifier cette couche technique a chaque fois c'est utile.

et lorsqu'on parle de changer de librairie , la je peux te répondre par manque d'expérience et aussi lorsqu'on parle de faire 36 000 réunion pour simplifier ce qu'on juge utile la aussi je peux te répondre par manque d'expérience

[Matthieu Brucher]

J'aime bien comme tu évacues le fait que je te prouves par a+b que c'est le cas dans tous les langages, pas que en C++.

[Issam_Lahlali]

J'aime bien comme tu évacues le fait que je te prouves par a+b que c'est le cas dans tous les langages, pas que en C++.

ce qui tu viens de dire prouve que t'a pas lu tout le message ou je dis:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
c'est vrai pour les autres langages mais c'est flagrant en C++.

Et le fait que c'est flagrant en C++ n'est pas un mythe, on le sait tous et c'est Normal vu l'historique.

si tu relis toute la discussion tu trouvera que la majorité de l'argumentation se base sur l'existence de librairies simples Boost, POCO ou autres, mais encore fois en realité c'est autre chose on ne trouve Boost que rarement tu n'a qu'a voir les projets open source en c++ et tu découvre qu'on a pas de Boost et rarement de STL et dans le monde d'entreprise c'est pareil.

par contre pour les projets java on utilise généralement JDK et bien sur d'autres librairies aussi mais pas autant que C++,et la logique de me dire qu'on revient a la même chose c'est comme si me dire 5=50 puisque de toute façon ça représente plusieurs.

si t'arrive pas a saisir cette réalité on peut pas aller trop loin, on va tourner en rond.

et si sur ce point on est d'accord t'a 3 solutions :

- tu change les librairies utilisés par Boost et autre et c'est une solution utopique.

- tu change rien et tu t'adapte avec la complexité des librairies utilisés.

- tu simplifie petit a petit les complexités engendrés par les librairies utilisés et c'est la solution que je préconise mais apparemment toute la discussion part de principes idéaux genre on peut utiliser Boost ou POCO ca va tout simplifier.

finalement on peut tourner comme ça en rond des années, donc je considère que c'est résolu , de toute façon c'est devenu n'importe quoi

Merci a tous pour vos contributions et A+.

[CedricMocquillon]

Désolé de rajouter un post à cette discussion, mais je voulais intervenir dans la journée mais je n'ai pas eu le temps.

Je voulais attirer votre attention sur le fait que le succès de Boost est à mon avis lié également au fait qu'il existait un manque de framework à la java ou à la C# en C++.

Personnellement, j'ai redécouvert le C++ avec la combinaison STL + Boost. Le succès de Qt est je pense lié aux même raisons (bien que je ne connaisse pas Qt, je parle donc sous votre contrôle): un framework qui permet de résoudre une grande variété de problème avec une homogénéité dans l'approche/syntaxe.

Pour les chefs de projet ces libs/framework ont également l'avantage d'avoir la garantie qu'elles seront maintenue pour un moment (succès oblige).

Enfin un dernier aspect plus "commercial" (et que d'une certaine manière je regrette): sur un CV Boost ou Qt ==> maitrise du framework (en théorie en tout cas) c'est plus simple à retenir pour un DRH qu'une somme de libs pour addresser l'ensemble de ce qui est traité par Boost ou Qt.

PS: je vous ai trouvé (inhabituellement) acerbes sur l'histoire du start_with, end_with. J'ai trouvé amusant que ces méthodes soient implémentées dans Boost (au delà du bien fondé de cette méthode dans le contexte exposé par le PO) et personnellement si le besoin s'en fait sentir, je développe ce type de méthodes (après avoir vérifié l'existence ou non dans Boost) dans des namespaces dédiés, je trouve que ça permet d'être très clair sur mon intention (un start_with est plus sémantiquement parlant que le compare et pour moi moins source de bug).

[metagoto]

@Mac LAK, fcharton and co

En fait, ce que je trouve étonnant est que dans vos argumentations, l'algorithmie semble secondaire. Le coût des lignes de code, des modifications, ou de la maintenance est asservi par un style, une norme, une convention interne, un dialecte ou que sais-je encore. Le sentiment que j'ai, c'est qu'en C++ plus qu'ailleurs, se cantonner à un dialecte (quand ce n'est pas se cantonner à un style tout court) a des conséquences importantes quant à l'efficacité du code et les possibilités de résolutions du problèmes posé. En python ou en php (que je connais bien), les différents styles n'impactent pas autant la pertinence des codes. C'est pour ça que j'ai dit qu'il y avait une sacrée différence entre la littérature et la réalité en C++. On pourra lire par exemple qu'on va essayer d'utiliser les meilleurs outils disponibles dans le langage pour résoudre le problème. Si la règle est, par exemple, de "ne pas utiliser de templates", il se peut que les performances au runtime soient bien moindre, ou que la complexité algorithmique soit bien plus défavorable. Bref, un coding standard "simpliste" en C++ a des conséquences qui vont au delà de la lisibilité ou de la complexité "cosmétique" du code: ça peut jouer sur la palette de solutions possibles dont certaines sont potentiellement bien meilleurs que d'autres en terme d'espace ou de cycles.

Et sinon pour http://books.google.com/books?id=RJb...age&q=&f=false , merci, je l'ai foutu, pardon, je l'ai mis en bookmark

[koala01]

Je crois encore une fois qu'il ne faut pas tout mélanger, et se méfier des raccourcis trop rapides...

Bien sur, conception, algorithmie, implémentation et technique sont très fortement imbriquées les unes dans les autres.

Et pour cause, elle entrent toutes dans un processus beaucoup plus général qui a pour but... d'arriver une application / bibliothèque qui fournit les services que l'on attend d'elle.

Bien sur on peut ( pour ne pas dire on doit ) toujours regretter qu'une décision (quel que soit le niveau auquel elle est prise) puisse mener à n'utiliser qu'une partie de la puissance et de la souplesse du C++.

Je fait d'ailleurs partie de ceux qui se font entendre le plus fort sur le sujet.

Mais, tant que l'on respecte les règles de conception (allant de la délégation des tâches à demeter, en passant par LSP et tout le toin-toin), que la logique est correcte et que l'implémentation évite d'envoyer le processeur cueillir les marguerites, il est difficile de faire un parallèle entre les restrictions que peuvent impliquer certains choix et la qualité d'un développement, tous axes ("accessibilité" du code, maintenabilité, évolutivité, débuggage, etc) confondus.

Au pire pourrions nous estimer que ce genre de restrictions rend le développement moins souple ou moins aisé, mais ce ne serait encore que qu'un avis purement subjectif:

• Quelqu'un n'ayant jamais fait que de la programmation procédurale trouvera sans doute la POO des plus compliquée
• Quelqu'un d'autre n'ayant jamais touché à la programmation générique aura un avis similaire concernant l'utilisation des "techniques avancées" mise en oeuvre par les template
• Quelqu'un s'étant toujours reposé sur un garbage collector trouvera la gestion manuelle de la mémoire lourde et fastidieuse
• J'en passe, et de meilleures

En effet, si je suis tout à fait d'accord sur le fait que certaines solutions (ne serait-ce qu'au point de vue algorithmique) sont très clairement plus efficaces que d'autres, j'ai la conviction qu'un *bon* algorithme (comprend: faisant ce qu'on attend de lui de la meilleure manière possible) présentera des performances similaires quels que soient les choix de conception, de langage ou de paradigmes effectués.

Si je devais mettre un bémol sur ce point, ce serait beaucoup plus volontiers concernant le langage que concernant les choix de conception ou de paradigme

Ne nous voilons pas non plus la face: les choix qui sont fait le plus tôt dans le processus de développement sont très certainement ceux qui ont l'impact le plus important sur l'ensemble du projet.

Mais c'est à dire que le choix de se limiter à un sous ensemble (ou à un dialecte) du C++, qui n'intervient réellement qu'une fois que l'on est devant son EDI favoris, sera sans doute le choix qui aura le moins d'impact en générale

[_skip]

Je me permet de faire un petit HS car j'aime particulièrement ce qu'il a dit...

Je voulais attirer votre attention sur le fait que le succès de Boost est à mon avis lié également au fait qu'il existait un manque de framework à la java ou à la C# en C++.

Personnellement, j'ai redécouvert le C++ avec la combinaison STL + Boost.

+100
Je suis tout à fait d'accord avec toi, et dans ma situation je trouve souvent une solution à mes problèmes courants dans boost. Cette lib propose un paquet de choses qui sont absentes ou pénibles à utiliser dans la STL.

Pour moi c'est l'équivalent des apache commons pour java. Fournir une API d'assez haut niveau, bien testée et éprouvée, pour des besoins qui reviennent fréquemment.

Le succès de Qt est je pense lié aux même raisons (bien que je ne connaisse pas Qt, je parle donc sous votre contrôle): un framework qui permet de résoudre une grande variété de problème avec une homogénéité dans l'approche/syntaxe.

Je m'intéresse depuis quelque temps à QT moi aussi et ça me rappelle beaucoup les frameworks disponibles dans les langages managés (qui sont le gros de mon expérience pro). Et effectivement, il a ses propres types qui font *ciment* entre les différents namespace proposées et qui permettent de lier facilement les fonctionnalités entre elles.
Car je suppose qu'utiliser une floppée de composants de sources différentes qui viennent chacun avec leurs propres types date/temps/heure (pour prendre un exemple) ça peut devenir vite le casse-tête.

un start_with est plus sémantiquement parlant que le compare et pour moi moins source de bug).

C'est aussi ce que j'en pense, d'ailleurs dans les classes que je développe, j'aime créer par exemple une méthode "bool parent::hasChild()" plutôt que de mettre des "parent.child != NULL" pour que le sens du test soit immédiat au premier coup d'oeil.

[Invité]

En fait, ce que je trouve étonnant est que dans vos argumentations, l'algorithmie semble secondaire.

En fait, c'est souvent le cas... L'algorithmie, au fond, c'est facile, il suffit de savoir des maths, et d'avoir lu les bons livres. Après, on code (ou on récupère) les "bons" algos, on les teste, et c'est tout.

Bien sur, si on n'y comprend rien, on peut faire de grosses erreurs couteuses, en prenant le mauvais algo, ou en essayant de faire soi même à la main des trucs vraiment difficile (typiquement, tous les algos numériques sur lesquels les problèmes de stabilité du calcul interviennent...). Mais presque toutes les boites sérieuses ont à leur tête, ou pas loin de leur tête, un "gros matheux" (chez moi c'est 2 pour 9 personnes) qui sait un peu de quoi il parle, ou au pire dans quel bouquin chercher.

Et puis, les algos, c'est la partie fun du métier, là ou l'on est tout à fait prêt à passer du temps. Du coup, c'est pas là que sont les problèmes. Les problèmes, ce sont toujours des petits bugs à la c... On aimerait bien, bien sur, que ce soient des trucs théoriques qui font planter le programme, mais en général non, c'est un cast sauvage, un pointeur de traviole, ou un compteur de boucle fou... L'informatique est une école de l'humiliation...

Enfin, le style de programmation *à l'intérieur* des algos n'a pas besoin d'être contraint : c'est là que la remarque de Mac Lak s'applique. Une fois que l'algo tourne, la façon dont il est implémenté (un template ou une fonction par type, récursif ou itératif, dans une classe ou en procédural, avec du boost à tous les étages ou tout roulé à la main...) ne concerne que le développeur de l'algo, qui souvent est seul.


Mais c'est rarement des algorithmes que viennent les problèmes. Souvent le gros du temps de développement et de maintenance est passé sur toute la tuyauterie et l'interface autour. Et là le principe de développement change. Là où pour un algo tu veux un truc bien testé qui va vite, ne bougera pas, et sera propre et élégant, les tuyaux et l'interface ont vocation à changer, presque tout le temps, sur une manie du client ou d'un commercial. Ils ont également moins de contraintes en termes de performance.

Pour la tuyauterie, tu veux un truc qui ne coute pas trop cher à faire (parce que de toutes facons, il va changer bientot), qu'on peut modifier facilement, et surtout qui se relit facilement (parce que tu vas écrire ton code une fois, et le relire cinquante). C'est là que le "simplisme" entre en jeu.

Bien sur, tout ne change pas tout le temps, avec l'expérience, certains morceaux de la tuyauterie d'un logiciel se "stabilisent", et cela vaut la peine de les refaire, proprement, de façon moins simpliste, mais ça, c'est dans un second temps (le faire au début, c'est toujours une mauvaise idée).


On pourrait d'ailleurs dire que le vrai rôle du chef de projet, ca ne devrait pas être (comme on le voit souvent) le respect dogmatique d'un cahier des charges en perpétuelle évolution, ou la mise à jour sur excel de rapports aussi complexes qu'inutiles, mais cette analyse de ce qui doit être "fait comme un algo", et de ce qui est de la "tuyauterie démontable", parce que c'est typiquement le genre d'analyse que la plupart des développeurs ne savent pas faire.

Francois

[Issam_Lahlali]

excusez moi j'ai oublier juste de vous dire quels sont les motivations pour lesquels j'ai basculer ce topic en Résolu

avant je vais vous expliquer les motivations de la question elle même, il faut juste avoir la patience de lire tout le message

théoriquement la conception doit être le plus possible indépendante du langage, mais en réalité a un moment il faut prendre en compte le langage cible dans notre conception, pour faire une analogie avec les langues et la pensée,normalement l'analyse et les idées doivent être indépendantes de la langue parlée mais les linguistes nous montrent que la langue influence aussi sur nos idées.

donc il y a un point de bascule qu'on peut noter PB ou on bascule vers le language cible, un langage moins riche nous impose une bascule rapide , vu les limitations du langage si on l'ignore et on va loin dans la conception sans le prendre en compte, soit ca sera impossible de l'implementer, soit possible mais d'une maniére trés trés compliquée.

par contre un langage riche a un PB trés elevée et on peut bien s'epanouir au niveau conception, le C++ est parmi les langages les plus riches donc on peut dire que PB(C++)>PB(Majorité des langages) donc +1 pour C++.

donc on peut dire qu'en C++ on peut aller trop loin dans une démarche "Design First" et éviter le piège de "Code First" ou on est trop dépendant de l'implémentation et de ces astuces.

Mais il y a un facteur aussi important qui est la complexité d'implémentation qu'on peut noter CI si on l'a combine avec l'étude de risque qui consiste a se focaliser sur la partie la plus risqué on a tendance a faire du "Code First" puisque l'implémentation est trop complexe et il faut la prendre en compte dés le départ.

finalement le vrai point de bascule sera modifié PBR=PB-F(CI)

et le point de bascule réel est limité par la complexité d'implémentation.

dans plusieurs domaines d'applications comme les applications de gestion on a
PBR(C++)<PBR(java ou dotnet)

et la cause de ce retournement de situation et ce fameux CI, puisqu'en C++ on a plus de mal a implémenter l'IHM par exemple que d'autres langages, c'est moins vrai maintenant avec Qt mais malheureusement elle est venu trop tard et j'en suis sur qu'ils vont simplifier plus cette couche.

je dirais qu'un bon développeur/concepteur dans un langage est celui qui se rapproche le plus au PB du langage.

le C++ est plus puissant mais on exploite pas toute sa puissance , java est moins puissant mais on exploite plus sa puissance que C++ , tout ca a cause de CI.

c'est comme si on exploite 30% de la puissance de C++ et 80% de la puissance de java ou dotnet.

la question qui se pose est comment libérer toute la puissance du langage?

au niveau des entreprises on préfère plus maintenant les langages avec un bon PBR vu l'investissement mis en jeu, et personnellement je préfère un langage avec un bon PB vu que je sais que le CI je peux le changer par contre le PB est fixe puisqu'il est imposer par les possibilités du langage.

C'est pour cela que je préfère un langage comme C++ puisqu'il me donne la possibilité de m'épanouir plus au niveau conception mais a condition que j'arrive a limiter l'impact du CI sinon mon PBR devient inférieur aux autres langages et je perd l'intérêt de la richesse.

et c'est la qu'on vient a la réflexion de simplifier la couche technique pour justement minimiser ce CI, et le malentendu que j'ai eu souvent avec les intervenants et que a chaque fois que je parle de simplification on me parle de Boost et d'autres librairies simples et comme quoi je ne sais pas choisir les librairies par manque d'expérience, et a chaque fois je réponds que ce n'est pas Boost qu'on trouve dans les projets réels et c'est pas évident de les convaincre de changer leur librairies par Boost, donc il faut s'adapter avec ce qu'ils ont et essayer de minimiser le CI pour augmenter le PBR et pour cela il faut avoir le reflexe de simplifier ce qu'on peut simplifier toujours dans cette optique :

minimiser CI=> augmenter le PBR=>se concentrer plus sur la conception et exploiter la richesse du langage.


mais a un moment donné on tourne en rond dans un cercle vicieux ou simplifier => utilisation de Boost mais c'est difficile de convaincre la boite de remplacer leur librairie par Boost donc il faut simplifier autrement => il nya que Boost => mais on peux .....

et ça peux rester comme ça jusqu'à des années

en gros je crois que C++ est le langage ou on peut s'épanouir le plus au niveau conception mais paradoxalement c'est celui qu'on s'épanouit plus au niveau code a cause de ce foutu CI.

et simplifier ça implique des fois juste des petits détails qui peuvent faire la différence comme l'exemple de _skip

C'est aussi ce que j'en pense, d'ailleurs dans les classes que je développe, j'aime créer par exemple une méthode "bool parent::hasChild()" plutôt que de mettre des "parent.child != NULL" pour que le sens du test soit immédiat au premier coup d'oeil.

ou l'exemple de start_with ou n'importe quelle autre qui peut simplifier l'utilisation , la compréhension et le debuguage.


j'espère que j'étais clair dans ce message et on comprend mieux mes motivations qui ont était compris a plusieurs reprises dans le sens ou je veux dénigrer C++ et montrer que c'est un langage a éviter, a l'inverse je préfère les langages ou je m'épanouis plus au niveau de conception quitte a payer le prix de faire l'effort de minimiser l'effet de ce fameux CI

[Mac LAK]

Je vais compléter un peu la réponse de Koala, via une approche un poil plus pragmatique je pense.

En fait, ce que je trouve étonnant est que dans vos argumentations, l'algorithmie semble secondaire.

Je parle pour moi sur ce coup, mais non, elle n'est pas secondaire... Elle est en fait déjà conçue, quand on en arrive au stade des contraintes d'implémentation !

Le coût des lignes de code, des modifications, ou de la maintenance est asservi par un style, une norme, une convention interne, un dialecte ou que sais-je encore.

"Welcome to the real world..."
Il faut bien voir que ces normes ont diverses raisons d'exister : si, dans une société, on te dit qu'il faut que chaque variable soit préfixée par "variable_", c'est un exemple de règle idiote ou, au minimum, mal pensée (trop long comme préfixe).

Si dans une norme de SdF on te dit de ne pas utiliser de pointeurs et de tout passer par valeur quelles que soient les tailles des items, ça a AUSSI une raison : c'est que, statistiquement, il y a beaucoup de bugs liés à des passages de pointeurs, et ils sont souvent critiques, voire catastrophiques suivant le système que le bug aura fait planter. La raison n'est pas ici d'embêter le dév ou de faire plaisir à un directeur lambda qui aura l'impression de comprendre le code ! C'est simplement une manière de faire baisser les problèmes (et donc les accidents) en interdisant les pratiques les plus génératrices de bugs.

Après, tu n'as peut-être pas compris un point essentiel de ces règles : d'une part, elles existent aussi pour garantir l'intéropérabilité quasi-immédiate des divers programmes réalisés par la société. Ce sont les règles qui t'imposent tel ou tel compilateur, tel ou tel réglages / langage, etc.
D'autre part, j'ai l'impression que tu crois, à tort, qu'il n'existe qu'une seule "règle" par société... Et ça, c'est totalement faux.

Dans ma boîte, on a des règles "communes" à tout le monde, c'est vrai. Que les dévs doivent suivre dans la mesure du possible. Mais crois-tu réellement que l'on a les mêmes contraintes quand on fait du bas niveau temps réel et quand on fait des IHM rafraichies toutes les secondes ?

En général, si c'est bien fait, tu as un jeu de règle pour chaque situation, plus quelques règles générales s'appliquant à tout le monde (stockage des documents, gestion de configuration, ...).

Le sentiment que j'ai, c'est qu'en C++ plus qu'ailleurs, se cantonner à un dialecte (quand ce n'est pas se cantonner à un style tout court) a des conséquences importantes quant à l'efficacité du code et les possibilités de résolutions du problèmes posé.
<snip>
Bref, un coding standard "simpliste" en C++ a des conséquences qui vont au delà de la lisibilité ou de la complexité "cosmétique" du code: ça peut jouer sur la palette de solutions possibles dont certaines sont potentiellement bien meilleurs que d'autres en terme d'espace ou de cycles.

Cela va te surprendre, mais en fait, non. Pas avec une bonne expérience et la connaissance de la plate-forme cible.

Cela a des conséquences importantes dans le code "amateur" (et je dis ça sans méchanceté), ou de débutant, car l'échelle classique de mesure est l'observation humaine à l'oeil nu. Dans ce genre de situation, quand on cherche à "optimiser" son programme, on ne sait en fait jamais réellement où est le véritable goulot d'étranglement.
Donc, on tripote, on tripatouille, on utilise les méthodes "conseillées" (utiliser STL/Boost par exemple), et à un moment BOUM ! Cela marche mieux, et plus vite. On en déduit souvent la chose suivante : "j'ai viré mon code maison, j'ai mis STL/Boost à la place, ça arrache en vitesse maintenant donc STL/Boost sont optimisés".

Et c'est souvent vrai, d'ailleurs... Mais pas toujours ! De par leur nature en template, ces librairies sont souvent proches de l'optimal, en effet. Mais quand tu commences à raisonner à des niveaux de vitesse bien plus bas, que tu es outillé pour ça y compris en oscilloscopes, analyseurs logiques / de bus, etc. tu te rends compte souvent qu'il est presque toujours possible de faire mieux que la STL ou Boost.

Parfois pas de beaucoup, c'est vrai, mais dans un système critique c'est toujours bon à prendre. Et la raison est très simple, en fait : quoi qu'il arrive, ces templates sont génériques, et contiennent systématiquement des instructions "inutiles" quand on se restreint à un cas particulier concret... D'où victoire de l'algo "maison". Le cas le plus courant d'optimisation ? Les tests de débordement : dans un système maîtrisé, on délègue ça à un niveau bien plus haut, par conception. On peut donc virer la plupart des tests pour gagner du temps. Mais comment veux-tu que le compilateur puisse le savoir, ça, et donc optimiser le code template ? C'est impossible, seul un humain peut faire ça.

Alors c'est vrai que pour la plupart des programmes, de telles optimisations sont non seulement inutiles, mais même contre-productives. Qui aurait réellement besoin d'une IHM répondant un million de fois plus vite que la vitesse de rafraichissement de l'écran ??? Tout temps passé à ça est du temps perdu, c'est une évidence.
Par contre, si tu considères par exemple un routeur logiciel, le moindre bout de cycle CPU gagné, c'est du temps CPU disponible pour les AUTRES processus du système, de la bande passante mieux utilisée, moins de risques de trames perdues, etc. Dans un tel cas, on ira jusqu'à l'optimisation quasi-maximale au contraire.

Donc, là, je t'ai montré un exemple où virer des templates permet, au contraire, d'optimiser les perfs... Pour le cas inverse, c'est que l'on peut aussi remplacer du code "manuel", mais performant, par un template "maison", adapté à ce que l'on fait (par exemple sans tests de débordement), et l'utiliser à plusieurs endroits.
Le code sera tout aussi performant qu'auparavant, mais bien plus maintenable... Et on pourra toujours trouver un contre-exemple !

Se figer sur une technologie, quelle qu'elle soit, aura toujours des conséquences néfastes suivant ce que l'on fait. Mais l'expérience peut aussi t'aider en te faisant savoir, à l'avance, quelles sont les technologies usuellement "mauvaises" pour telle ou telle activité... Dans le bas niveau, par exemple, les templates sont acceptés pour tout ce qui n'est pas critique (initialisation des modules par exemple), ou pour le pseudo-temps réel (c'est à dire temps réel pour un humain, pas pour la machine). Dans le temps réel "dur", si tu mets des templates, t'as intérêt à avoir des billes pour t'assurer que c'est réellement l'optimal...

Et réussir à faire de l'optimal pour chaque cas particulier à partir d'un système générique, tu n'as pas l'impression qu'il y a comme un problème de conception à la base ?


Comme souvent, c'est une affaire de compromis, et de marge de manœuvre. Les règles sont là pour interdire les techniques que l'on sait par avance comme étant très majoritairement "néfastes" par rapport au domaine d'activité.
Le "néfaste" peut être de nature multiple : coût de maintenance, temps de production, taux de bugs, adéquation au turn-over, temps de formation des nouveaux dévs, adéquation à une norme client, portabilité du code, ...
Bref, c'est plus vaste que tu ne le crois.

[metagoto]

Pour la tuyauterie, tu veux un truc qui ne coute pas trop cher à faire (parce que de toutes facons, il va changer bientot), qu'on peut modifier facilement, et surtout qui se relit facilement (parce que tu vas écrire ton code une fois, et le relire cinquante). C'est là que le "simplisme" entre en jeu.

Bien sur, tout ne change pas tout le temps, avec l'expérience, certains morceaux de la tuyauterie d'un logiciel se "stabilisent", et cela vaut la peine de les refaire, proprement, de façon moins simpliste, mais ça, c'est dans un second temps (le faire au début, c'est toujours une mauvaise idée).


On pourrait d'ailleurs dire que le vrai rôle du chef de projet, ca ne devrait pas être (comme on le voit souvent) le respect dogmatique d'un cahier des charges en perpétuelle évolution, ou la mise à jour sur excel de rapports aussi complexes qu'inutiles, mais cette analyse de ce qui doit être "fait comme un algo", et de ce qui est de la "tuyauterie démontable", parce que c'est typiquement le genre d'analyse que la plupart des développeurs ne savent pas faire.

+

Je crois encore une fois qu'il ne faut pas tout mélanger, et se méfier des raccourcis trop rapides...

Bien sur, conception, algorithmie, implémentation et technique sont très fortement imbriquées les unes dans les autres.

+

Ne nous voilons pas non plus la face: les choix qui sont fait le plus tôt dans le processus de développement sont très certainement ceux qui ont l'impact le plus important sur l'ensemble du projet.

Mais c'est à dire que le choix de se limiter à un sous ensemble (ou à un dialecte) du C++, qui n'intervient réellement qu'une fois que l'on est devant son EDI favoris, sera sans doute le choix qui aura le moins d'impact en générale

+

Je parle pour moi sur ce coup, mais non, elle n'est pas secondaire... Elle est en fait déjà conçue, quand on en arrive au stade des contraintes d'implémentation !

[...]

D'autre part, j'ai l'impression que tu crois, à tort, qu'il n'existe qu'une seule "règle" par société... Et ça, c'est totalement faux.

Il me manquait ces détails.. de taille!
Je résonnais plus en terme de règles omniscientes, pré-établies et applicable de facto à tous projets d'une même société (modulo des exceptions éparses -bien entendu).
D'où mon étonnement et cet exemple que j'ai sorti à propos de "ne pas utiliser de templates", qui, appliqué unilatéralement telle une Hungarian notation, aurait de sérieuses répercussions pour certaines classes de projets (tout comme son contraire, illustré par l'exemple du temps réel)

Donc effectivement, si le choix du "dialecte" est fonction du projet et est (généralement?) judicieusement défini, alors ça me parait tout de suite beaucoup plus clair... et cohérent.
Vous allez me dire que c'est d'une évidence affligeante. D'accord, mais comme par ailleurs on peut lire ci et là que certains bannissent des pans entiers du langage C++ quel qu'en soit le projet, ça pouvait corroborer l'illusion dans laquelle je me suis fourvoyé

Bref, c'est plus vaste que tu ne le crois.

Alors ça me rassure sur le devenir de l'espèce humaine!

[metagoto]

minimiser CI=> augmenter le PBR=>se concentrer plus sur la conception et exploiter la richesse du langage.

Ce n'est pas idiot. Cependant, j'aurais tendance à penser que le CI est fonction du PB... quelque soit le langage. Un PB élevé induit un CI élevé ne serait-ce que par la nécessité d'exprimer le choix. Shannon et Chomsky pourraient en débattre mieux que moi -je pense

[Issam_Lahlali]

Ce n'est pas idiot. Cependant, j'aurais tendance à penser que le CI est fonction du PB... quelque soit le langage. Un PB élevé induit un CI élevé ne serait-ce que par la nécessité d'exprimer le choix. Shannon et Chomsky pourraient en débattre mieux que moi -je pense

le CI dépend du PB bien sur mais plus du design pour montrer ça ,on peut prendre un exemple simple d'IHM et on va réduire le C++ juste a l'objet donc réduire son PB a un langage qui ne fait que POO et on cherchera a faire de l'IHM,et on cherche les frameworks pour faire ca , on peut trouver MFC et QT , les 2 exploitent surtout l'objet donc le même PB mais il y a un gouffre entre les 2.

donc a PB égale on a deux CI très différents.

et on se pose la question pourquoi cette grande différence, et la réponse comme c'était évoqué plusieurs fois dans cette discussion n'est pas le fait que Qt exploite plus la richesse de C++ que MFC , les 2 utilise l'objet mais Qt ont beaucoup jouer sur son design avec des idées simples comme signal et slot et une bonne abstraction a la complexité de la couche IHM bas niveau de windows.

Qt pour moi est l'exemple le plus flagrant pour montrer l'intérêt de réduire le CI et voila ce qui passe concrètement avec un CI élevé:

si je bosse avec MFC qui a CI élevé , je prend très tôt en compte cette complexité et j'ai tendance a faire du "Code First" et la mon PBR est minimisé et tout mon projet devient conceptuelement merdique.

et c'est ce qui explique que lorsqu'on utilise MFC on a énormément de dérives de conception.

QT a un CI moins élevé , donc je peux tranquillement me concentrer sur la conception et je sais pas qu'il n y a pas un grand risque d'implémentation.

parce que si a un moment on sait qu'il y un risque au niveau implémentation on se concentre plus sur l'implémentation et on fait du "Code First" , on peut se battre avec cette tendance on essayant de passer plus de temps en conception tout en sachant qu'on passera bcp de temps en implémentation mais le planing casse cette initiative et on fait du "Code First".

et voila ce qui se passe concrètement pour une Lib donnée:

a partir d'une richesse de langage donnée je fais un design pour la Lib qui influence sa manière d'utilisation et influence la complexité d'implémentation de mon projet si j'utilise cette librairie.

et moi je crois a cette implication

bad design d'une lib=> CI élevée=>PBR moindre=>bad design de mon projet

donc utilisé des librairies mal conçue influence non pas que sur mon implémentation qui va être tordu mais aussi sur le design de mon application.

cette corrélation on l'a voit vraiment que dans la pratique, en théorie en se demande quelle relation entre l'utilisation d'une librairie mal conçu sur ma conception et la relation est ce CI et ce PBR.


c'est dans ce sens qu'on prône l'utilisation de librairies bien conçu parce que leur CI est minime mais qu'est ce qui se passe si on utilise déjà des librairies mal conçu, est ce qu'on les changent complètement?

la je dis c'est utopique et c'est pour cela qu'a chaque fois lorsqu'on me parle de Boost je réponds qu'il faut être réaliste, et la solution que je vois c'est essayer de minimiser la complexité engendré par ces librairies utilisés qu'on peut pas forcement changer du jour au lendemain avec d'autres plus simples d'où l'intérêt des facades/Ponts/Adaptateurs.

et pour voir l'intérêt de cette démarche je vous conseille ce livre C++ Network Programming: Mastering Complexity Using ACE and Patterns , et on voit bien dans le titre Mastering Complexity et la moitié du livre parle de Wrapper et Facade pour minimiser la complexité.


a mon avis il ne faut pas négliger le CI et il ne faut pas négliger la corrélation entre le CI des librairies utilisés et le design de votre application, et croyez moi un CI élevée tue rapidement la richesse d'un langage et on l'exploite pas a ça juste valeur et autant changer de langage si on le minimise pas.

[loufoque]

L'algorithmie, au fond, c'est facile, il suffit de savoir des maths, et d'avoir lu les bons livres. Après, on code (ou on récupère) les "bons" algos, on les teste, et c'est tout.

L'algorithmique, c'est une discipline théorique assez difficile, c'est pas un truc trivial du tout.
C'est souvent couplé à des méthodes assez fines de combinatoire, des séries génératrice, de l'analyse complexe, etc.

[Invité]

L'algorithmique, c'est une discipline théorique assez difficile, c'est pas un truc trivial du tout.
C'est souvent couplé à des méthodes assez fines de combinatoire, des séries génératrice, de l'analyse complexe, etc.

Oui, oui... Ce sont parfois (pas toujours) des maths difficiles, mais en entreprise, c'est rarement ça qui pose problème. Si tu as un problème de ce type, tu embauches un matheux, qui connaitra la théorie, ou lira les bons livres, et c'est réglé. Comme tout le système éducatif français est fondé sur la sélection par les maths, il n'est pas très dur d'embaucher des matheux. Si t'as un problème très très difficile, tu vas chercher des normaliens, des X, des centraliens, si c'est un peu moins matheux tu vas probablement prendre des thésards ou d'autres écoles, s'il y a beaucoup de stats, tu vas aller voir du côté de l'ENSAE... Et ainsi de suite.

Et si tu as un problème ponctuel, tu vas t'acoquiner avec un universitaire pointu qui contre forte rémunération mettra en place les 3 ou 4 algos qui comptent dans ton logiciel. Une fois ceux ci trouvés, écrits (ou recopiés) et testés, tu es habillé pour l'hiver.

C'est en ce sens que je dis que c'est facile. Du point de vue de l'entreprise, c'est déterministe et prévisible. Le reste du développement (architecture, interface, maintenance, évolution) c'est une autre paire de manches...

(et puis tout n'est pas dur : la combinatoire et les séries génératrices, avec un bon bagage de prépa et une fois qu'on a pigé le truc, ça ne vole pas très haut, quand même)

Francois

[koala01]

Attention quand même à ne pas limiter l'algorithmique aux seules mathématique de (plus ou moins) haut niveau...

L'algorithmique, c'est aussi, tout simplement, et je dirais presque essentiellement, le fait de pouvoir aller d'un point A à un point B en apportant la meilleure efficacité et le plus de sécurité possible (ou, à défaut, le meilleur compromis entre les deux).

Et c'est sur tout ce pan de la programmation que l'algorithmique rejoint la conception et l'analyse des besoins, parce que, bien souvent, l'efficacité ira de paire avec le choix opportun des structures, sur base des besoins les plus importants