Pourquoi devrais-je apprendre le C ++ 11, après avoir connu le C et le C ++? [fermé]


28

Je suis programmeur en C et C ++, bien que je ne m'en tiens à aucun des deux langages et que j'écris un mélange des deux. Parfois, avoir du code dans des classes, peut-être avec une surcharge d'opérateur, ou des modèles et le oh si grand STL est évidemment une meilleure façon. Parfois, l'utilisation d'un simple pointeur de fonction C est beaucoup plus lisible et claire. Je trouve donc la beauté et l'aspect pratique dans les deux langues. Je ne veux pas entrer dans la discussion de "Si vous les mélangez et compilez avec un compilateur C ++, ce n'est plus un mélange, c'est tout C ++" Je pense que nous comprenons tous ce que je veux dire en les mélangeant. De plus, je ne veux pas parler de C vs C ++, cette question concerne C ++ 11.

C ++ 11 introduit ce que je pense être des changements importants dans le fonctionnement de C ++, mais il a introduit de nombreux cas spéciaux, exceptions et irrégularités qui changent la façon dont différentes fonctionnalités se comportent dans différentes circonstances, imposant des restrictions sur l'héritage multiple, des identificateurs qui agissent comme des mots clés, des extensions des littéraux de chaîne, capture de variable de fonction lambda, etc.

Je sais qu'à un moment donné dans le futur, quand vous dites C ++, tout le monde supposerait C ++ 11. Tout comme lorsque vous dites C de nos jours, vous voulez probablement dire C99. Cela me fait envisager d'apprendre C ++ 11. Après tout, si je veux continuer à écrire du code en C ++, je devrai peut-être à un moment donné commencer à utiliser ces fonctionnalités simplement parce que mes collègues l'ont fait.

Prenez C par exemple. Après tant d'années, il y a encore beaucoup de gens qui apprennent et écrivent du code en C. Pourquoi? Parce que la langue est bonne. Ce qui signifie bien, c'est qu'il suit de nombreuses règles pour créer un bon langage de programmation. Donc, en plus d'être puissant (ce qui est facile ou difficile, presque tous les langages de programmation le sont), C est régulier et a quelques exceptions, le cas échéant. C ++ 11 cependant, je ne pense pas. Je ne suis pas sûr que les changements introduits dans C ++ 11 améliorent le langage.

La question est donc: pourquoi devrais-je apprendre le C ++ 11?

learning  c++  c  c++11 

3
Je comprends qu'il ne devrait pas y avoir de diatribe C ++ 11 dans ce forum et je suis totalement d'accord sur ce point: chaque développeur a le droit d'avoir son goût personnel concernant les langages et outils de programmation. Il y a, cependant, un problème beaucoup plus pratique pour moi: je suis un développeur C ++ et je n'aime pas C ++ 11, vais-je être obligé d'utiliser C ++ 11 ou être hors du marché / passer à une autre langue au sein de quelques années?
Giorgio

Eh bien, j'y ai réfléchi un peu, bien sûr, il existe des langages à partir de zéro plus modernes tels que le langage de programmation D ou Go. Celles-ci pourraient convenir à votre domaine problématique, plus faciles et plus cohérentes, etc. Cependant, la part de marché .. aucun des acteurs clés de l'industrie ne prend en charge D et même Go ne semble être l'une des "expériences" de googles .. Donc, la motivation derrière C + +11 devrait être les améliorations utiles qui vous permettent d'écrire du code plus lisible, plus sûr et plus rapide ainsi que le large support de l'industrie.
Nils

@giorgio, au cours des deux dernières années, j'ai cessé d'utiliser C ++ autant qu'avant (principalement parce que je me suis rendu compte à quel point les fans de C ++ sont religieux, en lisant les réponses à cette question), mais j'ai quand même travaillé dans une bibliothèque C ++ que j'ai volontairement utilisé C ++ 11 pour. Mon expérience était la suivante: C ++ 11 s'adresse à beaucoup de coins de merde de C ++, et c'est admirable et en fait il s'améliore. La façon dont il le fait a ses propres coins de merde (voir le post original non édité). Cependant, ces coins de merde semblent être à l'écart si vous faites les choses "de la manière normale" (par exemple, ne stockez pas un lambda pour une utilisation future).

@giorgio, ce que je veux dire, c'est que C ++ 11 peut sembler mauvais au début, en fait C ++ lui-même a l'air terrible, mais si vous êtes d'accord avec C ++, vous aimeriez probablement C ++ 11 aussi. Évitez simplement de toucher ses parties de merde et vous pourriez en profiter.

@anon: Une façon de se débarrasser des parties merdiques d'une langue est de couper avec le passé et de commencer une nouvelle langue, comme Apple le fait avec Swift (pour ne citer qu'un seul des nombreux exemples). L'interfaçage avec le code hérité peut être effectué via une compilation séparée. Le problème avec C ++ est qu'il est étendu indéfiniment, probablement parce qu'il est soutenu par une communauté de fans qui croient religieusement que C ++ est le seul vrai langage. Bottom line: J'ai trouvé C ++ 03 un peu merdique mais il a fait le travail, en particulier grâce à des bibliothèques comme Qt et boost. D'un autre côté, je garderai mes mains loin de C ++ 11.
Giorgio

Réponses:


24

Vous devriez l'apprendre si vous pensez avoir besoin de le savoir à l'avenir pour obtenir un emploi. Si vous êtes convaincu que vous resterez commercialisable sur le marché du travail en tant que C / C ++ [et tout ce que vous pourriez savoir], alors ne l'apprenez pas. Si votre patron vous dit d'utiliser C ++ 11, dites "non, je ne fais pas ça". S'il vous congédie, allez travailler ailleurs. Apprenez le C ++ 11 lorsque vous prévoyez que bientôt vous ne pourrez pas trouver un emploi satisfaisant avec les compétences que vous connaissez actuellement.

Je voulais clarifier ma justification: je ne suis pas anti-C ++ 11. Je dis simplement que vous pouvez généraliser la question du PO à "Pourquoi devrais-je apprendre X". Je n'ai jamais appris le ML, le schéma ou le haskell parce que j'ai un travail avec C et C ++. Je suis sûr que ces langues sont utiles à quelqu'un, mais elles ne me sont pas utiles pour le moment. Si quelqu'un m'offrait beaucoup d'argent pour programmer en ML, je pourrais essayer de l'apprendre.


3
Si vous êtes un développeur "C / C ++", et si votre patron vous dit d'utiliser C ++ 11, ne devriez-vous pas simplement aller de l'avant et ajouter cela à votre arsenal? Je suis d'accord pour dire que vous ne devriez pas passer tout votre temps à apprendre des langues juste pour le plaisir de les apprendre, mais quand votre patron dit "Apprenez ceci", c'est probablement une bonne idée d'aller de l'avant et de l'apprendre. Cela vous rend également plus commercialisable, au lieu d'avoir à expliquer sur votre prochaine demande que vous avez été licencié pour insubordination.
Panzercrisis

Haskell ... Drôle, à cause de l'inclusion lente des lambdas dans C ++. : P
rbaleksandar

85

C'est simple. C ++ 11 rend le code considérablement plus facile, plus propre à écrire et plus rapide.

nullptrest une amélioration VAST par rapport à l'ancien 0. Il est sûr pour le type et ne se convertit pas alors qu'il ne devrait pas - contrairement à 0. C'est une bonne chose qui nullptrne se convertira pas en int. Cela n'a aucun sens que cela se produise du tout. Savez-vous ce que le comité C ++ a trouvé lorsqu'il a essayé d'envisager #define NULL nullptr? Des trucs comme char c = NULL;. C'est terrible, non? La seule raison pour laquelle il y a une exception ici est parce qu'il boolest considéré comme un type intégral, ce qui est tout à fait faux - mais qui était là en C ++ avant et en C. Le fait de nullptrne pas convertir est bon , c'est génial et vous devriez l'aimer.

Ou que diriez-vous des références rvalue et des modèles variadic? Code plus rapide et plus générique. C'est une victoire totale ici.

Qu'en est-il des améliorations de la bibliothèque? Des trucs comme function, unique_ptret shared_ptrsont tellement meilleurs que ce qui était auparavant, il est impossible de prétendre que la manière C ++ 03 était meilleure.

#define adding_func(x, y) ((x)+(y))

Pas même à distance équivalent. Les macros sont mauvaises pour six milliards de raisons. Je ne vais pas tous les citer ici, mais il est bien connu que les macros doivent être évitées à peu près à toutes les fins pour lesquelles elles peuvent éventuellement être évitées. Qu'allez-vous faire quand ce sera

#define add_twice(x) (x + x)

Oh attends, j'espère que tu n'as pas augmenté ou quelque chose dessus x. À laquelle la version de la fonction de modèle est totalement immunisée. J'espère également que vous n'aimez pas les espaces de noms , par exemple.

Ensuite, vous vous ouvrez à un monde de comportements indéfinis pour utiliser des variables externes dont les portées sont déjà terminées.

Dans une API fonctionnelle, par exemple les algorithmes STL, la référence est correcte. S'il s'agit d'un rappel stocké, vous devez capturer par valeur. Quelle que soit la documentation que vous avez sur la fonction, elle doit indiquer clairement celle qui est nécessaire. Le fait que le code soit écrit dans un lambda est sans importance pour le problème de référence aux variables locales - si vous passez un objet de fonction régulière, alors vous allez avoir exactement le même problème. Et ce n'est pas un problème. Du tout. Parce qu'il est intrinsèquement évident lorsque vous pouvez et ne pouvez pas faire référence à des variables locales.

Prenez C par exemple. Après tant d'années, il y a encore beaucoup de gens qui apprennent et écrivent du code en C. Pourquoi?

Il y a beaucoup de gens qui ne se brossent pas les dents le matin. Il y a beaucoup de meurtriers, de violeurs et de prostituées. Et les politiciens. Les gens qui se suicident. Diriez-vous que cela rend donc ces activités bonnes ou utiles? Bien sûr que non. C'est une erreur logique que juste parce que quelqu'un l'a fait, elle doit donc être bonne ou utile.

C est toujours en cours d'écriture pour trois raisons: parce que C ++ est une chienne à implémenter, par exemple en mode embarqué ou noyau; parce que les bases de code héritées sont écrites en C et coûteraient trop cher à mettre à niveau, bien que cela soit discutable étant donné l'excellent interopérabilité en C de C ++; et parce que les gens qui l'écrivent ne savent pas programmer. C'est ça. Il n'y a pas d'autre raison d'écrire C.

Si vous prenez C ou l'ancien C ++, vous ne trouverez pas beaucoup d'exceptions.

Que diriez-vous des tableaux pathétiques de style C, pour un exemple simple? Le nombre de personnes qui ne peuvent pas obtenir des tableaux et des pointeurs directement dans leur tête est obscène. Sans parler du fait que la bibliothèque C Standard est incroyablement dangereuse.

Vos principaux arguments sont pleins d'erreurs logiques et de malentendus.


7
> Le fait que nullptr ne convertisse pas est bon, c'est génial et vous devriez l'adorer. OK votre opinion, mais calmez-vous un peu sur ce que quelqu'un d'autre devrait AIMER, s'il vous plaît ... La prochaine étape est le talibanisme des avocats C ++!
Emilio Garavaglia

5
Je pense que la dernière partie de votre réponse explique davantage pourquoi C ++ devrait être préféré à C. C'est hors de question. "Les bibliothèques C ne sont pas sûres" - comment diable cela répond-il à la question? Je veux dire bien sûr que l'on devrait apprendre les nouvelles fonctionnalités qu'offre C ++ 11, mais C et C ++ ne sont PAS censés faire les mêmes choses. Si C ++ est une chienne à implémenter à bas niveau, il en va de même pour C #, Java, Python et ainsi de suite, car ils n'étaient pas destinés à fonctionner aussi bas. Ce n'est pas parce que C ++ se compile en code natif que vous pouvez utiliser OO et le thrashing de page qui lui est associé pour du code critique au niveau du noyau.
yati sagade

11
@Shahbaz, vous devez clairement en apprendre un peu plus sur les langages de programmation (par exemple, les systèmes de type, la portée lexicale, etc.), tous vos commentaires sont entièrement désynchronisés. Commencez avec ce livre: amazon.com/Theories-Programming-Languages-John-Reynolds/dp/…
SK-logic

5
@yati: C ++ a le même système de modules que C. Les fonctions membres sont implémentées comme de vieilles fonctions C simples. Les fonctions virtuelles sont implémentées de la même manière que le chargement de fonctions à partir d'une DLL. Il n'y a rien de débordant à ce sujet. Et oui, cela s'applique certainement. Pour commencer, votre conviction qu'Unix est le meilleur est subjective. Sa part de marché de 5% suggère le contraire. Et deuxièmement, même si j'adorais Unix sans fin, un exemple ne donnera pas de tendance. Il en va de même pour les autres exemples que vous citez. Quels exemples? Ils n'ont aucun sens. C ++ est tout aussi adapté aux procédures que C l'est.
DeadMG

8
@yatisagade C ++ est un langage multi-paradigme qui n'impose pas de fonctions virtuelles pour tout, et mes programmes en C ++ sont similaires. Certaines parties utilisent une conception orientée objet, certaines parties sont fonctionnelles, etc., selon ce qui résout le mieux ce sous-problème particulier. J'apprécie C ++ pour avoir ajouté le style orienté objet et j'apprécie C ++ 11 pour avoir considérablement étendu la prise en charge de la programmation fonctionnelle.
David Stone

29

C ++ 11 n'est pas un nouveau langage; ce n'est qu'une extension / modification de C ++ que vous connaissez déjà. C ++ 11 comme tout autre langage de programmation se compose de fonctionnalités. Beaucoup d'entre eux étaient là avant, certains sont nouveaux. Mais votre question est vraiment, dois-je apprendre toutes les fonctionnalités du langage (dans ce cas C ++ 11), ou seulement me familiariser avec 90% de celui-ci?

IMO même si vous n'utilisez pas toute la langue, vous devriez au moins lire ce que les nouvelles fonctionnalités font pour vous. Beaucoup d'entre eux ont été introduits pour rendre le code de bibliothèque / framework (en particulier les modèles) plus facile à écrire (par exemple, avant que le transfert parfait en C ++ 11 ne soit impossible), mais si vous n'avez jamais eu besoin de cette fonctionnalité auparavant, vous avez probablement des chances de gagner notez pas que ces fonctionnalités ont été ajoutées en C ++ 11.

D'un autre côté, si vous avez déjà essayé d'écrire du code de bibliothèque / noyau qui imite certaines des fonctionnalités STL / Boost et que vous vous êtes trouvé limité par le langage parce que vous avez atteint 95% d'avoir une solution très cool et élégante mais vous avez été arrêté parce que vous avez découvert que le langage ne supporte tout simplement pas ce que vous voulez, vous réaliserez la puissance vraiment impressionnante de C ++ 11. Depuis que notre équipe est passée à VS2010 (et nous avons découvert Boost dans le processus), j'ai été en mesure de lancer un code génial fou, qui serait tout simplement impossible avant des choses comme les références de valeur r et la transmission des paramètres de modèle.

Des choses comme lambda peuvent aussi sembler étrangères, mais elles n'introduisent pas de nouvelle construction. Au lieu de cela, ils rendent ce que nous avions avant tellement plus facile à écrire. Auparavant, chaque fonction lambda devait être une classe distincte. Maintenant, c'est juste {... code ...}. Aimer.

La clé est de ne pas regarder ces fonctionnalités et de penser à quel point la liste est intimidante. Au lieu de cela, utilisez C ++ comme vous le faites normalement et lorsque vous rencontrerez un scénario où ces nouvelles fonctionnalités C ++ 11 seront utiles (plus de 90% des gens n'y arriveront jamais), vous serez très heureux que l'extension à la langue a été fait. Pour l'instant, je vous suggère d'en apprendre suffisamment sur la langue pour savoir ce qu'il y a, pas nécessairement comment l'utiliser.


7
@Shahbaz - Je pense que vous manquez toujours l'intention de pourquoi des fonctions sans nom ont été ajoutées. Et "utiliser des variables sans les prendre en entrée" est appelé fermeture et est disponible dans de nombreux autres langages de haut niveau. Si vous écriviez beaucoup de code de modèle avec des objets foncteurs, avec C ++ 11, vous accueilleriez les fonctions lambda à bras ouverts. Pensez-y de cette façon ... lorsque le compilateur génère du code machine, la fonction ou la classe de modèle n'existe pas. Ils sont tous "instanciés" pour créer des classes / fonctions concrètes avant ce point. Les lambdas sont la même chose quand il s'agit de l'état ...
DXM

5
... des foncteurs. Au lieu de demander aux gens d'écrire une tonne de code, un pour chaque type de foncteur et chaque élément de fermeture que vous souhaitez transmettre, C ++ 11 vous permet de spécifier une syntaxe de raccourci et il instanciera automatiquement une classe de foncteur interne entière comme il instancie les modèles. Encore une fois, gardez à l'esprit que la plupart de ces fonctionnalités ne seront pas utilisées dans 98% du code au niveau de l'application, mais elles ont été ajoutées pour rendre les bibliothèques comme STL / Boost beaucoup plus puissantes et plus faciles à implémenter / maintenir / déboguer
DXM

10
@Shahbaz: D'accord, vous ne comprenez pas les fonctions lambda ou les fermetures. C'est raisonnable. Le fait qu'ils soient utilisés dans de nombreuses langues différentes devrait suggérer qu'ils sont utiles, que vous les compreniez ou non, et que vous devez les comprendre avant de trop les critiquer.
David Thornley

8
@Shahbaz: Si vous pensez que les fermetures sont similaires aux variables globales, vous ne comprenez pas les fermetures. (Astuce: les variables globales causent des problèmes car n'importe quelle fonction peut les modifier.) Si vous compreniez le concept de lambdas, pas l'implémentation, vous ne l'attribueriez pas à la confusion des classes par rapport au code. Tout dans la norme C ++ est là pour des raisons qui ont convaincu un grand nombre de personnes intelligentes. Vous n'êtes pas obligé d'être d'accord avec les raisons, mais sans les connaître, vous critiquez l'ignorance.
David Thornley

6
@Shahbaz, il n'y a absolument aucune similitude entre les fermetures et les globales, vous manquez complètement le point. Lisez ceci: en.wikipedia.org/wiki/Lambda_calculus et pour faire exploser votre cerveau: en.wikipedia.org/wiki/Combinatory_logic
SK-logic

18

Est-il si difficile d'écrire une fonction, que vous devez écrire le contenu de la fonction en ligne avec le code, en plus de ne lui donner aucun nom?

Lorsque vous faites cela, faites défiler vers le haut ou ouvrez un nouveau fichier source et ajoutez-y la définition de la fonction. Ensuite, vous devez revenir en arrière et continuer sur ce sur quoi vous travailliez, ce qui vous distrait dans une certaine mesure.

En dehors de cela, lorsque d'autres personnes vous lisent, un code lambda peut être plus auto-documenté dans certains cas, au lieu de dire "Oh, que fait cette fonction?" et en sautant sur sa déclaration, vous pouvez simplement jeter un œil à ce qu'il fait à sa place.

Il y a une belle discussion par Herb Sutter sur les lambdas, peut-être qu'il peut mieux vous convaincre:

http://channel9.msdn.com/events/PDC/PDC10/FT13

Eh bien, pourquoi n'y écrivez-vous pas simplement le code au lieu d'en faire une fonction lambda?

Parce que vous ne pouvez pas le faire lorsque vous utilisez des algorithmes STL ou toute fonction que vous utilisez qui vous oblige à passer une fonction.

#define add_func (x, y) ((x) + (y))

Il n'y a aucun moyen de justifier cette utilisation au lieu de lambdas, vous ne pouvez pas remplir votre code avec des macros partout. Les macros et les fonctions ont des objectifs différents, et l'une, en général, ne remplace pas l'autre.

template<class Lhs, class Rhs>
auto adding_func(const Lhs &lhs, const Rhs &rhs)
                -> decltype(lhs+rhs) {return lhs + rhs;}

Je suis d'accord, c'est moche. Cependant, je me souviens avoir dit "pourquoi diable devrais-je comprendre le type de cette expression même si le compilateur peut en déduire cela?" dans de nombreux cas. Cela pourrait aider beaucoup pendant ces moments.

Pour résumer:

Même si les nouvelles fonctionnalités de C ++ 11 semblent laides dans leur syntaxe, je pense que l'on peut s'y habituer en peu de temps. Chaque nouvelle construction de langage est difficile à apprendre au début; imaginez la première fois que vous avez appris à écrire une classe entière: Mettre la déclaration dans le fichier d'en-tête, sans oublier le point-virgule supplémentaire à la fin, mettre les définitions dans le fichier source, y compris le fichier d'en-tête tout en s'assurant qu'il a une garde pour empêcher inclusions multiples, sans oublier l'opérateur de résolution de portée dans les déclarations de fonctions membres et ainsi de suite ...

Mais je suis à peu près sûr qu'après avoir écrit quelques classes, vous vous y habituez, et vous ne pensez pas à la complexité de ce processus: parce que vous savez qu'une classe rend votre travail de programmeur beaucoup plus facile et l' utilité que vous gagnent de cette nouvelle construction est beaucoup plus grande que la perte d'utilité pendant le temps que vous essayez d'apprendre la langue . Je pense que cela peut être la raison pour laquelle on devrait essayer d'apprendre, ou utiliser C ++ 11 d'une manière similaire.


Des arguments sur l'auto-documentation et moins de défilement, etc., je suis à peu près sûr que des arguments opposés tels que "code d'encombrement", "restriction d'accès", etc. ont été utilisés pour expliquer pourquoi les fonctions en dehors de la classe doivent être interdites. Je pense que les gens doivent acquérir plus d'expérience pour décider lequel est le meilleur. Il me semble que c'est soit une expérience qui échoue, soit une mauvaise conception. Je suis plus convaincu de ne pas être le rat de laboratoire dans cette expérience.
Shahbaz

À propos de la syntaxe qui a l'air moche, prenez ces deux exemples: bool is_alive;et bool thisSpecialObjectOfMineIsAlive;. Les deux font de même, mais le second a l'air vraiment moche. Pourquoi? Parce que je pensais à tort que mettre plus d'informations le rendait plus clair, mais cela a fait le contraire. C'est la même affaire ici, Stroustrup signifiait bien en nous donnant des fonctionnalités, mais il ne le rendait pas beau. Pour moi, cela montre un mauvais design.
Shahbaz

3
beau! = bon et mauvais! = mauvais.
DeadMG

@Shahbaz: Je pense que les lambdas sont de grands concepts (et existent depuis de nombreuses années dans des langues comme Lisp). Je les utilise beaucoup à Haskell. Je suis moins sûr qu'ils s'intègrent dans des langages comme C ++, Java, etc. Ils me semblent un peu comme une réflexion après coup: quelque chose qui a été ajouté plus tard parce que les lambdas sont devenus populaires. Pourquoi n'ont-ils pas été introduits dans ces langues dès le début? Stroustrup et Goslin n'avaient-ils jamais entendu parler de Lisp?
Giorgio

8

En fait, le PO a quelques points, comme la plupart des réponses. Mais ils sont "distants" dans leur vision. Le C ++ (y compris le sous-ensemble C) a une longue histoire où un certain nombre de fonctionnalités ont été ajoutées au fil du temps, certaines d'entre elles étant utilisées plus ou moins fréquemment et - à travers leur utilisation et leurs erreurs - perfectionnées en d'autres et d'autres.

Parfois, il arrive qu'après l'introduction d'une nouvelle fonctionnalité, une ancienne soit plus nécessaire ou se sente en contradiction avec elle. Un langage "propre" doit être auto-cohérent tel qu'il est, et les fonctionnalités qui ne sont plus nécessaires doivent être supprimées.

Mais l'ajout ne détruit rien. La suppression (ou la modification) casse le code existant qu'il est toujours en production, donc quelle que soit la fonctionnalité que vous ajoutez, vous devez prendre soin de ne pas casser le code existant (en particulier, ne le cassez pas en silence , ce qui le fait faire des choses différentes comme prévu ).

Devez-vous apprendre tout cela? Oui, car toutes les fonctionnalités sont utilisées, en bien ou en mal, tôt ou tard. Que ce soit une bonne chose pour la «qualité» de la langue (en admettant qu'il existe une mesure objective ) est une autre histoire: combien de temps la compatibilité descendante devrait-elle être conservée? difficile de trouver une réponse, quand quelqu'un dit 3 ans et certains disent 50.

L'alternative pour garder le C ++ plus "régulier" est ... de le casser plus souvent, avec un redémarrage à zéro. Mais ce ne sera plus du C ++.

Il y a aussi des tentatives pour le faire (pensez à D, par exemple: beaucoup plus orthogonal que le C ++ (même 11)), mais quelle est leur popularité? L'une des raisons de leur difficulté à avoir un élan est l'incompatibilité avec de nombreux codes existants qui doivent encore s'exécuter.

C ++ 11, pour moi, est clairement un compromis entre les nouveaux besoins et la compatibilité descendante. Cela a entraîné un certain "désordre" de ses spécifications et de sa mise en œuvre. Jusqu'à ce que le coût de ce "désordre" soit inférieur au coût de l'incompatibilité ... vous devez partir avec ce compromis.

Si vous ne pouvez plus le tolérer, ... mieux vaut envisager une autre langue plus jeune. C ++ ne peut tout simplement pas être simplifié dans ce sens. Pas à cet âge.


Je suis également d'accord. Et en tant que développeur, je trouve très dérangeant d'avoir une langue qui change tout le temps (que je dois réapprendre encore et encore). Si vous développez une nouvelle langue, vous devez prendre un nouveau départ et utiliser un nom différent. Si vous souhaitez qu'il coopère avec le code hérité, il existe une compilation séparée pour cela. Je ne comprends donc vraiment pas la politique de changer une langue existante en incorporant les dernières fonctionnalités qui sont devenues à la mode. Comme l'a dit quelqu'un: un développement ultérieur n'implique pas automatiquement des progrès.
Giorgio

"C ++ ne peut tout simplement pas être simplifié dans ce sens. Pas à cet âge.": Pourquoi les autres langages de programmation (par exemple C, Ada, ...) ne suivent-ils pas le même chemin? Peut-être parce qu'ils ont leur propre niche d'applications et qu'ils ne devraient pas être l'outil pour tous les domaines d'application possibles.
Giorgio

@giorgio: oui ... vous avez probablement raison dans le sens "pragmatique". Mais en théorie ... Je me souviens de bons jours où pascal était le "langage de référence pédagogique" et ada était le "tout langage de programmation".
Emilio Garavaglia

J'ai également appris la programmation en Pascal. Autant que je sache, Ada a subi plusieurs révisions, mais la conception de base du langage n'a pas été renversée. Même chose avec C et Pascal. Si l'on veut développer un langage vraiment nouveau, il faut être assez courageux pour faire une coupe claire et commencer quelque chose de nouveau, comme D, Java, C #. Mon problème avec le chemin actuel pris par C ++ est qu'il devient (inutilement) trop complexe. Si les principes KISS et YAGNI s'appliquent à la conception de logiciels, pourquoi ne devraient-ils pas s'appliquer également à la conception de langages de programmation?
Giorgio

@Giorgio: oh ... ils s'appliquent ... exactement comme vous l'avez dit. Si vous pensez que C # ou D a fait un meilleur choix qu'un C ++ "bouilli" (mon interprétation de votre ressenti), utilisez-les simplement au lieu de C ++. Au fur et à mesure que le temps passe, C ++ mourra lentement. En ce moment, je vois C ++ 11 donner une nouvelle chance au C ++ 03 "bouilli", et D avec encore quelque chose qui manque pour briser la barrière de départ. L'économie et les intérêts des entreprises jouent également un rôle dans la façon dont le développement est financé et encouragé. Vous avez raison en théorie, mais le monde réel est plus complexe.
Emilio Garavaglia

7

Même si vous décidez d'ignorer les nouvelles fonctionnalités C ++ 11, vous en bénéficierez toujours car la bibliothèque standard C ++ les utilisera. Par exemple, en C ++ 98, avoir une variable de type vector<string>était potentiellement un désastre de performance en raison du nombre de copies à effectuer lorsque le vecteur se développait. Avec le constructeur de déplacement C ++ 11, ce n'est pas un problème. En fait, je souhaite que C ++ 11 nous apporte plus de nouvelles fonctionnalités, pas moins - en particulier dans la bibliothèque standard.


6

Après tant d'années, il y a encore beaucoup de gens qui apprennent et écrivent du code en C. Pourquoi? Parce que la langue est bonne.

Premièrement, la plupart des étudiants de nos jours apprennent Java ou .NET, pas C. Deuxièmement, les gens utilisent toujours C non seulement en raison de ses avantages en tant que langage, mais principalement parce qu'il existe une énorme quantité de logiciels existants écrits en C qui doivent être maintenu et étendu, et parce que dans de nombreux cas (par exemple les plates-formes embarquées) un compilateur C est tout ce qu'il y a. Soit dit en passant, ce sont quelques-unes des raisons pour lesquelles les gens écrivent encore COBOL.

Il est très rare qu'un programmeur de l'industrie commence à travailler sur un tout nouveau projet qui n'est pas lié à une base de code existante et continue à travailler seul. Ainsi, la raison d'apprendre C ++ 11 est que vous devrez probablement traiter avec du code écrit par d'autres personnes, qui utilise les nouvelles fonctionnalités. En outre, les fonctionnalités qui ont été ajoutées ont été ajoutées pour une raison. Une fois que vous les apprenez et les utilisez, vous pourriez les apprécier.


Vous avez cité ma phrase de manière incomplète. Comme je l'ai dit dans la phrase suivante, goodcela signifie qu'il suit les règles d'un bon langage de programmation. Je ne sais pas où vous étudiez, mais je connais 4 ou 5 pays et ils commencent tous à apprendre la programmation avec C. Comme je l'ai dit, avec C, il n'y a pratiquement aucune exception (quelque chose qui est opposé à Java, vous pourriez à peine trouver une construction qui n'a pas d'exception).
Shahbaz

1
@Shahbaz: J'ai cité des phrases complètes. Vous avez établi un lien de causalité et j'ai dit qu'il était au mieux incomplet. Heureusement, je n'étudie plus. :) J'en ai fait assez. Je vis aux États-Unis, et quand je suis allé à l'université (il y a plus de 15 ans), C était la langue d'introduction. Cependant, aujourd'hui, la plupart des écoles américaines commencent par Java, et il n'y a pas beaucoup de jeunes programmeurs qui connaissent C.
Dima

5
@Shahbaz: Je ne vois vraiment pas le problème des règles de langage ayant des exceptions. Oui, C est un langage beaucoup plus simple que C ++. D'un autre côté, C ++ facilite l'écriture de code plus simple. Pour écrire du code plus simple, vous avez besoin de plus de fonctionnalités linguistiques. Cela rend le langage plus complexe. Pour ma part, j'aime des choses comme les classes, les références, RAII, les modèles, les constructeurs, les destructeurs, les exceptions et les espaces de noms. Mais vous avez dit que votre question ne concernait pas C vs C ++, donc je n'ai pas écrit à ce sujet dans la réponse.
Dima

5
  • L'assembly a été créé parce que les gens n'aimaient pas écrire du code machine
  • C a été créé parce que les gens n'aimaient pas écrire l'assemblage
  • C ++ a été créé parce que les gens n'aimaient pas écrire C
  • C ++ 11 a été créé parce que les gens n'aimaient pas écrire C ++

Vous allez arriver à un point de votre carrière en C ++ où vous vous dites: "Je souhaite que les foncteurs soient plus simples" ou "Pourquoi NULL est-il un int?" puis vous comprendrez C ++ 11.


Toutes les langues ont été créées parce que quelqu'un n'aimait pas les langues existantes. Cela ne rend aucun d'entre eux bon.
Shahbaz

Je ne dis pas que ça NULLdevrait être un int. Ça ne devrait pas. Ce que je ne trouve pas approprié, c'est d'introduire une construction dans le langage qui résout cela, mais introduit des exceptions. Ils auraient dû être capables de faire la même chose d'une meilleure façon.
Shahbaz

2
"C ++ 11 a été créé parce que les gens n'aimaient pas écrire C ++": s'ils n'aimaient pas écrire C ++, pourquoi C ++ est-il un sous-ensemble de C ++ 11?
Giorgio

1
Cela devrait être: C # et Java ont été créés parce que les gens n'aimaient pas écrire C ++.
Calmarius

4

L'apprentissage est toujours bénéfique. La connaissance, c'est le pouvoir.

Voilà la réponse, essentiellement. Tout le reste n'est que des détails sur la façon dont vous pouvez en bénéficier et quels pouvoirs vous avez en le sachant, et ils sont si nombreux que toute énumération serait incomplète.

Un exemple est votre propre question. Vous ne pourriez même pas le demander sans en apprendre au moins un peu.

Et comme je l'ai commenté - la vraie préoccupation n'est pas pourquoi apprendre, mais pourquoi utiliser . Et c'est une question entièrement différente.


4

Vous devez apprendre le C ++ 11 car les fonctionnalités ajoutées vous permettent d'écrire un meilleur code. Certaines personnes ont mentionné la sécurité des pointeurs NULL et des lambdas, qui sont très agréables. Mais je veux attirer l'attention sur ce que je pense être le changement le plus spectaculaire en C ++ 11, en particulier dans un grand environnement de production: déplacer la sémantique.

C ++ 11 prend en charge des notions distinctes de «déplacement» et de «copie». En C ++ normal, nous avons juste l'opérateur = qui fait essentiellement les deux. Mais vraiment, nous exprimons deux idées distinctes avec un seul opérateur, ce qui est dangereux.

L'exemple le plus évident où cela est utile est le nouveau unique_ptr. Il possède toutes les meilleures fonctionnalités des anciens auto_ptr et scoped_ptr. Supposons que nous voulons avoir un pointeur qui est garanti d'être le seul pointeur pointant vers un objet. Comment traitons-nous avec a = b? Eh bien, avant, nous étions bloqués, vous pouviez soit le refuser complètement (comme scoped_ptr), soit faire ce que auto_ptr fait où a = b vole la propriété à b. Ce comportement de auto_ptr est très déroutant car a = b change en fait b. unique_ptr gère cela: a = b n'est pas autorisé, mais vous avez a = std :: move (b) pour voler la propriété. Comment est-ce utile? Où, il existe une version séparée (surchargée) du swap qui utilise la sémantique de déplacement plutôt que la sémantique de copie. Cela signifie que ce unique_ptr peut être échangé, pas de problème. Cela signifie que unique_ptr, contrairement à auto_ptr, est sûr à utiliser dans un conteneur, puis dites trier. unique_ptr est fondamentalement la solution de gestion de mémoire sécurisée lorsque vous n'avez pas besoin de plusieurs pointeurs sur le même objet.

Un autre excellent exemple: supposons que vous ayez un objet qui n'est pas copiable. Ceci est utile dans un certain nombre de situations. Vous ne pouvez jamais renvoyer cet objet à partir d'une fonction, car lorsque la fonction se termine, elle copie tout ce que vous retournez. L'ironie est qu'en général le compilateur optimise réellement cela (c'est-à-dire que rien n'est réellement copié à la fin, la valeur de retour est créée à l'adresse de l'affectation éventuelle). Mais cela n'a rien à voir avec la raison pour laquelle nous l'avons rendu non copiable; le retour d'une fonction ne fait que déplacer l'objet de la portée de la fonction vers l'extérieur. Vous pouvez maintenant écrire des objets qui ne sont pas copiables mais SONT mobiles, et ces objets peuvent être renvoyés par les fonctions.

La sémantique de déplacement facilite l'écriture de code qui ne fuit pas et qui est sûr pour les threads.


Et aussi, soit dit en passant, efficace.
Nir Friedman
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.