Discussion :

[Ehonn]

Puis-je vraiment dire que mon code respecte le principe RAII si sur mes 200 classes composant mon programme seul Server est RAII et que les autres classes que j'ai moi-même codé prennent un malin plaisir à mettre à mal le principe RAII ?

Ce qui compte ici, c'est le code de l'utilisateur, c'est-à-dire celui qui manipule la classe Foo, pas celui de la classe elle-même.
Je suis d'accord pour dire que le code de la classe Foo n'est pas RAII (mais l'utilisation de la classe Foo est RAII).

Code :

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

1
2
3
Server(void)
~Server(void)
int main(void)

Faut arrêter de mélanger le C et le C++

[Neckara]

Il n'y a pas à distinguer classe RAII et utilisation RAII.

A quoi servirait alors le RAII si on l'utilise mal ensuite ?
C'est comme encapsuler des pointeurs intelligents pour offrir une interface donnant des pointeurs nus, c'est complètement ridicule et je n'appellerais pas cela "utiliser des pointeurs intelligent".

Le RAII c'est l'acquisition de ressources à l'initialisation et la libération à la destruction : c'est un modèle de conception.

Et un pointeur nu n’acquiert à l'initialisation ni ne libère à la destruction.

[Neckara]

Je suis d'accord pour dire que le code de la classe Foo n'est pas RAII (mais l'utilisation de la classe Foo est RAII).

Voilà c'est ce que je voulais dire.
Et je ne parlais pas de l'utilisation de Foo mais de Bar.

Faut arrêter de mélanger le C et le C++

?

[Aleph69]

Je pense que tu as mal lu mon exemple.

Ton exemple c'est

Code :

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

1
2
3
4
5
6
class Foo
{
       Foo(void) : m_toto(new Toto){}
       ~Foo(void){ delete m_toto; }
       Toto * m_toto;
}

et mon exemple c'est

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
class Bar;
class Foo
{
 
public:
 
  Foo(int arg) : m_data(new Bar(arg))
  {}
 
  ~Foo()
  { delete m_data; }
 
private:
 
  Bar* m_data;
 
};

Quelle est la différence?

Désolé, j'arrête là sur RAII.
La discussion est vraiment intéressante mais c'est aussi vraiment hors propos.

[Ehonn]

Juste par curiosité : pourquoi tu n'aimes pas séparer déclarations et définitions?
Moi je le fais systématiquement car j'aime bien avoir une vue d'ensemble de l'interface d'une classe sans me soucier forcément de l'implémentation.

- Une fausse raison : car je fais du header-only avec pas mal de template et que c'est plus simple à distribuer.
- Car cela duplique le code (les déclarations)
- Car je n'ai pas encore eu de souci de temps de compilation
- Pour la vue d'ensemble, je fourni la Doxygen (et faudrait que j'écrive des tutoriels).

[Neckara]

Quelle est la différence?

Je ne vois pas pourquoi ta classe Toto respecterait RAII et pas ma classe Foo : je ne vois pas de différence.

Dans mon exemple, Toto est dans Foo.
Dans ton exemple, c'est Bar qui est dans Foo.

Donc si tu ne vois pas la différence entre Toto de mon exemple (= le Bar de ton exemple) et le Foo de ton exemple (= le Foo de mon exemple)...

[Ehonn]

Faut arrêter de mélanger le C et le C++

?

En C

Code :

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

1
2
void f()     // f peut accepter un nombre non spécifié d'arguments
void f(void) // f n'accepte aucun argument

En C++

Code :

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

1
2
void f()     // f n'accepte aucun argument
void f(void) // f n'accepte aucun argument

[Aleph69]

A quoi servirait alors le RAII si on l'utilise mal ensuite ?

Je réponds juste à ça pour éviter tout mal entendu.
Je dis que ce que tu appelles utilisation RAII est en fait la même chose qu'une classe RAII.
Dans l'exemple,

Code :

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

1
2
3
4
5
class Baz
{
private:
  std::vector<int> m_vector;
};

tu n'"utilises" pas RAII, tu crées une classe RAII : à l'initialisation, tu acquiers m_vector et tu le libères à la destruction.
Tu te reposes sur les mécanismes automatiques de construction/destruction du C++, exactement comme dans la version "pointeur nu" :

Code :

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

1
2
3
4
5
6
7
8
class Baz
{
public:
  Baz(size_t size) : m_vector(new int[size]) {}
  ~Baz() { delete [] m_vector; }
private:
  int* m_vector;
};

Tu ne peux pas détruire Baz sans libérer la ressource m_vector (RAII).

En l'absence de livre sous la main, je ne peux pas faire mieux que t'envoyer un exemple par Stroustrup, l'inventeur du RAII : http://www.stroustrup.com/bs_faq2.html#finally
Tu verras qu'il y a un pointeur nu dans sa classe.

[Aleph69]

Dans mon exemple, Toto est dans Foo.
Dans ton exemple, c'est Bar qui est dans Foo.

Donc si tu ne vois pas la différence entre Toto de mon exemple (= le Bar de ton exemple) et le Foo de ton exemple (= le Foo de mon exemple)...

Désolé, je me suis trompé : je parlais évidemment de ta classe Foo.
Tu dis qu'elle respecte RAII mais c'est exactement la même que ma classe Foo dont tu dis qu'elle le viole.

Je ne peux vraiment pas continuer la discussion.

Merci à tous de m'avoir répondu.

[Neckara]

En C

Code :

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

1
2
void f()     // f peut accepter un nombre non spécifié d'arguments
void f(void) // f n'accepte aucun argument

En C++

Code :

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

1
2
void f()     // f n'accepte aucun argument
void f(void) // f n'accepte aucun argument

Oui, ça je le sais.
Donc en quoi mon code serait "C" parce que j'utilise : Server(void); ?
Je trouve que c'est beaucoup plus joli d'indiquer "void" explicitement.

C'est un choix de style.

@Aleph69 :

Tu dis qu'elle respecte RAII mais c'est exactement la même que ma classe Foo dont tu dis qu'elle le viole.

Je ne dit pas que Foo viole le RAII mais que ton code n'est pas RAII.

Pour reprendre mon exemple où Toto est RAII :

Code :

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

1
2
3
4
5
6
7
class Foo
{
       Foo(void) : m_toto(new Toto){}
       ~Foo(void){ delete m_toto; }
       Toto * m_toto;
}

Tu es d'accord que, si Toto n'était pas RAII, ce code est équivalant :

Code :

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

1
2
3
4
5
6
7
class Foo
{
       Foo(void){ m_toto.allocate(); }
       ~Foo(void){ m_toto.desallocate(); }
       Toto m_toto;
}

Au final, que Toto soit RAII ou non, on revient exactement au même à cause de l'utilisation de ton pointeur nu qui est non RAII.
Donc pourquoi créer une classe Toto RAII si tu n'utilises pas le fait qu'il soit RAII (à cause de ton pointeur) ? Pourquoi ne pas faire une classe Toto non-RAII ? Cela reviendra au même.
Quel est ici l'intérêt que Toto soit RAII ?

C'est comme si je dit "utiliser des pointeurs intelligents", et que je créé une classe MyPtrSuperClever que j'encapsule de la sorte :

Code :

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

1
2
3
4
5
6
7
class Foo {
public :
         Foo( void * ptr) : myPtrSuperClever(ptr){}
         void * get(void){ return & * myPtrSuperClever; }
private :
         MyPtrSuperClever myPtrSuperClever;
}

Quel est l'intérêt du pointeur intelligent ?

[Médinoc]

En mettant de côté les histoires de non-canonicité des classes RAII présentées ici (on va simplement supposer qu'on a déclaré copie et affectation en =delete), le seul cas où je verrais un clair inconvénient à la version "pointeur", c'est celui où la classe en contiendrait plusieurs, car là c'est l'exception-safety qu'elle violerait.

Une classe ne doit pas gérer "manuellement" plus d'une ressource pour être exception-safe.

[Neckara]

Une classe ne doit pas gérer "manuellement" plus d'une ressource pour être exception-safe.

Pourrais-tu nous en dire plus ?

[Médinoc]

Je ne me souviens plus trop de ce que j'avais lu exactement ni où je l'avais lu, mais si tu dois gérer toi-même deux ressources que tu alloues dans ton constructeur, tu dois gérer la destruction de manière complexe:

Code C++ mauvais :

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

1
2
3
4
5
6
7
8
class Foo : boost::noncopyable
{
	Bar * a;
	Bar * b;
public:
	Foo() : a(new Bar), b(new Bar) {}
	~Foo() { delete a; delete b; }
};

Code C++ passable :

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
class Foo : boost::noncopyable
{
	Bar * a;
	Bar * b;
public:
	Foo() {
		a = new Bar;
		try {
			b = new Bar;
		} catch(...) {
			delete a;
			throw;
		}
	}
	~Foo() { delete a; delete b; }
};

Code C++ exception-safe :

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

1
2
3
4
5
6
7
8
9
class Foo : boost::noncopyable
{
	unique_ptr<Bar> a;
	unique_ptr<Bar> b;
	Qux* c;
public:
	Foo() : a(new Bar), b(new Bar), c(new Qux) {}
	~Foo() { delete c; }
};

[Neckara]

Je vois, c'est dans le cas où on pourrait avoir une exception dans le constructeur (lancée par new) :

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
A::A() throw (int)
try
{
    pBuffer = NULL;
    pData = NULL;
    cout << "Début du constructeur" << endl;
    pBuffer = new char[256];
    cout << "Lancement de l'exception" << endl;
    throw 2;
    // Code inaccessible :
    pData = new int;
}
catch (int)
{
    cout << "Je fais le ménage..." << endl;
    delete[] pBuffer;
    delete pData;
}

Ce n'est pas si compliqué que cela.

[Ehonn]

Oui, ça je le sais.
Donc en quoi mon code serait "C" parce que j'utilise : Server(void); ?
Je trouve que c'est beaucoup plus joli d'indiquer "void" explicitement.

C'est un choix de style.

Rajouter void n'apporte aucune information en C++.
Pour les goûts et les couleurs : je déteste.
Pour moi : cela dégrade la lisibilité du code en rajoutant des choses inutiles.
Utiliser des choses qui sont dans C++ uniquement pour la compatibilité C rend ton code un peu moins C++ à mes yeux.

[Neckara]

Pour moi : cela dégrade la lisibilité du code en rajoutant des choses inutiles.

Pour ma part, au contraire, je trouve qu'on voit beaucoup plus rapidement qu'il n'y a pas de paramètres.

Utiliser des choses qui sont dans C++ uniquement pour la compatibilité C rend ton code un peu moins C++ à mes yeux.

Mon but n'est pas d'avoir une compatibilité C.

[Ehonn]

Je vois, c'est dans le cas où on pourrait avoir une exception dans le constructeur (lancée par new) :

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
A::A() throw (int)
try
{
    pBuffer = NULL;
    pData = NULL;
    cout << "Début du constructeur" << endl;
    pBuffer = new char[256];
    cout << "Lancement de l'exception" << endl;
    throw 2;
    // Code inaccessible :
    pData = new int;
}
catch (int)
{
    cout << "Je fais le ménage..." << endl;
    delete[] pBuffer;
    delete pData;
}

Ce n'est pas si compliqué que cela.

Sauf que new peut envoyer uniquement std::bad_alloc et donc ton catch est inutile. De plus, comme tu as spécifié throw (int) dans la signature du constructeur, l'utilisateur ne pourra jamais attraper une autre exception que int. Et donc, si new envoie std::bad_alloc, le programme "plantera forcément" sans avoir la possibilité d'attraper l'exception.

[Ehonn]

Pour ma part, au contraire, je trouve qu'on voit beaucoup plus rapidement qu'il n'y a pas de paramètres.
Mon but n'est pas d'avoir une compatibilité C.

C'est C++ qui supporte cette syntaxe pour la compatibilité C. (C'est pas en utilisant cette syntaxe que notre programme va être compatible C).

[Neckara]

Sauf que new peut envoyer uniquement std::bad_alloc et donc ton catch est inutile. De plus, comme tu as spécifié throw (int) dans la signature du constructeur, l'utilisateur ne pourra jamais attraper une autre exception que int. Et donc, si new envoie std::bad_alloc, le programme "plantera forcément" sans avoir la possibilité d'attraper l'exception.

C'est un exemple de constructeur lançant une exception.
Que le constructeur lance une exception "int", "std::string", "Foo", c'est le même principe.
Toi t'aimes pinailler, non? .

C'est C++ qui supporte cette syntaxe pour la compatibilité C. (C'est pas en utilisant cette syntaxe que notre programme va être compatible C).

Cela ne m'empêche pas de trouver que c'est beaucoup plus lisible/rapide d'avoir un "void" mis en valeur grâce à la coloration syntaxique que de rechercher l'absence d'arguments.

[Ehonn]

Que le constructeur lance une exception "int", "std::string", "Foo", c'est le même principe.
Toi t'aimes pinailler, non?

On parle d'exception dans le constructeur avec de l'allocation dynamique et l'exemple que tu donnes est un code qui n'a ni queue ni tête et qui fait un throw 2; juste pour le plaisir.
Certes ce n'est pas toujours évidant de donner du code logique et minimal lorsqu'on veut montrer un problème relativement complexe mais bon là c'est vraiment trop artificiel.
Au dessus de ça, ton code est gênant car il empêche l'utilisateur d'attraper une autre exception que int.