retour de copy

J'ai souvent le dileme suivant. Je doit faire une fonction qui retourne une copy de donnée(s) et j'hésite toujours entre alloué la mémoire dans ma fonction et retourné un pointeur sur ce que j'ai alloué(solution 1) ou demander à lutilisateur de me passer un pointeur ou (une ref) sur de la mémoire que lui à alloué lui même et que je remplis.

solution 1:
definition de ma fonction:

Code:

---

1 2 3 4 5 6

mesDonnees * MaClasse::CopyDonnees() { mesDonnees * v_pRet = new mesDonnees; *v_pRet = m_ClasseDonnees; return v_pRet; }

---

utilisation:

Code:

---

1 2 3

mesDonnees* v_pDonnees = v_aInstance.Copy(); /* utilisation des donnees */ delete v_pDonnees;

---

solution 2:
definition de ma fonction:

Code:

---

1 2 3 4 5

void MaClasse::CopyDonnees(mesDonnees * _pToFill) { _pToFill = *m_ClasseDonnees; return; }

---

utilisation:

Code:

---

1 2 3 4

mesDonnees* v_pDonnees = new mesDonnees; v_aInstance.Copy(v_pDonnees); /* utilisation des donnees */ delete v_pDonnees;

---

l'expérience montre que si on utilise la première solution, lutilisatuer ne lit jamais la doc et oublie le delete. Donc fuite mémoire.
Mais la solution 2 n'est pas forcément très souple, notament en cas tableau de taille variable, ou même au niveau de l'encapsulation. Par exemple si ma fonction calcul une clée à utiliser comme entrée d'un conteneur assiociatif et que je veut modifier mon algo et que cela fasse varier la taille de ma clé.
Donc voilà vous qu'en pensez vous solution 1, 2, ou une autre encore mieux ?

La meilleure solution c'est d'utiliser les auto_ptr, ça marche du tonnerre pour ça. La réf en en la matière :
http://www.gotw.ca/publications/usin...ffectively.htm
cf. le paragraphe 'ownership, sources, and sinks'

Salut,

a priori une fonction copy comme son nom l'indique te retourne une copy et l'utilisateur doit ensuite la liberer.

C'est donc la solution 1 qui va etre utilisée le plus souvent

XXiemeciel

Pourquoi ne pas utiliser le constructeur de recopie ?

Code:

---

1 2 3 4 5 6 7 8

// sans pointeur mesDonnees data1; mesDonnees copie1( data1 );   // avec pointeurs mesDonnees *data2 = new mesDonnees; mesDonnees *copie2 = new mesDonnees( *data2 );

---

Jette un oeil à cette QR aussi:
http://c.developpez.com/faq/cpp/?page=classes#CLASS_clone

Citation:

---

Envoyé par VoidSeer

La réf en en la matière :
http://www.gotw.ca/publications/usin...ffectively.htm

---

Je viens justement de découvrir que auto_ptr ne convient pas dans le cas du pimpl, car il provoque un comportement indéfini : l'appel de delete sur une type non concret (forward declaration). Ce passage de gotw est faux à ce sujet.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Pourquoi ne pas utiliser le constructeur de recopie ?

---

non un constructeur par copie ne va pas car je ne copy pas toute les données de ma classe. Le terme de Copy induit en erreur j'aurrai du enutiliser un autre.

pour les auto_ptr ça à l'air pas mal, mais je me méfie des la STL, devant faire du code multiplateforme (NT, linux, solaris, AIX) j'ai déjà eu des mauvaises surprises. Mais bon là je ne pense pas qu'il y est de PB.

Aucun pb pour Linux/NT en ce qui concerne les auto_ptr (enfin gcc/VC7/mingw)

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Je viens justement de découvrir que auto_ptr ne convient pas dans le cas du pimpl, car il provoque un comportement indéfini : l'appel de delete sur une type non concret (forward declaration). Ce passage de gotw est faux à ce sujet.

---

Peux tu préciser ce point STP ?

Je n'ai pas de règles absolues. Pour les petits objets et généralement pour tous ceux qui ont une sémantique de valeur, je renvois, par défaut, des copies.
S'il s'avère qu'il y a besoin de performances à cet endroit, où que la sémantique de référence est la seule possible, je pars sur des auto_ptr ou autres équivalents qui me confèreraient une sémantique de déplacement en sortie de la fonction.
Cf l'article d'Andrei Alexandrescu sur le sujet (mot clé: mojo à utiliser sur la page des articles sur son site), ou les propositions d'amélioraton du standard.

