No, I don't see the difference. Memory block returned by .data() doesn't need to be freed either and pointer is made invalid when the string is deleted.

Dustin, that's sort of my problem, but not really -- and it IS present in GCC. It's not really the compilers fault though. You can't use the char * returned from data or c_str after the object has gone out of scope!

No, sprintf works just fine, and will put a Null Terminator at the end of your string for you; What happens with Dustin's example is that he's declaring a string that goes out of scope (and the internal data is therefore freed) before he even does anything with it. It probably only works in GCC 95% of the time because the pointer is freed before it passes the data on to the next consumer, and the next consumer is just getting lucky the majority of the time that the same data is still there.

I have noticed though that MSVC is amazing as far as what it lets me do with OOP as opposed to GCC which just finds endless reasons to complain at me for really obscure things. :-(

Yeah, that was polite.

Look, I understand you hate MSVC, but it's just not the problem I'm having. MSVC has proven to be just as good as, if not better than GCC to me. The problem I had occured in GCC also, and it makes plain sense: You can't use pointers to structures/classes (or to members of such structures/classes) that have been freed/deleted (which happens automatically to an object on the stack when it goes out of scope...) You just can't.

The compiler can't do things like "MyFunction((4+x) * c)", or "MyFunction(x(), y(), z())"
it rearranges the code so you end up with things like

temp = 4 + x;
temp *= c;
MyFunction(temp)

or

temp1 = x();
temp2 = y();
temp3 = z();
MyFunction(temp1, temp2, temp3);

In your example you create a string by passing in a char * (we'll call it A)
that string creates another char * of it's own (we'll call it B), and then copies the contents of A into B...

The compiler reorganizes your code for optimization of course, and the last point in time that you use your variable that was allocated on the stack, it gets popped off (it's destructor is called and it's memory is freed.)

The function that you're passing B into (Well call this F) needs a reference to B of course, which is gotten right before F is called. Once it has the pointer to B returned by c_str, the string is no longer needed and it's popped off the stack, it's destructor is called, and in the process B is freed, then the function is called and the pointer to B (now freed) is passed in. Just because you have a pointer to a piece of data inside an object does not mean that the object won't get popped off the stack after it's last usage. If it's an object you allocated, THEN it won't be deallocated until you delete it, but if it's on the stack the compiler can reorder when it's destructor is called freely to anywhere after it's last usage.

It all makes perfect sense, here's what I believe to be the equivalent:

char * myref = (char*)malloc(100); // creating the new string (B)
sprintf(myref, "Something"); //creating the new string (copying A into B)
char * temp = myref; //The object's function returned a reference to B 
                     // that we can pass in to F (c_str is called)
free(myref);  //Call the object's destructor since it's 
              // not used again after this point... (B is freed)
MyFunction(temp); //call our function (F) now passing in a reference to B.

You understand exactly what I meant KC (and Actually I wouldn't be surpirsed if you knew about some obscure C standard that said it should be one way or the other -- I have quite a high opinion of you...)

As far as I can guess #2 in your example would be what MSVC might be up to, while #1 is what GCC could be doing. From the information provided in this thread I would assume that the MSVC optimizer tries to remove objects from the stack the first chance it gets (optimized for low memory consumption?) while the GCC one let's the stagnate until right before the scope is lost (optimized for speed)?

For other readers I just want to emphasize the huge difference between:

MyFunction(string("Xyz"));

And

MyFunction(string("Xyz").c_str());

In the second function the string is declared (aparently) in the scope of the actual function call, and since you only need the result of one of the object's deterministic functions in order to call MyFunction, once the result is had, you would ideally no longer need the initial object (the string).

Your words are getting more passionate, maybe you believe you can make something true by saying it more?

Your passion is keeping you from seeing the bigger picture. Rules defined by a particular language or compiler are simply that, just rules. There is no hand of god enforcing them and you don't even have to agree with them.

I would like to challenge your statement by saying this: Why must the returned string be a "members of such structures/classes". What rule defines this, and where did it come from?

Buh? Are you fucking mad? Who taught you to program?

the standard string class is just implemented that way -- it has an internal pointer to a char *.

When a string class is destructed (you can delete it, or it can fall off the stack) the char * is freed. No one forced them to do it that way, it just WAS done that way, and now you have to live with it.

When you pass a reference to that char * into your function, a reference to a char * that has already been freed, the old data is not guaranteed to be there. It's not safe.

Me having passion for my hobby has nothing to do with it -- I think you're projecting though. Maybe you believe you can make something true by saying complete nonsense. That's your deal, count me out. -- The whole C++ standard is defined somewhere -- I think the last one was in the 90s the next one is comming out in 2009 (or so they say)... -- If you really need proof of concept go look it up -- as for me, my code works in GCC and MSVC.

But is it the same order in every compiler? ... Someone posted some really neat code a while back that produced different results on different compilers because the C standards didn't specify an order for something and each compiler was doing it it's own way. I found it really interesting.

The order is prescribed by the standard. In my experience gcc-3.x and newer and MSVC8 use the order of how the members are declared. My code highly relies on the order of initialization and never had problem with it. Moreover, some things cannot be written without knowing the order, like a class with all const members.

If that's your argument then it has nothing to do with the compiler anyway, it's your standard library. My point is, something has to free the memory returned by c_str somewhere if it's allocated somewhere otherwise you'd get memory leaks. Microsoft does it in a perfectly logical place, the destructor. It's really a horrible practice to retain a pointer to something an object gave you after the object is disposed especially if it's not documented to work like that.

Let me ask you this Dustin: If there's no standard defining where the pointer should go(what scope it should have), or when it's allocated/destroyed, then why write code that's dependent on your STL being implemented one undocumented way over another? This game of yours is dumb, if this is what you had meant the whole time then you should have just came out and said it. I now think you a far bit less insane than I thought you to be last night, but I also now know that you're talking about something completely different.

I stepped through the disposing of a basic_string and _Tidy is called in the destructor which deallocates "any storage" -- in the MSVC version. (_Built = true, _Newsize = 0).

Further more, supporting Dustin's claims:

  char * m = NULL;
  {
    string x = "42";
    m = (char*)x.c_str();
  }

  printf("%s\n", m);

Works in GCC (g++ -v = 3.4.2), but not MSVC 8. Though there's no guarantee that it will work in any given compiler, because as Dustin pointed out, there is no rule or standard that says that what c_str returns can't be destroyed in x's destructor.

Simple non-reentrant C. If the user wants to keep the string around after the call, he should make a copy.

And yes, you can use your std::string and keep that as the static variable instead.

I was writing a function that overloads a virtual in the base class that returns a char * (I had no control over that.)

I have new methods that return strings, but for the old methods to work, they have to return char *, I decided that I'd just keep the string around as a private variable for the class, which works great.

Exactly. That's all I'm trying to say. Just because version X of GCC's standard library lets you do it doesn't mean it's a good thing.

Well there you have it

when you call function F, each term is evaluated independently BEFORE the function is called.

Example:

F(x(), y(), z());

is rendered as:

t1 = x();
t2 = y();
t3 = z();
F(t1,t2,t3);

Wow, and I thought that was a smoking gun. KC you're a badass.

So, to bring my ignorance to it's full measure: what else are commas used for in C++ besides parameter lists? I really can't think of anything... maybe when initializing arrays or something...

edit:
so in my above example I got the order wrong, it should be:

Example:

F(x(), y(), z());

is rendered as:

t3 = z();
t2 = y();
t1 = x();
F(t1, t2, t3);

no?