Discussion :

[koala01]

Salut,

Si je me souviens : Le C++ n' est qu' une forme de syntaxisme qui crée un mode de vision (objet) et donc qui signale les dérappagent par des règles de compilation qui seraient plutot des règle de précompilation.

Conclusion : Il s'gait d'un concensus ... pour justement pouvoir partager entre développeur ... Et je n'ai jamais connu cette phase ...

Justement, le gros de la puissance du C++ ne vient pas du paradigme objet, mais bel et bien du fait qu'il permet de combiner à notre guise trois paradigmes pourtant considérés comme particulièrement distincts (ce qui est normal, vu qu'un paradigme est considéré comme un rail dont il est dangereux de s'écarter, cf la définition donnée par wikipedia).

Mais, comme l'orienté objet est déjà mal compris à la base (non : le principe fondamentale de l'OO, ce n'est pas l'encapsulation comme beaucoup de vieux le pensent encore, mais bel et bien la substituabilité au termes du respect du LSP; qui est souvent très mal compris lui aussi d'ailleurs) et que les langages qui "ont le vent en poupe" (ou qui l'on eu... allez savoir) on tapé sur le clou OO au point que certains ont l'impression qu'ils ne peuvent plus faire que cela sans se prendre une mandale, je peux personnellement comprendre que certains "affisionados" du procédural hésitent très sérieusement avant de se lancer dans l'étude d'un langage qui passe encore trop souvent pour être "orienté objets".

Alors, oui, bien sur, il y a la forme canonique orthodoxe de Coplien ou la règle des trois grands (qui est devenue la règle des cinq grands depuis l'apparition de la sémantique de mouvement) qui nous incitent à appliquer le RAII, la dualité entre la sémantique d'entité et la sémantique de valeur qui gagne vraiment à être prise en compte (j'irais meme jusqu'à dire : qu'il est criminel de ne pas prendre en compte), et oui, tout cela, ce sont des concepts OO auxquels on a tendance à être très attaché.

Mais le fait est que ce sont justement ces concepts (qui pourraient très bien être adaptés en C, du moins dans une certaine mesure) qui nous permettent d'obtenir des choses "sécurisantes" à l'utilisation, sans souffrir de pertes de performances et qui permettent au compilateur de constater de nombreuses erreurs impossible à détecter en C.

Mais il ne faut pas oublier que C est un langage particulièrement laxiste, car il nous permet de transtyper strictement n'importe quoi en n'importe quoi d'autre sans tirer la moindre sonnette d'alarme et ce, même s'il n'est simplement pas opportun de permettre le transtypage en question.

Et l'on peut encore continuer à énumérer les faiblesses du C, avec la possibilité qu'il donne de fournir "n'importe quel nombre de paramètre" à une fonction, sans nous donner réellement les moyens de nous assurer qu'ils sont "en nombre suffisant" et du type adéquat ou qu'il nous permet d'ignorer purement et simplement un retour de fonction ou, à contrario, que si l'on veut garantir la sécurité de tous les chemins d'exécution potentiels, on est rapidement parti pour gérer une quantité de tests et de valeurs différentes propres à donner le tourni à un dervishe tourneur!

J'ai lu à peu près toutes les interventions depuis que le fil a été ouvert. Et beaucoup de pro C (anti C++) ne se plaignent finalement que d'une seule et unique fonctionnalité : la possibilité de pratiquer un héritage public. Or, c'est une des fonctionnalités dont on peut sans doute se passer le plus facilement en C++. Et n'allez pas croire que la présence d'un constructeur, d'un constructeur de copie, d'un opérateur d'affectation et d'un destructeur soit faite pour vous embêter!!! Bien au contraire, ce sont les fonctionnalités qui vous permettent de garantir à peu de frais que n'importe quel objet est dans un état valide dés sa création, et qu'il le reste jusqu'à ce qu'il sera détruit.

Après, si vous tenez à refuser toute fonction membre autre que ces quatre là (il faudrait encore m'expliquer pourquoi, car une fonction membre n'est jamais que l'équivalent d'une fonction libre à laquelle on dont implicitement un pointeur sur la donnée courante), libre à vous de le faire... Avec la facilité (entre autre) de pouvoir profiter de la surcharge de fonctions, de la prise de décision (et d'une très forte capacité à reprérer les incohérences) à la compilation, j'en passe, et de meilleures!

[romatou18]

Les commentaires en défaveur du c++ ne manque pas apparament...

Un bon professionel est bien souvent celui qui sait doser les efforts et utiliser les bon outils au bon moment. Comme un ebeniste n'utilise pas le rabo pour faire les finitions, mais la ponceuse, le dev embarqué n'utilisera pas necessairement le c++ pour programmer son micro-controlleur, mais le C (qui est utilisable aux cotés du C++, tout comme l'assembleur).

Bref, peut etre que pour faire progresser un domaine quel qu'il soit faut-t-il deja écouter les autres avant d'affirmer, dans ce cas regarder la vidéo.
Pour avoir fait partie d'equipes de R&D ayant mis sur le marché plusieurs produits qui marchent, je pense comme l'auteur de cette vidéo qu'aucune option n'est `a écarter, specialement quand on considere qu'un produit qui marche est un produit qui arrive sur le marché `a temps et que pour cela certains outils ou langages peuvent faire gagner pas mal de temps sur certaines taches.

Un exemple concret : quand plusieurs equipes travaillent ensembles une sur un framework qui lie un systeme embarqué `aun systeme d'info plus large, par exemple quand il y a un besoin de calcul sur differents coprocesseurs, qu'en gros on a autre chose qu'un petit programme tout seul dans son coin, C++ comme d'autre outils peut etre d'une grande aide pour aller vite et s'interfacer avec l'existant qui souvent n'est jamais qu'uniquement du C mais plein d'autres technos souvent plus facilement interfacable avec le C++ qu'avec le C. Enfin organiser une grosse base de code en C, c'est pas top et la POO apporte sans doute cela. Avant d'avoir un code optimise faut t il encore qu'il soit clair, maintenable et facile a comprendre.

Enfin sur le plan technique que sauf en desactivant toutes les optimisations, le compilateur optimisera en C comme en C++, et qu'a moins de bien tester le code, il y aura des suprises en C comme en C++ quand il s'agit de problématiques de temps réel etc. D'ailleurs c'est pas tellement le langage qui compte, mais l'OS, exemple : pour faire une mesure physique, une frequence, tension ou autre en temps reelil est evident qu'il faut utiliser un systeme temps reel, il est moins evident de dire que C++ ne fera que du code imprevisible a cause des pointeurs automatiques ou autres. C'est mal connaitre le langage que de dire des choses pareilles.