Discussion :

[koala01]

Par contre, je pense que l'apprentissage de la programmation doit commencer par un langage comme le C ou un langage apparenté qui demande de la rigueur et la compréhension des pointeurs. Certe rigueur/compréhension sera très utile lorsque l'on développera avec des langages objets (C++, C# ou Java).

Je ne suis pas du tout d'accord avec toi...

Apprends le C si tu veux développer en C, apprends C++ si tu veux développer en C++.

Par contre, le fait d'apprendre C++ avant java ou C# pourra effectivement t'apporter une rigueur plus importante que le fait d'apprendre C# ou java en premier (mais te fera peut etre détester ces langages )

[EDIT] quant au début de ton intervention, je te conseillerais de relire les miennes: limiter C++ à son aspect OO est par trop restrictif

[moldavi]

Apprends le C si tu veux développer en C, apprends C++ si tu veux développer en C++.

On est d'accord mais le stagiaire demande a être guidé. Dans quel/quels langages va-t-il travailler plus tard ?

limiter C++ à son aspect OO est par trop restrictif

Quels sont les autres aspects ?

[koala01]

Pour moi le SRP quand il apparaît n'est qu'une constatation que je fais quand je relis mon code, et je ne le respecte pas nécessairement (bien qu'au final mon code le respectera très certainement dans sa majeure partie). D'ailleurs, dans mes premières étapes de développement c'est bien un des principes que je respecte le moins ^^.

Et pourtant, c'est sans doute le concept qu'il est le plus facile de respecter dés le début, et qui risque de poser le plus de problème pour arriver à le respecter lors d'évolutions.

Mais nous avons déjà abordé ce sujet ensemble, et c'est encore un autre débat

Tu auras peut-être noté le "littéralement" dans mon dernier message. C'est parce que je considère que le RAII n'est pas aussi mal nommé que tous ceux qui en font mention semblent le dire.

Le contrôle de la durée de vie de mes objets est une de mes plus grandes préoccupations. D'ailleurs cette expression serait plus appropriée pour décrire mon approche au RAII. OLTC : Objets LifeTime Control. Pourquoi ? Parce que je me préoccupe autant du moment où mes objets sont créés que du moment ou ils sont détruits, et met un point d'honneur à les initialiser à leur construction.

Et tu as tout à fait raison de le faire.

Cependant, il y a beaucoup plus de risque à mal libérer des ressources qu'il n'y en a à mal les initialiser.

Or, il existe un terme pour parler de l'initialisation et aucun terme pour parler de la libération des ressources, ce qui est franchement dommage, non

Ceci dit, le fait de rapprocher OLTC du RAII est à mon sens une chose des plus saines

Ceci signifie notamment que les méthodes init(), start() et autres, sont absolument ignobles à mes yeux. Cela exclue également un paramétrage post-construction (et par là-même me dispense donc de setters) dans un très grand nombre de cas.

La dessus, nous sommes tout à fait d'accord, et depuis longtemps me semble-t-il

Disposer de services qui ont pour résultat la modification de l'objet est sans doute normal, mais tu connais mon point de vue en ce qui concerne les mutateurs

Mais bon, c'est, encore, un autre débat

On me pose souvent la question quand je montre un code, on me demande pourquoi j'ai mis plusieurs paires d'accolades à l'intérieur d'une fonction. C'est parce que c'est un élément essentiel qui me permet de contrôler l'ordre de construction et de destruction de mes objets, ainsi que la mémoire avec un degré de précision et de certitude bien plus supérieure, sans pour autant devoir créer une fonction supplémentaire qui prendrait plus de paramètres qu'elle ne serait appelée. Ceci diminue également drastiquement la mémoire utilisée sur la pile.

Je ne te poserais pas la question, car je le fais moi-même...

Mais, ceci dit, quitte à avoir une paire d'accolades, j'aime autant qu'elle entoure une fonction particulière

L'une des seules raisons en dehors du DNRY (j'insiste sur le 'N', sans cela ça veut dire strictement le contraire ) qui me pousse à écrire disons un helper privé (je ne sais pas s'il existe un terme approprié pour décrire ça), c'est lorsque j'ai besoin du return (surtout dans une fonction qui retourne void, cela m'arrive très fréquemment). Ça aussi ça fait partie des choses qui étonnent ceux qui lisent mon code. Pourtant c'est également un outils de contrôle très important qui évite moultes complexifications du code. Et seul l'OLTC me garantie que marquer return; au milieu de ma fonction est efficace et surtout sans bug aucun.

Je ne peux qu'approuver, bien sur...

Cependant, quelle différence fais-tu par rapport à SRP

Tu sembles refuser SOLID, car cela te semble "trop stricte", mais, au final, tu semble pourtant appliquer les principes avec une rigueur particulièrement importante

C'est également la raison pour laquelle je critique abondamment la syntaxe des flux en C++ puisqu'on est obligé de construire des objets sans pouvoir les initialiser. J'aimerais beaucoup travailler à un proposal pour améliorer ça car sans ce problème les flux seraient d'une qualité et d'un intérêt sans pareil.

Heu, de quels flux parles tu

Pour autant que je sache, tous les flux peuvent être initialisé directement (par contre, aucun n'est copiable, et c'est logique)

[germinolegrand]

Quels sont les autres aspects ?

impératif, générique, oo, fonctionnel (de ce que j'ai pu comprendre de ce qu'en dit Flob90), ...

[koala01]

Le stagiaire demande a être guidé. Dans quel/quels langages va-t-il travailler plus tard ?

Bon, je reformule:

Apprend C si tu veux, si tu as besoin de connaitre C, apprend C++ si tu veux, si tu as besoin de connaitre C++

Et, ceci dit, le stagiaire, il travaillera de toutes façons avec le langage qu'il préfère, ou celui que lui imposera son patron: faut bien rapporter la bidoche à la maison

Quels sont les autres aspects ?

Tu m'obliges à me répéter sans doute pour la troisième fois sur cette discussion...

C++ est l'un des rares langage multi paradigme que je connaisse.

Il présente aussi bien le paradigme purement impératif ("orienté fonctions") que le paradigme orienté objets, mais il ne faut pas non plus oublier le paradigme générique, qui apporte son lot de possibilités.

Il est, comme je l'ai déjà répété plusieurs fois sur cette discussion, tout à fait possible de se limiter à l'utilisation d'un seul paradigme, même si tout le monde sera d'accord sur le fait que c'est la parfaite intégration des trois qui rend C++ si puissant

[moldavi]

impératif, générique, oo, fonctionnel (de ce que j'ai pu comprendre de ce qu'en dit Flob90), ...

Au début de mon intervention, je dis que le langage C++ est objet. Ce qui est vrai.

Selon toi j'aurais dû dire le langage C++ est impératif, générique, oo, fonctionnel...

Tu comprends, je l'espère, que je fais de l'économie avec mon clavier, pas parce que je ne connais pas l'aspect multiparagdime du C++.

[koala01]

Au début de mon intervention, je dis que le langage C++ est objet. Ce qui est vrai.

En effet, c'est vrai...

Mais c'est particulièrement réducteur car cela passe sous silence d'autres aspects, qui rendent la suite de ton raisonnement pour le moins branlant

Quand on pense que vingt minutes avant ta première intervention j'en postais une dans laquelle je précise explicitement qu'il est tout à fait possible d'"oublier" que C++ propose le paradigme objet pendant toute une partie de l'apprentissage et que tu viens nous dire (et je ne fais que te citer)

En effet le C est impératif et le C++ est objet, deux philosophies de développement complètement différentes.

Passer du C au C++ est très délicat parce que plus rien n'est linéaire, tout est dispatché dans les classes. Le développeur C se sent perdu, c'est trop abstrait.

Passer du C++ au C est tout aussi délicat, plus rien n'est en encapsulé, on a l'impression de ne pas pouvoir maîtriser correctement le code, la gestion des chaînes de caractères est un calvaire. Le développeur C++ se sent frustré.

on ne peut que revenir avec un grand "attention, malheureux, tu es trop réducteur dans ce que tu viens de dire"

[germinolegrand]

Je ne fais que répondre à ta question : "Quels autres aspects ?"

@Koala: je te rédige une réponse après

[moldavi]

et que tu viens nous dire (et je ne fais que te citer)on ne peut que revenir avec un grand "attention, malheureux, tu es trop réducteur dans ce que tu viens de dire"

Certe je ne développe pas le fond de ma pensée (c'est un forum pas un lieu de thèse). Pose-moi plutôt des questions sur ce pourquoi je pense comme cela, plutôt que de travestir ce que j'écris.

[koala01]

Certe je ne développe pas le fond de ma pensée (c'est un forum pas un lieu de thèse). Pose-moi plutôt des questions sur ce pourquoi je pense comme cela, plutôt que de travestir ce que j'écris.

Ooh là...

Je n'ai absolument rien travesti de ce que tu as écrit, et j'ai réagis on ne peut plus clairement par rapport à tes écrits.

En plus, tu as demandé à ce que je précise ce que j'entendais par "trop restrictif" et je me suis fendu d'une réponse claire et précise.

Si tu estimes que "j'ai travesti" tes écrits, n'hésites pas à me présenter tes arguments, peut etre ai-je effectivement mal compris ce que tu voulais dire.

En attendant, toutes mes interventions dans cette discussion ont chaque fois veillé à être claire et motivées et, quand ce n'était pas le cas, je n'ai jamais refusé d'approfondir le moindre aspect.

Si donc tu estimes que je n'ai pas compris le sens de ton intervention, ce n'est pas à moi de te demander de l'exprimer plus clairement, c'est à toi de vouloir le faire. N'inversons pas les rôles, veux tu bien

[LSMetag]

Disons qu'il y a du pour et du contre.

Oui on peut commencer par du C++ en procédural. Car le débutant serait largué de commencer direct par de la POO.
Mais c'est donner de mauvaises habitudes au programmeur.

C'est intéressant de faire une cassure entre C = procédural et C++ = objet et autres.
Car c'est l'utilisation qui en est faite le plus souvent.

Sinon, les mecs, par conforts, peuvent programmer en procédural sur du C++, java ou autre. Et se faire rattraper par leurs lacunes.

[koala01]

Disons qu'il y a du pour et du contre.

Oui on peut commencer par du C++ en procédural. Car le débutant serait largué de commencer direct par de la POO.
Mais c'est donner de mauvaises habitudes au programmeur.

Ca se discute...

Je ne crois pas que l'utilisation de fonctions libres soit réellement une mauvaise habitude en C++

Finalement, une fonction membre reste quand même une fonction, d'abord et avant tout

Et le fait de passer d'une fonction libre à une fonction membre s'inscrit dans le cadre du "intéressons nous aux comportement que l'on attend de la part de notre objet"

C'est intéressant de faire une cassure entre C = procédural et C++ = objet et autres.
Car c'est l'utilisation qui en est faite le plus souvent.

On privilégie effectivement souvent l'approche OO en C++, mais c'est oublier un peu vite que l'on travaille avec énormément de fonctions libres (essentiellement les fonction "operator")... sans compter une bonne dose de paradigme générique

Sinon, les mecs, par conforts, peuvent programmer en procédural sur du C++, java ou autre. Et se faire rattraper par leurs lacunes.

Surement pas en java, car le seul moyen de faire du pseudo procédural en java serait de passer par des fonction statiques

Quant au fait de programmer en procédural sur du C++ et de se faire rattraper par ses lacunes, j'aimerais que tu détailles un tout petit peu ce que tu entends par là.

Les gens pourraient, effectivement, avoir des lacunes du coté de l'aspect OO, mais elles ne se feront sentir qu'au moment où ils voudront effectivement utiliser ce paradigme (et recourir, par exemple, à l'héritage).

Et c'est bien pour cela que j'insiste sur le fait que l'apprentissage des tous les paradigmes est important

Mais j'insiste aussi sur le fait qu'il est beaucoup plus cohérent de s'attaquer à chaque paradigme "séparément" et de manière graduelle (comment comprendre la substituabilité si on n'a déjà pas compris la notion de fonction )

[LSMetag]

@koala01

Justement, il y a plusieurs choses que je veux dire par là :

Il y aurait un mélange des paradigmes assez pourri. En faisant du procédural, le programmeur ne s'apercevrait pas qu'il fait également de l'objet.
Donc, après dur dur de revoir ses acquis dès qu'il fait de l'objet où tout se mélangerait.

J'ai commencé le Java en "pseudo procédural" et ça a duré plusieurs mois.
Si je n'avais pas fait de C++ avant je ne sais pas comment j'aurais réagi.
Mais je suis presque sûr que "static" aurait été un mot clé que j'aurais mis sans comprendre pourquoi, n'ayant aucune notion d'objet. J'aurais mis "static" devant tout et dans le même fichier et puis basta.

Et oui, comme je l'ai dit, le mec aurait beau apprendre l'objet en C++, il n'y aurait pas de cassure au niveau du langage, et il est tout à fait possible que par confort, il continue à utiliser le langage de façon procédurale, sauf si il est obligé. Et il pourraît s'imaginer ensuite qu'on peut faire pareil avec Java, C#,... Bref de mauvaises habitudes. "L'objet c'est un cap, et en gros ce qu'on faisait avant ce n'était qu'une intro". C'est comme ça que je résumerais.

[germinolegrand]

Je vais donc répondre à Koala (en omettant la partie sur les flux qui est un tout autre sujet), dans l'ordre pour une fois :

Cependant, il y a beaucoup plus de risque à mal libérer des ressources qu'il n'y en a à mal les initialiser.

Le mal insidieux se cache dans les petits recoins. En effet, une fois qu'on sait se servir d'un destructeur et de pointeurs intelligents, la question de la destruction est somme toute assez vite réglée (ahem ).

Les constructions croisées sont un mal extrêmement ardu à combattre proprement.

Or, il existe un terme pour parler de l'initialisation et aucun terme pour parler de la libération des ressources, ce qui est franchement dommage, non

allocation => initialisation/construction (c'est exactement et strictement pareil)
destruction => désallocation

C'est donc oublier bien vite la différence entre malloc/free et new/delete ^^.
Vouloir faire une fonction init() c'est donc utiliser un new alors qu'il n'aura que la valeur sémantique d'un malloc. Là bizarrement tout le monde commence à être d'accord que init() c'est le mal .

Mais, ceci dit, quitte à avoir une paire d'accolades, j'aime autant qu'elle entoure une fonction particulière

La différence est là en effet ^^.

Cependant, quelle différence fais-tu par rapport à SRP ?

Je crée ce genre de helper pour des raisons techniques, et non conceptuelles.

C'est peut-être là la clé de bon nombre de mes propos, puisque je fais du DNRY pour une raison technique (ie. c'est ch***t de faire du copier-coller et de le maintenir) et non conceptuelle.

Le SRP découle tout seul du DNRY, ce n'est qu'une conséquence des concepts que j'applique.

Tu sembles refuser SOLID, car cela te semble "trop stricte", mais, au final, tu semble pourtant appliquer les principes avec une rigueur particulièrement importante

La différence n'est pas le résultat, mais les motivations. C'est bien pour cela que je dis que mon code ne suis pas ces principes, mais que ça n'empêche pas qu'ils soient vérifiés.

Mais on n'a pas parlé de SOLID au complet :
SRP : comme on l'a vu, oui par conséquence ;
OCP : même chose que SRP ;
LSP : là encore c'est la même chose que le SRP, bien que je me fiche pas mal des pre/post conditions... ;
ISP : celui-là je peux te dire qu'il va très souvent aux oubliettes de façon explicite , ça n'empêche pas qu'il soit parfois vérifié ;
DIP : conséquence possible du DNRY :-°.

Pour l'ISP, je ne sais pas si ça rentre dans ce cadre, mais je suis très attaché au const-correctness, peut-être est-ce une application particulière de ce principe ?

Au final je m’aperçois que je dois ajouter le const-correctness dans ma liste car je n'y déroge jamais ^^.

[koala01]

@koala01

Justement, il y a plusieurs choses que je veux dire par là :

Il y aurait un mélange des paradigmes assez pourri. En faisant du procédural, le programmeur ne s'apercevrait pas qu'il fait également de l'objet.

Je crois comprendre ton point de vue, mais j'ai quand même beaucoup de mal à y souscrire...

Comprend que, même si on ne s'intéresse qu'à l'aspect procédural de C++, il faut quand même être bouché à l'émeri pour ne pas se rendre compte que l'on utilise parfois des fonctions apportées par les objets qu'on manipule (cf l'exemple de push_back que j'ai utilisé dans mes différentes intervention à ce sujet )

Il y a donc une nette différence entre les fonctions libres et les fonctions membres, et on s'en rend d'office compte en C++

Donc, après dur dur de revoir ses acquis dès qu'il fait de l'objet où tout se mélangerait.

Ici, on parle du temps nécessaire à assimiler les bases du langage et les principes "simples"...

Je ne crois pas que cela se compte en plus de trois mois à quelques heures par semaine

J'ai commencé le Java en "pseudo procédural" et ça a duré plusieurs mois.
Si je n'avais pas fait de C++ avant je ne sais pas comment j'aurais réagi.
Mais je suis presque sûr que "static" aurait été un mot clé que j'aurais mis sans comprendre pourquoi, n'ayant aucune notion d'objet. J'aurais mis "static" devant tout et dans le même fichier et puis basta.

En java, le problème se poserait beaucoup plus car, effectivement, il n'y a pas moyen de créer des fonctions libres.

Comme nous sommes bien d'accord sur le fait que le seul moyen de faire du pseudo procédural en java serait de passer par des fonctions statiques, nous serons sans doute aussi d'accord sur le fait que l'utilisation de ces fonctions passera systématiquement par un code proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClass::maFonction(lesArgument);

et, à partir de là, je serai tout à fait d'accord avec toi sur le fait qu'il devient pour le moins difficile de faire la part entre le procédural et l'objet, vu que, de toutes manières, l'appel de fonctions "soi disant libres" passe par l'utilisation d'un objet

Mais, comme je l'ai indiqué plus haut, ce problème n'apparait pas (ou en tout cas, beaucoup moins) en C++ simplement parce qu'il y a une différence flagrante entre une fonction libre et une fonction membre, fut-elle statique

Quelque part, la signification que l'on donne au mot clé static est totalement différente en java qu'en C++:

En java, cela peut (bien que ce ne soit pas le cas) être plus ou moins considéré comme une fonction libre, alors qu'en C++, c'est clairement une fonction qui "dépend d'un type particulier, même si elle ne dépend d'aucune instance de ce type" (bon, d'accord, je prend de très forte libertés en ce qui concerne java, mais c'est le genre d'amalgame qu'un étudiant pourrait etre tenté de faire )

Et oui, comme je l'ai dit, le mec aurait beau apprendre l'objet en C++, il n'y aurait pas de cassure au niveau du langage, et il est tout à fait possible que par confort, il continue à utiliser le langage de façon procédurale, sauf si il est obligé. Et il pourraît s'imaginer ensuite qu'on peut faire pareil avec Java, C#,... Bref de mauvaises habitudes.

Je crois que je viens de répondre, je vais juste dire: avec des langages comme java, je t'accorde bien volontiers ce point, mais avec C++, je ne crois pas que ce soit un problème réel, du fait de la possibilité de faire du vrai impératif, et non seulement du "pseudo impératif" basé sur des fonctions membres statiques

"L'objet c'est un cap, et en gros ce qu'on faisait avant ce n'était qu'une intro". C'est comme ça que je résumerais.

Tout à fait, et on peut parfaitement le faire avec C++: si on commence par une approche purement impérative du langage, l'introduction nous permet d'apprendre toute la syntaxe et de déjà bien nous amuser

Par contre, il serait à mon sens criminel de vouloir le faire avec un langage comme java car (décidément, on en revient toujours à cela) on ne ferait pas de l'impératif pur mais du "pseudo impératif, basé sur des fonctions membres statiques"

Quelque part, cela va peut être sembler aberrant ce que je m'apprête à écrire, mais je verrais beaucoup plus l'apprentissage de C comme introduction à celui de java (ou de C#, ne faisons pas de jaloux ), histoire de donner à l'étudiant un aperçu du paradigme impératif, que comme introduction à l'apprentissage de C++ qui se "suffit à lui-même" à ce point de vue

Mais, à ce moment là, peut être serait il préférable d'utiliser d'autres langages qui soient moins "perclus" de chausses trappes .

Enfin, ca, c'est encore un autre débat, ne vous sentez pas obligés de répondre à cette partie

[koala01]

allocation => initialisation/construction (c'est exactement et strictement pareil)
destruction => désallocation

C'est donc oublier bien vite la différence entre malloc/free et new/delete ^^.
Vouloir faire une fonction init() c'est donc utiliser un new alors qu'il n'aura que la valeur sémantique d'un malloc. Là bizarrement tout le monde commence à être d'accord que init() c'est le mal .

Oh là là, ne me fais pas dire ce que je n'ai pas dit...

J'ai juste regretté que RAII ne s'intéresse qu'à une seule partie du problème: celle de l'initialisation / acquisition des ressources et oublie (ou du moins ne fasse aucune mention) du phénomène qui consiste à les libérer en temps utiles.

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

La différence est là en effet ^^.



Je crée ce genre de helper pour des raisons techniques, et non conceptuelles.

C'est peut-être là la clé de bon nombre de mes propos, puisque je fais du DNRY pour une raison technique (ie. c'est ch***t de faire du copier-coller et de le maintenir) et non conceptuelle.

Le SRP découle tout seul du DNRY, ce n'est qu'une conséquence des concepts que j'applique.

Je trouve quelque peu dommage que des considérations techniques fassent que tu finisses par respecter des principes conceptuels parce que j'estime que la conception devrait précéder la mise en oeuvre, mais je trouve malgré tout que le fait que, au final, tes motivations techniques permettent de vérifier une grosse partie des considérations conceptuelles a quelque chose de rassurant

Disons que je suis peut etre un peu plus fainéant que toi et que je préfères déchirer un petit dessin que de devoir revenir sur du code

La différence n'est pas le résultat, mais les motivations. C'est bien pour cela que je dis que mon code ne suis pas ces principes, mais que ça n'empêche pas qu'ils soient vérifiés.

Mais on n'a pas parlé de SOLID au complet :
SRP : comme on l'a vu, oui par conséquence ;
OCP : même chose que SRP ;
LSP : là encore c'est la même chose que le SRP, bien que je me fiche pas mal des pre/post conditions... ;
ISP : celui-là je peux te dire qu'il va très souvent aux oubliettes de façon explicite , ça n'empêche pas qu'il soit parfois vérifié ;
DIP : conséquence possible du DNRY :-°.

Pour l'ISP, je ne sais pas si ça rentre dans ce cadre, mais je suis très attaché au const-correctness, peut-être est-ce une application particulière de ce principe ?

Au final je m’aperçois que je dois ajouter le const-correctness dans ma liste car je n'y déroge jamais ^^.

Ben, je viens de répondre, hein

[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 .

[Luc Hermitte]

a- Pour apprendre le C++, vaut-il mieux avoir appris le C ?

Je suis d'accord pour dire que non. En effet le C est impératif et le C++ est objet, deux philosophies de développement complètement différentes.

Passer du C au C++ est très délicat parce que plus rien n'est linéaire, tout est dispatché dans les classes. Le développeur C se sent perdu, c'est trop abstrait.

Passer du C++ au C est tout aussi délicat, plus rien n'est en encapsulé, on a l'impression de ne pas pouvoir maîtriser correctement le code, la gestion des chaînes de caractères est un calvaire. Le développeur C++ se sent frustré.

b- Par contre, je pense que l'apprentissage de la programmation doit commencer par un langage comme le C ou un langage apparenté qui demande de la rigueur et la compréhension des pointeurs. Certe rigueur/compréhension sera très utile lorsque l'on développera avec des langages objets (C++, C# ou Java).

a- J'allais dire que ce n'est pas le débat ni le sujet de l'article. On parle de C Vs C++ procédural.
Les discussions ont légèrement dévié ensuite. En réponse je dirai que
- Dans les langages OO maintreams, dans tous les cas on commencera toujours par l'impératif (une instruction après l'autre), puis le procédural (notion de fonctions). Car ces langages ont ces deux propriétés et on ne peut pas passer à la suite tant qu'elles ne sont pas un minimum maitrisées. Après on peut enchainer sur les TAD (jusque là, c'est un cours classique d'algo & Ada), et montrer comment cela se réalise dans le paradigme objet. Puis introduire les notions de services, et montrer comment le SRP ne s'applique pas seulement aux fonctions mais aussi aux objets/acteurs du système.

- Dans tous les cas je préfère les mauvaises habitudes procédurales du C++ en C++, que les mauvaises habitudes du C en C++. Cela fait moins de dégâts.

On en arrive au point b-
b- Je m'inscris en faux. C'est du pipo complet. Oui pour bien faire il faudrait maitriser ce principe de rigueur pour faire du C. Sauf qu'il ne faut pas se leurrer, tout juste un élève sur 100 sera capable de l'appréhender à défaut de l'acquérir. Les cours ne sont pas orientés rigueur. La gestion des erreurs passent à la trappe -- je ne parle même pas de goto, mais de faire un if toutes les deux lignes. realloc est mal utilisé. printf reçoit des pointeurs n'importe comment. Les tailles finissent dans des int. Les casts pleuvent, en particulier entre tableaux et pointeurs (je ne vous dit même pas quand il y a plusieurs dimensions). Un élève qui sort d'un cours de C n'aura pas appris la rigueur (je vous renvois à l'article de Raymond Chen (auquel répondait l'article de Lahman) dont la genèse est justement liée à ces codes dépourvus de rigueur). Il aura appris à écrire des programmes qui tombent en marche -- le pire c'est que seuls les moins prétentieux en auront conscience.

Au moins en C++, pour la partie impérativo-procédurale équivalente, l'élève (qui suit un cours de C++ moderne, et non historique) aura appris à faire du code correct sans même sans rendre compte -- merci la SL et le RAII.
Il pourra ensuite continuer son apprentissage sur les TAD/classes.

---
Autre truc, je ne sais comment comment "haut-niveau" est apparu dans la discussion. Je considère que cela ne veut plus rien dire. Les langages vont supporter des choses appartenant à des familles distinctes et orthogonales (accès hardware, gestion fine de la mémoire, gestion implicite et/ou déterministe des ressources, Prog par contrat, OO, généricité, méta-prog générative, fonctionnel, déclaratif (cf prolog), lib standard minimale, prog concurrente, prog parallèle, réseau, bases de données, web services/bus logiciels, etc). Et pour chacune des familles on peut définir des sortes d'axes (à trous) et attribuer une note de support par les langages.
En fin de compte, on se retrouverait avec un graphe radar: http://fr.wikipedia.org/wiki/Diagramme_de_Kiviat

[Luc Hermitte]

OLTC ne dit rien quant à comment ça fonctionne -- pourquoi cela ne correspondrait pas à un Life Time Manager comme il y a dans ACE?. De plus c'est restreint aux durées de vie, pas aux ressources (quid d'un pot de peinture à refermer et ranger à sa place sur l'étagère)

RAII se réfère à un principe bien précis (sitôt acquis, sitôt confié), même si la propriété qui nous intéresse le plus dans l'histoire est le RFID (Resource Finalization is Destruction).

[germinolegrand]

OLTC n'a pas pour but de remplacer le RAII... il le complète !

Ma dernière phrase était peut-être ambigüe il est vrai et assez fausse s'il en est comme tu viens de le démontrer ...

Pour reprendre ton pot de peinture, c'est l'OLTC qui dit quand on doit acquérir le contrôle du pot de peinture (avant ou après le pinceau ?) et quand on doit le rendre (avant ou après le pinceau ?). Le RAII dit comment l'acquérir (on le sort de l'étagère et on ouvre le pot) et comment le rendre (on ferme le pot et on le remet sur l'étagère).

Encore une fois, l'OLTC se retrouve mêlé encore plus au RAII : on ferme le pot avant de le ranger ? ou l'inverse ? (réponse plus haut, assez évidente je pense...).

L'OLTC est déjà largement présent dans le C++ : si on regarde ne serait-ce que l'ordre de construction et de destruction dans une hiérarchie d'héritage, il est clair qu'un énorme travail a déjà été effectué dessus.

Comme pour le RAII, le langage nous donne des outils pour mettre en oeuvre l'OLTC : les scopes, la déclaration au milieu de la fonction (ça me manque horriblement en C ! *hop ce message n'est plus hors-sujet, z'avez vu ? *), les return multiples, la move-semantic, les pointeurs, and so on... Le C++11 apporte un bon lot de fonctionnalités s'y rapportant. Ce qui contribue évidemment beaucoup à me faire apprécier le langage .

Se préoccuper de la durée de vie des objets avec minutie me semble être une bonne approche complémentaire au RAII.