Returning reference to STL String class

Im trying to refresh my c++ skills.. its been years and Im a little confused if this is OK or not.
I know you shouldn't return local variables, but I've seen this done before. Does the string class allocate its internal memory on the heap and so its ok.. thus returning just a pointer to the heap allocated object?

Code:

---

typedef std::string String;

//Is this ok? why?
String GetSomeString() {
  String ret;

  ret="bipbip";
  return ret;
}


//How does this differ.. can this lead to any memory corruption?
//If I just use the returned value as a check..
//if(GetSomeString=="bipbip")....
String GetSomeString() {
  return "bipbip";
}

---

Thanks!
Adam

both are fine and are equivalent. The trap you are trying not to fall into is returning a refernece to a local object. Code below demonstrates the flaw you should not fall into.

Code:

---

std::string&  flawfunc()
{
  std::string retval;
  return retval;
}

---

Here i make a new std::string object then return a refernce to it as it gets deleted. So the calling function has a reference to a dead object. Dont do this.

Thanks for the reply.
So is a copy of the string object being performed when its returned in my case? I see the only differences are your function is defined as returning the & whereas Im returning a string object.
Now if my object is being copied and then returned, can't you run into other problems with this (I seem to remember something about virtual functions getting goofy on copied objects).

Yes you could but std::string is designed as a value type so there will be no trouble bar the efficiency loss of creating temporaries and copying.There should be no trouble with slicing anyway.

Quote:

---

I know you shouldn't return local variables, but I've seen this done before.

---

That is nothing wrong with it. If it is a user defined datatype a copy (the copy-constructor is invoked) is returned. The memory allocation/deallocation is maintained automatically by the string class, no worry there for memory leak.

In the second example it´s more trickier because of the conversion mechanism. I think that that code snippet will compile (not recommended). The string class also supports operator overloading for operator==(const string&) and operator==(const char*) for backward compability. No memory leak is suffered.

it all makes sense now. Thanks everyone.