Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Je ne suis pas du tout d'accord avec toi...Envoyé par moldavi
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
On est d'accord mais le stagiaire demande a être guidé. Dans quel/quels langages va-t-il travailler plus tard ?
Quels sont les autres aspects ?limiter C++ à son aspect OO est par trop restrictif
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
Et tu as tout à fait raison de le faire.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.
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
La dessus, nous sommes tout à fait d'accord, et depuis longtemps me semble-t-ilCeci 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.
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
Je ne te poserais pas la question, car je le fais moi-même...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.
Mais, ceci dit, quitte à avoir une paire d'accolades, j'aime autant qu'elle entoure une fonction particulière
Je ne peux qu'approuver, bien sur...L'une des seules raisons en dehors du DNRY (j'insiste sur le 'N', sans cela ça veut dire strictement le contraire
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
Heu, de quels flux parles tuC'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.
Pour autant que je sache, tous les flux peuvent être initialisé directement (par contre, aucun n'est copiable, et c'est logique)
impératif, générique, oo, fonctionnel (de ce que j'ai pu comprendre de ce qu'en dit Flob90), ...
Bon, je reformule:
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 maisonApprend C si tu veux, si tu as besoin de connaitre C, apprend C++ si tu veux, si tu as besoin de connaitre C++
Tu m'obliges à me répéter sans doute pour la troisième fois sur cette discussion...Quels sont les autres aspects ?
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
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++.
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)on ne peut que revenir avec un grand "attention, malheureux, tu es trop réducteur dans ce que tu viens de dire"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é.
Je ne fais que répondre à ta question : "Quels autres aspects ?"
@Koala: je te rédige une réponse après
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.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"
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
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.
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"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ériqueC'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.
Surement pas en java, car le seul moyen de faire du pseudo procédural en java serait de passer par des fonction statiquesSinon, les mecs, par conforts, peuvent programmer en procédural sur du C++, java ou autre. Et se faire rattraper par leurs lacunes.
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
@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.
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:
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 (ahemCependant, il y a beaucoup plus de risque à mal libérer des ressources qu'il n'y en a à mal les initialiser.).
Les constructions croisées sont un mal extrêmement ardu à combattre proprement.
allocation => initialisation/construction (c'est exactement et strictement pareil)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
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.
La différence est là en effet ^^.Mais, ceci dit, quitte à avoir une paire d'accolades, j'aime autant qu'elle entoure une fonction particulière
Je crée ce genre de helper pour des raisons techniques, et non conceptuelles.Cependant, quelle différence fais-tu par rapport à SRP ?
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.
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.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
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
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 ^^.
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++
Ici, on parle du temps nécessaire à assimiler les bases du langage et les principes "simples"...Donc, après dur dur de revoir ses acquis dès qu'il fait de l'objet où tout se mélangerait.
Je ne crois pas que cela se compte en plus de trois mois à quelques heures par semaine
En java, le problème se poserait beaucoup plus car, effectivement, il n'y a pas moyen de créer des fonctions libres.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.
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
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
Code : Sélectionner tout - Visualiser dans une fenêtre à part MaClass::maFonction(lesArgument);
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
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 statiquesEt 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.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"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.
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
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
Oh là là, ne me fais pas dire ce que je n'ai pas dit...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
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
A la limite, je regrettais surtout de ne pas connaitre cet acronyme
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
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.
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
Ben, je viens de répondre, heinLa 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
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 ^^.
Come on, men ! I just invented it !Tu as parlé de OLTC (acronyme que tu m'as appris à l'occasion, ce dont je te remercie
A la limite, je regrettais surtout de ne pas connaitre cet acronyme
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.
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
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).
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 ?
Se préoccuper de la durée de vie des objets avec minutie me semble être une bonne approche complémentaire au RAII.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager