[bug] Initialisation invalide d'une référence non const à partir d'un temporaire.

bonjour.

J'ai défini une petite classe comme suit:

Code:

---

1 2 3 4 5 6 7 8 9 10

class solid_pos: public point { angle<SOLID_ANGLE_PREC> dir;   public: solid_pos(const point & pt=point(),angle<SOLID_ANGLE_PREC> agl=angle<SOLID_ANGLE_PREC>()); solid_pos(const solid_pos & pos); inline solid_pos & operator-()const;   };

---

or dans l'implémentation de operator -:

Code:

---

1 2 3 4

inline solid_pos & solid_pos::operator-()const { return solid_pos(point::operator-(),-dir); //plante ici }

---

il me fait l'erreur suivante sur le return:

Citation:

---

...solid_pos.h|28|erreur: invalid initialization of non-const reference of type ‘solid_pos&’ from a temporary of type ‘solid_pos’|

---

ce que j'ai du mal à comprendre vu qu'une référence doit forcément s'initialiser à partir d'un objet...

bref, un éclairement serait bienvenu.


merci.

Tu ne peux pas retourner une référence sur un objet qui n'existe plus.

Par contre, tu peux retourner une référence sur un objet constant, car le C++ s'arrange pour ne pas le supprimer tant <wrong>qu'il y a une référence dessus.</wrong> que la référence constante est en vie.

Citation:

---

Envoyé par hiura

Tu ne peux pas retourner une référence sur un objet qui n'existe plus.

Par contre, tu peux retourner une référence sur un objet constant, car le C++ s'arrange pour ne pas le supprimer tant qu'il y a une référence dessus.

---

heu, qu'apelle-tu exactement un objet constant ? un objet revoyé avec une fonction const ? si oui, c'est déjà le cas...

Citation:

---

Envoyé par hiura

car le C++ s'arrange pour ne pas le supprimer tant qu'il y a une référence dessus.

---

Le C++ Aurait-il un ramasse miettes ?

Citation:

---

Envoyé par méphistopheles

heu, qu'apelle-tu exactement un objet constant ? un objet revoyé avec une fonction const ? si oui, c'est déjà le cas...

---

Non, mais par une fonction qui retourne un objet const :

Code:

---

const T& f(...);

---

Citation:

---

Envoyé par Lucien63

Le C++ Aurait-il un ramasse miettes ?

---

J'avais lu le principe du ramasse miettes y a vraiment longtemps, mais d'après ce que je me souviens il ne s'agit pas de ça.
Soit le code :

Code:

---

1 2 3 4

T f(void); void g(void) { const T& = f(); } // T est détruit, l'objet auquel il fait référence aussi.

---

Le C++ va, dans ce cas particulier, garder en mémoire l'objet const retourné par f en mémoire et le détruire que quand la référence sera détruite.

Lire http://herbsutter.wordpress.com/2008...portant-const/

EDIT : ce code est faux, voir mon prochain message ( bien plus bas ) .

Code:

---

1 2 3 4 5

T f(void); void g(void) { const T& = f(); // ou est le type et ou est le nom de la variable ? } // T est détruit, l'objet auquel il fait référence aussi.

---

T est un type ou une variable ?

Citation:

---

T est détruit, l'objet auquel il fait référence aussi

---

Par quel artifice l'objet est-il détruit ?

T est un type.
La portée.

Citation:

---

Envoyé par Lucien63

Le C++ Aurait-il un ramasse miettes ?

---

Pas du tout..

Citation:

---

Envoyé par Goten

Citation:

---

Envoyé par Lucien63

Le C++ Aurait-il un ramasse miettes ?

---

Pas du tout.

---

Ça je savais, mais je disais cela en rapport à la reponse de hiura.
Car je n'ai jamais vu que la destruction de toutes les références sur un objet fesait que c++ détruisait l'objet auquel elle fesaient références.

Citation:

---

Envoyé par loufoque

Citation:

---

Envoyé par Lucien63

T est un type ou une variable ?

---

T est un type.

---

Je m'en doutais, mais je ne savait pas "que l'on pouvait détruire un Type" :

Citation:

---

Envoyé par hiura

// T est détruit,

---

C'est pour cela que je posait la question !

Citation:

---

La portée

---

Idem que plus haut. La variable référence est détruite ok, mais comment peut tu dire que l'objet auquel elle fait référence est détruit ?

T'a lu le gotw qu'a donné de hiura?

tout est expliqué :

Citation:

---

However, C++ deliberately specifies that binding a temporary object to a reference to const on the stack lengthens the lifetime of the temporary to the lifetime of the reference itself

---

C'est une feature du C++..

J'ai été un peu vite,

Code:

---

1 2 3 4

T f(void); void g(void) { const T& = f(); } // T est détruit, l'objet auquel il fait référence aussi.

---

Dans ce contexe là oui car l'objet retourné par f est une copie.

Ce qui m'a induit en erreur c'est le premier prototype de la fonction

Citation:

---

Non, mais par une fonction qui retourne un objet const :

Code:

---

const T& f(...);

---

---

Dans ce cas c'est tout a fait different.

Salut,

La règle est simple: tout objet est détruit lorsque l'on quitte la portée dans laquelle il a été déclaré, exception fait du cas où il est renvoyé par valeur (c'est à dire, pas par référence ni référence constante).

La portée dans laquelle un objet est déclaré est définie par la paire d'accolade où se trouve la déclaration de l'objet, c'est à dire n'importe quel bloc d'instruction faisant partie de l'implémentation d'une fonction.

Pour les membres de classes et de structures, ils sont détruit au moment où l'objet du type de la classe ou de la structure est détruite (au moment où l'on quitte la portée dans laquelle l'objet du type de la structure ou de la classe est déclaré).

C'est à dire que, parmis les trois fonctions suivantes, seule la première est autorisée

Code:

---

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

Type foo(/* parametres */ ) { return Type(/* parametres */); } Type& badFoo(/* parametres */ ) { return Type(/* parametres */); /* KO: renvoie une référence sur un objet   * qui est détruit lorsque l'on passe   * l'accolade fermante   */ } Type const& badFoo2(/* parametres */ ) { return Type(/* parametres */); /* KO: renvoie une référence constante   * sur un objet qui est détruit   * lorsque l'on passe l'accolade fermante   */ }

---

Par contre, le code suivant serait accepté, car l'objet renvoyé est un membre (d'un membre) de la classe:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class MaClass { public: Type& createType(/* parametres */) { tab.push_back(Type(/*parametres*/)); return *(tab.rbegin()); } private: std::vector<Type> tab; };

