C++ Programming :: Reference of the return value.


	Reference of the return value. Question about reference of the function return object. class A { public: std::string getString() const { return str_; } private: std:: string str_; }; function_ref(const A& a){ ... const std::string& str = a.getString(); //getString () return 'std::string' not 'const std:string&', cout << "Text is: " << str; //use str here will be OK ... } function_point(const A& a) { ... const std::string* pStr = &a.getString(); //the return object of 'std::string' will destruct here cout << "Text is: " << pStr; //so using 'pStr' here may cause a crash ... } My question is if there had any problem with reference of the function return object, because 'a.getString()' just return a temp object. After I debugged this in VS2003, I found that the temp object will be destroyed at the end of this function. 'function_ref(const A& a)' will be running without any problem in VS2003 but 'function_point(const A& a)' may cause error. I want to ask if that reference of a temp return value delay the destruction is just a property of MS VS2003 or C++ standard. sss.z@gmail.com wrote: > My question is if there had any problem with reference of the > function return object, because 'a.getString()' just return a temp > object. No. The return is a temporary rvalue. If you bind it to a const reference it will live as long as the reference. Pointers, however, have no inteligence about what they refer to. The temporary rvalue from the return, when not bound to a reference, is destroyed at the end of the full expression it is created in. In this case, it's history as soon as the initialization of the pointer takes place. > No. The return is a temporary rvalue. If you bind it to a const > reference it will live as long as the reference. > Pointers, however, have no inteligence about what they refer to. > The temporary rvalue from the return, when not bound to a reference, > is destroyed at the end of the full expression it is created in. > In this case, it's history as soon as the initialization of the > pointer takes place. Thanks for you help. You answers let me know a concept of lvalue and rvalue. So const reference to a temporary rvalue can be using a concept of the c++ standard, not the VS2003 property, and this is another difference between the reference and the pointer. Ron Natalie wrote: > No. The return is a temporary rvalue. If you bind it to a const > reference it will live as long as the reference. Is this also true for const references as member variables? If I try this, it compiles without warnings but causes a segmentation fault (at least with gcc 3.3): #include <iostream> #include <string> class A { const std::string& s; public: A(): s("test2") {} void print() { std::cout << s << std::endl; } }; int main() { A a; a.print(); - Hide quoted text - } - Hide quoted text - Juha Nieminen <nos@thanks.invalid> wrote in message... > Ron Natalie wrote: > > No. The return is a temporary rvalue. If you bind it to a const > > reference it will live as long as the reference. > Is this also true for const references as member variables? If I try > this, it compiles without warnings but causes a segmentation fault > (at least with gcc 3.3): > #include <iostream> > #include <string> > class A{ > const std::string& s; > public: > A(): s("test2") {} > void print() { std::cout << s << std::endl; } > }; > int main(){ > A a; > a.print(); > } Think about what you are initializing the reference to. std::string &rs( "Hi There" ); // Error: could not convert `"Hi There"' to `std::string&' class A{ std::string s; const std::string &rs; public: A(): s( "test2" ), rs( s ){} void print() { std::cout << rs << std::endl;} }; int main(){ A a; a.print(); } -- Bob R POVrookie - Hide quoted text - BobR wrote in message... > Juha Nieminen <nos@thanks.invalid> wrote in message... > > Ron Natalie wrote: > > > No. The return is a temporary rvalue. If you bind it to a const > > > reference it will live as long as the reference. > > Is this also true for const references as member variables? If I try > > this, it compiles without warnings but causes a segmentation fault > > (at least with gcc 3.3): > > #include <iostream> > > #include <string> > > class A{ > > const std::string& s; > > public: > > A(): s("test2") {} > > void print() { std::cout << s << std::endl; } > > }; > > int main(){ > > A a; > > a.print(); > > } > Think about what you are initializing the reference to. > std::string &rs( "Hi There" ); > // Error: could not convert `"Hi There"' to `std::string&' > class A{ > std::string s; > const std::string &rs; > public: > A(): s( "test2" ), rs( s ){} > void print() { std::cout << rs << std::endl;} > }; > int main(){ > A a; > a.print(); > } Oooops, sorry Juha. I see what you were doing now. I forgot Murphy's [net] Laws - Never post while on your first cup of coffee! Oh well, maybe my example will help some newbie. -- Bob R POVrookie Juha Nieminen wrote: > Ron Natalie wrote: >> No. The return is a temporary rvalue. If you bind it to a const >> reference it will live as long as the reference. > Is this also true for const references as member variables? If I try > this, it compiles without warnings but causes a segmentation fault > (at least with gcc 3.3): No. Easy test code attached. #include <iostream> template <int N> struct X { X() { std::cout << "X<" << N << ">::X()\n"; } ~X() { std::cout << "X<" << N << ">::~X()\n"; } }; struct A { const X<1> & x; A() : x( X<1>() ) { std::cout << "A::A()\n"; } ~A() { std::cout << "A::~A()\n"; } }; int main() { const X<2> & x2 = X<2>(); A a; - Hide quoted text - } Gianni Mariani wrote: > Juha Nieminen wrote: >> Is this also true for const references as member variables? > No. Why doesn't gcc issue at least a warning? It's assigning a temporary to the reference. Can't it see that in this case it will cause misbehavior? Juha Nieminen wrote: > Gianni Mariani wrote: >> Juha Nieminen wrote: >>> Is this also true for const references as member variables? >> No. > Why doesn't gcc issue at least a warning? It's assigning a temporary > to the reference. Can't it see that in this case it will cause misbehavior? That's a good suggestion. I'd probably file a bug with GCC and see what happens.