Pourquoi la communauté C++ s'intéresse plus à la technique et ignore la conception ?

Le , par Issam_Lahlali, Membre extrêmement actif
Bonjour,

Depuis la naissance de C++ et la communauté se focalise plus sur la technique et ces astuces.

Or s'intéresser a la conception simplifie beaucoup de choses et contribue a rendre l'utilisation de C++ très simple.

Malheureusement les sociétés commencent à fuir c++ à cause de sa complexité puisqu'on perd beaucoup de temps au niveau des couches techniques or l'essentiel c'est la couche métier.

La communauté DotNet et Java s'intéressent plus a la conception et ça se voient dans la facilité d'utilisation de leurs frameworks.

Quand la communauté C++ s'intéressera plus a la conception ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Mac LAK Mac LAK - Inactif http://www.developpez.com
le 07/09/2009 à 16:57
Citation Envoyé par white_tentacle  Voir le message
Je ne remets pas en cause la nécessité de faire du code spécifique.

Je me trompes peut-être, ou ce n'est pas assez clair, mais c'est l'impression générale qui découlait de tes propos (et de ceux de koala01 et Luc Hermitte) : l'impression que "STL=panacée"... Après, je le martèle encore une fois : vous avez raison de façon générale, SAUF quand on va vers les limites de la machine (taille des données ou performances).

Citation Envoyé par white_tentacle  Voir le message
Par contre, j'estime qu'il y a une réelle plus value à le faire en restant dans l'interface de la STL, via spécialisation de templates, car :
- cela garde un code auquel le développeur est habitué

Et c'est justement ce que je reproche : j'ai souvent vu le cas avec des débutants dans le code critique (et, hélas, pas forcément des débutants en développement) qui, "parce que ça y ressemble", te collent une std::map<std::string,std::vector> (ou autre horreur du même genre) en plein milieu d'un goulet d'étranglement...
L'avantage d'utiliser un container non standard, c'est que cela oblige le développeur qui reprends le code à réfléchir avant de faire n'importe quoi. Même si, au final, il a exactement les mêmes fonctions que dans le container STL, simplement nommées différemment et/ou avec certaines défections (méthodes ou paramètres).

Citation Envoyé par white_tentacle  Voir le message
- cela peut être fait après coup (et donc, après mesure, car il est difficile de déterminer à l'avance où seront les goulets d'étranglement), avec quasiment zéro coût de migration (aucun code à changer).