---

voire, le code suivant, s'il est opportun de l'envisager:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class MaClass { public: Type& createType(/* parametres */) { elem= new Type(/* parametres */); return *elem; } private: Type* elem; };

---

Dans le cadre de l'opérateur "-", tu renvoie un objet qui n'est pas ton objet d'origine, tu dois donc le renvoyer par valeur, et non par référence:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class solid_pos: public point { angle<SOLID_ANGLE_PREC> dir;   public: solid_pos(const point & pt=point(), angle<SOLID_ANGLE_PREC> agl=angle<SOLID_ANGLE_PREC>()); solid_pos(const solid_pos & pos); inline solid_pos operator-()const;   }; inline solid_pos solid_pos::operator-()const { return solid_pos(point::operator-(),-dir); //plante ici }

---

par contre, pour l'opérateur -=, s'il est opportun de les définir, tu renverra en réalité ton objet d'origine modifié, et tu peux donc le renvoyer par référence ;)

Code:

---

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

class solid_pos: public point { angle<SOLID_ANGLE_PREC> dir;   public: solid_pos(const point & pt=point(), angle<SOLID_ANGLE_PREC> agl=angle<SOLID_ANGLE_PREC>()); solid_pos(const solid_pos & pos); inline solid_pos operator-=()const;   }; inline solid_pos & solid_pos::operator-=(solid_pos const & rhs) { /* la logique pour appliquer l'opérateur */ return *this }

---

merci beaucoup, je ne sait pas ce que j'avais quand j'ai codé ça, mais je n'était pas tres en forme.

en me levant ce matin, le problème m'a paru évident.


merci encore.

Oulà ! Je devais vraiment être fatigué quand j'ai écrit le code avant ! Il manque effectivement qqch :

Code:

---

1 2 3 4

T f(void); void g(void) { const T& var = f(); // <- oubli du nom de la variable, ne compilait pas. } // var est détruit, l'objet auquel il fait référence aussi.

---

Mea-culpa.

Citation:

---

Envoyé par koala01

Salut,
La règle est simple: tout objet est détruit lorsque l'on quitte la portée dans laquelle il a été déclaré, exception fait du cas où il est renvoyé par valeur (c'est à dire, pas par référence ni référence constante).

---

Pinaillons. :mrgreen:
La règle est même encore plus simple :
Tout objet est détruit lorsque l'on quitte la portée dans laquelle il a été déclaré, sans aucune exception.

Dans le cas d'un retour par valeur, c'est une copie temporaire qui est renvoyée. :D

