Quand utiliser le C++ et quand utiliser plutôt le C pour un problème ?

Bonjour, ma question risque d'être un peu bête ; je suis apprenti et j'ai commencé par le C avant d'apprendre le C++. Je connais un peu mieux le C que le C++ actuellement. Étant donné que le C++ est une amélioration du C ; depuis le « C with class » jusqu'au C++ moderne de maintenant, ma question est la suivante*: dois-je tout faire mes projets en C++ et laisser le C ? Par exemple, si j'ai un problème de développement ou un projet, comment savoir que pour faire telle partie de l'application, ça sera mieux en C et l'autre sera mieux avec le C++ moderne d'aujourd'hui. Et enfin, quel sont les domaines approfondir en C et C++.

J'ai fait un parcours similaire, il y a une vingtaine d'années, et ma conclusion lors, et encore plus désormais, serait : C++, qui permet plus de choses plus aisément (destructeurs, templates, ... en particulier depuis C++11 et la move-semantic) et m'offrait/m'offre plus d'opportunités professionnelles
À moins de travailler sur une architecture spécifique ne possédant pas de compilateur C++ et où seul le C est disponible, je travaille en C++

Citation:

---

Étant donné que le C++ est une amélioration du C

---

Il ne faut pas voir ça comme ça. Au départ le C++ était une surcouche du C, mais après les 2 langages ont divergés.

