Cela fait plus de vingt ans que je développe, autant professionnellement que pour mes projets personnels, quasi exclusivement en C++. Je n'utilise qu'une partie des possibilités offertes par ce langage, et rares sont les nouveautés que j'adopte. La dernière en date sont les variadic templates, apparus avec C++11. Je ne peux donc prétendre être un expert C++, et ça n'a d'ailleurs jamais été mon ambition.
Je peux d'autant moins prétendre être un expert C++ que les seules bibliothèques C++ que j'utilise sont... les miennes.
À mes débuts, il n'y avait pas autant de langages qu'aujourd'hui, et la plupart n'étaient pas très répandus. En outre, comme je connaissais déjà le langage C, c'est tout naturellement que je me suis tourné vers le C++. Ayant, dés le début, fait le choix d'écrire des programmes portables, entre les différences de comportement d'une même bibliothèque d'une plateforme à l'autre, et les bugs de certaines bibliothèques, je me suis retrouvé à écrire mes propres bibliothèques C++, codées en interne en C.
Cela est grandement facilité par le fait qu'avec C++, j'ai directement accès aux bibliothèques C standards, ainsi que systèmes, voire à l'assembleur. J'utilise donc exactement le même environnement de développement pour, d'une part, développer mes bibliothèques C++ (en C ou en assembleur), et, d'autre part, pour développer les logiciels qui s'appuient sur ces bibliothèques. Avec la plupart des autres langages, pour avoir des performances optimales, j'aurais dû quand même développer les bibliothèques en C ou en C++, et donc avoir deux environnements de développement radicalement différents. Pour le jeune aspirant développeur que j'étais à l'époque, cela aurait été probablement rédhibitoire.
Rétrospectivement, bien que ce choix ai été dicté par les circonstances, coder dans un langage sans en utiliser les bibliothèques standards paraît tout à fait insensé, encore plus de nos jours. Pourtant, c'est un choix que je ne regrette absolument pas. L'avantage est que j'ai des bibliothèques avec une API sur mesure, vu que je peux la modifier comme bon me semble, et dont les performances ne sont limitées que par les caractéristiques de la machine sur laquelle sont exécutés mes logiciels. L'inconvénient, c'est que, aujourd'hui, je suis le seul à vouloir/pouvoir modifier mes logiciels, essentiellement parce que mes bibliothèques ne sont pas documentées.
Ces derniers mois, j'ai eu l'occasion de réaliser des développements pour Java, Node.js, PHP, Python, Ruby et je suis actuellement en train d'en réaliser pour Perl. Bien que j'ai trouvé certains de ces langages intéressants par certains aspects, je préfère, et de loin, coder en C++. Mais cela est probablement dû à ma manière inhabituelle de coder en C++, c'est-à-dire en utilisant exclusivement des bibliothèques maisons.
Cette manière de coder est hautement critiquable et ne saurait être encouragée. N'empêche que c'est la mienne et qu'elle me convient parfaitement. Et il se trouve que C++ est l'un des rares langages (le seul à ma connaissance, avec le C) qui facilite autant cette manière de coder, autant par l'ouverture de son environnement de développement (accès direct au C et à l'assembleur), que par les performances qu'il permet d'obtenir (qui n'ont rien à envier à celles des bibliothèques fournies en standard).
Voilà donc un autre point de vue d'un développeur C++ ayant eu un début de parcours fort similaire au tien.
Concernant certains des points évoqués dans ton journal.
Je ne trouve pas que développer en C++ est lent, mais c'est probablement parce que j'ai une flopée de bibliothèques pour mettre facilement et rapidement en œuvre toutes les fonctionnalités dont j'ai pu avoir besoin au cours de mes différents développements. Certes, développer ces bibliothèques m'a pris du temps, mais cela s'est fait au fil de l'eau, en généralisant au maximum et en déportant chaque nouvelle fonctionnalité dans une bibliothèque dés que j'ai eu besoin de cette fonctionnalité pour un logiciel.
Pour ce qui est de la compilation, vu que je n'ai jamais de dépendances du fait que je n'utilise pas de bibliothèques tiers, je n'ai besoin que d'un Makefile pour la compilation. Ce Makefile est généré à partir d'un fichier projet avec un format maison qui se contente, en gros, d'indiquer la nature du projet (exécutable, bibliothèque dynamique...), et de lister les bibliothèques utilisées. Ce fichier projet sert d'ailleurs aussi au paquetage automatique des sources de l'application dans le but de la distribuer.
Le seul gros manque, c'est une méthode standard de paquetage, ainsi qu'éventuellement un dépôt officiel. Ce n'est pas tellement gênant pour des développement à façon, car je fournis au client généralement un .zip avec les binaires. Mais pour tout mes développements open source, à part pour Windows, je ne sais pas comment faire pour mettre à disposition mes logiciels sans les faire compiler par l'utilisateur, ce qui implique qu'il ai un compilateur C++, en plus de make.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
# Moi, pas du tout expert C++, je ne compte pas abandonner C++
Posté par Claude SIMON (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 4.
Cela fait plus de vingt ans que je développe, autant professionnellement que pour mes projets personnels, quasi exclusivement en C++. Je n'utilise qu'une partie des possibilités offertes par ce langage, et rares sont les nouveautés que j'adopte. La dernière en date sont les variadic templates, apparus avec C++11. Je ne peux donc prétendre être un expert C++, et ça n'a d'ailleurs jamais été mon ambition.
Je peux d'autant moins prétendre être un expert C++ que les seules bibliothèques C++ que j'utilise sont... les miennes.
À mes débuts, il n'y avait pas autant de langages qu'aujourd'hui, et la plupart n'étaient pas très répandus. En outre, comme je connaissais déjà le langage C, c'est tout naturellement que je me suis tourné vers le C++. Ayant, dés le début, fait le choix d'écrire des programmes portables, entre les différences de comportement d'une même bibliothèque d'une plateforme à l'autre, et les bugs de certaines bibliothèques, je me suis retrouvé à écrire mes propres bibliothèques C++, codées en interne en C.
Cela est grandement facilité par le fait qu'avec C++, j'ai directement accès aux bibliothèques C standards, ainsi que systèmes, voire à l'assembleur. J'utilise donc exactement le même environnement de développement pour, d'une part, développer mes bibliothèques C++ (en C ou en assembleur), et, d'autre part, pour développer les logiciels qui s'appuient sur ces bibliothèques. Avec la plupart des autres langages, pour avoir des performances optimales, j'aurais dû quand même développer les bibliothèques en C ou en C++, et donc avoir deux environnements de développement radicalement différents. Pour le jeune aspirant développeur que j'étais à l'époque, cela aurait été probablement rédhibitoire.
Rétrospectivement, bien que ce choix ai été dicté par les circonstances, coder dans un langage sans en utiliser les bibliothèques standards paraît tout à fait insensé, encore plus de nos jours. Pourtant, c'est un choix que je ne regrette absolument pas. L'avantage est que j'ai des bibliothèques avec une API sur mesure, vu que je peux la modifier comme bon me semble, et dont les performances ne sont limitées que par les caractéristiques de la machine sur laquelle sont exécutés mes logiciels. L'inconvénient, c'est que, aujourd'hui, je suis le seul à vouloir/pouvoir modifier mes logiciels, essentiellement parce que mes bibliothèques ne sont pas documentées.
Ces derniers mois, j'ai eu l'occasion de réaliser des développements pour Java, Node.js, PHP, Python, Ruby et je suis actuellement en train d'en réaliser pour Perl. Bien que j'ai trouvé certains de ces langages intéressants par certains aspects, je préfère, et de loin, coder en C++. Mais cela est probablement dû à ma manière inhabituelle de coder en C++, c'est-à-dire en utilisant exclusivement des bibliothèques maisons.
Cette manière de coder est hautement critiquable et ne saurait être encouragée. N'empêche que c'est la mienne et qu'elle me convient parfaitement. Et il se trouve que C++ est l'un des rares langages (le seul à ma connaissance, avec le C) qui facilite autant cette manière de coder, autant par l'ouverture de son environnement de développement (accès direct au C et à l'assembleur), que par les performances qu'il permet d'obtenir (qui n'ont rien à envier à celles des bibliothèques fournies en standard).
Voilà donc un autre point de vue d'un développeur C++ ayant eu un début de parcours fort similaire au tien.
Concernant certains des points évoqués dans ton journal.
Je ne trouve pas que développer en C++ est lent, mais c'est probablement parce que j'ai une flopée de bibliothèques pour mettre facilement et rapidement en œuvre toutes les fonctionnalités dont j'ai pu avoir besoin au cours de mes différents développements. Certes, développer ces bibliothèques m'a pris du temps, mais cela s'est fait au fil de l'eau, en généralisant au maximum et en déportant chaque nouvelle fonctionnalité dans une bibliothèque dés que j'ai eu besoin de cette fonctionnalité pour un logiciel.
Pour ce qui est de la compilation, vu que je n'ai jamais de dépendances du fait que je n'utilise pas de bibliothèques tiers, je n'ai besoin que d'un Makefile pour la compilation. Ce Makefile est généré à partir d'un fichier projet avec un format maison qui se contente, en gros, d'indiquer la nature du projet (exécutable, bibliothèque dynamique...), et de lister les bibliothèques utilisées. Ce fichier projet sert d'ailleurs aussi au paquetage automatique des sources de l'application dans le but de la distribuer.
Le seul gros manque, c'est une méthode standard de paquetage, ainsi qu'éventuellement un dépôt officiel. Ce n'est pas tellement gênant pour des développement à façon, car je fournis au client généralement un .zip avec les binaires. Mais pour tout mes développements open source, à part pour Windows, je ne sais pas comment faire pour mettre à disposition mes logiciels sans les faire compiler par l'utilisateur, ce qui implique qu'il ai un compilateur C++, en plus de make.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...