Quelles seraient les limites de C++ par rapport au langage C? [fermé]
Voici les avantages de c/" class="blnk">C++
- C++ fournit les fonctionnalités spécifiques qu'ils demandent à propos de
- leur compilateur C est presque certainement un compilateur C++, donc il n'y a pas d'implications de coût de logiciel
- C++ est aussi portable que C
- le code C++ peut être aussi efficace que C (ou plus ou moins)
y a-t-il des raisons concrètes et scénarios spécifiques, où il faut utiliser C au lieu de C++?
la Référence à cette question: Bibliothèque pour les médicaments génériques en C
ce n'est pas une copie, car cette question porte sur les limites de la langue et non sur le fait de ne pas apprendre une langue plutôt qu'une autre.
le billet de Peter Kirkham était pour moi le plus informatif, particulièrement en ce qui concerne les questions C99 que je n'avais pas envisagé, donc j'ai accepté. Merci à tous ceux qui y ont pris part.
30 réponses
ceci est motivé par une réponse que j'ai donnée à une question courante qui demande à propos d'une bibliothèque de génériques pour C - l'auteur de la question précise qu'il ne veut pas utiliser c++.
C est un langage de programmation complet. C n'est pas un sous-ensemble arbitraire de C++. C est pas un sous-ensemble de C++.
valable C:
foo_t* foo = malloc ( sizeof(foo_t) );
pour le faire compiler en C++ vous devez écrire:
foo_t* foo = static_cast<foo_t*>( malloc ( sizeof(foo_t) ) );
qui n'est plus valide C. (vous pouvez utiliser le cast de style C, ce qui signifie qu'il compilerait en C, mais serait ignoré par la plupart des normes de codage C++, et aussi par de nombreux programmeurs C; voir les commentaires "don't cast malloc" sur le débordement de la pile).
ils ne sont pas la même langue, et si vous avez un projet existant en C vous ne voulez pas le réécrire dans une langue différente juste pour utiliser une bibliothèque. Vous préférez utilisez des bibliothèques avec lesquelles vous pouvez communiquer dans la langue dans laquelle vous travaillez. (Dans certains cas, cela est possible avec quelques fonctions d'enrubannage extern "C" , en fonction de la façon dont une bibliothèque c++ est template/inline.)
prendre le premier fichier C dans un projet sur lequel je travaille, c'est ce qui se passe si vous changez gcc std=c99 pour g++ :
sandiego:$ g++ -g -O1 -pedantic -mfpmath=sse -DUSE_SSE2 -DUSE_XMM3 -I src/core -L /usr/lib -DARCH=elf64 -D_BSD_SOURCE -DPOSIX -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112L -Wall -Wextra -Wwrite-strings -Wredundant-decls -Werror -Isrc src/core/kin_object.c -c -o obj/kin_object.o | wc -l
In file included from src/core/kin_object.c:22:
src/core/kin_object.h:791:28: error: anonymous variadic macros were introduced in C99
In file included from src/core/kin_object.c:26:
src/core/kin_log.h:42:42: error: anonymous variadic macros were introduced in C99
src/core/kin_log.h:94:29: error: anonymous variadic macros were introduced in C99
...
cc1plus: warnings being treated as errors
src/core/kin_object.c:101: error: ISO C++ does not support the ‘z’ printf length modifier
..
src/core/kin_object.c:160: error: invalid conversion from ‘void*’ to ‘kin_object_t*’
..
src/core/kin_object.c:227: error: unused parameter ‘restrict’
..
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier
au total 69 lignes d'erreurs, dont quatre sont des conversions invalides, mais surtout pour les caractéristiques qui existe en C99 mais pas en C++.
ce n'est pas comme si j'utilisais ces fonctionnalités pour m'amuser. Il faudrait beaucoup de travail pour le faire passer à une autre langue.
il est donc tout à fait erroné de suggérer que
[un] compilateur C est presque certainement vraiment un compilateur C++, donc il n'y a pas de logiciel implications en termes de coûts
il y a souvent des implications de coûts importantes dans le transfert de données existantes. Code C vers le sous-ensemble de procédures de C++.
donc suggérant " utilisez la Classe C++ std::file d'attente " comme réponse à une question cherchant une implémentation de bibliothèque d'une file d'attente en C est dafter que suggérant " utilisez l'objectif C " et " appelez le java.util.Classe de file d'attente en utilisant JNI ' ou "appeler la bibliothèque CPython " - L'objectif C est en fait un surensemble approprié de C (y compris C99), et les bibliothèques Java et CPython sont toutes les deux appelables directement depuis C sans avoir à transférer du code non lié au langage C++.
bien sûr, vous pouvez fournir une façade C à la bibliothèque C++, mais une fois que vous faites cela C++ n'est pas différent de Java ou Python.
je me rends compte que ce n'est ni une réponse professionnelle ni une réponse particulièrement bonne, mais pour moi c'est simplement parce que J'aime vraiment C. C est petit et simple et je peux adapter le langage entier dans mon cerveau, C++ pour moi a toujours semblé comme un énorme désordre étendu avec toutes sortes de couches que j'ai du mal à grogner. En raison de cela, je trouve que chaque fois que j'écris C++ je passe beaucoup plus de temps à déboguer et à frapper ma tête contre les surfaces dures que lorsque je code C. encore une fois, je me rends compte que beaucoup de ceci est en grande partie le résultat de ma propre ignorance".
si je dois choisir, j'écrirai toutes les choses de haut niveau comme l'interface et l'interaction de base de données en python (ou éventuellement C#) et toutes les choses qui doivent être rapides en C. Pour moi, cela me donne le meilleur de tous les mondes. Écrire tout en C++, c'est comme avoir le pire de tous les mondes.
Edit: Je voudrais ajouter que je pense que C avec quelques fonctionnalités C++ est en grande partie une mauvaise idée si vous allez être plusieurs personnes travaillant sur un projet, ou si la maintenabilité est la priorité. Il y aura désaccord sur ce qui constitue un "Quelques" et quels bits devraient être faits en C et quels bits en C++ conduisant finalement à une base de code très schizophrénique.
C++ n'est tout simplement pas supporté dans certains environnements réels, comme les systèmes embarqués de bas niveau. Et il y a une bonne raison à cela: c facilement assez bon pour de telles choses, alors pourquoi utiliser quelque chose de plus grand?
quelques raisons pourraient être:
- manque de support - Tous les compilateurs C ne sont pas aussi des compilateurs C++. Tous les compilateurs ne sont pas particulièrement conformes à la norme, même s'ils prétendent supporter C++. Et certains compilateurs C++ génèrent du code désespérément gonflé et inefficace. Certains compilateurs ont des implémentations terribles de la bibliothèque standard. Le développement en mode noyau rend généralement impossible l'utilisation de la bibliothèque standard C++, ainsi que certains langages caractéristique. Vous pouvez encore écrire du code C++ si vous vous en tenez au cœur du langage, mais alors il peut être plus simple de passer à C.
- familiarité. C++ est un langage complexe. Il est plus facile d'enseigner à quelqu'un C qu'en C++, et il est plus facile de trouver un bon programmeur C qu'un bon programmeur C++. (mot-clé ici est "bon". Il y a beaucoup de programmeurs C++, mais la plupart n'ont pas appris le langage correctement)
- courbe D'apprentissage - comme ci-dessus, enseigner à quelqu'un C++ est une tâche immense. Si vous écrivez une application qui doit être maintenue par d'autres dans le futur, et que ces autres ne sont peut-être pas des programmeurs C++, l'écrire en C rend la tâche beaucoup plus facile.
je préférerais quand même écrire en C++ quand je peux m'en tirer, et dans l'ensemble, je pense que les avantages l'emportent sur les inconvénients. Mais je peux également voir l'argument pour utiliser C dans certains cas.
il y a des tas d'arguments sur la programmation intégrée, la performance et tout, Je ne les achète pas. C++ compare facilement à C dans ces domaines. Toutefois:
récemment, après avoir programmé en C++ pendant plus de 15 ans, j'ai redécouvert mes racines C. Je dois dire que bien qu'il y ait de bonnes fonctionnalités en C++ qui rendent la vie plus facile, il y a aussi un tas d'embûches et une sorte de "there-is-always-a-better-way" de faire les choses. Vous n'avez jamais obtenez en fait très heureux de la solution que vous avez fait. (Ne vous méprenez pas, ce pourrait être une bonne chose, mais surtout pas).
C++ vous donne des coups de feu infinis. Ce qui pourrait être bien, mais on finit toujours par en abuser. Cela signifie que vous dissimulez vos solutions avec des couches "belles" et "jolies" d'abstractions, de généralité, etc.
ce que j'ai découvert en revenant à C était que c'était en fait la programmation amusante à nouveau. Après avoir passé tant de modélisation du temps et de réflexion sur la meilleure façon d'utiliser l'héritage je trouve que la programmation en C rend en fait mon code source plus petit et plus lisible. Cela dépend bien sûr de votre niveau d'autodiscipline. Mais il est très facile de mettre trop d'abstractions sur du code simple, ce qui n'est jamais vraiment nécessaire.
C A l'avantage principal que vous pouvez juste voir ce qui se passe vraiment quand vous regardez un morceau de code (ouais préprocesseur: compiler avec-E et puis vous le voyez). Quelque chose qui est trop souvent faux quand on regarde un code C++. Il y a des constructeurs et des destructeurs qui sont appelés implicitement sur la base de scope ou à cause d'assignations, vous avez des opérateurs surchargés qui peuvent avoir un comportement surprenant même s'il n'est pas mal utilisé. J'admets que je suis un maniaque du contrôle, mais j'ai venu à la conclusion que ce n'est pas une mauvaise habitude pour un développeur de logiciels qui veut écrire un logiciel fiable. Je veux juste avoir une chance équitable de dire que mon logiciel fait exactement ce qu'il est censé faire, et ne pas avoir un mauvais sentiment dans mon estomac en même temps parce que je sais qu'il pourrait encore y avoir tellement de bugs que je n'aurais même pas remarqué quand j'ai regardé le code qui les provoque.
C++ a aussi des gabarits. J'ai la haine et l'amour, mais si quelqu'un dit qu'il ou elle les comprend parfaitement, Je l'appelle un menteur! Cela inclut les rédacteurs du compilateur ainsi que les personnes impliquées dans la définition de la norme (ce qui devient évident lorsque vous essayez de la lire). Il y a tellement de cas d'angle absurdement trompeurs impliqués qu'il n'est tout simplement pas possible de les considérer tous pendant que vous écrivez le code réel. J'aime les modèles C++ pour leur puissance. Il est vraiment étonnant ce que vous pouvez faire avec eux, mais ils peuvent également conduire à la plus étrange et plus difficile de trouver des erreurs un peut (pas) l'imaginer. Et ces erreurs se produisent en fait, et même rarement. Lire sur les règles impliquées pour résoudre les gabarits dans le bras C++ fait presque exploser ma tête. Et cela me donne le mauvais sentiment de perdre du temps à lire des messages d'erreur de compilateur qui sont de plusieurs milliers de caractères pour lesquels j'ai déjà besoin de 10 minutes ou plus pour comprendre ce que le compilateur veut réellement de moi. Dans le code C++ (bibliothèque) typique vous trouvez aussi souvent beaucoup de code dans les fichiers d'en-tête pour faire certain les gabarits possibles qui à leur tour rendent les cycles de compilation/exécution douloureusement lents même sur les machines rapides et nécessite la recompilation de grandes parties du code quand vous changez quelque chose là.
C++ a aussi le piège const. Vous évitez const pour tous sauf les cas d'utilisation les plus triviaux ou vous aurez tôt ou tard à jeter ou à remanier de grandes parties de la base de code quand il évolue, surtout quand vous êtes sur le point de développer un design oo agréable et flexible.
C++ a plus de frappe que C, ce qui est génial, mais parfois j'ai l'impression de nourrir un Tamagotchi quand j'essaie de compiler du code C++. Une grande partie des avertissements et des erreurs que j'obtiens habituellement de lui ne sont pas vraiment moi faire quelque chose qui ne fonctionnerait pas, mais juste des choses que le compilateur ne m'aime pas à faire de cette façon ou pas sans casting ou mettre quelques mots-clés supplémentaires ici et là.
ce sont juste quelques-unes des raisons pour lesquelles je n'aime pas C++ pour les logiciels que je Ecrire seul en utilisant seulement quelques bibliothèques externes prétendument robustes. La véritable horreur commence quand vous écrivez le code dans des équipes avec d'autres personnes. Peu importe qu'ils soient des hackers C++ très intelligents ou des débutants naïfs. Tout le monde fait des erreurs, mais C++ rend délibérément difficile de les trouver et encore plus difficile de les repérer avant qu'elles ne se produisent.
avec C++ vous êtes simplement perdu sans utiliser un débogueur tout le temps mais j'aime être en mesure de vérifier l'exactitude de mon code dans ma tête et ne pas avoir à compter sur un débogueur pour trouver mon code tournant sur des chemins que je n'aurais jamais prévus. J'essaie en fait d'exécuter tout mon code dans ma tête et d'essayer de prendre toutes les branches qu'il a, même dans les sous-programmes, etc. et n'utiliser un débogueur qu'occasionnellement juste pour voir comment il fonctionne bien dans tous les endroits douillets que j'ai préparés pour lui. L'écriture et l'exécution de tant de cas de test que tous les chemins de code ont été utilisés dans toutes les combinaisons avec toutes sortes de données d'entrée étranges est tout simplement impossible. Si vous ne connaissez peut-être pas les bogues des programmes C++, mais cela ne veut pas dire qu'ils ne sont pas présents. Plus un projet C++ est grand, moins il y aura de bugs non détectés, même s'il fonctionne parfaitement avec toutes les données de test que nous avons sous la main. J'ai fini par le jeter et recommencer avec une autre langue ou une combinaison d'autres langues.
je pourrais continuer, mais je crois que j'ai été assez clair. Tout cela m'a fait sentir improductif quand j' Je n'ai plus confiance en L'exactitude de mon propre code, ce qui signifie que je ne l'utiliserai plus, alors que j'utilise et me fie encore au code C que j'ai écrit il y a plus de 20 ans. Peut-être que c'est simplement parce que je ne suis pas un bon programmeur C++, ou peut-être que le fait d'être assez bon en C et dans d'autres langues me permet de reconnaître quel lamer je suis réellement quand il s'agit de C++, et que je ne pourrai jamais le comprendre complètement.
la vie est courte...
dans un environnement embarqué de bas niveau, certains des" ingénieurs logiciels " ont une formation en EE et maîtrisent à peine C. C++ est plus complexe et certains de ces gars ont simplement peur d'apprendre un nouveau langage. C est donc utilisé comme le plus petit dénominateur commun. (Avant de suggérer de se débarrasser de ces gars, ils sont au moins aussi importants que les majors CS qui ne comprennent pas les trucs analogiques hardcore.)
parler de l'expérience d'avoir hérité et maintenu les deux: une conception horrible en C est difficile à comprendre, décompresser, et se transformer en quelque chose d'utilisable.
une conception horrible en C++ est infiniment pire que des couches aléatoires d'abstraction envoient votre cerveau se carénant autour de la base de code en essayant de comprendre quel code va être exécuté dans quelles circonstances.
si je dois travailler avec des ingénieurs qui, je le sais, ne produiront pas de grandes conceptions, je préfère de loin les premiers plutôt que les seconds.
Je ne vois pas d'autre raison que l'aversion personnelle, même pour programmer des systèmes intégrés et des choses semblables. En C++ , vous payez les frais généraux seulement pour les fonctionnalités que vous utilisez. Vous pouvez utiliser le sous-ensemble C du C++ dans certaines situations spécifiques où C++ overhead est trop élevé pour vous. Ceci dit, je pense que certains programmeurs C surestiment les frais généraux de certaines constructions C++. Permettez-moi d'énumérer quelques exemples:
- les Classes et les fonctions des membres ont zéro frais généraux par rapport à fonctions normales (sauf si vous utilisez des fonctions virtuelles, auquel cas il n'y a pas de frais généraux par rapport à l'utilisation de pointeurs de fonctions)
- les gabarits ont très peu de frais généraux (le plus souvent pas de frais généraux du tout)
une raison valable serait quand vous programmez pour une plate-forme qui n'a pas de compilateur C++ décent (pas de compilateur C++ du tout, ou un compilateur existe, mais est mal mis en œuvre et impose une surcharge inutile pour certains C++ caractéristique.)
Pourquoi se limiter à parler en anglais? Vous seriez peut-être un auteur plus créatif en serbe.
c'est le même argument, avec des erreurs évidentes. Si vous avez une tâche, et vos outils confortables résoudre la tâche efficacement, vous aurez probablement utiliser vos outils confortables pour une bonne raison.
C++ a une courbe d'apprentissage beaucoup plus longue. C a seulement quelques constructions dont vous devez être conscient et alors vous pouvez commencer à coder logiciel puissant. En C++ , vous devez apprendre la Base C, puis la programmation OO et générique, exception, etc. Et après un certain temps, vous connaissez peut-être la plupart des fonctionnalités et vous pouvez les utiliser, mais vous ne savez toujours pas comment le compilateur va les traduire, quels sont les frais généraux implicites qu'ils ont ou non. Ceci prend beaucoup de temps et d'énergie.
pour un projet professionnel cet argument peut ne pas compter, parce que vous pouvez employer des personnes qui connaissent déjà très bien le c++. Mais dans les projets Open Source, où C est encore largement utilisé, les gens choisissent la langue qu'ils aiment et ils sont capables d'utiliser. Considérez que tous les programmeurs OS ne sont pas des programmeurs professionnels.
Je n'ai jamais vu d'arguments pour utiliser C sur C++ que je considérerais convaincants. Je pense que la plupart des gens ont peur de certaines offres C++, souvent à juste titre. Mais cela ne me convainc pas parce que l'on peut imposer si oui ou non utiliser certaines fonctionnalités à travers les normes de codage. Même en Do, il y a beaucoup à éviter. Rejeter entièrement C++, c'est essentiellement dire qu'il n'offre aucun avantage tangible par rapport à C qui aiderait quelqu'un à écrire un meilleur code, ce qui est un point de vue que je considère comme être tout à fait ignorant.
en outre, les gens semblent toujours soulever la situation des plates-formes où il n'existe pas de compilateur C++. Bien sûr C serait approprié ici, mais je pense que vous seriez difficile de trouver une plate-forme comme ça ces jours-ci.
j'aimerais donner suite à la réponse de Dan Olson. Je crois que les gens craignent les caractéristiques potentiellement dangereuses et contre-productives du C++, et à juste titre. Mais contrairement à ce que dit Dan, Je ne pense pas que le simple fait de décider d'une norme de codage soit efficace, pour deux raisons:
- les normes de codage peuvent être difficiles à appliquer rigoureusement
- Il peut être très difficile de trouver un bon.
Je pense que la deuxième raison est beaucoup plus importante que la première, parce que décider d'une norme de codage peut facilement devenir une question politique et faire l'objet d'une révision ultérieure. Considérons le cas simplifié suivant:
- vous êtes autorisé à utiliser des conteneurs stl, mais pas à utiliser de gabarits dans votre propre code.
- les gens commencent à se plaindre qu'ils seraient plus productifs s'ils étaient juste autorisés à coder tel ou tel modèle classe. La norme de codage
- est révisée pour permettre cela.
- faites glisser une pente vers une norme de codage trop compliquée que personne ne suit et qui utilise exactement le genre de code dangereux que la norme était censée prévenir, combiné à un excès de bureaucratie entourant la norme.
(l'alternative que la norme ne soit pas révisée à l'étape 3 est empiriquement trop improbable à considérer et ne serait pas beaucoup mieux de toute façon.)
bien que j'utilisais C++ pour à peu près tout il y a quelques années, je commence à penser fortement que C est préférable dans les tâches de bas niveau qui doivent être gérées par C ou C++ et tout le reste devrait être fait dans un autre langage. (Seules exceptions possibles étant certains domaines de problèmes à hautes performances spécifiques, wrt. Blitz++ )
j'utilise C, ou au moins exporter une interface C lorsque j'écris du code de bibliothèque.
Je ne veux pas de problèmes ABI mal définis.
un point que je n'ai pas encore vu soulevé, qui je pense est le plus important:
la plupart des bibliothèques que j'utilise quotidiennement sont des bibliothèques C avec des reliures pour Python, Ruby, Perl, Java, etc. D'après ce que j'ai vu, il est beaucoup plus facile d'envelopper des bibliothèques C avec 19 reliures de langage différentes que d'envelopper des bibliothèques C++.
par exemple, j'ai appris Le Caire une fois, et je l'ai utilisé depuis dans 3 ou 4 langues différentes. Grande victoire! Je préfère écrire un programme qui peut être utilisé à nouveau dans l'avenir, et l'écriture qui peut être facilement adopté à d'autres langages de programmation est un cas extrême de cette situation.
je sais qu'il est possible de lier des bibliothèques C++, mais ce N'est pas la même chose. J'ai utilisé Qt (v3 et v4) dans d'autres langues et ce n'est pas aussi agréable à utiliser: ils ont envie d'écrire C++ dans une autre langue, pas comme les bibliothèques natives. (Vous devez passer la méthode c++ sigs comme chaînes de caractères!)
C++ est probablement un meilleur langage si vous écrivez une fonction à utiliser une fois, ou si vous pensez que tout le monde est C++. C semble comme une langue plus facile si vous concevez pour la langue-portabilité dès le début.
développement du noyau Windows ne supporte pas c++ (malheureusement).
vous pouvez lire un rant divertissant sur la raison pour laquelle Linus Torvalds favorise C ici
code Natif sur mac est objective-c. Code natif sur un PC est c (fenêtre.h) ou c++ (mfc). Ces deux environnements vous permettra d'utiliser c avec peu ou pas de modifications. Quand je veux qu'une bibliothèque de code soit multiplateformes et que c soit un bon choix.
je peux penser à plusieurs raisons.
il se peut qu'il n'y ait pas de compilateur C++ satisfaisant. C++ est un langage beaucoup plus grand, et j'ai lancé des compilateurs C sur des systèmes qui ne seraient pas capables de gérer le C++moderne.
l'auteur de la question, ou les personnes avec lesquelles il travaille, peut être familier avec C mais pas C++.
le projet peut être en C. Bien qu'il soit possible d'ajouter des fonctionnalités C++ à C, cela peut facilement conduire à un gâchis Impossible à gérer. Je suggère de choisir une langue ou l'autre (Généralement c++, si possible).
l'auteur de la question peut avoir une vision obsolète de la courbe d'apprentissage de C++. (Lorsqu'on l'aborde correctement, c'est plus facile que les "C". La plupart des livres d'introduction que j'ai vus ne l'abordent pas correctement.)
rappelez-vous que C et c++ sont deux langues différentes, et deviennent de plus en plus différentes au fil du temps. Le codage dans les deux à la fois est une mauvaise idée, et en utilisant un sous-ensemble de type C de c++ passe à côté de la plupart des les avantages du C++.
si vous travaillez dans un environnement à deux langues, Vous pouvez utiliser C pour certaines fonctions critiques de bas niveau et un langage plus fonctionnel/de haut niveau comme C#/Java pour la logique d'affaires. Si le code C++ est utilisé pour ces fonctions ,les enveloppeurs de C sont nécessaires pour le code JNI/non géré et cela rend les choses plus complexes que d'utiliser uniquement C.
j'utilise le C++ et la programmation en C, pour deux raisons:
-
vectoretstringpour obtenir la matrice de la gestion de la mémoire, loin de moi - contrôle de type strict et lance pour prévenir et / ou attraper toutes les nuisances que je manquerais autrement.
donc C emprunte vraiment Quelques c++ mais utilise le compilateur c++ autant que je peux. Comme quelqu'un d'autre dit dans les réponses, je trouve maintenant que je suis effectivement ramasser plus de C++ de cette façon et là où C serait trop impliqué, j'utilise C++. Monitor / Lock using RAII est l'un de ceux que j'ai utilisé récemment dans le cadre de programmes multi-threads et une autre construction similaire pour ouvrir/fermer des fichiers.
je pense que C est plus portable. J'ai fait quelques travaux il y a environ 5 ans portant du code à de nombreuses saveurs d'unix (AIX,Irix,HPUX,Linux). Le code C était facile à transférer, mais nous avons eu divers problèmes pour transférer une partie du code C++. Peut-être que c'était juste des environnements de développement immatures mais je préférerais utiliser C sur C++ pour cette raison...
-
C est un langage simple, C++ ne l'est pas. Pour beaucoup de gens, C++ est simplement trop compliqué à maîtriser, voir http://en.wikipedia.org/wiki/C%2B%2B#Criticism .
-
en raison de la complexité, différents programmeurs ne maîtrisent généralement que des sous-ensembles différents du langage. Cela rend la lecture du code d'autres personnes douloureuse.
-
la complexité, les pièges de la langue d'ajouter trop de distraction, et parfois nuire à la productivité. Au lieu de me concentrer sur le travail lui-même, je me suis souvent retrouvé à me battre avec la langue elle-même. Java / python sont des alternatives plus productives.
-
déboguer un code C cassé est habituellement beaucoup plus simple que déboguer un code C++ cassé.
-
contrairement à Java / C#, la bibliothèque standard c++ atteint peu au-delà de la portée du C la bibliothèque standard.
-
certains programmeurs célèbres comme Linus Torvalds (Linux) et Richard Stallman (Emacs) n'aiment pas C++.
la plupart des programmeurs tiennent pour acquis que tout le monde considère la qualité comme une priorité. Ce n'est pas toujours le cas. Si vous êtes habitué au C, le C++ peut sembler en faire trop pour vous dans les coulisses. La rigueur de la vérification de type en C++ peut aussi sembler confinant. Beaucoup de gens sont prêts à prendre le risque d'introduire le genre de bogues que C++ peut aider à prévenir pour éviter ces "nuisances."
Il y a trois raisons je pense. L'une est que C est plus adapté aux systèmes embarqués, en raison de la petite taille de ses binaires et de la plus grande disponibilité de compilateurs C sur n'importe quel système. La seconde est la portabilité: C est un langage plus petit, et et ANSI C code compilera n'importe où. C'est plus facile de casser la portabilité en C++. Le dernier est le langage lui-même. C++ est plus dur, et est certainement un langage très mal conçu. Torvalds saisines sont rapportées ci-dessus. Vous pouvez également pour regarder les réponses c++ fréquemment interrogées ( http://yosefk.com/c++fqa / ).
Portabilité peut être un problème. Contrairement à la réponse de Gordon Carpenter-Thomp, je dirais que c'est plutôt le support d'exécution de différentes versions de libstdc++ sur différentes versions linux/unix. Voir ce lien pour une bonne discussion à ce sujet. Un petit extrait:
le code de support d'exécution utilisé par différentes parties d'une application C++ doit être compatible. Si une partie du programme doit dynamic_cast ou attraper les objets fournis par un autre, les deux parties doivent s'entendre sur certains détails d'implémentation: comment trouver vtables, comment décompresser la pile, et ainsi de suite.
pour C++ et quelques autres langages supportés par GCC avec des fonctionnalités similaires, ces détails sont spécifiés par un ABI C++. Chaque fois que L'ABI utilisé par GCC change, vous finirez avec des bibliothèques incompatibles produites par les différentes versions de GCC. La même chose est vraie pour C simple, mais le C ABI est beaucoup plus simple et a été autour beaucoup plus longtemps donc c'est assez stable.
je peux suivre beaucoup de suggestions ici dans les deux sens. Mais en fin de compte, il revient à l' a) comparable simple B) complexe comparable.
je n'ai pas d'idée si quelqu'un a "inventé" une sorte de mesure de la complexité du langage.
sur une échelle de 0 à 10, j'évaluerais probablement C à 2 ou 3 alors que C++ se situerait entre 8 et 10. Je dirais que C++ est l'un des langages les plus complexes mais je ne sais pas E. gada, PL1 ou autre, alors peut-être que c'est pas de complexe par rapport à certaines autres langues.
C++ hérite de toute la complexité de C donc il ne peut pas être en dessous du niveau de complexité de C.
pour ma part, je serais beaucoup plus à l'aise en utilisant un langage de script et C. donc, à la fin, on doit répondre à la question suivante. "Plus c'est toujours mieux?"
la chose la plus utile que j'ai trouvée en C est le manque d'espaces de noms et de surcharges: les noms de fonctions et de symboles sont des identificateurs uniques. Pour trouver les endroits où ces symboles sont utilisés, Vous pouvez juste grep à travers les fichiers de code source et les résultats de recherche afficheront les emplacements.
c'est essentiel lorsque vous câblez une nouvelle caractéristique ou un nouveau composant à un système ancien et enchevêtré.
vous ne pouvez pas faire cela facilement en C++, sans un appel sophistiqué graphique de l'outil de construction.
la plupart des gens semblent penser que C et C++ sont en quelque sorte liés, mais ils se trompent tristement. C++ est un langage complètement différent de C.
en C++, vous pensez en termes d'objets et comment ils sont reliés entre eux. En C, vous pensez en termes D'API. C'est comme la différence entre le jour et la 17.
une mauvaise analogie: si quelqu'un ajoute le Chinois à l'anglais et l'appelle anglais++, vous ne vous sentiriez probablement pas à l'aise d'ajouter une ligne en chinois votre dernière lettre d'amour, parce que c'est tellement plus facile d'exprimer de l'amour dans cette partie de l'anglais++.
voici toutes les raisons pour lesquelles il peut être avantageux de limiter un projet à C:
- compilation plus rapide parce que le langage est beaucoup plus simple
- nécessite moins de support d'exécution, ce qui le rend plus adapté aux environnements de bas niveau
- interface beaucoup plus facile avec d'autres langues
- supporte les tableaux de dimensions variables sur la pile
- code d'assemblage plus facile à lire car il n'y a pas de nom mangeant
- permet de combiner facilement du code produit par différents compilateurs puisqu'il s'agit de l'interface binaire d'application standard de facto