Discussion :

[koala01]

et std::vector

std::vector s'occupe de faire respecter (de manière transparente) le RAII sur un pointeur dont il est déjà propriétaire à la base: c'est std::vector qui se charge d'appeler new pour pouvoir y placer ses éléments

Une "capsule RAII" (comme les pointeurs intelligents" accaparent la propriété (quitte à ce qu'elle soit partagée) d'une ressource dont il ne sont pas propriétaire à la base:

Ce n'est ni std::unique_ptr ni std::shared_ptr qui appelle new, mais celui qui décide de leur confier la propriété (std::make_unique, std::make_shared, appel explicite à new de la part de l'utilisateur (de std*_ptr), factory, autres...)

On se rend compte qu'il y a donc bel et bien "une légère différence" -- et pourtant bien réelle -- entre une classe appliquant le RAII automatiquement et de manière transparente pour une de ses ressources interne et une capsule RAII : la création de la ressource fait partie de son "frichti interne", alors qu'elle est totalement extérieure à la deuxième.

Ou, dit plus simplement, on pourrait dire qu'une capsule RAII n'a comme seule raison d'être que d'assurer une fin RAII à (la "destruction propre" de) la ressource dont elle prend la responsablilité, alors que RAII en entier concerne également toutes les manières dont une classe peut acquérir les ressources dont elle est directement responsable.

[gl]

Parce que ce n'est pas un objet qui est encapsulé : ce sont soit des pointeurs soit des structures avec des pointeurs, mais en cas des classes C++

OK, ici j'employais objet dans un sens plus large que celui qu'il a en POO (plutôt dans le sens qu'utilise le standard : "An object is a region of storage."). Je suis d'accord c'est confusant.

[koala01]

et std::vector

En fait, je me demande si toute la confusion entre une "classe (applicant le) RAII" et une "capsule RAII" ne vient pas, tout simplement, du fait que les deux concepts sont simplement "mal définis" (ou, du moins, de manière trop imprécise).

Car le princie des classes RAII, il existe depuis... toujours et en très grand nombre dans la bibliothèque standard : Toutes les classes agissant comme des collections de taille dynamique (incluant std::[basic_|w]string et std::basic_streambuf) ou manipulant un "file descriptor" (comme les std::[basic_|i|o]fstream) et j'en oublie très certainement agissent comme des classes (appliquant) le RAII.

Toutes ces classes pourraient en effet correspondre à une définition proche de

une classe prenant (de manière transparente pour l'utilisateur ) la responsabilité de la création, de la modification et de la destruction finale de toute ressource dont elle a besoin

Par contre, la définition d'une capsule RAII serait plutôt proche de

Une classe destiner à assurer une destruction correcte et sécurisée (dans l'esprit du RAII) de la ressource qui lui est confiée aussi longtemps que la responsabilité lui échoit

Avant C++11, la seule classe qui aurait pu correspondre à cette définition dans la bibliothèque était std::auto_ptr, mais

1. la sauce n'a jamais vraiment bien pris et
2. comme c'était la seule classe de sa catégorie, elle était plutôt considérée comme une exception / anomalie / curiosité / aberration (*), si bien que l'intérêt de choisir un terme pour la définir ne s'est sans doute jamais fait sentir.

(biffer les mentions inutiles)

Avec C++11 sont arrivées quelques classes qui

1. elles ne s'occupent pas de la création de la ressource qu'on leur confie
2. elles peuvent abandonner la responsabilité de la ressource qu'on leur a confier (cf release)
3. elles peuvent passer d'une ressource à l'autre (en assurant la fin RAII de l'ancienne au passage)
4. le principe de ces classes a fait ses preuve (d'utilité et d'utilisabilité) car il existait dans boost depuis "pas mal de temps"

Du coup, ces classes ne sont donc plus considérée comme des curiosité, mais bien comme des fonctionnalités (de première importance ) et des aides efficaces face à une situation qui a toujours posé problème.

Et comme toute fonctionnalité (utile / importante ) doit pouvoir être identifiée clairement, il a bien fallu trouver un terme qui permette d'identifier la fonctionnalité associée à ces quelques classes

S'il y avait eu la moindre chance que toutes ces classes se résument juste à un "essai manqué" comme cela a été le cas pour auto_ptr, le terme de "capsule RAII" n'aurait sans doute jamais vu le jour

Mais, comme la fonctionnalité qu'il décrit est "relativement nouvelle" (du moins, dans la bibliothèque standard) et qu'en plus, elle n'est applicable / appliquée que par un nombre restreint de classe, il ne faut pas s'étonner si le terme qui la décrit n'est encore que peu utilisé