C'est hélas un vœu pieux : d'une part, par expérience, il y a des endroits / types de code où l'on sait par avance qu'un container générique sera moins efficace.
D'autre part, les mesures, tests et autres analyses dynamiques dans ce genre de code sont souvent pénibles à faire, et prennent pas mal de temps. Comme dans 99% des cas, on connait le résultat à l'avance, autant passer directement sur la solution "correcte" (d'un point de vue performances) plutôt que d'essayer deux méthodes et, au final, perdre du temps.

De plus, ce genre de code est en général tellement "en dur" que les codes du genre "zéro modifications" sont souvent illusoires, même si je suis le premier à le déplorer. Je sais, ça parait toujours étrange et bizarre à ceux qui n'ont jamais mis les mains dans ce genre de code, mais c'est une réalité pourtant.
On peut faire des templates maison pour améliorer un peu ce phénomène, mais ce n'est jamais du code "bisounours" où tout le monde est beau et modulaire...
Avatar de Luc Hermitte Luc Hermitte - Expert éminent http://www.developpez.com
le 07/09/2009 à 17:09
Une bonne règle est celle de Michael A. Jackson : "1. do not optimize. 2. do not optimize (yet), for guru/expert only". (de mémoire)

Pour l'error safety, offrir la garantie forte n'est souvent qu'une question d'ordre des instructions plus un test et une affectation, et elle va intervenir sur les ajouts -- relativement à la partie qui concerne un conteneur. Je n'estime pas qu'il s'agisse d'un prix exorbitant à payer -- face au risque de quelqu'un qui implémente à une croissance à coups de new[] avec une taille incrémentée de 1.
Se passer du test ? Hum ... Rien de tel pour avoir des comportement non déterminés ou des plantages. Reste la solution d'interdire les allocations. ~~> Pas de croissance possible ? Facile. On s'expose pas le push_back sur un héritage privé.

Reste la zéro-initialisation, qui fait en fait souvent parti de règles qualité de toutes façons. J'avais croisé une solution itérable à cette pessimisation.

Pour les mutex, mon problème n'est pas tant dans leurs performances, que dans le fait que personne n'est correctement formé pour s'en servir sans introduire de deadlock -- les sémaphores que je n'utilise jamais, j'avais vu ; les hiérarchies de mutex, les tâches, les compteurs atomiques, ..., pratiquement que dalle. (A ce sujet, Stroutrup a sorti des articles au sujet de conteneurs lock-free il y a peu).

PS: ma réaction vient de "mon code à moi coute moins cher à écrire et maintenir" -- je simplifie.
Avatar de - http://www.developpez.com
le 07/09/2009 à 17:21
Citation Envoyé par white_tentacle  Voir le message
- cela garde un code auquel le développeur est habitué

Oui, c'est même une règle générale : si on fait du code maison, conserver autant que possible interfaces et conventions standard. Il me semble que la STL aide beaucoup, dans ce domaine. En fait, il n'est pas facile, une fois qu'on en a pris l'habitude, d'écrire du code "incompatible".

Citation Envoyé par white_tentacle  Voir le message
- cela peut être fait après coup (et donc, après mesure, car il est difficile de déterminer à l'avance où seront les goulets d'étranglement), avec quasiment zéro coût de migration (aucun code à changer).

C'est là où je ne suis pas d'accord. Les cas où l'optimisations est nécessaire, ils sont peu nombreux et on doit les connaitre à l'avance. Savoir où sont les quelques appels cruciaux, les volumes de données impliqués, et les algorithmes qu'il faut appliquer, c'est un problème de conception, ca se traite avant le dev. Après, c'est trop tard, et c'est là que l'optimisation mène à des horreurs.

Francois
Avatar de white_tentacle white_tentacle - Membre émérite http://www.developpez.com
le 07/09/2009 à 17:29
C'est là où je ne suis pas d'accord. Les cas où les optimisations sont nécessaires, ils sont peu nombreux et on doit les connaitres à l'avance. Savoir où sont les quelques appels cruciaux, les volumes de données impliqués, et les algorithmes qu'il faut appliquer, c'est un problème de conception, ca se traite avant le dev. Après, c'est trop tard, et c'est là que l'optimisation mène à des horreurs.

Pour moi, tu mélanges deux choses. L'optimisation des algorithmes, qui est effectivement faite en face de conception, et l'optimisation de l'implémentation, qui elle se fait pendant/après l'implémentation.

Si tu en es à réfléchir à implémenter un vecteur maison pour ton type de données pour supprimer deux trois tests qui traînent dans la STL, c'est clairement de l'optimisation d'implémentation.
Avatar de Mac LAK Mac LAK - Inactif http://www.developpez.com
le 07/09/2009 à 17:32
Citation Envoyé par Luc Hermitte  Voir le message
Je n'estime pas qu'il s'agisse d'un prix exorbitant à payer -- face au risque de quelqu'un qui implémente à une croissance à coups de new[] avec une taille incrémentée de 1.

Ce qui commence mal : une allocation dynamique dans un code critique ????
Hum hum....

Citation Envoyé par Luc Hermitte  Voir le message
Pour les mutex, mon problème n'est pas tant dans leurs performances, que dans le fait que personne n'est correctement formé pour s'en servir sans introduire de deadlock -- les sémaphores que je n'utilise jamais, j'avais vu ; les hiérarchies de mutex, les tâches, les compteurs atomiques, ..., pratiquement que dalle. (A ce sujet, Stroutrup a sorti des articles au sujet de conteneurs lock-free il y a peu).

Je ne sais pas pour toi, mais pour ma part, j'ai eu des cours d'archi parallèle en fac, où l'on a été bassinés en long, en large et en travers sur tous les éléments de synchronisation usuels, sur les cas vicieux de deadlocks, etc. Ayant justement très peu de deadlocks dans mes programmes grâce à ça (99% du temps un simple oubli, visible en dix secondes de debug maximum), je peux difficilement laisser dire que "personne n'est formé".
Quant aux conteneurs lock-free... J'utilise des techniques lock-free sur ce genre de code depuis des années, apprises "sur le tas" et/ou conçues exprès pour virer, justement, des mutex beaucoup trop gourmands en temps CPU. Pour moi, ce n'est pas quelque chose de "récent", c'est quasiment la règle de base.
C'est juste pour que tu comprennes bien que c'est un domaine tout à fait spécifique et particulier, justement parce que situé aux limites normales du code, et donc forcément en dehors de la normale par plusieurs aspects.

De la même manière qu'un moteur de BD ne fonctionne pas avec des "std::map" pour chercher dans les tables, d'ailleurs...

Citation Envoyé par Luc Hermitte  Voir le message
PS: ma réaction vient de "mon code à moi coute moins cher à écrire et maintenir" -- je simplifie.

Je comprends ta réaction. Mais c'est pourtant le cas, en conservant le facteur primaire de performances avant tout le reste.
Avatar de Luc Hermitte Luc Hermitte - Expert éminent http://www.developpez.com
le 07/09/2009 à 18:05
Pas d'alloc dynamique ? (comment ça j'attendais que tu le confirmes ? ) Il ne reste que la 0-initialisation qui peut couter plus cher que nécessaire sur un vecteur.

