I'm doing some maintenance work and ran across something like the following:
std::string s;
s.resize( strLength );
// strLength is a size_t with the length of a C string in it.
memcpy( &s[0], str, strLength );
I know using &s[0] would be safe if it was a std::vector, but is this a safe use of std::string?
A std::string's allocation is not guaranteed to be contiguous under the current standard, but the new standard forces it to be. In practice, neither I nor Herb Sutter know of an implementation that does not use contiguous storage.
EDITED TO ADD: Following the comments below, it is guaranteed by the current standard if strLength > 0, otherwise invokes undefined behavior. It would not be guaranteed if you did str.begin() or &*str.begin(), but for &s[0] the standard defines operator[] as:
Returns: If pos < size(), returns data()[pos]. Otherwise, if pos == size(), the const version returns charT(). Otherwise, the behavior is undefined.
This is where the undefined behavior would occur if strLength == 0.
Continuing on, data() is defined as:
Returns: ... a pointer to the initial element of an array whose first size() elements equal the corresponding elements of the string controlled by *this ...
Since you resize, you should have a contiguous array of at least strLength. Note that the memcpy is not copying a null terminator, but if it did would have not been guaranteed to work.
Technically, no, since std::string is not required to store its contents contiguously in memory.
However, in almost all implementations (every implementation of which I am aware), the contents are stored contiguously and this would "work."
Legal? Maybe, maybe not. Safe? Probably, but maybe not. Good code? Well, let's not go there...
Why not just do:
std::string s = str;
...or:
std::string s(str);
...or:
std::string s;
std::copy( &str[0], &str[strLen], std::back_inserter(s));
...or:
std::string s;
s.assign( str, strLen );
?
This is generally not safe, regardless of whether the internal string sequence is stored in memory continuously or not. There's might be many other implementation details related to how the controlled sequence is stored by std::string object, besides the continuity.
A real practical problem with that might be the following. The controlled sequence of std::string is not required to be stored as a zero-terminated string. However, in practice, many (most?) implementations choose to oversize the internal buffer by 1 and store the sequence as a zero-terminated string anyway because it simplifies the implementation of c_str() method: just return a pointer to the internal buffer and you are done.
The code you quoted in your question does not make any effort to zero-terminate the data it copied into the internal buffer. Quite possibly it simply doesn't know whether zero-termination is necessary in this implementation of std::string. Quite possibly it relies on the internal buffer being filled with zeros after the call to resize, so the extra character allocated for the zero-terminator by the implementation is conveniently pre-set to zero. All this is implementation detail, meaning that this technique depends of some rather fragile assumptions.
In other words, in some implementations you'd probably have to use strcpy, not memcpy to force the data into the controlled sequence like that. While in some other implementations you'd have to use memcpy and not strcpy.
The code might work, but more by luck than judgement, it makes assumptions about the implementation that are not guaranteed. I suggest determining the validity of the code is irrelevant while it is a pointless over complication that is easily reduced to just:
std::string s( str ) ;
or if assigning to an existing std::string object, just:
s = str ;
and then let std::string itself determine how to achieve the result. If you are going to resort to this sort of nonsense, then you may as well not be using std::string and stick to since you are reintroducing all the dangers associated with C strings.