Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Le temps de développement et la complexité de mise en œuvre d'une architecture modulaire (pourtant très simple en java et c#).
Trop de possibilités offertes aux développeurs de faire n'importe quoi (ex : les différents type de chaines de caractères).
Une lecture trop complexe pour les non-initiés.
Cela dit, le c++ a beaucoup d'avantages en termes de déploiement, de rapidité du code, de parallélisme, et de choix d'architecture, par rapport aux langages "plus" évolués.
Bonjour,
n'ayant pas fait beaucoup d'autre langage, je ne me permets pas de donner un avis!
par contre, je n'arrive pas à comprendre l'argument :
Pour moi, une des différences principale entre le C++ et les 2 autres langages citées est le garbage collector!complexité de mise en œuvre d'une architecture modulaire (pourtant très simple en java et c#)
Pourriez-vous m'éclairer ou approfondir l'argument?
Tu sais que des garbage collector existe aussi en C++?Envoyé par zenetcalme
C'est le problème et l'avantage du C++ : tout existe... mais personne n'utilise la même chose.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Malheureux, tu n'imagines pas. Les pointeurs doivent toujours tous être gérés à la main en C/C++. Toujours!
PS: lien rajouté
PPS: (pɹɐbé un,p snןd à ʇǝ) ¿ uıǝɥ 'zǝʌɐs snoʌ 'ǝnbıuoɹı ʇsǝ,ɔ
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
Bonjour,
J'ai une experience de quelques années en C, puis C++ pour finir sur Java.
Le C était pour moi un trés bon langage, certes avec des défauts.
A l'inverse C++, m'a beaucoup déçu et ce pour plusieurs raisons:
- Mixité entre C et C++ comme déja beaucoup souligné ici
- Surcharge d'opérateur : Au début c'est magique, on adore... mais on adore pour soit !!! quand on se reprend un code source où la surcharge d'opérateur a été utilisée à profusion, ça devient complétement illisible. Avec du recul, c'est un mécanisme à éviter en POO même si c'est tentant (c'est un peu le champ de la siréne...)
- Pour moi, le pire dans tout ça, concerne le polymorphisme désactivé par défaut (faut déclarer explicitement les méthodes polymorphes), ce qui va à l'encontre même de la POO...
Pour le reste, il hérite quelques inconfortabilité du C, la compilation et l'édition de lien peuvent vite devenir galère quand on a 10000 libs et qu'on veut mettre en place des scripts de compilation multi-plateforme (voire de cross-compil).
Bref, pour moi C++ ne vaut pas la star qu'est son grand père (C).
JBusyComponent, une API pour rendre occupé un composant swing.
SCJP Java 6.0 (90% pass score)
Pour ce qui est du mac ( et donc iphone ...) il me semble que c'est plutôt de l'objective C non?
Pour tout ce qui est WEB, je pense qu'on a plus de Java/php/c# ... que de C/C++ ( il doit plus en rester beaucoup à faire du CGI ..), et ça je pense que ça commence à représenter un gros pourcentage des développements actuels.
En fait on pourrait se passer de C++ : on peut le replacer par du Java/c# dans la plupart des cas, sauf là où la performance est primordiale ( embarqué, noyaux des OS) mais dans ce cas le C est souvent utilisé.
Le seul avantage qu'il lui reste, c'est qu'il est l'un des rares langages objets à générer du code natif.
Sinon un autre inconvénient du C++ est sa très faible évolutivité comparé à des langages plus 'vivants' comme Java ou c#. ( mais ça peut être considéré comme un avantage)...
JB
Effectivement, je ne savais pas qu'on pouvait avoir aussi un garbage collector en C++.
mais bon, du coup, je comprends encore moins la différence entre le C++ Java C# etc...
une architecture logicielle est quasi indépendante du langage de prog utilisé non?
a- Parfois j'ai l'impression que les gens critiquent les vélos parce qu'ils ne sont pas adaptés aux escaliers et que du coup il faudrait toujours se balader à pieds.
Oui, il y a aura toujours des garnements qui utiliseront de travers ce qu'ont leur met à disposition. Reste que c'est bien plus agréable à utiliser que les interfaces SAXPYiennes des BLAS, ou même de ce que l'on trouvera en Java.
b- Bien au contraire. Je me permets de copier-coller de la prose que j'avais écrite pour un doc de qualité:
Un petit exemple qui illustre cela : les listes et les listes triées. Quelqu'un d'un peu naïf pourra croire qu'il suffit de dériver une classe liste pour définir une classe listetriée après avoir redéfini la fonction d'insertion pour insérer au bon endroit. Sauf que cela sabotera complètement le contrat de la liste.3.7.8. Les fonctions membres d'une classe ne seront pas déclarées virtuelles par défaut. Elles le seront uniquement si cette fonction correspond à un point de variation prévu lors de la conception de classe.
Une école tend à définir toutes les fonctions en virtuel : « mettons la fonction en virtuel, quelqu'un pourrait vouloir la supplanter ». Seulement...
Si une fonction ne correspond pas à un point de variation [Coplien1998] prévu lors de la conception, il reste peu probable que l'on puisse étendre le système simplement parce que la fonction était virtuelle. Bien souvent, rajouter correctement un point de variation non initialement prévu demande un refactoring non trivial du code, c'est-à-dire bien plus qu'ajouter un simple "virtual".
Bien sûr, plus les fonctions d'une classe respectent la règle Section 3.1.3, « Une fonction doit faire une chose, et doit le faire bien. Ainsi, le nombre de lignes d'instructions efficaces (générant du code exécutable) d'une fonction doit être limité à 50 lignes, soit environ un demi écran moderne. On évitera également l'abondance de niveaux d'imbrications. », plus il est simple d'introduire des points de variations à la volée. Seulement si toutes sont virtuelles, cela veut aussi dire que toutes ces fonctions membre (en nombre plus ou moins important) peuvent être supplantées. Les classes filles auraient alors une visibilité complète de la classe mère. De cette rupture d'encapsulation inter-générations, il devient alors vite complexe de savoir ce qui peut être supplanté, et sous quelles conditions (contraintes).
De plus, les hiérarchies polymorphes ayant naturellement une sémantique d'entité, définir virtuelle une quelconque fonction membre d'une classe à sémantique de valeur n'a aucun sens. C'est aussi pour cela qu'aucun conteneur de la bibliothèque standard ne dispose de fonction membre virtuelle (voir la règle Section 3.7.7, « Éviter de dériver de classes non prévues pour être des classes de base. »).
Enfin, virtual introduit un sur-coût lors d'un appel de fonction où il n'était pas nécessaire. De fait, pour des raisons d'optimisation, on évite également de payer inutilement pour un service dont on n'a pas besoin : à savoir un branchement conditionnel déterminé à l'exécution (NB: il n'y aucune différence de rapidité, voire de meilleures performances sont à attendre de virtual par rapport à des if en chaîne, un switch-case, des tables d'indirection, etc.).
Références
[Meyers2002], [Hejlsberg2003].
Accessoirement, la liaison tardive n'est qu'un des aspects du polymorphisme (d'inclusion -- mine de rien, le C++ en supporte 3 autres). virtual n'est pas nécessaire pour utiliser en place de.
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
Pour moi un des plus gros défaut du c++ ( qui vient probablement plus des compilateurs que du c++ lui même ) est le manque d'avertissement.
Combien de fois je me suis arraché les cheveux avant de voir que j'avais initialisé la variable ... ( et vu que c++ prend ce qui est a l'emplacement pointe a la place de l'initialiser .... )
un petit Warning disant "variable non initialise" ne ferait pas de mal certaines fois.
De plus je ne peux qu'être d'accord sur l'obscurantisme des messages d'erreur des templates .. ( dommage que ça ait finalement été rejeté pour le c++1x)
Cela dit je suis contre les arguments pur OO avances par certains dans ce thread, c'est, à mon avis ce qui fait la grand force du c++.
L'OO, de par le manque de formation est-ce que je considère comme un des pires fléau de l'optimisation.
Certes, c'est très pratique, et il n'y a aucune raison de s'en priver, mais il n'y a non plus aucune raison de l'évangéliser.
Combien de fois un design oriente plus "data" que strictement "Object" peut nous faire gagner en performances, et c'est justement là la force du c++, nous laisser faire nos propres choix.
On retombe tout a fait dans ce qui a été dis dans certains post, le manque de formation et de gens compétents et un des plus gros problème du c++.
Ça me fait penser que le mot-clé "virtual" n'était peut-être pas le plus clair pour annoter une méthode pouvant être redéfinie. A moins de s'intéresser au fonctionnement interne du runtime du C++, c'est même assez abstrait.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Et j'ajouterais qu'avec des éditeurs modernes comme Eclipse, quand on programme en Java(c'est aussi valable pour C# sous VStudio), on peut réduire le code aux déclarations de méthodes/classes (grâce au symbole +). Une fois réduit le fichier ressemble à un .h. Sauf qu'en Java ou C# pas de redondance .h/.cpp...
Je suis largement pro-C++ mais il faut avouer qu'en terme de productivité le couple Java/Eclipse explose littéralement C++/Visual ou tout autre éditeur que j'ai pu tester. En C++ je me retrouve à recopier sans cesse du code, alors qu'en Java je peux remplir des pages en tapant quelques lettres et en jouant du click (ah la complétion sur une lettre quel bonheur <3 ).
Mon seul espoir réside dans QtCreator qui reprend justement beaucoup de principes d'Eclipse ( détections d'erreurs de syntaxes à la volée, complétion bien plus avancée que VC++...).
Je n'est pas d'info là dessus par contre :
d'après un conférencier au TechDays 80% des richesses produites par le développement logiciel est fait par 5% des entreprises qui font du C++. Ce qui est normal lorsque l'on sait qu'il y a Windows, Visual Studio, Office et de nombreux autre et surtout quasiment toute l'industrie vidéo ludique ce qui fait beaucoup d'argent...
Salut
Ca mon cher, c'est vrai dans un beau monde utopique ou tout le code livré est documenté. Quand tu développes en environnement industriel, les codes des collègues sont mieux documentés par les *.h que par autre chose.
Je suis par contre d'accord pour dire que la dualité *.h/*.cpp est un peu lourde, mais elle présente tout de même des avantages. C'est plus facile pour moi de lire les *.h des collègues que de lire des implémentations directement. Elle a aussi le mérite de séparer la description structurelle des objets et le code procédural applicatif dans deux fichiers différents. Ce n'est pas si mal.
Find me on github
Ça par contre c'est la faute au chef d'équipe qui n'a pas entretenu la qualité de son code. Je peux comprendre que du temps de la création du C++, la plupart des informaticiens étaient des barbues dans leurs caves qui avaient la flemme d'écrire de la doc. Il fallait bien faire une séparation claire entre l'implémentation et la déclaration pour favoriser la ré-utilisabilité. Aujourd'hui avec une dizaine(centaine?) de petites équipes de 5 personnes, le minimum est une doc bien faite. C'est plus important que le code lui même. D'ailleurs tous les outils actuels permettent l'ajout simplifié de commentaire pour chaque action effectuée par un membre de l'équipe.
Est-ce que sérieusement on peut se passer du .h (ou équivalent) pour des langages compilés en code natif ?
Si Java et assimilés peuvent s'en passer c'est que le mécanisme de Reflection et le parsing du byte code permet de connaître exactement le prototype d'une méthode…
Une fois compilé - et sans l'aide de fichier de symboles pour le debugging - il ne reste plus que la taille des paramètres sur le stack dans le binaire…
même l'ordre des paramètres peut-être affecté par des pragma…
(par exemple pour indiquer l'ordre "Pascal" plutôt que "C"…)
ou le namespace ("C" ou "C++"…) qui va affecté l'édition des liens…
le "header file" reste, faute de mieux, la solution la plus pratique pour donner le minimum d'informations nécessaires pour utiliser une librairie compilée dont on ne dispose pas des sources…
et pour ce qui est de la POO et C++ :
"Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.",
Alan Kay
Ça par contre je n'y avais pas pensé
J'interviens juste pour faire quelques remarques :
Ne prenez pas le C/C++ pour les Dieux des langages.
Beaucoup de firmeware utilisent des langages adhoc, beaucoup de BIOS (celui des Mac notamment) utilisent du Forth, qui est bien plus adapté pour faire du code compact et performent que le C.
Le problème du Forth, c'est qu'il est spécialisé et donc avec très peu de fonctions.
A la fin, code natif ou code interprété, c’est du code machine, qui est un langage, qui est exécuté. Sans compter le microcode dans les CPU.
C/C++ sont des langages polyvalents qui ont servi au début dans les OS, doit leur omniprésence dans ce domaine (plus le C que le C++). Mais les OS ont généralement besoin d'être polyvalents, mais rarement les applications. Le développeur, lui, aime être polyvalent donc un dédain/peur des langages spécialisés.
Il ne faut pas non plus se leurrer, un avantage indéniable pour l'acceptance du C++ était sa proximité supposé avec le C.
Maintenant, cela joue en sa défaveur mais on ne peut pas tous avoir.
Le fait de la multitude d'intervenant dans la norme C++ peut expliquer bien des choses que je voudrais souligner par un exemple.
Bon nombre de personnes n'aime pas le diptyque .H/.CPP. D'autres trouve cela indispensables pour une bonne organisation.
Les deux ont raison et le fait qu'il y ai un nombre très important d'intervenant dans C++, interdit de compenser des lourdeurs par de l'outillage.
Si l'on prend des langages comme C# ou Java, avec les IDE VS et Eclipse, les outils de refactoring influences directement le langage.
La qualité d'un langage tient, maintenant que la puissance CPU des stations des développeurs est "considérables", énormément dans son "écosystème".
Le C++, par son ouverture, ne dispose pas actuellement d'un écosystème aussi efficace au niveau productivité. Quantitativement, grâce à Intellisence par exemple, mais aussi qualitativement, par les outils de tests automatiques et d'analyse de code.
"lint" contre "Code Analysis" : au moins 20 ans d'écart.
Je pense que le fait que le C++ reste un langage "Notepade-aware" bride énormément son évolution.
Les fichiers d’en-tête ont été conçus pour accélérer la compilation. N’oubliez pas que C a été conçu au début des années 70, sur des PDP-11 je crois.
Avec un IDE, qu’il y est un fichier d’en-tête ou pas ne devrait être qu’un détail qui n’influence pas le langage.
Java qui début publiquement en 1995 sur Pentium Pro n’a pas les même contraintes.
Le fait de définir des interfaces avec les .h n’est qu’un effet de bord, vertueux je l’admets, mais ne remplace par la définition de vrais interfaces. Un IDE peut facilement faire l’extraire l’API d’une classe de manière automatique (facile aujourd’hui mais pas en 1971)
En résumé, le langage n’est pas le problème, c’est sont écosystème hétérogène qui bride son évolution aux besoins des années 2010 et non aux besoins de 1971 (C) ou de 1985 (C++).
Salut
Même idée, le jour ou tous les chefs d'équipe pourront toujours tout faire proprement et documenté dans le délai imposé par leur supérieur n'est pas arrivé, sinon ça se saurait. Il y a effectivement des commentaires formatés, et nous nous en servons, et c'est ce qui sert de doc. Commentaires + signatures des méthodes, dans la majorité des cas, c'est une doc suffisante pour développer. Dans mon cas, on est 2000 à taffer en intégration continue sur un code commun, alors autant te dire qu'au niveau qualité, il y a un suivi et des outils assez poussés, sinon ça se casse vite la gueule.
Mais qu'on soit bien clair : là je parle de code en interne. le code exposé aux clients est documenté, cela va de soi.
Find me on github
a- Ne déclare plus jamais une variable autrement que const (ou comme indice de boucle-for), et tu verras ce problème disparaitre.
La règle en C++ est de toujours retarder la définition d'une variable jusqu'au moment où l'on peut l'initialiser à une valeur qui a du sens, et de préférence à une valeur finale.
Maintenant, une fois de plus l'héritage de langages d'une autre époque font que beaucoup croient qu'il est plus propre de déclarer toutes les variables en début de fonction -- et à côté de ça ils feront des fonctions de 3km de long sans sourciller.
b- les concepts reviendront peut-être pour une prochaine mouture, en attendant il y a toujours STLfilt (je vous ai parlé de STLfilt ? (je ne sais pas pourquoi, je sens que cela va revenir))
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager