Discussion :

[germinolegrand]

Tu as parlé de OLTC (acronyme que tu m'as appris à l'occasion, ce dont je te remercie ), et je trouve qu'il est à ce titre presque meilleur que RAII, car il parle de la "durée de vie", ce qui sous entend "de la construction à la destruction".

A la limite, je regrettais surtout de ne pas connaitre cet acronyme

Come on, men ! I just invented it !

Je viens juste d'inventer cet acronyme, ravi qu'il te plaise .

Je suis d'accord avec toi que le mot RAII est assez malmené, puisqu'en plus de signifier l'inverse de sa signification littérale, il ne parle que d'une partie du problème.

Peut-être serait-il approprié de diffuser ce nouvel acronyme ?
En tout cas, je l'adopte définitivement pour mes prochaines discussions/explications/publications.
Il parle de lui-même, on ne peut pas en dire autant du RAII .

[iolco51]

Je vais volontairement jouer le provocateur, mais selon moi penser que le C++ est adapté aux débutants est une idée stupide. Le C++ est un langage complexe et compliqué, que même les experts devraient redouter. Point.
Si vous voulez me convaincre du contraire, soit vous mentez soit vous ne savez pas de quoi vous parlez .

Je ne vais pas rentrer dans les détails, ni plus avant dans le débat, mais pour faire bref le C++ est un beau bordel. C'est au delà des concepts OO et impératifs qui n'ont rien à voir dans mon opinion: surcharge des opérateurs (la pire idée jamais inventée selon moi), moyen bizarre d'utiliser les streams avec des opérateurs non cohérent avec le reste du langage, concept de pointeurs ET de références, heritage multiple (avec la joyeuse pagaille que cela peut engendrer), templates...etc.

En comparaison malgré ses défauts, le C est plutot simple et cohérent, très facile a lire. Le C est aussi une bonne introduction a la programmation système et bas niveau car très proche de l'assembleur en étant parfaitement lisible.

Enfin, si vous pensez que la compréhension de ce qui se basse en bas niveau (processeur, registres, allocation mémoire) est dispensable vous vous trompez. Si je devais conseiller deux langages aux débutants ce serait le C et pourquoi pas le python, mais pas tout de suite le C++.

Je vous invite par ailleurs a lire cet article que j'ai bien aimé:
http://damienkatz.net/2013/01/the_un...ness_of_c.html

[stardeath]

Si vous voulez me convaincre du contraire, soit vous mentez soit vous ne savez pas de quoi vous parlez .

tout ce que tu peux faire en c, tu peux le faire en c++. cqfd

c'est souvent un faux argument qui revient tout le temps, le c++ a des concepts compliqués DONC on est OBLIGÉ de les utiliser, les utiliser mal et sans suivre aucune convention d'écriture.

le c n'a pas ces concepts "compliqués" mais on peut très bien écrire du code inefficace, illisible et compliqué, tout dépendra du programmeur. Point

[iolco51]

qui revient tout le temps, le c++ a des concepts compliqués DONC on est OBLIGÉ de les utiliser, les utiliser mal et sans suivre aucune convention d'écriture.

le c n'a pas ces concepts "compliqués" mais on peut très bien écrire du code inefficace, illisible et compliqué, tout dépendra du programmeur. Point

Merci. J'avais dit que je ne rentrerais pas dans le débat mais c'est plus fort que moi.

Je n'ai pas dit cela.

Donc ta logique est de faire débuter avec un langage "compliqué" sous prétexte qu'on peut aussi faire du code pourri avec des langage plus "simples"? Mais je ne vois pas en quoi cela rend le langage adéquat pour débuter.

Crois tu honnêtement qu'un codeur débutant ne sachant pas faire du C un petit peu propre saura faire mieux en C++?

Certes tu peux aborder plusieurs concepts différents avec du C++... Mais quel est l'avantage pour le débutant?
Et si tu n'utilises que le C++ pour débuter, quid de la programmation fonctionnelle?
Et les frameworks de tests en C++... En quoi une syntaxe compliquée va aider le débutant à écrire de bons tests?

Métaphore: un apprenti pilote de ligne doit-il commencer faire ses armes sur un boeing 787 ou sur un petit avion de tourisme, auquel cas les bases de l'aérodynamique s'appliquent de façon évidente a l'appareil et aux commandes du pilote?

[Klaim]

Crois tu honnêtement qu'un codeur débutant ne sachant pas faire du C un petit peu propre saura faire mieux en C++?

Je crois qu'un debutant en programmation a me fait de d'abord comprendre les notions haut niveau de la programmation (conteneurs, strings, comment acheminer et transformer l'information) avant d'avoir des details sur comment ca marche a l'interieur (pointeurs, gestion de memoire etc.)

C'est pas pour rien que le Python est souvent recommande comme premier language.

Certes tu peux aborder plusieurs concepts différents avec du C++... Mais quel est l'avantage pour le débutant?

Il est question de se concentrer sur l'essentiel de ce qu'est la programmation, pas d'apprendre tous les concepts d'un language.

Et si tu n'utilises que le C++ pour débuter, quid de la programmation fonctionnelle?

Quid en C aussi?

Au passage, il y a de la programmation fonctionnelle en C++, d'abord a la compilation (templates), mais aussi via les lambdas (meme si il va falloir attendre la prochaine version du language pour aoivr un truc plus complet).

Note: il se peut que tu confondes programation fonctionelle et programmation procedurale, il faudra que tu confirmes...

Et les frameworks de tests en C++... En quoi une syntaxe compliquée va aider le débutant à écrire de bons tests?

C'est des debutant, depuis quand on apprends directs aux debutants de faire des tests???

En plus des frameworks de test en C++ yen a des tas et ils sont tres efficaces et simples.

Métaphore: un apprenti pilote de ligne doit-il commencer faire ses armes sur un boeing 787 ou sur un petit avion de tourisme, auquel cas les bases de l'aérodynamique s'appliquent de façon évidente a l'appareil et aux commandes du pilote?

Cette metaphore n'a aucun sens parcequ'un pilote d'avion doit savoir toutes les bases du pilotage (theorie) avant de piloter (pratique). En programmation, la theorie et la pratique sont intriquees et on doit apprendre les deux ensemble sous peine de faire les memes remarques que toi (qui apparemment ne comprends pas bien les differences entre C et C++).

[gbdivers]

depuis quand on apprends directs aux debutants de faire des tests???

Ceci dit... ça serait pas une mauvaise chose d'apprendre la validation de code aux débutant (voir de la programmation par contrat et tout ce qui est lié) pour qu'il puisse s'auto-corriger

[iolco51]

Note: il se peut que tu confondes programation fonctionelle et programmation procedurale, il faudra que tu confirmes...



C'est des debutant, depuis quand on apprends directs aux debutants de faire des tests???

Non je ne confonds pas fonctionnel et procédural.
La programmation fonctionnelle a un bel avenir et il est selon moi approprié de l'aborder tôt, ce qui éviterait d'avoir a désapprendre un tas de trucs par la suite.

Je te rejoins sur le python.

En revanche je pense qu'un bon programmeur doit apprendre à des débutants à écrire des bons tests, pas toi?

[stardeath]

Crois tu honnêtement qu'un codeur débutant ne sachant pas faire du C un petit peu propre saura faire mieux en C++?

comme dit un peu partout dans cette discussion, donc pour paraphraser, le c++ avec la stl à tout ce qu'il faut pour éviter les pièges du c.

donc sans les pièges manifestes, le code d'un débutant à beaucoup plus de chance de s'exécuter correctement, et non pas tomber en marche.

[iolco51]

comme dit un peu partout dans cette discussion, donc pour paraphraser, le c++ avec la stl à tout ce qu'il faut pour éviter les pièges du c.

donc sans les pièges manifestes, le code d'un débutant à beaucoup plus de chance de s'exécuter correctement, et non pas tomber en marche.

... Je suis à court d'arguments: Ma vision de la STL n'est pas exactement le meilleur moyen de débuter en programmation (sauf pour débuter en C++, bien sur, mais ce n'était pas la question).

Si tu penses que dans l'absolu un débutant doit commencer par C++ avec la STL, il est évident que nous n'avons pas la même version de débuter et d'apprendre, et que nous n'arriverons manifestement jamais à un consensus.

Ceci dit je respecte ton opinion.

[Freem]

En comparaison malgré ses défauts, le C [...] très proche de l'assembleur en étant parfaitement lisible.

C'est le seul point auquel j'ai envie de répondre.

De quel assembleur parles-tu?
J'ai déjà vu à quoi ressemble l'asm x86 en mode réel, et le C n'a pas grand chose à voir... pas d'interruptions, pas d'équivalent à SWP, rien de comparable à ROR ou ROL (rotations de bits), la possibilité de ne tester que le flag ZF, pas la possibilité de pousser un argument supplémentaire à une fonction qui ne l'a pas prévu... (oui, je suis au courant pour les variadic arg, je ne parle pas de ça, ici)

Bref, le C est simpliste à côté de l'asm x86. Il y a d'autres, beaucoup d'autres, asm, comme le motorola, mais je ne les connaît pas.

C très proche de l'assembleur? Raté, le troll, rien à voir. Pour quelqu'un qui pense manifestement maîtriser le bas niveau, c'est regrettable de telles erreurs.
Si le C était proche de l'assembleur, il ne serait pas portable. C'est un niveau d'abstraction au dessus, et programmer en asm mode réel est bien plus simple que programmer en C.
Pour le fait que connaître grossièrement la structure interne d'une machine est important, je te rejoins, c'est une excellente chose pour la culture générale.
Ca s'arrête la.

Ou alors, il faudrait aussi enseigner aux gens les subtilités de l'ordonnancement des tâches, de l'allocation mémoire en mode protégé et maintenant les modes introduits par x86_64, les registres et instructions travaillant sur les flottants, la représentation physique d'un flottant...

Tout ces points améliorent certainement la compétence d'une personne, mais sont loin d'être vitaux dans 90% des applications. La preuve, de nombreux programmes Java, Basic et C# marchent très bien, quoiqu'on pense de ces langages.
Et de nombreux programmes C ou C++ plantent aussi très bien. Pas de cause à effet ici, pour moi.

[iolco51]

C très proche de l'assembleur? Raté, le troll, rien à voir.

Non je ne suis effectivement pas expert en programmation bas niveau ni en assembleur, mais tu as probablement raison, le C++ doit être plus proche de l'assembleur. C'est un fait bien connu.
Merci d'attaquer sur mes compétences, je suis certain que tu es plus compétent que moi et que cette attaque élève le débat.


Pour ma part je serai moins catégorique: je pense que tu es simplement malhonnête dans ta façon d’interpréter mes propos.

Ce n'est pas parce que le C est portable qu'il est loin de l'assembleur et des concepts bas niveaux (c'est mon opinion et je peux le prouver).

Tiens faisons un test: dé-compile un programme simple écrit en C, le même programme en C++ (en utilisant les concepts c++ sinon ce serait le meme) , et compare les deux en ASM (celui que tu veux, peu importe la plate-forme) et dis moi sur lequel tu reconnais structurellement le programme tel que tu l'as écrit?

[Freem]

Non je ne suis effectivement pas expert en programmation bas niveau ni en assembleur, mais tu as probablement raison, le C++ doit être plus proche de l'assembleur. C'est un fait bien connu.
Merci d'attaquer sur mes compétences, je suis certain que tu es plus compétent que moi et que cette attaque élève le débat.


Pour ma part je serai moins catégorique: je pense que tu es simplement malhonnête dans ta façon d’interpréter mes propos.

Ce n'est pas parce que le C est portable qu'il est loin de l'assembleur et des concepts bas niveaux (c'est mon opinion et je peux le prouver).

Tiens faisons un test: dé-compile un programme simple écrit en C, le même programme en C++ (en utilisant les concepts c++ sinon ce serait le meme) , et compare les deux en ASM (celui que tu veux, peu importe la plate-forme) et dis moi sur lequel tu reconnais structurellement le programme tel que tu l'as écrit?

Je relève le défi.

Mais ce que les gens essaient ici de te faire comprendre, c'est qu'un des sous-ensembles du C++ est quasi-identique au langage C.

Quel concept C++ veux-tu que j'utilise?
L'objet?
Mais C++ n'est pas objet, il est orienté vers l'objet, et ses concepts sont, à ma connaissance, nombreux:
_ ne payer que ce qu'on utilise. Ca, c'est le coeur de C++. Printf est du C++, pour ceux qui ne veulent pas utiliser la RTTI intégrée par les flux, par exemple. Idem pour les exceptions, on peut les activer ou pas. Entres autres.
_ pouvoir faire de l'objet
_ pouvoir faire du structurel
_ pouvoir faire du générique

Maintenant que j'ai résumé quelques-uns des concepts C++, donnes-moi ton code C et l'assembleur qui va avec, je ferai la même chose en C++ et te montrerai les 2 sources asm et cpp.
Je te demande juste de te limiter un peu, j'ai pas envie de me palucher 1K LoC de code à écrire pour prouver une évidence.


