Expérience

De plus, je trouve les programmes en C++ beaucoup moins lisibles que ceux écrit en C. Il y a aussi le "nullptr" dont je ne vois pas l'intérêt, le "NULL" me paraît plus rapide à écrire et plus lisible car écrit en majuscules.

NULL est problématique parce que c'était 0 en C++ et un cast de void * de 0 en C. Rien que pour ça il y a problème de compatibilité.

En étant 0, il y a ambiguité dès lors qu'on a deux fonctions surchargées qui peuvent prendre soit un int soit un pointeur quelconque. Le mot clé nullptr est spécifiquement là pour les pointeurs. En plus, en C23 il y a aussi nullptr :).

Certains diront: l'avantage est la programmation objet. Mais avec l'option de GCC "-fms-extensions", on peut imbriquer les structures de la sorte:

La programmation orientée objet n'est pas la réponse à tout. Quand je vois certains projets avec 7 niveaux de hierarchie avec des fonctions virtuelles/abstraites de tous les côtés je suis bien content de pas y mettre les pieds. Comme disait Carmack, parfois la meilleure implémentation n'est qu'une fonction. En C on peut faire un peu d'orienté objet avec des pointeurs de fonction, c'est la méthode la plus courante pour implémenter des choses abstraites. Un système de fichier virtuel est clairement un des exemples les plus concret

struct vio {
 int (*open)(const char *name);
 int (*close)(int fd);
};
// plus tard dans le code
int fd = my_zfs_vio->open("foo.txt");
mu_vfs_vio->close(fd);

Donc je ne vois pas quels sont les avantages du C++ sur le C ?

Il y en a, heureusement sinon personne ne l'utiliserait. Je vais faire court.

• les namespaces : qui aime vraiment écrire gtk_tree_widget_my_super_fonction ? qui aime avoir un conflit de noms parce qu'une autre bibliothèque a un nom identique ?
• les templates : bien utilisé ils permettent de réutiliser du code sans avoir à passer par des macros dégueulasses. les devs C qui utilisent les listes chainées connaissent bien ce problème.
• la bibliothèque standard : en C, soit on réinvente la roue tout le temps soit on doit forcer / utiliser une bibliothèque externe. Quand on design un framework plus haut niveau cela peut être particulièrement chiant. Si Gtk a besoin de tableau dynamique, de listes ou autres ils vont devoir choisir une bibliothèque ou recoder les fonctions et les imposer à l'utilisateur. Ainsi on se retrouve avec une quantité astronomique de code qui fait la même chose.
• les fonctionnalités avancées : les initializer_list font parti des fonctionnalités les plus agréables. pouvoir créer un objet json comme ceci est vraiment cool json foo{"bar", baz};.

Bon la liste est longue donc je te laisse faire ton propre avis. Et parce que j'aime beaucoup le C et que je trouve que le C++ devient de plus en plus dégueu au fur et à mesure des nouvelles normes je fais aussi un exemple opposé.

• simplicité : en C on sait presque immédiatement à quoi va ressembler le binaire final et quand on fait de l'embarqué voir les symbols qui seront placés en RAM ou en flash c'est le pied. On a un controle absolu.
• simplicité 2 : implémenter un compilateur C est presque un jeu d'enfant, pour cibler une nouvelle plateforme il y a peu d'effort à faire.
• temps de compilation : il y a pas photo
• pas de boite noire : quand on instancie simplement std::string x on a aucune idée de ce qu'il risque de se passer sur l'allocation mémoire, en C on a quasiment aucune surprise.
• rigueur : les gens qui dev en C ont souvent plus de rigueur car c'est plus facile de se planter, à l'inverse à chaque fois que je vois un projet en C++ je peux voir un mélange de vieilleries et de nouveauté et ça donne pas toujours envie notamment ceux qui sont coincés en c++98 par choix.

Note, je suis dans le développement embarqué donc mon avis est un peu biaisé bien que j'ai passé une grande partie de ma vie à développer des applications en C++.

AI is a mental disorder