Citation:

---

Tout objet est détruit lorsque l'on quitte la portée dans laquelle il a été déclaré, sans aucune exception.

---

Ben justement, si, il y a une exception, le cas de l'affectation d'une référence const à cet objet, qui étend sa portée ;).

car la référence n'est pas un objet, mais un lien vers l'objet

Non, l'objet local à la fonction est bien détruit en sortant de la portée.
Par contre c'est vrai que la copie temporaire qui devait être détruite à la fin de l'instruction ("au point virgule") voit sa vie prolongée dans le cas d'une liaison à une référence constante....

Bon ok, j'amende. :cry:

"Tout objet est détruit lorsque l'on quitte la portée dans laquelle il a été déclaré, sauf les objets temporaires (rvalue) liés à des références constantes. Dans ce cas la durée de vie du temporaire s'étend à celle de la référence."

Là ça devrait être bon non ?

Et pourtant:
avec le code (basique je l'admet)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

class Test { public: Test(){cout<<"ctor"<<endl;} Test(Test const&){cout<<"copy ctor"<<endl;} Test& operator=(Test const&) { cout<<"assignment"<<endl; return *this; } ~Test(){cout<<"dtor"<<endl;} }; Test foo() { Test t; return t; }   int main() { cout<<"recuperons l'objet par valeur"<<endl; Test t=foo(); cout<<"et maintenant par reference constante"<<endl; Test const & r=foo(); cout<<"fin du test et destruction"<<endl; return 0; }

---

j'obtiens comme seul affichage:

Code:

---

1 2 3 4 5 6 7

recuperons l'objet par valeur ctor et maintenant par reference constante ctor fin du test et destruction dtor dtor

---

(Gcc 4.4.0, Code::blocks, win XP SP3, sans gestion NRVO)

Ce qui semble confirmer que l'objet n'est ni détruit, ni copié dans foo() ;)

Faut faire gaffe pour le premier, le compilo peut assigner directement main::t à foo:t suivant comment il travaille.

Citation:

---

Envoyé par hiura

Faut faire gaffe pour le premier, le compilo peut assigner directement main::t à foo:t suivant comment il travaille.

---

C'est bien pour cela que j'ai donné les informations qui permettent de reproduire le comportement observé, et que j'ai pris toutes les précautions d'usage afin d'établir le fait que je ne me base ici que sur une observation, qui peut être dépendante de l'implémentation

(je pourrais aussi avoir recours à la norme, mais j'avoue avoir la flemme aujourd'hui :P:aie:)

J'ai testé ton code avec codeblock gcc et j'obtiens le même résultat.
Puis je l'ai testé avec BCB et là le résultat est différent :

Citation:

---

recuperons l'objet par valeur
ctor
copy ctor
dtor
et maintenant par reference constante
ctor
copy ctor
dtor
fin du test et destruction
dtor
dtor

---

Ce résultat me semble plus coherant.

Vérification faite, ce comportement est laissé à discrétion de l'implémentation

Citation:

---

Envoyé par la norme chapitre 6.6.3 return statment

A return statement without an expression can be used only in functions that do not return a value, that is, a
function with the return type void, a constructor (12.1), or a destructor (12.4). A return statement with an expression of non-void type can be used only in functions returning a value; the value of the expression is returned to the caller of the function. The expression is implicitly converted to the return type of the function in which it appears. A return statement can involve the construction and copy of a temporary object (12.2). Flowing off the end of a function is equivalent to a return with no value; this results in undefined
behavior in a value-returning function.

---

(le point important étant l'usage de can et non de must;))

Citation:

---

Envoyé par la norme, chapitre 12.8 Copying class objects, §15

When certain criteria are met, an implementation is allowed to omit the copy construction of a class object, even if the copy constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization.111) This elision of copy operations is permitted in the following circumstances (which may be combined to eliminate multiple copies):
— in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object with the same cv-unqualified type as the function return type, the copy operation can be omitted by constructing the automatic object directly into the function’s return value
<snip>

---

En deux mots, personne n'a tout à fait tord... ni tout à fait raison ;)

Les deux comportements sont parfaitement admis :D

A la réflexion, je trouve même que le comportement qui permet d'éviter la copie de l'objet renvoyé est beaucoup plus logique dés qu'il s'agit de structures ou de classes:

Pour un type primitif, on peut effectivement estimer que la copie ne pose pas trop de problème, ni en temps ni en utilisation de la mémoire, mais, pour une classe ou une structure:

La copie peut être très couteuse en temps et en mémoire
que faire avec une classe non copiable :question:

Cela veut-il dire que nous ne pourrions pas écrire un code proche de :question:

Code:

---

1 2 3 4 5 6 7

NonCopiable foo(/* parametres */) { /* tests de validités des paramètres */ NonCopiable t(/* parametres*/); return t; }

---

Ca promettrait du plaisir :aie: (car nous serions tenu de la créer dynamiquement ou de la renvoyer par référence... mais est-ce seulement opportun :question:)

Citation:

---

Envoyé par koala01

Cela veut-il dire que nous ne pourrions pas écrire un code proche de :question:

---

Oui. J'ai fait quelque tests avec MinGW ( basé sur gcc 3.4 ) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

class NC { NC(const NC&); NC& operator=(const NC&); public : NC() { } };   NC a(void) { return NC(); // error: `NC::NC(const NC&)' is private }   NC& b(void) { return NC(); // error: invalid initialization of non-const reference of type 'NC&' from a temporary of type 'NC' }   const NC& c(void) { return NC(); // error: `NC::NC(const NC&)' is private // warning: returning reference to temporary }   const NC d(void) { return NC(); // error: `NC::NC(const NC&)' is private }   NC e(void) { NC t; return t; // error: `NC::NC(const NC&)' is private }   NC& f(void) { NC t; // warning: reference to local variable `t' returned return t; }   const NC& g(void) { NC t; // warning: reference to local variable `t' returned return t; }   const NC h(void) { NC t; return t; // error: `NC::NC(const NC&)' is private }

---

Seul f et g fonctionne. Mais je me suis pas encore intéressé à " ces variables retournées peuvent-elles être utilisées ? "

J'ai été un peu plus loin :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

class NCs { NCs(const NCs&); NCs& operator=(const NCs&); public : NCs(int i) : _i(i) { } int _i; };   NCs& fs(void) { NCs t(42); // warning: reference to local variable `t' returned return t; }   const NCs& gs(void) { NCs t(42); // warning: reference to local variable `t' returned return t; }   int main() { std::cout << "Hello world!" << std::endl;   NCs x1 = fs(); // error: `NCs::NCs(const NCs&)' is private NCs x2 = gs(); // error: `NCs::NCs(const NCs&)' is private   NCs& x3 = fs(); NCs& x4 = gs(); // error: invalid initialization of reference of type 'NCs&' from expression of type 'const NCs'   const NCs& x5 = fs(); const NCs& x6 = gs();     std::cout << x3._i << '\n' << x5._i << '\n' << x6._i << std::endl; /*   Sortie : 2293472 2293472 2293472   Par contre, si dans fs et/ou gs on place un std::cout la sortie est bien : 42 42 42   A ajouter ( par exemple ) : std::cout << "";   */   const NCs x7 = fs(); // error: `NCs::NCs(const NCs&)' is private const NCs x8 = gs(); // error: `NCs::NCs(const NCs&)' is private   return 0; }

---

Mais je viens de réaliser que le comportement change assez brutalement rien qu'en changeant les options d'optimisations ! Ci-dessus c'est les remarques avec -O2, mais si je mets -O3 je n'ai aucun problème.

Citation:

---

Envoyé par koala01

Et pourtant:
avec le code (basique je l'admet)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

class Test { public: Test(){cout<<"ctor"<<endl;} Test(Test const&){cout<<"copy ctor"<<endl;} Test& operator=(Test const&) { cout<<"assignment"<<endl; return *this; } ~Test(){cout<<"dtor"<<endl;} }; Test foo() { Test t; return t; }   int main() { cout<<"recuperons l'objet par valeur"<<endl; Test t=foo(); cout<<"et maintenant par reference constante"<<endl; Test const & r=foo(); cout<<"fin du test et destruction"<<endl; return 0; }

---

j'obtiens comme seul affichage:

Code:

---

1 2 3 4 5 6 7

recuperons l'objet par valeur ctor et maintenant par reference constante ctor fin du test et destruction dtor dtor

---

(Gcc 4.4.0, Code::blocks, win XP SP3, sans gestion NRVO)

Ce qui semble confirmer que l'objet n'est ni détruit, ni copié dans foo() ;)

---

Sans NRVO on devrait plutôt obtenir quelque chose comme ça :

Citation:

---

recuperons l'objet par valeur
ctor
copy ctor
dtor
copy ctor
dtor
et maintenant par reference constante
ctor
copy ctor
dtor
fin du test et destruction
dtor
dtor

---

En C++03, la conversion d'une rvalue en lvalue requiert la possibilité de copier le type.