Pour ma malhonnêteté... clairement, j'ai été mesquin et bas, mais tu t'amènes, sans argument, foulant des pieds tout ce qui à été dit avant, traitant les gens de menteurs ou d'incompétents.
Comment veux-tu que les gens réagissent, si ce n'est en te considérant comme un bon gros troll velu?

Quant au C++ plus bas niveau que le C... non, il est aussi bas niveau, et en même temps plus haut niveau.
Et, oui, si le C était proche de l'assembleur, il ne serait pas portable, car il n'aurait pas l'abstraction nécessaire.
Plus on abstrait le langage, plus on s'éloigne du matériel, et plus c'est portable. Du moins, c'est mon avis, corroboré par les gens qui emploient Java et HTML5, par exemple: ils prônent la portabilité plus importante que celle des binaires C et C++. L'artifice étant de passer par une machine virtuelle, qui elle spécialise l'abstraction.

[gbdivers]

corroboré par les gens qui emploient Java et HTML5

Hum, interdit de lancer un débat sur la portabilité du Java par rapport au C++, je garde ça pour une prochaine fois

[Luc Hermitte]

Je vais volontairement jouer le provocateur, mais selon moi penser que le C++ est adapté aux débutants est une idée stupide. Le C++ est un langage complexe et compliqué, que même les experts devraient redouter. Point.
Si vous voulez me convaincre du contraire, soit vous mentez soit vous ne savez pas de quoi vous parlez .

