Thread: Construct a std::string from char*

Is there a way to make a std::string from a char* without copying it? If I understand correctly using the = operator will copy a c-string to a std::string. Using std::string constructor will again do the same. Is there a way to assign the internal char array of std::string to a char* or char[]?

I am just looking for a method that I can use a std::string when a c-method asks for a char* to right on. If it asks to read, this is solved with string.c_str(). But I am kind of confused about how to write on a std::string instead of a char*.

I don't want the copy just because of the added time needed. A memset() hack could be available, but it would depend on how std::string is implemented (where its internal char array is located)

Originally Posted by whiteflags

string.data()

Yup that with combination of const_cast works fine. But you can also use c_str I guess, which would append a '\0'. I always thought c_str() created a copy, but I guess they rely on the const of it not to be corrupted.

Treating a std::string as a char* is useful on occasions that you have to work with char*. Instead of using both c-strings and std::string I find it a better idea to use only std::string and use the above method to pass them to functions that will write in them taking advantage of pointers.
Would you consider doing:

Code:

std::string str;
....
recv(const_cast<char*>(str.data()), str.size(), 0);

a bad idea?
There is no chance that you won't have memory, so I can't seem to find any problem. So you get read of c-strings and use std::string. The best would be to have a recv() function that accepts a std::string& and optionally a length parameter, still ensuring you won't write more than size() char.

Originally Posted by C_ntua

Yup that with combination of const_cast works fine. But you can also use c_str I guess, which would append a '\0'. I always thought c_str() created a copy, but I guess they rely on the const of it not to be corrupted.

The reason you need a const_cast is because string::data returns const - the intent is that it will not be used to modify the string's data.

c_str() potentially returns a copy. That is implementation defined.

Originally Posted by C_ntua

Would you consider doing:

Code:

std::string str;
....
recv(const_cast<char*>(str.data()), str.size(), 0);

a bad idea?

Yes, I would, for the reason I mentioned above. Also, as cyberfish said, there is no guarantee that std::string uses a contiguous array of char. Your technique assumes it does, and will break if you use an implementation of the standard library that does not do that.

You absolutely cannot do such a thing in C++03. GCC's std::string, for example, uses reference counting, so you could be overwriting the memory that is shared between different strings.

std::string's memory MUST be continuous, that's actually guaranteed by implication in C++03, and explicitly in C++0x. But you must never modify the memory returned by data().

You may, however, pass &s[0] as a char* and modify from there.

Originally Posted by CornedBee

std::string's memory MUST be continuous, that's actually guaranteed by implication in C++03, and explicitly in C++0x.

Actually, it is not guaranteed by implication in C++03 due to a defect in the standard that will be fixed in the next version (as you noted). Therefore, whether you can "pass &s[0] as a char* and modify from there" in C++03 is not guaranteed (unless it has been fixed in a defect report, but I have not checked, and it does not matter in practice now anyway).

Originally Posted by CornedBee

std::string's memory MUST be continuous, that's actually guaranteed by implication in C++03, and explicitly in C++0x. But you must never modify the memory returned by data().

Strings in the C++ standard (ratified 1998 as opposed to later proposed revisions) are only required to conform with requirements of a Sequence. A Sequence - according to Section 23.1.1 - may be contiguous, but need not be (a linked list would also comply with requirements of a Sequence).

Interestingly, both data() and c_str() are specifically allowed (but not required) to invalidate any of a basic_string's iterators. This suggests both methods (among other things) have freedom to affect the internal data representation of the string.

Originally Posted by CornedBee

You absolutely cannot do such a thing in C++03. GCC's std::string, for example, uses reference counting, so you could be overwriting the memory that is shared between different strings.

Can you elaborate on that? I don't get what you mean. Since it passes a char* it would point on a memory location with continuous memory, otherwise there is no sense returning a pointer. That continuous memory location would have size() bytes that have the same value of the std::string.
In other words, since you can read them, why can't you write on them?

My point is that the way I understand it you will be writing on a memory location that is reserved to have the values of the std::string. If data() makes a copy, then you will be writing on the copy, which would make the method useless. But I don't see how you can risk changing something you shouldn't change? The size() of the std::string for example cannot be on the bytes you are writing. The const char* returned is internal also, which means it has a specific location. Otherwise, calling data() two times and assuming it allocates memory somewhere and then frees that memory to allocate somewhere else, would case the pointer of the first data() to point to somewhere invalid. So I am guessing that the value returned from data() is always the same.

Yes, of course, you are right about that.
What if you called reserve() first to make sure it won't re-allocate memory?

So

Code:

   *  A string looks like this:
   *
   *  @code
   *                                                 [_Rep]
   *                                                 _M_length
   *   [basic_string<char_type>]    _M_capacity
   *   _M_dataplus                          _M_refcount
   *   _M_p ---------------->               unnamed array of char_type
   *  @endcode
   *
   *  Where the _M_p points to the first character in the string
    ........................
   *  The reason you want _M_data pointing to the character array and
   *  not the _Rep is so that the debugger can see the string
   *  contents.

and later on

Code:

data() const { return _M_data(); }
............
_M_data() const  { return  _M_dataplus._M_p; }
_CharT* _M_p; // The actual data.

So I am guessing that data() returns a pointer to the first character of the string, always. That is after everything else. Since you can read those data, you can as well change them.

If you do this

Code:

char* buf = const_cast<char*>(str.data());

you should have buf = str._M_p. If the string re-allocates memory it would do something like

Code:

str._M_p = realloc(....);

sto wouldn't

Code:

*buf = 'a';

still modify the first character of the string??
If you later do

Code:

str += "baa";

it will reallocate memory and copy the values. Again won't buf be pointing at _M_p, thus at the internal buffer?

I am reading about reference counting, so I get what CornedBee meant. I guess it becomes troublesome