Citation Envoyé par Mac LAK  Voir le message
Je ne sais pas pour toi, mais pour ma part, j'ai eu des cours d'archi parallèle en fac, où l'on a été bassinés en long, en large et en travers sur tous les éléments de synchronisation usuels, sur les cas vicieux de deadlocks, etc. Ayant justement très peu de deadlocks dans mes programmes grâce à ça (99% du temps un simple oubli, visible en dix secondes de debug maximum), je peux difficilement laisser dire que "personne n'est formé".

Les hiérarchies de mutex sont le concept essentiel que je n'ai découvert que récemment. Je ne sais pas si c'est parce que je dormais durant ce cours ou si cela avait été occulté, mais j'avais retenu plus de choses sur les outils de synchronisation que je n'utilise jamais que sur ces hiérarchies de mutex.
Qu'est-ce qui me fait dire que je n'étais pas le seul ? Des codes que j'ai croisé et qui abusent de mutex -- car abus d'états partagés. Avec une réflexion dès la conception pour voir qu'il n'y avait un gros sac de noeud en place d'une hiérarchie, les choses auraient été différentes.

Pour les lock-free, j'ai l'impression que c'est récent comme approche (du moins, c'est moins confidentiel qu'avant), mais les implémentations qui marchent me semblent brevetées...
Avatar de Mac LAK Mac LAK - Inactif http://www.developpez.com
le 07/09/2009 à 18:54
Citation Envoyé par Luc Hermitte  Voir le message
Pas d'alloc dynamique ? (comment ça j'attendais que tu le confirmes ? ) Il ne reste que la 0-initialisation qui peut couter plus cher que nécessaire sur un vecteur.

Attention : l'initialisation d'un code critique n'est PAS critique... Le code critique, c'est celui qui tourne en boucle, hors initialisation et finalisation. Oui, je sais, c'est vicieux.
Donc, t'as le droit à un new/malloc à l'init, mais pas pendant le fonctionnement (à fortiori, encore moins le droit aux resize/realloc bien sûr).

Citation Envoyé par Luc Hermitte  Voir le message
Qu'est-ce qui me fait dire que je n'étais pas le seul ? Des codes que j'ai croisé et qui abusent de mutex -- car abus d'états partagés. Avec une réflexion dès la conception pour voir qu'il n'y avait un gros sac de noeud en place d'une hiérarchie, les choses auraient été différentes.

T'inquiètes pas, j'en ai vu aussi : non, tu n'es pas fou, ni maudit, ni persécuté par les serial-mutexeurs...
Comme toujours, il y a des gens qui les utilisent sans savoir le faire réellement. Mais il y a aussi des gens qui savent les utiliser, et surtout QUAND les utiliser, simplement ils ne sont pas légion.