Donc tu n'as pas lu l'article ou le débat. Tu peux le dire, ça se voit. Aller, je commence les confidences: en 99 j'étais tout autant persuadé que toi de la débilité de voir le C++ avant le C. J'étais jeune, je sortai de l'école et j'avais déjà vu le C (et bien d'autres choses). C'était donc logique de faire comme nos aïeux.

Bref, il était pourtant clair depuis le début que l'on n'a jamais parlé d'enseigner tout le C++ à la place du C. Mais le sous-ensemble impérativo-procédural équivalent au C, mais sans les erreurs et les pièges inhérents au C.

C est un des pires premiers choix possibles à mon avis. Le C++ n'est pas idéal, mais il est moins pire.

Métaphore: un apprenti pilote de ligne doit-il commencer faire ses armes sur un boeing 787 ou sur un petit avion de tourisme, auquel cas les bases de l'aérodynamique s'appliquent de façon évidente a l'appareil et aux commandes du pilote?

Tu as raison, il faut apprendre le latin avant le français. Sans voir d'abord les bases qui ont abouti à ce que nous avons aujourd'hui on ne peut pas s'exprimer correctement.

Une autre analogie fallacieuse ? Pour taper sur le clavier/marcher, nous pensons à bouger chaque muscle précisément et nullement à ce que l'on n'écrit ou où l'on va. Car le bas niveau, il n'y a que ça qui nous permette d'aller plus loin.

[koala01]

Je vais volontairement jouer le provocateur, mais selon moi penser que le C++ est adapté aux débutants est une idée stupide. Le C++ est un langage complexe et compliqué, que même les experts devraient redouter. Point.

As tu vu une seule intervention dans laquelle quiconque aurait prétendu que C++ n'est pas un langage complexe

As tu vu une seule intervention dans laquelle quiconque aurait laissé croire qu'il ne faut effectivement pas le pratiquer (très) longtemps avant de prétendre en avoir fait le tour

Si vous voulez me convaincre du contraire, soit vous mentez soit vous ne savez pas de quoi vous parlez .

Ou peut être que l'on a, simplement, un point de vue différent de toi

Mais nous pourrions donc (vu que tout se résumerais à une question de point de vue) très facilement te faire les mêmes reproches.

Comme ce serait gaminerie que de tomber dans ce travers, je vais plutôt essayer de discuter en personne sensée

Je ne vais pas rentrer dans les détails, ni plus avant dans le débat

Et pourtant, tu as pris la peine de répondre... Cela dénote au minimum l'envie de rentrer dans le débat

Le problème, c'est que si tu ne veux pas donner de détail, il sera difficile d'avoir un débat constructif basé sur ton point de vue .

Un autre problème est que, à te montrer si catégorique sans vouloir, justement, expliquer ton point de vue, tu perds toute crédibilité (re)

mais pour faire bref le C++ est un beau bordel.

Il est vrai que C n'a absolument rien d'un "bordel" avec ses propres sucres syntaxique, bien sur

C'est au delà des concepts OO et impératifs qui n'ont rien à voir dans mon opinion: surcharge des opérateurs (la pire idée jamais inventée selon moi)

A-t-on jamais dit nulle part qu'il fallait surcharger les opérateurs n'importe quand n'importe comment

Chaque fois que la surcharge d'opérateur est à l'ordre du jour, on attire au contraire l'attention sur le fait que cela doit se faire pour de bonnes raisons et de manière réfléchie.

Du coup, on veille à limiter l'usage de la surcharge d'opérateurs à ce qui a sémantiquement lieu d'être

moyen bizarre d'utiliser les streams avec des opérateurs non cohérent avec le reste du langage,

Pourquoi "non cohérent avec le reste du langage"

Parce qu'ils sont aussi utilisé pour le décalage de bits

Que faudrait il penser de l'étoile, gracieusement apportée par C, qui présente deux significations carrément inverse selon le contexte dans lequel elle est utilisée :question;

concept de pointeurs ET de références

En quoi est-ce un problème

Outre le fait d'éviter une copie qui leur est commun, pointeurs et références rencontrent des besoins différents

heritage multiple (avec la joyeuse pagaille que cela peut engendrer)

Encore une fois, où est le problème

Il n'y a rien conceptuellement parlant, qui interdise en quoi que ce soit l'héritage multiple!

Et je remarquais récemment que ce sont, assez bizarrement, les langages qui prétendent l'interdire qui, de par le mensonge de leur concept d'interface en font le plus grand usage

Alors, bien sur, l'héritage multiple est à considérer avec précaution, mais l'héritage l'est "à peine moins"

Et, surtout, l'héritage, qu'il soit multiple ou non, correspond à un besoin qu'il s'agit de pouvoir rejoindre

templates...etc.

Les template sont là parce que c'est un langage multi paradigmes

Bien sur, chaque paradigme que l'on ajoute à un langage apporte un degré de complexité supplémentaire à ce langage, mais, chaque niveau de complexité apporte son lot de souplesse (et sans doute de sécurisation) supplémentaire aussi

En comparaison malgré ses défauts, le C est plutot simple et cohérent,

Mais avec lequel tu dois être attentif à de nombreux points finalement "hors scope" de ton problème réel

très facile a lire.

Heu...

A condition que le code soit bien écrit, de respecter des règles de codage strictes et que l'on n'utilise pas trop de sucre syntaxique.

Ce qui est parfois loin d'être le cas (mais bon, c'est un problème que l'on rencontre dans tous les langages, y compris C++

Le C est aussi une bonne introduction a la programmation système et bas niveau car très proche de l'assembleur en étant parfaitement lisible.

Sites moi une seule chose que tu pourrais faire en C que tu ne pourrais pas faire en C++

Enfin, si vous pensez que la compréhension de ce qui se basse en bas niveau (processeur, registres, allocation mémoire) est dispensable vous vous trompez.

A voir...

Note que, plutôt que de dire que c'est dispensable, nous disons plutôt que cela peut attendre d'avoir assimilé d'autres concepts

Si je devais conseiller deux langages aux débutants ce serait le C et pourquoi pas le python, mais pas tout de suite le C++.

Ceci dit, je le répète encore une fois, le but de l'article n'est pas de dire qu'il ne faut pas apprendre C, ni même de venir donner un ordre d'apprentissage des différents langages, c'est de tordre le cou à cette idée fausse qui veut que l'apprentissage de C est un prérequis indispensable à l'apprentissage de C++.

C'est donc un débat totalement différent

[iolco51]

Et pourtant, tu as pris la peine de répondre... Cela dénote au minimum l'envie de rentrer dans le débat

...

Ceci dit, je le répète encore une fois, le but de l'article n'est pas de dire qu'il ne faut pas apprendre C, ni même de venir donner un ordre d'apprentissage des différents langages, c'est de tordre le cou à cette idée fausse qui veut que l'apprentissage de C est un prérequis indispensable à l'apprentissage de C++.

C'est donc un débat totalement différent

Merci pour cette longue réponse que ma provocation ne méritait pas vraiment.
C'est vrai, je me suis laissé prendre dans le débat bien que ce n'était pas dans mon intention initiale.

A lire ta tirade, je constate que nous ne serons manifestement jamais d'accord.
Je reconnais bien des vertus au C++. S'il y a toutefois une seule vertu que je ne reconnaitrai jamais à ce langage, c'est son adéquation pour enseigner aux débutants (avant le C puisque tu tiens à le préciser). Et je suis plutot surpris d’être le seul à penser ainsi sur ce forum d'experts (notez que je suis absolument sincère et je ne considère pas en faire partie).

Pour les amoureux du langage (et les autres aussi), voici un article que j'ai beaucoup apprécié sur la beauté du code de doom3 en C++ (mais je pense que vous l'aurez déjà lu, et que vous ne serez pas toujours d'accord avec l'auteur).
http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
.

