views:

736

answers:

4

I have a method that requires a const char pointer as input (not null terminated). This is a requirement of a library (TinyXML) I'm using in my project. I get the input for this method from a string.c_str() method call.

Does this char pointer need to be deleted? The string goes out of scope immediately after the call completes; so the string should delete it with its destructor call, correct?

+8  A: 

The char array returned by string.c_str() is nul terminated. If tinyXML's function takes a not nul terminated char* buffer, then your probably gonna get some unexpected behaviour.

const char* c_str ( ) const;

Get C string equivalent

Generates a null-terminated sequence of characters (c-string) with the same content as the string object and returns it as a pointer to an array of characters.

A terminating null character is automatically appended.

No, it does not need to be released. String's destructor does that for you.

The returned array points to an internal location with the required storage space for this sequence of characters plus its terminating null-character, but the values in this array should not be modified in the program and are only granted to remain unchanged until the next call to a non-constant member function of the string object.

source: http://www.cplusplus.com/reference/string/string/c_str/

Tom
I doubt tiny XML's function would barf at a null terminated char*. After all, it's not as though the size can be determined just from the pointer. Also, if you have an arbitrary char*, it's possible the memory right after the memory you allocated has a null character. I have a feeling that Jack BeNimble was just trying to emphasize that the argument did not have to be a typical c string. (Ps - this is a different Tom from the poster :-) )
Tom
Lol, got very confused for a second or two :-) I was here first !!!It was strange for me too the fact that a method asks for a "not null terminated char pointer", that's why i asked for the name of Tiny xml's method. (this is Tom, the poster.)
Tom
Tom (the poster): Please edit your answer to remove the erroneous stuff about nul terminated strings. Then Tom (the different) can delete his comment, you can yours, and I can mine.
Ari
+10  A: 

Do not delete the memory you get from std::string::c_str. The string is responsible for that (and it is entirely possible it gave you a pointer to its internal buffer, so if you deleted it, that would be a bad thing (tm)).

Logan Capaldo
+4  A: 

On another note,
If you don't need to char pointer to be null terminated then you're better off to used str.data() rather than str.c_str(). The difference is that .data() doesn't grantee that what you get is going to be null terminated. This is useful if the your string just happens to occupy the entire length of the internal buffer allocated by string. In this case, calling .c_str() would force string to reallocate the date to a new bigger buffer, ones that contains enough space to add the '\0' in the end.

In any rate, ofcourse you shouldn't delete the pointer returned. string will take care of that.

shoosh
+1 because I like your point that you can save reallocation by calling .data(). I never realized that existed. I think I must have assumed that std::string always kept a null terminator in place for the call to c_str(). Good to know :-).
Tom
+1 Good point about reallocation.
Tom
+1  A: 

std::string.c_str() returns a pointer to a nul terminated string. The actual array of characters is still owned by the std::string object, and it is valid as long as:

  1. The std::string object is valid, and
  2. No calls to non-const member functions on the std::string object are made (i.e. modifying the string invalidates any previous C-style string pointed to).

It's up to the string object itself to allocate and release the nul terminated array-of-char it returns to you.

You can always use a nul-terminated string as a non-nul-terminated string. Afterall, a NTS is just a non-NTS with an extra zero at the end. As long as the string is correctly terminated as the function expects, it'll never see the "extra" nul. :)

Wuggy
Thanks Wuggy. I just posted that last point you made as a comment to (other) Tom's post.
Tom