Certains te l'ont déjà évoqué mais la principale motivation pour passer au C++ est le support du paradigme objet.
De base le C n'est qu'un langage procédural. Lorsque tu programmes dans certains domaines l'approche objet est assez "naturelle".
Même si c'est théoriquement possible avec le C tu te retrouves très vite limité par le langage. Si tu es intéressé cet ouvrage est fait pour toi: https://www.cs.rit.edu/~ats/books/ooc.pdf)
Simuler un héritage rudimentaire et le polymorphisme à base de "cast" est à peu près tout ce que tu peux atteindre, simplement.
Au delà tu réinventes tellement de truc qu'il vaut mieux se poser la question de savoir s'il ne faut pas passer à autre chose. C'est la vocation de C++ et d'ObjectiveC
Avec le C++ tu auras automatiquement:
* la redéfinition des méthodes, statiques ou virtuelles (bon courage avec les pointeurs de fonction dans tes structures en C)
* l'héritage multiple
* La généricité qui te permet d'instancier de nouveaux types abstraits
* la surcharge des opérateurs ainsi que de nouveaux (>>)
...
Il y aussi tous les frameworks autours qui peuvent te faciliter la vie (ramasse-miette, ...)
Tu as une belle base de comparaison aujourd'hui avec les 2 toolkits graphiques mainstream sur Linux: GTK ecrit en C prouve que c'est possible. Qt a fait le choix de s'appuyer sur le C++ et déborde largement le cadre de l'interface graphique aujourd'hui.
C'est donc à toi d'évaluer ton besoin sachant que ça peut-être superflu. Par exemple le multi-héritage a aussi ses inconvénients et on peut s'en passer simplement avec la notion d'interfaces. Java est là pour en attester. (Et je n'aborde pas les design pattern, composition vs héritage, ...)
De même l'approche objet ne résout pas tout. Aujourd'hui, le paradigme fonctionnel revient en force et on s'appuie aussi beaucoup sur la programmation par aspect pour compléter l'approche objet de manière orthogonale (Spring AOP en java, ...).
En revanche si tu n'appréhendes pas la programmation objet et que tu veux comprendre, je ne suis pas certain que le C++ soit le langage le plus adapté étant donné sa complexité. GTK est peut-être un 1er point d'entrée pour ça.
Mais il vaut peut-être mieux aussi commencer par des langages plus simple et plus productifs (l'auteur m'en est témoin) comme le Ruby (pur objet) et le python (qui prend quelques libertés avec le duck typing par exemple) et qui offrent en plus l'avantage d'être multi-paradigme et moins contraignants au début de par leur typage dynamique .
A partir de là, peut-être que l'abord du C++ sera moins rugueux.
[^] # Re: Et par rapport au C ?
Posté par El Titi . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 9.
Certains te l'ont déjà évoqué mais la principale motivation pour passer au C++ est le support du paradigme objet.
De base le C n'est qu'un langage procédural. Lorsque tu programmes dans certains domaines l'approche objet est assez "naturelle".
Même si c'est théoriquement possible avec le C tu te retrouves très vite limité par le langage. Si tu es intéressé cet ouvrage est fait pour toi: https://www.cs.rit.edu/~ats/books/ooc.pdf)
Simuler un héritage rudimentaire et le polymorphisme à base de "cast" est à peu près tout ce que tu peux atteindre, simplement.
Au delà tu réinventes tellement de truc qu'il vaut mieux se poser la question de savoir s'il ne faut pas passer à autre chose. C'est la vocation de C++ et d'ObjectiveC
Avec le C++ tu auras automatiquement:
* la redéfinition des méthodes, statiques ou virtuelles (bon courage avec les pointeurs de fonction dans tes structures en C)
* l'héritage multiple
* La généricité qui te permet d'instancier de nouveaux types abstraits
* la surcharge des opérateurs ainsi que de nouveaux (>>)
...
Il y aussi tous les frameworks autours qui peuvent te faciliter la vie (ramasse-miette, ...)
Tu as une belle base de comparaison aujourd'hui avec les 2 toolkits graphiques mainstream sur Linux: GTK ecrit en C prouve que c'est possible. Qt a fait le choix de s'appuyer sur le C++ et déborde largement le cadre de l'interface graphique aujourd'hui.
C'est donc à toi d'évaluer ton besoin sachant que ça peut-être superflu. Par exemple le multi-héritage a aussi ses inconvénients et on peut s'en passer simplement avec la notion d'interfaces. Java est là pour en attester. (Et je n'aborde pas les design pattern, composition vs héritage, ...)
De même l'approche objet ne résout pas tout. Aujourd'hui, le paradigme fonctionnel revient en force et on s'appuie aussi beaucoup sur la programmation par aspect pour compléter l'approche objet de manière orthogonale (Spring AOP en java, ...).
En revanche si tu n'appréhendes pas la programmation objet et que tu veux comprendre, je ne suis pas certain que le C++ soit le langage le plus adapté étant donné sa complexité. GTK est peut-être un 1er point d'entrée pour ça.
Mais il vaut peut-être mieux aussi commencer par des langages plus simple et plus productifs (l'auteur m'en est témoin) comme le Ruby (pur objet) et le python (qui prend quelques libertés avec le duck typing par exemple) et qui offrent en plus l'avantage d'être multi-paradigme et moins contraignants au début de par leur typage dynamique .
A partir de là, peut-être que l'abord du C++ sera moins rugueux.