[koala01]

Je reconnais bien des vertus au C++. S'il y a toutefois une seule vertu que je ne reconnaitrai jamais à ce langage, c'est son adéquation pour enseigner aux débutants (avant le C puisque tu tiens à le préciser). Et je suis plutot surpris d’être le seul à penser ainsi sur ce forum d'experts (notez que je suis absolument sincère et je ne considère pas en faire partie).

Mais la question n'est pas son adéquation à l'apprentissage pour un débutant, ni de savoir s'il vaut mieux l'apprendre avant ou après tel autre langage (C, en l'occurrence).

J'aurais d'ailleurs tendance à dire que l'apprentissage de C et de C++ devrait se faire en même temps (mais dans des cours clairement distincts), mais c'est un autre débat

La question est de savoir si la connaissance de C est un prérequis indispensable à l'apprentissage de C++, et là, la réponse est clairement: non

Pour les amoureux du langage (et les autres aussi), voici un article que j'ai beaucoup apprécié sur la beauté du code de doom3 en C++ (mais je pense que vous l'aurez déjà lu, et que vous ne serez pas toujours d'accord avec l'auteur).
http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
.

J'ai effectivement très apprécié cet article, et, effectivement, je ne suis pas d'accord avec certains points, mais, contrairement à ce que tu pourrais croire à me lire, cela n'a rien à voir avec l'utilisation du C++ "pur" ou non: plutôt quelques détails par ci par là