Historiquement, il fallait plus de puissance pur faire du C++ (on parle d'une époque ou la RM était réduite ainsi que le puissance CPU par rapport à nos jours).

Maintenant, on peut aussi utiliser le C++ avec l'embarqué.

c'est bien de connaitre les 2, mais en tant qu'apprenti, mieux vaut investir sur le C++ je pense.

Bonjour,

Plus on connaît de langages mieux c'est. Cela permet de choisir celui le plus adapté au besoin. La plupart des langages permettent de tout faire mais, selon les domaines, avec plus ou moins de facilité et d'efficience.

Plus le nombre de langages maîtrisé est grand, plus l'apprentissage d'un nouveau langage devient facile, car ils s'inspirent les uns des autres.

Prenons un exemple tellement intégré que nous y pensons rarement. Pourquoi l'affectation se fait toujours vers la gauche alors que le résultat de l'expression à affecter (à droite) n'est connu qu'après son exécution. À l'origine, c'était parce que cela permettait simplement au compilateur de savoir à l'avance le type du résultat. Aujourd'hui, il serait possible sans grande difficulté d'avoir une affectation à droite qui ouvrirait en plus des possibilités d'affectations en cascade. Mais le pli est pris.

Le C++ est un langage plus généraliste que le C. Son spectre d'emploi fonctionnel est donc plus large. Mais C reste un outil préférentiel pour les programmations au ras du matériel que ce soit des éléments systèmes, des pilotes ou de l'embarqué. L'usage du C++ sur l'embarqué fait frémir les puristes, car ce domaine, relativement pauvre en ressources, incite fortement à utiliser un style C pour éviter les hauts niveaux d'abstraction plus consommateurs qu'offre le C++. Avec la montée en puissance des MPU, cela pourrait se révéler rapidement faux, mais pas nécessairement au profit du C++. Les langages interprétés (encore plus gourmands en ressources) possèdent l'avantage de permettre des développements très rapides.

En résumé, ce n'est pas fromage ou dessert, mais fromage et dessert. Et il y a beaucoup de fromages 8-)

Salutations

Citation:

---

"Le C++ est un langage plus généraliste que le C. Son spectre d'emploi fonctionnel est donc plus large. Mais C reste un outil préférentiel pour les programmations au ras du matériel que ce soit des éléments systèmes, des pilotes ou de l'embarqué. L'usage du C++ sur l'embarqué fait frémir les puristes, car ce domaine, relativement pauvre en ressources, incite fortement à utiliser un style C pour éviter les hauts niveaux d'abstraction plus consommateurs qu'offre le C++. Avec la montée en puissance des MPU, cela pourrait se révéler rapidement faux, mais pas nécessairement au profit du C++. Les langages interprétés (encore plus gourmands en ressources) possèdent l'avantage de permettre des développements très rapides".

---

Merci beaucoup pour vos reponses. Si j'ai bien compris, et en attendant d'approfondir ces 2 langages pour mieux prendre des decisions, je vais un peu plus m'investir dans le c++ pour le devellopement d'application , jeux video + simulation, creation d'outils et moteur, mais je vais qu'a meme rester dans le c pour la programmation systeme et le systeme embarqué car le c consomme un peu moins de ressources et je pourrais aussi le faire ou apprendre a le faire en c++

Il y a beaucoup de FUD (Fear Incertainty Doubt), et de méconnaissance, autour du C++ dans les domaines systèmes et embarqués. Techniquement il a la possibilité d'être au moins autant (cad "potentiellement plus") léger ou performant que le C.

Il s'agit de ne pas utiliser les features qui sont connues comme ayant une empreinte plus lourde que les équivalentes en C. Il y a déjà eu beaucoup de débats et de ressources données autour de ces sujets. P.ex. ici, où je recommande vivement les conférences données par Dan Saks: https://www.developpez.net/forums/d1...p/#post8752931

Depuis 1-2 ans, Khalil Estell a présenté comment améliorer le support des exceptions (et avoir des binaires plus petits en C++ grâce aux exceptions sur des cibles embarquées...) lors de deux confs (plus à venir) -- c'est toujours plus lent que les codes de retours sur la remonté d'erreur. Avec le nom les personnes intéressées pourront trouver les ressources en question sur YouTube.

Un gros plus 1 à Bousk. Pareil pour moi: quand je n'ai pas le choix pour des raisons techniques. Pour les raisons humaines (les plus courantes), je débats.

Bonjour,

C reste plus efficace que C++ sauf quand ce dernier se replie sur son ancêtre historique pour faire jeu égal. Ce n'est ni une peur ni un doute : les tests le montrent. À qualité de développement équivalente, C reste plus performant.

Les formulations restrictives comme "techniquement" ou hypothétiques comme "possibilité" et "potentiellement" le confirment.

Mais la concurrence ne se limite pas aux performances brutes, C++ permet de développer plus rapidement que C des fonctionnalités qui présentent un haut niveau d'efficacité qui pourraient certes être développées en C plus efficacement, mais au prix d'un bien plus grand investissement.

C'est une logique économique : quel est le coût du gain ? Et C++ est alors souvent un très bon choix.

Si ce n'était pas le cas, tout serait développé par des experts en assembleur.

Il y a un autre paramètre, plus subjectif. Même en connaissant plusieurs langages, nous avons plus d'affinité avec certains indépendamment de leurs qualités propres.

Salutations

Salut,

Citation:

---

Envoyé par Guesset

Bonjour,

a- C reste plus efficace que C++ sauf quand ce dernier se replie sur son ancêtre historique pour faire jeu égal. Ce n'est ni une peur ni un doute : les tests le montrent. À qualité de développement équivalente, C reste plus performant.

b- Les formulations restrictives comme "techniquement" ou hypothétiques comme "possibilité" et "potentiellement" le confirment.

---

a- Nullement.

Et les exemples ne manquent pas. `std::sort()` qui est plus performant que `qsort()`. L'emploi de références qui se traduit en pointeur + `assume(not null)` chez gcc et clang. `printf()` de la lib C écrite en C++ générique chez Microsoft. L'exemple de Bartosz Szurgot donné dans la conversation derrière mon précédent lien où l'emploi de choses telles que `not_null<T>` permettent d'entrer dans des zones où la non-nullité est garantie et n'a donc plus besoin d'être testée de façon défensive -- en fait, c'est une application directe de l'encapsulation qui garantit les invariants positionnés dès la construction d'objets. Plus les expressions constantes dont l'évaluation est garantie à la compilation.

Ou encore pour paraphraser Khalil Estell on peut avoir des binaires de taille moindre grâce aux exceptions -- ses expériences sont en embarqué. Et généralement de perfs subtilement améliorées dans le cas nominal -- ça s'inverse de manière non subtile dans lors de la propagation des erreurs.

C'est grâce à cela que le C++ permet de faire au moins mieux: on a quasi tout le vocabulaire du C, plus des trucs absents du C qui sont plus performants en C++. On peut aussi faire bien pire si ça nous fait plaisir -- on n'est pas obligés de s'en servir non plus.


b- Par techniquement il faut lire: plateforme exotique avec un unique compilo C fournit par le distributeur du matériel, et rien d'autre.

Nous sommes globalement d'accords sur le reste.

Citation:

---

C reste plus efficace que C++ sauf quand ce dernier se replie sur son ancêtre historique pour faire jeu égal. Ce n'est ni une peur ni un doute : les tests le montrent. À qualité de développement équivalente, C reste plus performant.

---

J'aurais cru qu'avec la puissance actuelle des compilos, pour du code bien pondu et n'utilisant des features spécifique au C++ il n'y avait pas vraiment d'écart en perf.

Mais ça dépasse mon niveau, je ne suis pas dev.

Un exact même code syntaxiquement valable dans les deux, qu'il soit compilé en C ou en C++ produira normalement le même ASM. Et même un code d'accumulation sur un tableau avec une boucle for en C produira le même ASM qu'un `std::accumulate` sur un vecteur ou un span -- sur gcc et/ou clang, je ne sais plus lequel.

Dans ces cas, les écarts de perfs deviennent des imprécisions sur la mesure, ou des effets de bord chelous -- cf Mytkowicz & al., "Producing Wrong Data Without Doing Anything Obviously Wrong!" -> https://users.cs.northwestern.edu/~r...wrong-data.pdf

Bonjour Luc Hermitte,

Citation:

---

Envoyé par Luc Hermitte

...
Et les exemples ne manquent pas. `std::sort()` qui est plus performant que `qsort()`. L'emploi de références qui se traduit en pointeur + `assume(not null)` chez gcc et clang. `printf()` de la lib C écrite en C++ générique chez Microsoft. L'exemple de Bartosz Szurgot donné dans la conversation derrière mon précédent lien où l'emploi de choses telles que `not_null<T>` permettent d'entrer dans des zones où la non-nullité est garantie et n'a donc plus besoin d'être testée de façon défensive -- en fait, c'est une application directe de l'encapsulation qui garantit les invariants positionnés dès la construction d'objets. Plus les expressions constantes dont l'évaluation est garantie à la compilation.

Ou encore pour paraphraser Khalil Estell on peut avoir des binaires de taille moindre grâce aux exceptions -- ses expériences sont en embarqué. Et généralement de perfs subtilement améliorées dans le cas nominal -- ça s'inverse de manière non subtile dans lors de la propagation des erreurs...

---

Comparer des bibliothèques est intéressant, mais cela peut traduire des algorithmes différents, même subtilement, comme le choix du pivot dans un quick sort. Cela ne ressort donc pas seulement du langage.

À partir du moment où C++ peut se replier sur du C, il peut faire aussi bien que C. Cela n'est pas contestable.

not_null évite d'écrire des tests de vérification qui polluent la lisibilité du code (quand ils ne sont pas oubliés). Son effet systématique est un garant de sécurité. Cependant, cela engendre des contrôles (certes en assembleur genre test p, p; jcz @ouhlala) pas nécessairement plus efficaces que ceux résultant d'un code C défensif, mais dont le systématisme peut induire un excès. Cela reste à l'avantage du C++ en termes de sécurité.

Seules des améliorations de bas niveaux peuvent augmenter les performances (je rêve de retrouver le test arithmétique du Fortran qui outrepasse le test binaire en offrant 3 possibilités), mais cela ne semble pas la voie d'évolution de C++. Les exceptions sont un contre-exemple effectif quand elles sont bien utilisées.

L'évolution des compilateurs est peut-être plus dynamique en C++, mais comme le C peut en bénéficier en tant que sous-ensemble cela ne devrait pas jouer en faveur de l'un ou l'autre.

Quand je regarde les codes opérationnels pour l'embarqué, aujourd'hui encore, ce sont essentiellement du C ou du C++ à la mode C.

Salut

Salut,

L'avantage de std::sort sur qsort n'est pas juste un avantage algorithmique.

C'est un avantage obtenu par la généricité des templates C++ qui débouche sur de l'inlining de la fonction de comparaison alors que qsort va toujours appeler une fonction. Certes qsort aurait pu être implémentée avec des macros.

> not_null évite d'écrire des tests de vérification qui polluent la lisibilité du code (quand ils ne sont pas oubliés). Son effet systématique est un garant de sécurité. Cependant, cela engendre des contrôles (certes en assembleur genre test p, p; jcz @ouhlala) pas nécessairement plus efficaces que ceux résultant d'un code C défensif, mais dont le systématisme peut induire un excès. Cela reste à l'avantage du C++ en termes de sécurité.

Je ne suis pas sûr de comprendre ce à quoi tu réfères avec "**cela** engendre...".
La programmation défensive engendre bien un surcoût. Mais justement pas not_null qui offre la garantie au moment de la compilation.

> L'évolution des compilateurs est peut-être plus dynamique en C++, mais comme le C peut en bénéficier en tant que sous-ensemble cela ne devrait pas jouer en faveur de l'un ou l'autre.

Pour moi ce sont les mêmes compilos. Seuls les langages vont vraiment choisir leur propre chemin.

> Seules des améliorations de bas niveaux peuvent augmenter les performances; mais cela ne semble pas la voie d'évolution de C++.

Des contraintes fondamentales dans l'évolution C++ sont:
- ne pas casser l'ABI
- 0 cost abstractions (bien qu'il y ait parfois des échecs -> regex, hashage des unordered map qui sont bloqués à cause de la 1ere contrainte)

Pour le bas niveau, C++26 introduit des abstractions standards pour adresser les jeux d'instruction SIMD de façon portable. Il y a des discussion sur la trivial relocability. L'introduction d'une introspection statique pour une meta-programmation encore plus poussée.

> (je rêve de retrouver le test arithmétique du Fortran qui outrepasse le test binaire en offrant 3 possibilités),

Ce que fait le spaceship operator du C++20?

> Quand je regarde les codes opérationnels pour l'embarqué, aujourd'hui encore, ce sont essentiellement du C ou du C++ à la mode C.

Plusieurs facteurs AMA:

- on ne va pas réécrite l'existant
- FUD, biais et tradition

A cause de ces biais sur le C++, AMA la migration vers Rust sera plus acceptable pour les esprits que l'introduction de template, de constexpr, ou des algo génériques tel que c'était advocatisé (je ne sais plus comment on dit en français) par Dan Saks.

Après, rester en procédural est parfaitement valide.

Bonjour Luc,

Citation:

---

Envoyé par Luc Hermitte

...Ce que fait le spaceship operator du C++20?...

---

Ce serait plutôt quelque chose comme : ifa(expr) { // inf 0 ou < } eq { // = 0 ou == } else { // >0 ou >} qui permettrait de réutiliser mieux les flags de comparaison sans les labels spaghetti du Fortran. Mais je suis peut-être plus dans une amélioration du C...

Salut

Citation:

---

Des contraintes fondamentales dans l'évolution C++ sont:
- ne pas casser l'ABI

---

Il y a une ABI en C++ ???

Bonjour Bacelar,

Citation:

---

Envoyé par bacelar

Il y a une ABI en C++ ???

---

Sauf erreur, l'ABI dépend de l'OS et du type de processeur. Par exemple, UNIX vs Windows et x86 vs Amd64 ne réservent pas les même registres d'où l'obligation d'avoir 4 versions de code assembleur pour opérer sur ces variantes (Unix_x86, Unix_Amd64, Win_X86, Win_Amd64). Le langage (enfin le code exécutable généré) doit juste s'y plier.

Salut

Stricto sensu vous avez parfaitement raison. Il n'existe pas d'ABI standard C++.

Maintenant, les problèmes auxquels je fais référence concernent les choix d'interfaces ou d'implémentation de certains types ou fonctions standard. Les changer rend les bibliothèques incompatibles avec d'autres binaires selon qu'une partie ait été compilée avant ou après changement.
C'est à ça qu'"ABI breaks", fait référence.

Ce papier en parlera bien mieux que moi. https://www.open-std.org/jtc1/sc22/w...20/p2028r0.pdf