Merci à loufoque pour cette précision dont je tiendrais compte.
Version imprimable
Merci à loufoque pour cette précision dont je tiendrais compte.
Il faut aussi se rendre compte que RAII n'est, en définitive qu'un concept (ou peut etre un idiome, d'ailleurs)...
L'orientation OO tend (entre autres) à en généraliser la mise en oeuvre, et à l'automatiser, mais, même en C, un bon programmeur veillera à initialiser correctement les différents champs d'une structure au moment de la création d'une variable ;)
De plus, il ne faut malgré tout pas oublier que le genre d'application que l'on faisait dans les années 80 (voire même dans les années 90) n'a - finalement - pas grand chose avec les applications que l'on fait actuellement, et que l'augmentation des possibilités des ordinateurs a été de paire avec l'augmentation de ce que l'utilisateur en attend...
L'orientation objet a un objectif clair: permettre de concevoir des applications plus complexes tout en assurant - si la conception est correcte - la qualité de l'application sans pour autant que les délais de conception ne soient forcément proportionnels (voire carrément exponentiels) par rapport à la complexité de l'application.
Cela implique la généralisation de concepts tels que le RAII, la programmation par contrat ou autres, dont l'utilisation était déjà recommandée pour les applications "simples" d'il y a dix ou vingt ans, mais dont on se rend compte qu'ils deviennent quasi incontournable dans le cadre des applications actuelles...
Finalement, le problème n'est pas que le langage permette au programmeur d'être moins attentif, c'est qu'il puisse s'adapter à de nouveaux concepts;).
Le RAII c'est plutôt associer une ressource à une portée. Quand on quitte la portée, la ressource est libérée automatiquement.Citation:
L'orientation OO tend (entre autres) à en généraliser la mise en oeuvre, et à l'automatiser, mais, même en C, un bon programmeur veillera à initialiser correctement les différents champs d'une structure au moment de la création d'une variable
D'un, un programmeur C écrira très souvent du code qui ne lie pas une ressource à une portée.
C'est monnaie courante d'allouer un truc quelque part et de le désallouer ailleurs.
Deuxièmement, on peut quitter la portée à cause d'une erreur, qui peut se produire n'importe où. Il faut donc alors libérer les bonnes ressources, ce qui nécessite de pouvoir savoir quelles sont les ressources qu'on a allouées jusqu'à présent (ce qui rend donc l'utilisation d'un unique label "cleanup" difficile, par exemple, à moins d'utiliser des objets nuls partout et ne pas les libérer s'ils sont nuls).
Pour le code C++ suivant
il faudrait écrire le code CCode:
1
2
3
4
5
6 void foo() { A a; B b; C c; }
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24 int foo() { A a; B b; C c; if(A_construct(&a) < 0) return -1; if(B_construct(&b) < 0) { A_destruct(&a); return -1; } if(C_construct(&c) < 0) { B_destruct(&b); A_destruct(&a); return -1; } return 0; }
Je trouve quand même que le terme RRIF (Resource Release Is Finalization) est plus parlant que RAII, car j'utilise souvent cet idiome pour libérer des ressources acquises avant ou après la construction de l'objet...
Et d'ailleurs, je suis souvent peiné que certaines classes ne permettent pas cela.
Certains parlent aussi de SBRM (Scope Bound Resource Management).
D'ailleurs l'appellation SBRM est la plus parlante je trouve...
En effet. Je ne connaissais pas cette terminologie.