[germinolegrand]

Allez, on reprend les discussions après une longue journée () de sommeil.

Comme d'habitude ça va me prendre 3h puisque vous avez eu le temps de remplir deux pages complètes (!). Vais essayer de prendre dans l'ordre.

Tu as parlé (hop, un biais rapide) d'un code sans commentaire à un moment. J'apprécie, je fais pareil: raisons techniques (commentaire désynchronisés, ce qui inclue les doxycomment).

C'est encore un autre débat (très intéressant), mais l'aborder ici serait totalement hors-sujet (je veux dire, encore plus que toutes mes interventions ici ).

c :: Franchement... l'auto-complétion, c'est une raison bassement technique.

Les raisons bassement techniques sont parfois les meilleures... taper machin.get c'est taper m_ ça permet d'accélérer je dirais d'un facteur x10 la vitesse d'écriture.
Quand on a à écrire un vrai getter, autant l'appeler par son nom. Il ne sert à rien de se voiler la face.

De plus prendre std::string en exemple ainsi que size() tel qu'il existe dans la STL est une mauvaise idée, car cela fait partie des choses les plus critiquées dans la STL.

Je crois qu'il à le même problème que moi, en fait, c'est à dire ne pas apprécier d'appliquer un principe sans le comprendre parfaitement

Qu'on ne se méprenne pas : comme dit plus haut, je comprends bien les principes en questions, et les approuve comme étant d'excellentes analyses d'un code terminé. Ce à quoi je n'adhère pas c'est de les appliquer.

Pourquoi?
En quoi l'objet est-il constamment plus approprié que l'impératif?
Perso, il m'arrive de faire des gadgets. Quand je les commence, je commence par la fonction main. J'ajoute des fonctions. Quand elles manipulent les mêmes trucs et que j'ai la flemme de lire tant de lignes, au fil des ajouts, j'en fais une classe.
Pour ces gadget, je pars donc bel et bien d'un bête truc impératif...

Je ne peux que plussoyer.

--------------

@germinolegrand
Il me semble que tu oublies un point important (on a déjà eu des discutions équivalentes sur le chat) : l'intérêt d'avoir un vocabulaire commun est de faciliter la discussion. En inventant tes propres sigles, ne penses tu pas que cela peut nuire au travail dans une équipe conséquente ? Imagine si chaque personne de l'équipe utilise ses propres sigles ?

Contrairement à d'habitude, je n'invente rien ici, j'essaie seulement de combler un manque de vocabulaire !
Dois-je à chaque fois que je parle du contrôle de la durée de vie des objets réexpliquer en détail de ce dont je parle ? Cf le message de luc sur l'utilité des sigles.
Existe-t-il un terme pour parler de ceci ? si tu en connais un, je serais ravi de pouvoir l'utiliser. Dans le cas contraire, diffuser un nom commun pour en parler ne me parait pas une nuisance, au contraire.

Je ne vais pas parler d'OLTC à quelqu'un qui l'entend pour la première dois sans dire ce que c'est, ce serait stupide de ma part, c'est comme parler dans le vent. Mais pour ceux qui savent déjà de quoi je parle, eh bien il est tout simplement plus rapide de noter OLTC dans la conversation, d'ailleurs tout le monde s'est empressé de s'emparer de cet acronyme pour me répondre.

