Is it ok to do the following?
auto len = GetWindowTextLengthA(min_area_edit_hwnd);
std::string buffer(len, '\0');
GetWindowTextA(min_area_edit_hwnd, &buffer[0], len + 1);
I mean, is it ok to tell the GetWindowTextA function that &buffer[0] points to the buffer with len + 1 size? Is it correct or should I create string in the following way
std::string buffer(len + 1, '\0');
?
This is generally legal starting from C++11, but you do indeed have to reserve an extra character for the null terminator.
Before C++11 such uses of std::string were illegal. However, note that buffer.length() will not automatically update just because GetWindowTextA placed a \0 somewhere in the middle of its controlled sequence. If you want C-length of the string to be consistent with buffer.length(), it is your responsibility to resize() your buffer accordingly.
I'd tend to err on the side of caution myself:
char cbuffer[MAX_LEN_OF_SOME_DESCRIPTION];
GetWindowTextA(..., cbuffer, ...);
cbuffer[len] = '\0';
std::string buffer(cbuffer); // assuming you actually NEED a C++ string.
This method will work without having to parse the rather voluminous C++ standards documents to find out whether writing directly into a string object is legal :-)
The GetWindowTextA function will write into the provided buffer. In C++11 and C++14, it is undefined behaviour to write out of bounds of the string content of a std::string, even if you're writing a null terminator over the null terminator.
You will need to size the string to len + 1 before making the call, and then resize the string again afterwards, based on the return value.
From the standpoint of the standard, the following is guaranteed:
operator[](std::size_t) will not invalidate iteratorsoperator[](size())I would therefore conclude, that it is perfectly fine to do as long as the function does not eagerly write a null terminator (i.e. checks if it already ends with '\0' which it always will and then does nothing). Also, I have only heard of one instance of a string being implemented such that this would actively lead to real trouble, that is the implementation at Facebook.
Personally, I would go with the safer route and set the size to be a byte longer if you can not strictly control the access, so I would not pass a size of len + 1 .
Edit: from a comment under another answer, not correctly handling the (possibly not allocated) null terminator can result in real failures, see CppCon 2016: Nicholas Ormrod “The strange details of std::string at Facebook"
According to the Standard, this is not safe. The Standard goes to some considerable effort to explicitly state that writing to the NUL terminator is undefined behavior:
and
Slightly more difficult to analyze is whether &buffer[0] points to size() + 1 consecutive characters to begin with. The Standard does not make this guarantee explicitly, and in fact the wording of operator[] quoted above seems to leave the door open to having a buffer of only size() consecutive characters, with the terminator stored separately. However when all the semantic rules are considered, the string must actually have room for size() + 1 characters at all times. (Otherwise a call to c_str(), which is a const member function, could not return a pointer to a run of size()+1 characters without invalidating references, which it is not allowed to do. A second proof, also valid, is that c_str() cannot copy the content to a new location and still meet the complexity requirement).
However, it is not assured that the character at location size() + &buffer[0] is actually a NUL until c_str() or data() is called (at which point &buffer[size()] begins returning a reference to it instead of an alternate location).
&(buffer[0]) has a type char*, and probably points to the text of length len, but even this is not guaranteed. You should use char buffer[len+1]; instead.