Sinon, auto_ptr<> est plutôt bien défini. Il y a avait des problèmes avec des anciennes implémentations de la SL. Perso, j'en use et abuse pas mal avec une vieille version de Sunpro CC couplée avec STLPort. Au pire, il est vite fait de s'en rajouter une implémentation suivant les spécs du standard.

Citation:

---

Envoyé par BigNic

pour les auto_ptr ça à l'air pas mal, mais je me méfie des la STL, devant faire du code multiplateforme (NT, linux, solaris, AIX) j'ai déjà eu des mauvaises surprises. Mais bon là je ne pense pas qu'il y est de PB.

---

Faisant du multiplateforme Solaris, AIX, HP-UX, Linux et utilisant la SL sans faire particulièrement attention, je me demande quel problèmes tu as rencontrés.

Citation:

---

Envoyé par BigNic

J'ai souvent le dileme suivant. Je doit faire une fonction qui retourne une copy de donnée(s) et j'hésite toujours entre alloué la mémoire dans ma fonction et retourné un pointeur sur ce que j'ai alloué(solution 1) ou demander à lutilisateur de me passer un pointeur ou (une ref) sur de la mémoire que lui à alloué lui même et que je remplis.

---

Je suis peut-être stupide, mais si la classe a une sémantique de valeur, je retourne une valeur, si elle a une sémantique de référence, je retourne une référence (pas au sens C++, un pointeur éventuellement intelligent ou encapsulé dans une classe proxy ou handle). Je ne vois donc pas tellement la raison du dilemne, j'ai rarement des classes à sémantique de valeur couteuses à copier, je préfère alors une classe a sémantique de référence ayant un membre copy (peut-être est-ce en fait ça ma solution à ton dilemne).

Citation:

---

Envoyé par VoidSeer

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Je viens justement de découvrir que auto_ptr ne convient pas dans le cas du pimpl, car il provoque un comportement indéfini : l'appel de delete sur une type non concret (forward declaration). Ce passage de gotw est faux à ce sujet.

---

Peux tu préciser ce point STP ?

---

J'ai pas donné de lien désolé:
On std::auto_ptr<>
http://www.octopull.demon.co.uk/arglib/TheGrin.html

Dans l'exemple suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Pimpl;   class Test { public: Test();   private: std::auto_ptr<Pimpl*> pimpl_; }

---

Le compilateur va générer le destructeur par défaut. Il va le faire dans chaque unité de compilation qui inclut Test.h. Cela veut dire qu'il va instancier de multiples fois ~auto_ptr<Pimpl*>, le trie se faisant à l'édition de liens. Et que fait ~auto_ptr ? Un delete, sur un Pimpl*, qui est dans ce contexte un type non concret, ce qui revient à écrire:

Code:

---

1 2 3 4 5

class Pimpl;   Pimpl *p = GetPimpl(); delete p; // <-- comportement indéfini

---

Voilà le problème.
Sous VC++ tu obtiens un warning à utiliser la classe Test, et pour le faire sauter faut déclarer le destructeur de Test, comme ça il en génère pas. Ca enlève un peu l'utilité de auto_ptr s'il faut écrire un destructeur... et à bien y réfléchir, auto_ptr ne se prête pas bien au Pimpl car ta classe Test ne peut pas être copiable.
grin_ptr résoud tous ces problèmes.

Interessant.

Indépendemment du pimpl, en revanche, je continuerai d'abuser de l'auto_ptr dans le cadre de la question initiale de ce post. A savoir, comment gérer la propriété d'un objet instancié dynamiquement dans une méthode. Le système de source/sink à vraiment l'avantage de clarifier au niveau de la programmation (et non de la documentation) le partage des responsabilités, et assure en plus une certaine sécurité en terme de fuite mémoire.

@Aurélien
Quelque chose me dérange dans l'explication ci-dessus.
L'instanciation des instances d'auto_ptr et la génération du code par défaut se fera au moment de la compilation du fichier source de la classe utilisant le pimpl.
Si le source inclue la définition de l'implémentation, la classe sera définie avant lors de l'instanciation du template et le comportement indéfini que tu décris n'aura pas lieu.
En tout cas, le code suivant fourni un résultat parfaitement correct sous Linux/gcc4.
Je ne suis pas sûr que ce soit un coup de chance dû à la plate-forme.
Test.H

Code:

---

