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