Discussion :

[aperdemak]

Bonjour, dans mes class qui gèrent des ressources j'ai l'habitude je créer une méthode Free/Delete que j'appelle qu'une seule fois pour éviter que lors de la réalocation d'un vector(par ex) que le destructeur soit appelé et que les ressources(fichier/connexion/...) soient libérée par erreur. On m'a dit que c'était pas très RAII. Je trouve ça bien pratique moi, c'est si mal que ça ?
merci d'avance.

[Médinoc]

Depuis l'ajout de la sémantique de mouvement par C++11, tu n'as plus à te soucier du problème de réallocation d'un vecteur: Utilise un vecteur de unique_ptr et le constructeur de déplacement fera le boulot correct.

[Bousk]

dans mes class qui gèrent des ressources j'ai l'habitude je créer une méthode Free/Delete que j'appelle qu'une seule fois

Et tu l'appelles quand ? Quand tu vas détruire ton objet ? C'est exactement à ça que sert le destructeur, donc quelle est la plus-value et l'intérêt de cette pratique ?

pour éviter que lors de la réalocation d'un vector(par ex) que le destructeur soit appelé et que les ressources(fichier/connexion/...) soient libérée par erreur.

Il n'y a pas d'erreur, le code exécuté est celui que tu écris. vector ne détruit pas arbitrairement les données quand tu le redimensionnes, il les copie dans son nouveau buffer. C'est à toi de rendre ta classe copiable correctement si tu comptes l'utiliser avec vector.
En plus maintenant avec la sémantique de mouvement, il aura tendance à plutôt les déplacer, ce qui est encore plus intéressant.

Une ressource ce devrait être un std::unique_ptr<Resource> que tu maîtrises. Et cette maîtrise passe en particulier par un constructeur et destructeur correct et logique.
Ce serait dommage qu'un fichier ou une connexion ne soit pas libérée parce que ton appel à Delete/Free n'a pas été fait parce que oubli/crash/erreur/...

[aperdemak]

Je connais tout ça mais je code jamais de gros programme donc je m'encombre pas. Pour rendre l'objet copiable il faut dézinguer l'objet ayant été copié pour qu'il ne libère pas le buffeur c'est légal de faire ça dans le copy constructor ? Je veux pas utiliser d'unique ptr car c'est pas un pointeur qu'il me faut.

[Médinoc]

Je connais tout ça mais je code jamais de gros programme donc je m'encombre pas. Pour rendre l'objet copiable il faut dézinguer l'objet ayant été copié pour qu'il ne libère pas le buffeur c'est légal de faire ça dans le copy constructor ?

Ça ne se fait pas dans le copy-constructor, ça se fait dans le move-constructor (et donc, tu n'as pas besoin de rendre ton objet copiable).

Et sinon, si tu tiens à être "copiable", il reste l'option de faire un comptage de reférences...

[Mat.M]

Bonjour, dans mes class qui gèrent des ressources

d'abord il faudrait être vraiment précis : c'est quoi des ressources ?
Si tu n'est pas précis on ne va pas te comprendre.
Je suppose que par ressources il faut comprendre images,texte, données binaires ?

[aperdemak]

oui c'est ça je pensais que c'était évident. Sinon à part move constructor/gestion manuelle/reference counting il y a pas de façon plus propre de faire ?

concrètement ce que je fais c'est que j'ai des vbo dans un vector dans une class Vao et c'est cette classe qui appelle Vbo.Free() qui est ma méthode pour détruire les vbo qui ne peuvent pas l'être depuis leur destructeur puisqu'il y a beaucoup de passage en paramètre/réalocation etc.

merci d'avance.

[Médinoc]

Le move-constructor est, la façon propre. Avec ça, tu n'as pas à te soucier des réallocations des conteneurs.
Quant aux passages de paramètres, c'est souvent mieux fait avec des références...

Le seul cas compliqué que je voie, c'est celui où le conteneur peut être agrandit alors qu'il y a une fonction extérieure qui contient une référence vers ton objet. Dans ce cas, faire une classe alternative "non-propriétaire" de la ressource pour la manipuler peut être une bonne idée. L'autre solution étant de stocker des unique_ptr<> vers tes objets au lieu de stocker les objets eux-mêmes.

[aperdemak]

Ok merci à tous j'ai une meilleure idée de la chose maintenant.