1 2 3 4 5 6 7 8 9 10

#include <memory>   class A;   class B { public: B(); std::auto_ptr<A> a; };

---

Test.C

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#include <iostream> #include "Test.H"   using namespace std;   struct A { ~A(){cout << "~A" << endl}; };   B::B() { a = auto_ptr<A>(new A()); }     int main() { B b; }

---

Citation:

---

Envoyé par VoidSeer

@Aurélien
Quelque chose me dérange dans l'explication ci-dessus.
L'instanciation des instances d'auto_ptr et la génération du code par défaut se fera au moment de la compilation du fichier source de la classe utilisant le pimpl.
Si le source inclue la définition de l'implémentation, la classe sera définie avant lors de l'instanciation du template et le comportement indéfini que tu décris n'aura pas lieu.

---

C'est ce que je croyais aussi, mais en fait ça ne se passe pas comme ça. Le destructeur par défaut ~B() est généré dans chaque unité de compilation, c.a.d partout où B.h est inclus. Dans le cas de B.cpp, comme A.h est défini, pas de problème. Dans les autres cas, tu te paye un comportement indéfini. Là où je ne suis pas sûr c'est ce qui concerne le choix de l'instanciation implicite par le linker. Je ne sais pas ce que dit la norme car il va détecter différentes version du même destructeur. Moi j'ai constaté avec VC++ qu'il choisissait bien celui de B.cpp, et donc y'avait pas de problème. Je ne sais pas si c'est ou non garantit par la norme. Donc peut être qu'il n'y a pas comportement indéfini, mais ce qui est sûr, c'est que le warning que tu te paye en compilant autre chose que B.cpp est justifié.

Citation:

---

En tout cas, le code suivant fourni un résultat parfaitement correct sous Linux/gcc4.
Je ne suis pas sûr que ce soit un coup de chance dû à la plate-forme.
Test.H

Code:

---

1 2 3 4 5 6 7 8 9 10

#include <memory>   class A;   class B { public: B(); std::auto_ptr<A> a; };

---

Test.C

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#include <iostream> #include "Test.H"   using namespace std;   struct A { ~A(){cout << "~A" << endl}; };   B::B() { a = auto_ptr<A>(new A()); }     int main() { B b; }

---

---

ce code ne pose aucun problème, A est un type concret au moment de la génération de ~B. Il faudrait déplacer:

Code:

---

1 2 3 4 5 6 7 8 9

struct A { ~A(){cout << "~A" << endl}; };   B::B() { a = auto_ptr<A>(new A()); }

---

dans un autre fichier B.cpp pour rencontrer le problème. La compilation de main() va alors générer ~B() et donc ~auto_ptr<A> et donc appeler ~A et là, A n'est pas un type concret...

D'accord, je peux reproduire le problème. Effectivement, dès que le destructeur de la classe englobant l'auto_ptr est implicite ou inline, il va y avoir un soucis pour la compilation de chaque unité de compilation cliente.
A priori, c'est une erreur bien gérée par les compilo modernes (en tout cas gcc4 et VC 7+) qui AMA va devenir un classique avec l'introduction de smart pointers dans la librairie standard (TR1). Le choix est entre inclure la définition de la classe pointée dans le fichier d'entête de la classe englobante, ou s'interdire d'utiliser un destructeur inline ou celui par défaut.
Pour des problèmes d'indépendance de compilation, je pense que ce sera quasi-systématiquement le 2e choix qui sera fait.

Cela dit, je ne pense pas que cela remette en cause l'utilisation d'auto_ptr pour un pimpl.

Merci pour le pointeur, en tout cas. Ca m'a permis de vérifier dans nos sources que ce cas de figure ne se présentait pas.

Il me semble que le compilo privilégie toujours une instanciation explicite, ce qui fait que tu arriver en le voulant vraiment à l'induire en erreur. Il suffit d'instancier toi même ~B quelque part sans que A soit concrète. C'est plutôt un résultat attendu.
Là où je suis un peu perdu, c'est avec les instanciation implicites différentes. Le compilo semble toujours choisir le bon destructeur de ~B = celui qui a été généré quand A est concrète. Je ne sais pas comment il gère ça.

Citation:

---

Cela dit, je ne pense pas que cela remette en cause l'utilisation d'auto_ptr pour un pimpl.

---

