Pourquoi le C ++ est-il toujours "hybride"

Sur une question connexe , il a été précisé pourquoi C ++ n'est pas compatible avec C à bien des égards. Cependant, C ++ est toujours un langage "hybride" *. Et malheureusement, de nombreux programmeurs considèrent toujours le C ++ comme un "C avec des flux et des chaînes intégrées". Cela se traduit par un code écrit vraiment mauvais, que ce n'est ni C ++ ni C. À mon humble avis, il serait préférable que le langage / compilateur oblige dans une certaine mesure les programmeurs à écrire du code plus élégant. Existe-t-il donc une justification pour maintenir l'hybride C ++ moderne (par exemple C ++ 0x et les futures versions)?

_{* Par hybride, je veux dire que c'est au programmeur de décider s'il utilisera: des chaînes et des flux standard, des classes, des espaces de noms autres que ceux par défaut, etc.}

Oui, il existe une justification solide: le code C ++ doit presque toujours appeler le code C existant. Le mieux que nous puissions faire est de faciliter l'écriture d'un bon code. Un concepteur de langage ne peut rien faire pour empêcher l'écriture de mauvais code.

À mon humble avis, il serait préférable que le langage / compilateur oblige dans une certaine mesure les programmeurs à écrire du code plus élégant.

Non, ce ne serait pas le cas. Du tout. Comme une démonstration triviale de pourquoi, définissez élégant, puis je parie que dix personnes seront en désaccord avec vous.

Les styles de codage imposés par le langage sont vraiment, vraiment mauvais. Sans oublier tout le code hérité qui sera cassé.

Notamment, les classes de chaîne et de flux standard sont en fait nul . std::stringn'a pas de support Unicode et la pire interface gonflée que vous pourriez imaginer. Les flux ont des frais généraux horribles et une conception médiocre, recourant même à l'héritage virtuel, et des pointeurs de fonction, const char*et des laideurs comme ça. Je ne pénaliserais personne pour avoir complètement remplacé ces deux classes / groupes de classes par des classes personnalisées.

Ne pas utiliser de classes et d'espaces de noms est parfait pour le code de style tableau blanc, et il existe de très nombreuses bibliothèques qui fournissent des fonctions qui ne sont pas dans une classe. La classe forcée est une très mauvaise idée.

C ++ est un hybride non pas parce qu'il permet d'écrire du code de style C, mais parce qu'il prend en charge plusieurs paradigmes de programmation, tels que procéduraux, orientés objet et génériques. C ++ ne vous oblige pas à une seule façon de faire les choses, et c'est sa force, car différents problèmes peuvent être résolus plus facilement en utilisant différents paradigmes.

À mon humble avis, il serait préférable que le langage / compilateur oblige dans une certaine mesure les programmeurs à écrire du code plus élégant.

Ensuite, vous devez d'abord définir ce que signifie élégant . Ensuite, vous devriez voir si votre définition d'élégant convient à tous les domaines et plates-formes problématiques pour lesquels C ++ est utilisé. Un style de codage élégant pour l'écriture d'un traitement de texte pour Windows peut ne pas convenir parfaitement à l'écriture d'un système embarqué.

Pensez à écrire du code C ++ pour l'exécuter sur un DSP. Tout d'abord, le compilateur C ++ pour ce DSP peut tout simplement ne pas prendre en charge certaines fonctionnalités C ++, comme les flux. Deuxièmement, vous êtes fortement limité par la vitesse du processeur, et éventuellement la mémoire, de sorte que certaines fonctionnalités C ++ peuvent simplement tuer vos performances. Par exemple, vous devrez peut-être éviter les fonctions virtuelles pour des raisons de vitesse. De telles considérations changeraient radicalement votre style de programmation, par rapport à ce que vous utiliseriez sur un PC, et C ++ le permet.

Pour résumer, C ++ est un langage énorme et compliqué avec beaucoup de fonctionnalités. Il existe de nombreuses raisons pour lesquelles un sous-ensemble de ces fonctionnalités peut ne pas être applicable à un projet particulier: vitesse, portabilité, prise en charge du compilateur, ou même expérience et familiarité du programmeur. Pour cette raison, le langage pour forcer le développeur à utiliser certaines fonctionnalités par opposition à d'autres pour une tâche donnée est une mauvaise idée. Pensez à Java, où le langage exige que chaque fonction soit une méthode d'une classe. Il y a tellement de cas où créer une classe juste pour envelopper une méthode est maladroit et inutile, et pourtant vous devez le faire parce que le langage vous y oblige.

À mon humble avis, il serait préférable que le langage / compilateur oblige dans une certaine mesure les programmeurs à écrire du code plus élégant.

Personne ne force personne à utiliser C ++ en premier lieu. Si le langage ne vous convient pas, utilisez-en un autre - il existe de nombreux langages facturés en "C ++ sans C".

La philosophie de conception C ++ consiste à laisser le programmeur décider. S'ils veulent se tirer une balle dans le pied, laissez-les. Cela permet de faire beaucoup de mauvaises choses, mais permet également une grande flexibilité. Par exemple, il est peu probable que Boost puisse être écrit dans un langage comme Java car il tire parti des fonctionnalités et des pratiques du langage généralement évitées. Il est également peu probable que C ++ devienne aussi grand qu'aujourd'hui - avoir accès à la vaste bibliothèque C est un énorme avantage, à prendre ou à laisser.

La compatibilité de C ++ avec C est certainement l'un de ses points faibles, mais gardez également à l'esprit qu'il est l'un de ses meilleurs.

Je vais ajouter une merveilleuse citation de Jon Purdy qui me semble extrêmement pertinente:

Tout se résume au pragmatisme contre l'élégance, et pour moi, malgré mon obsession pour un code précis et beau, écrire un programme laid qui fonctionne est mieux que d'écrire un beau programme qui ne fait rien.

La suppression de l'hybride peut améliorer l'élégance, mais elle entrave la capacité.

Si le comité tentait de forcer les gens à utiliser (la notion de quelqu'un de) un langage plus élégant, il serait probablement ignoré. Les gens continueraient de faire ce qu'ils veulent et les vendeurs de compilateurs suivraient le marché (mais les vendeurs de compilateurs ont suffisamment de représentation au sein du comité pour empêcher cela).

Une grande partie de ce que vous préconisez est vraiment une question de jugement, basé sur le domaine du problème de toute façon. Il existe de nombreux petits programmes qui n'ont tout simplement pas besoin (pour un exemple) d'espaces de noms. Essayer de me forcer à utiliser un espace de noms lorsque j'écris un filtre de texte de 30 lignes serait stupide et arrogant. Même si vous décidiez que cela ne s'appliquerait que lorsque plus de X lignes de code, ou Y fonctions, ou quoi que ce soit, cela serait généralement contre-productif. Les espaces de noms ont été conçus pour une raison, afin de prévenir / guérir des problèmes spécifiques. Tenter de forcer leur utilisation en l’absence de ces problèmes n’apporte rien d’utile à personne.

En même temps, je pense que cela vaut la peine de noter que beaucoup de gens passent vraiment beaucoup de temps et d'efforts à essayer non seulement d'activer l'élégance en C ++, mais aussi d'enseigner et d'amener les gens à utiliser ces capacités pour écrire un meilleur code (par exemple, de nombreux contributeurs Boost). En tant que tel, les gens qui continuent d'insister pour écrire leur code en "C avec des classes" ignorent à peu près ce qui existe de toute façon. Je pense qu'ils seraient aussi à l'aise d'ignorer les nouveaux compilateurs que d'ignorer tout ce qui a été appris sur la façon d'utiliser C ++ au cours de la dernière décennie ou plus (par exemple, Modern C ++ Design a été publié il y a 11 ans maintenant - mais la plupart des gens dont vous parlez apparemment n'en avez pas encore entendu parler, encore moins lu ou compris même ses parties les plus simples).

Votre idée constitue une grande partie de la logique de conception derrière Java. Java vous oblige à utiliser des classes, à organiser la hiérarchie des fichiers en fonction de la hiérarchie des packages, à intercepter les exceptions, etc. Les gens parviennent toujours à y écrire du code de type C.

En tant que programmeurs, nous oublions parfois que la meilleure solution n'est peut-être pas technique. Les examens par les pairs sont la solution la plus connue dans ce cas.

C ++ n'a pas de "voie unique"; chaque approche a ses forces et ses faiblesses. La solution peut être écrite de cent manières différentes.

En tant que développeur de logiciels, vous devez décider quelle approche convient le mieux à la tâche à accomplir.

Je pense que le fait que toutes ces choses que vous énumérez soient facultatives crée un potentiel pour plus d' élégance, pas moins. Une fonctionnalité inutilement utilisée est inélégante à mes yeux.

Les problèmes que nous devons résoudre en utilisant la programmation sont très différents.
Certains sont bien résolus en utilisant les principes OO (par exemple les interfaces graphiques), certains se prêtent mieux à un traitement purement fonctionnel (par exemple des éléments numériques), tandis que certains s'expriment mieux dans un langage de bas niveau "proche du silicium".

De nombreux logiciels doivent résoudre les sous-problèmes les mieux résolus de l'une de ces manières. Forcer la solution dans un formulaire spécifique ne conduira qu'à un code moins adapté à son objectif (vous pourriez même dire "moins élégant").

C'est pourquoi l'hybridation de C ++ est une bonne chose - elle nous permet de résoudre un vaste éventail de problèmes d'une manière qui convient au problème , pas au dogme actuel.
Bien sûr, il peut être utilisé à mauvais escient - chaque fois que vous avez une chose flexible, vous risquez de la plier dans le mauvais sens - mais l'élégance vient d'une réflexion et d'une expérience minutieuses, et non de l'adhésion à la mode du jour.