If you create a std::string inside of your function, and then you return its .c_str(), you should simply be able to use:

const char *theFunction(void)
{
   string myString;
   myString = "Groovy, baby!";
   return (myString.c_str());
}

That will copy "myString" into a specific address, which you will be able to address when the function returns. However, I'm not certain if simply <b>char theFunction() would work or if you need to declare the <b>char pointer a const: <b>const char theFunction().

Well, if you want to do it that way...

char *theFunction(void)
{
   string myString = "Groovy!";
   char *theResult = new char[myString.size()];
   return theResult;
}

This results in a new without the matching delete, so like Milan said, you'd have to document that the end-programmer will have to free that memory.

Heh, not quite. You're returning an uninitialized memory block. Here is the right way to do this dumb function:

char *theFunction(void)
{
   std::string myString = "Groovy!";
   return strdup(myString.c_str());
}

Now you have to free() the memory. It is important to note whether to use free() or delete to free the memory.

IMO, the better way to do it is to avoid C strings at all, if possible.

It was just an example... anyway strdup is easier.

What I've decided to do, is that the class will keep an internal pointer to the string it returns, and upon disopsale, or a request for a new string, it frees the old one.

edit: Yeah, it has to return it, I'm attempting to write a virtual function that overloads a base class function (unsucessfully) -- or I'd just return a string. I do like that static version though.

edit: ack, all bad -- all bad. -- multiple callers == death.

:: smacks forehead ::

In standard c++ there is a type of pointer that knows who owns it and when it can delete itself (when the owner goes out of scope). It is called auto_ptr. Note: there can only be one owner at a time. Otherwise it works like a regular pointer.

http://www.gotw.ca/publications/using_auto_ptr_effectively.htm

The solution to this problem is to stop using MSVC and start using GCC. MSVC just sucks like that.

char buf[256];

sprintf(buf, "%s", string("test").c_str());

buf[255] = 0;

printf("%s", buf);

Assuming above is the issue you're talking about I've run into it and dealt with it.

In my tests MSVC seems to print out garbage, while gcc does what you'd hope for.

Possibly you tried this on a version of gcc more immature then mine?

I'm using gcc version 3.4.2 (mingw-special)

_{**Fixed print_r to be printf (man I've done too much php coding lately :o ).}

On a complete tangent, I've found this issue very annoying:

int i;
istringstream("5") >> i;
printf("%d", i);

Earlier versions of gcc can't handle this code.. The workaround is to name the instance of istringstream. I find this work-around very ugly .

Thats exactly the same, but requires three extra hard to reach key strokes.

Yeah thats just a check so MSVC doesn't crash when it tries to output the string. Not really the point of the excerise, just a cleaning operation.

You post too fast .

So the problem is that sprintf() doesn't put '\0' at the end, or is printf() ignoring it for some reason?

You should use snprintf anyway. But I guess that setting the last thing to zero is a fix in case you overflow the string or hit the end, or something. I vaguely recall having to do something similar at one time, but I've since moved to less primitive, more civilized languages, so I forgot why I had to do such an ugly thing.

[edit]
Why would you want to have something like that? If it was anonymous, it could go out of scope at anytime, leaving that c_str() dangling.

Clean code can handle possible situations it will go into. In this respect GCC's string::c_str has cleaner code then MSVC's string::c_str as far as handling edge cases goes.

Things like this make me like GCC better then MSVC. You'd think this is a rarely used edge case, but I use this functionality all the time.