le fait est que auto_ptr ne convient pas à l'utilisation d'une classe déclarée de manière anticipée. D'autres smart ptr savent le faire : grin_ptr, ainsi que boost_shared_ptr qui m'a-t-on dit utilise une technique spéciale, mais j'ai pas trop fouillé.
Dans le cas d'un pimpl c'est différent, vu que c'est le destructreur de la classe englobante qui détruit l'auto_ptr. Il est possible d'avoir un comportement légal je pense en définissant explicitement ce destructeur en question. Et puis plus de warning non plus.
C'est juste que du coup, auto_ptr perd de son utilité s'il faut créer un destructeur. De là à le supprimer et le remplacer par un delete, il n'y a qu'un pas...

Code:

---

le fait est que auto_ptr ne convient pas à l'utilisation d'une classe déclarée de manière anticipée

---

Dans l'absolu, oui, mais j'y mettrais un bémol tout de même. auto_ptr peut tout à fait se substitué au membre d'une classe de type pointeur sur un objet, tout en déclarant de manière anticipée ces objets, aux conditions mentionnées précédemment.

Si dans le cas d'un pimpl, cela devient plutôt une question de style, pour d'autre type de classe ça reste pratique. Clairement, d'autre smart pointers font le même travail de manière plus intelligente, néanmoins, ils n'ont pas (encore) le mérite de faire partie de la bibliothèque standard, ce qui peut-être un soucis parfois.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Citation:

---

Envoyé par BigNic

pour les auto_ptr ça à l'air pas mal, mais je me méfie des la STL, devant faire du code multiplateforme (NT, linux, solaris, AIX) j'ai déjà eu des mauvaises surprises. Mais bon là je ne pense pas qu'il y est de PB.

---

Faisant du multiplateforme Solaris, AIX, HP-UX, Linux et utilisant la SL sans faire particulièrement attention, je me demande quel problèmes tu as rencontrés.

---

lors de l'utilisation d'un hash multimap map sous linux (RedHand entreprise) on a eu de grâves problème de perf. Les clès que l'on utilise sont toujours croissantes et il semble que leur map n'est pas d'algo d'auto équlibrage donc on avait une complexité observée en O(N) au lieu d'en avoir une annoncée moyenne en NxLog(N). Par contre sous NT et Solaris tout allait bien.
Ok c'est pas énorme comme bug, mais mon métier étant de faire des serveurs, les problèmes de perfs c'est imortant.

Ca tombe bien, les hash ne sont pas standards...

Citation:

---

Envoyé par BigNic

Citation:

---

Envoyé par Jean-Marc.Bourguet

Citation:

---

Envoyé par BigNic

pour les auto_ptr ça à l'air pas mal, mais je me méfie des la STL, devant faire du code multiplateforme (NT, linux, solaris, AIX) j'ai déjà eu des mauvaises surprises. Mais bon là je ne pense pas qu'il y est de PB.

---

Faisant du multiplateforme Solaris, AIX, HP-UX, Linux et utilisant la SL sans faire particulièrement attention, je me demande quel problèmes tu as rencontrés.

---

lors de l'utilisation d'un hash multimap map sous linux (RedHand entreprise) on a eu de grâves problème de perf. Les clès que l'on utilise sont toujours croissantes et il semble que leur map n'est pas d'algo d'auto équlibrage donc on avait une complexité observée en O(N) au lieu d'en avoir une annoncée moyenne en NxLog(N). Par contre sous NT et Solaris tout allait bien.
Ok c'est pas énorme comme bug, mais mon métier étant de faire des serveurs, les problèmes de perfs c'est imortant.

---

Si je recois de N quand je m'attends à du N log N, je suis content :-)

Je crois qu'on s'était mal compris. Je ne voulais pas écrire que je n'ai jamais vu de bugs la dedans, mais que je n'avais pas vu significativement plus de problèmes de portabilité avec la SL qu'avec le reste de la chaîne de compilation. En fait, les implémentations de la SL masquent même des différences entre compilateurs.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Je crois qu'on s'était mal compris. Je ne voulais pas écrire que je n'ai jamais vu de bugs la dedans, ...

---

Ou c'est peut-être moi qui me suis mal exprimé :)

Note pour plus tard: Relire mes posts pleins de fautes d'orhtographe et de grammaire, qui n'aident pas à la compréhension.

Effectivement je n'ai jamais vraiment eu de problème de portabilité de STL . Le seul vrai problème de portabilité que j'ai rencontré, en 2 ou 3 ans de C++, était un problème de fonctions template sous AIX qui n'était pas supportées si je me souviens bien.