Discussion :

[mess-mate]

Merci à loufoque pour cette précision dont je tiendrais compte.

[koala01]

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.

[HanLee]

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.

Ca dépend de ce qu'on appelle RAII. RAII au sens gestion déterministe des ressources, c'est typiquement C++-ien.

[loufoque]

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

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.

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

Code :

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

1
2
3
4
5
6
void foo()
{
    A a;
    B b;
    C c;
}

il faudrait écrire le code C

Code :

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

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;
}

[white_tentacle]

Ca dépend de ce qu'on appelle RAII. RAII au sens gestion déterministe des ressources, c'est typiquement C++-ien.

Les clauses using de C# (et il me semble que java a la même), c'est pourtant typiquement ça .

[Médinoc]

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.

[Noxen]

Légère correction de language : on parle de programmeur, pas de programmateur.

Pour l'anecdote :

En fait, le terme d'origine c'est bien programmateur (verbe programmer + suffixe -ateur). Programmeur est la francisation du terme anglais programmer.

[loufoque]

Certains parlent aussi de SBRM (Scope Bound Resource Management).

[Goten]

D'ailleurs l'appellation SBRM est la plus parlante je trouve...

[Médinoc]

En effet. Je ne connaissais pas cette terminologie.