about c_str()

[matish]

Hi,

in:

string s("Hi");
const char* c = s.c_str();

how long will the pointed cstring live?
I see that calling delete c or delete []c fail, that the cstring survives
the end of the scope in witch it is decleard and even delete s does not
destroy it (I thougth c could be a pointer to some internal buffer of s,
but it seems not to be the case).

So, what should one do after having created a char* with c_str()? Delete it
in some way or leave it there?

Thanks

 

[Tomás]

matish posted:

Hi,

in:

string s("Hi");
const char* c = s.c_str();

how long will the pointed cstring live?

The object pointed to by "c" is valid until "s" goes out of scope.

I see that calling delete c or delete []c fail

A lot of Undefined Behaviour fails. There's no reason to call "delete" on
what "c" points to, because it was never dynamically allocated with
"new" (or if it was, then it's still not your responsibility to delete
it).

So, what should one do after having created a char* with c_str()?

Absolutely nothing. The following is okay.

#include <string>
using std::string;

int main()
{
string s("Hi");

const char * const p = s.c_str();
}


-Tomás

 

[Christopher Benson-Manica]

The object pointed to by "c" is valid until "s" goes out of scope.

Or until a non-const operation is performed on s, yes?

 

[Larry I Smith]

Or until a non-const operation is performed on s, yes?

Yes. If you change 's' in any way, 'c' becomes invalid.

 

[Jim Langston]

Hi,

in:

string s("Hi");
const char* c = s.c_str();

You are making c point to the internal buffer in s that c_str() returns.

how long will the pointed cstring live?

It will survive until s goes out of scope, or s changes in some way (new
chars added, cleared, whatever).

I see that calling delete c or delete []c fail, that the cstring survives
the end of the scope in witch it is decleard and even delete s does not
destroy it (I thougth c could be a pointer to some internal buffer of s,
but it seems not to be the case).

c does not "own" the buffer that c_str() returns. s "owns" it, and such it
will delete it itself in the destructor. You should not mess with it or
change it (it is constant after all).

So, what should one do after having created a char* with c_str()? Delete
it
in some way or leave it there?

Leave it alone, make it point to something else, make it point to NULL, it
doesn't matter. It's just a pointer. It depends on what you want to use c
for after you are done with it.

 

[Roland Pibinger]

Or until a non-const operation is performed on s, yes?

Probably also const member functions invalidate the result of c_str().
When you call c_str() twice (consecutively) I guess it's not
guaranteed that the same address is returned for both calls.

Best wishes,
Roland Pibinger

 

[Kai-Uwe Bux]

Probably also const member functions invalidate the result of c_str().

21.3.6 says:

const charT* c_str() const;

Returns: A pointer to the initial element of an array of length size() + 1
whose first size() elements equal the corresponding elements of the string
controlled by *this and whose last element is a null character specified by
charT().

Requires: The program shall not alter any of the values stored in the array.
Nor shall the program treat the returned value as a valid pointer value
after any subsequent call to a non-const member function of the class
basic_string that designates the same object as this.


Note the restriction to non-const member functions. Thus calling const
member functions is considered ok.

When you call c_str() twice (consecutively) I guess it's not
guaranteed that the same address is returned for both calls.

True. It is just guaranteed that the first pointer is not invalidated.



Best

Kai-Uwe Bux

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

In this special case the pointer will (probably) be valid for the total
execution-time of the application since the string is hard-codes and
thus stored in the data- or text-segment of the applications memory.

Probably also const member functions invalidate the result of c_str().
When you call c_str() twice (consecutively) I guess it's not
guaranteed that the same address is returned for both calls.

According to the standard (or rather a draft of it) only non-const
operations can invalidate the pointer.

Erik Wikström