Heap/stack, RVO, and destructors

Question

yes, wonderful topic name...
I always wondered if the following (c++) code would work:
std::string& foo()
std::string* s = new std::string("bar");
return *s;
void test()
std::string s = foo();
} //does s get properly destroied here?
the problem is as follows:
in test(), s is declared as a stack (auto) variable...
in foo(), s is created on the heap, and returned by reference, instead of by pointer...
technically, this code is sound... however I don't know if proper destruction takes place... will RVO (return value optimization) take care of it?

Answer 1

i3839 wrote:Perhaps I'm missing some hidden magick of references, but you said they were the same as pointers, and you made a new object and got a reference, no pointer in sight, so how can you blame pointers?
that's excatly it... "new" returns a pointer... technically one should just [return string("foo");] without the "new" - and RVO then takes the construction into account so it's not done twice (once on the return line, then a copy constructor when the actual return does it's job)
i3839 wrote:As for the memory management, what "internal memory management"? If you get data with new you need to free it yourself, either directly or indirectly (delete(this)?). All the memory management needs to be build into the classes as far as I can tell, or did C++ change so much recently?
I was talking specifically about the STL... which is C++, as much as some people don't like to admit... anyone can write a class that has resource issues in general... hell you can do it with database connections in java (and C#)
When you initialize an std::string, it calls new internally... and actually stores just the begin/end pointers, but it takes care or it's own resources...
the pseudo-techincal term is "RAII" (Resource Acquisition is Initialization) - constructor calls new, destructor deletes... it's all internal... when consuming that class, you never need worry about memory management if done correctly.