Citation Envoyé par Luc Hermitte  Voir le message
Pour les lock-free, j'ai l'impression que c'est récent comme approche (du moins, c'est moins confidentiel qu'avant), mais les implémentations qui marchent me semblent brevetées...

Brevetés, je ne sais pas, mais confidentiels et en code fermé, ça je peux te le garantir par contre... Mettre 50% de perfs dans les dents à la concurrence, ça vaut son pesant d'or et tu tiens donc le "comment" secret.
Avatar de Issam_Lahlali Issam_Lahlali - Membre extrêmement actif http://www.developpez.com
le 07/09/2009 à 20:53
Pour cette histoire de code critique il y a des techniques qui demandent surtout un code fait maison, par exemple Pool d'allocation et le Cache c'est deux la peuvent affecter les performances d'une manière très significative et en général leurs implémentations reste spécifique a ce qu'on veut faire.

par exemple pour doxygen, ou il y a utilisation d'un cache fait maison pour accélérer le traitement, j'ai fait l'expérience de virer le cache et le temps a tout simplement doublé pour le traitement de certains projets.

Pour l'abstraction et la simplification de la couche technique qui était l'origine d'une grande querelle, j'ai tomber par hasard sur un post du créateur de boost.asio qui dit:

Code : Sélectionner tout
1
2
3
4
5
6
7
8
 
A design goal of asio is to provide a basis for further levels of  
abstraction. One of the ways to develop abstractions on top of  
asio is to create what I like to call composed operations. These are  
simply operations that are made up of calls to other lower-level  
operations. Asio already includes some composed operations to address  
common network programming problems: async_read and async_write to deal  
with short reads and writes; and async_read_until to perform delimited reads.
a un moment j'ai insister qu'on peut faire une abstraction pour une librairie existante pour notre besoin spécifique et j'avais pris comme exemple boost.asio justement , vu que les librairies en général propose des fonctionnalités génériques, mais il y avait une grande résistance

le but la n'est pas de relancer le sujet, parce que je pense que ça ne se terminera jamais mais le but est de montrer que c'est un point de vu que beaucoup le partage, et chacun a sa manière de structurer et concevoir, il n y a pas de manière unique.
Avatar de Arkal Arkal - Membre régulier http://www.developpez.com
le 18/02/2011 à 21:11
Le vrai vrai de vrai, vraiment réél probleme de C++, c'est qu'en tant que développeur en dotNet, avec un framework qui possede un très grand nombre de librairies, ou tu peux ajouter enterprise library, entity framework ou nhibernate ou une tonne d'utilitaires très pratique facile, c'est difficile de se retrouver dans un monde C++ ou tout est disparate et non standard, t'as le choix de plein de librairies, pas toujours facile à trouver, pas toujours facile à inclure dans un projets et ca rend la complexité tellement grande que c'est difficile de monter un environnement de developpement en C++ pour faire quelques applications que ce soit....
Avatar de - http://www.developpez.com
le 19/02/2011 à 15:17
certains trouvent que c'est un problème, d'autres que c'est mieux comme ca.
Si C# et C++ etaient similaire, quel interêt d'avoir les deux?
Avatar de r0d r0d - Expert éminent http://www.developpez.com
le 22/02/2011 à 10:50
Pour ma part, je dirais que c'est parfois un problème, parfois un avantage.
Mais j'avoue que c'est parfois assez énervant. Du coup, j'ai de plus en plus tendance à programmer en java ou en c# lorsque je dois faire des applis simple, standar (dans le sens: qui n'ont pas besoin de faire des choses vraiment spécifiques) et avec peu de contraintes (rapidité et portabilité principalement).
Mais parfois, le C++, voire le C, sont tout simplement indispensables. Et au final, avec un peu d'expérience, on fini par s'habituer à la "constellation" de bibliothèques et a apprendre à les utiliser sans trop se prendre la tête.
Offres d'emploi IT
Linéarisation d'amplificateur RF H/F
Atos - Provence Alpes Côte d'Azur - Aix-en-Provence (13100)
Ingénieur vhdl h/f
Atos - Provence Alpes Côte d'Azur - Aix-en-Provence (13100)
Développeur .net
HUMANLOG - Provence Alpes Côte d'Azur - Sophia Antipolis

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique C++