-----------------

Est-ce un manque du langage, du source, ou de l'outil?

De l'outils selon moi.

-----------------

As tu vu une seule intervention dans laquelle quiconque aurait laissé croire qu'il ne faut effectivement pas le pratiquer (très) longtemps avant de prétendre en avoir fait le tour

Stroustrup lui-même n'en a pas encore fait le tour .
Pour continuer dans la même logique, je préfère un langage qui me donne la possibilité d'en apprendre toujours plus qu'un langage limité.

-----------------

S'il y a toutefois une seule vertu que je ne reconnaitrai jamais à ce langage, c'est son adéquation pour enseigner aux débutants

S'il y a bien une vertu que je reconnais au C++11 (attention pas au C++03), c'est celle-là. Ce langage est outrageusement () débutant-friendly.

-----------------

La question que je me pose à chaque fois dans ce genre de discussions, c'est "de quelle version du langage parle-t-on ???", j'aimerais utiliser les arguments du C++11 correctement, mais comme il n'est pas encore assez répandu, j'ai peur de répondre à côté...

[koala01]

Qu'on ne se méprenne pas : comme dit plus haut, je comprends bien les principes en questions, et les approuve comme étant d'excellentes analyses d'un code terminé. Ce à quoi je n'adhère pas c'est de les appliquer.

Et cela ne te donne pas l'impression de "travailler à l'envers"

Que se passe-t-il, par exemple, si tu te rend compte qu'un principe n'est pas respecté lorsque tu analyse ton code terminé

A- Tu t'en fous, ca fontionne, c'est ce qui importe, et "on verra plus tard" en cas de besoin

B- C'est embêtant, corrigeons maintenant tant que c'est frais dans mon esprit

A titre perso, la réponse A me met très mal à l'aise, car je suis persuadé que j'aurai eu le temps d'oublier un détail ou l'autre d'ici à ce que le problème se pose, et que je vais donc perdre un temps bête à essayer de me souvenir de ce détail...

Cela revient à "reculer pour mieux sauter", et j'ai horreur de ca

La réponse B ne me convient pas d'avantage, car cela signifie que je dois revoir mon code, et sans doute modifier pas mal de truc pour arriver à respecter les principes qui ne le sont pour l'instant pas.

Et comme je l'ai dit, je suis fainéant: j'ai horreur de faire deux fois ce que j'aurais pu faire correctement dés le départ

Car soyons simplement pragmatiques et logiques: si j'avais pris le principe en compte avant d'écrire mon code, je ne devrais pas modifier mon code pour le prendre en compte maintenant, non

La question que je me pose à chaque fois dans ce genre de discussions, c'est "de quelle version du langage parle-t-on ???", j'aimerais utiliser les arguments du C++11 correctement, mais comme il n'est pas encore assez répandu, j'ai peur de répondre à côté...

AMHA, toute occasion est bonne pour faire la promo de C++11...

Pour l'instant, faut juste penser à préciser que ce que l'on dit y est spécifique

[Neckara]

@Freem @germinoland : Oui c'est l'outils qui fait cela.
Ce n'est qu'une fois la méthode sélectionnée que le prototype apparaît.

create: en général, on utilise un constructeur pour ça. Dans certaines situations ou la restriction causée par le nom du constructeur est gênante, il me semble que les gens mettent celui-ci en accès protégé (private/protected) et implémentent des méthodes statiques, qui, elles, appellent ce constructeur.

Dans un design pattern Factory, on aura une classe dont le but est de créer des instances (et d'initialiser) d'une autre classe.
Elle aura donc bien une méthode create() ou équivalant.

to: pour convertir, il y a les opérateurs de cast.

Dans certains cas, le cast ne suffit pas.
Certes on peut définir un opérateur de conversion implicite operator(Type) mais parfois on souhaite que cette conversion ne se fasse que de manière explicite.
Or il ne me semble pas qu'il soit possible de définir un tel opérateur (?)