I want to provide zero-copy, move based API. I want to move a string from thread A into thread B. Ideologically it seems that move shall be able to simply pass\move data from instance A into new instance B with minimal to none copy operations (mainly for addresses). So all data like data pointers will be simply copied no new instance (constructed via move). So does std::move on std::string garantee that .c_str() returns same result on instance before move and instance created via move constructor?
Does std::move on std::string garantee that .c_str() returns same result?
Asked Answered
No,
but if that is needed, an option is to put the string in std::unique_ptr. Personally I would typically not rely on the c_str() value for more than the local scope.
Example, on request:
#include <iostream>
#include <string>
#include <memory>
int main() {
std::string ss("hello");
auto u_str = std::make_unique<std::string>(ss);
std::cout << u_str->c_str() <<std::endl;
std::cout << *u_str <<std::endl;
return 0;
}
if you don't have make_unique (new in C++14).
auto u_str = std::unique_ptr<std::string>(new std::string(ss));
Or just copy the whole implementation from the proposal by S.T.L.:
How to put a string into unique_ptr.having it by value? –
Privation
No. There's no requirement for std::string to use dynamic allocation or to do anything specific with such an allocation if it has one. In fact, modern implementations usually put short strings into the string object itself and don't allocate anything; then moving is the same as copying.
It's important to keep in mind that std::string is not a container, even though it looks very similar to one. Containers make stronger guarantees with respect to their elements than std::string does.
So in case of for example std::vector we are garanteed to have pointer to the first oiunt to the same place after move? –
Privation
@DuckQueen: I'm not really sure. The standard says that the target container after move has the same value as the operand before the move, but that's a bit vague. Only for
swap does it say that no container elements are touched. –
Cannular No, it's not guaranteed.
Guaranteeing it would basically prohibit (for one example) the short string optimization, in which the entire body of a short string is stored in the string object itself, rather than being allocated separately on the heap.
At least for now, I think SSO is regarded as important enough that the committee would be extremely reluctant to prohibit it (but that could change--when the original C++98 standard was written, they went to considerable trouble to allow copy-on-write strings, but they are now prohibited).
No,
but if that is needed, an option is to put the string in std::unique_ptr. Personally I would typically not rely on the c_str() value for more than the local scope.
Example, on request:
#include <iostream>
#include <string>
#include <memory>
int main() {
std::string ss("hello");
auto u_str = std::make_unique<std::string>(ss);
std::cout << u_str->c_str() <<std::endl;
std::cout << *u_str <<std::endl;
return 0;
}
if you don't have make_unique (new in C++14).
auto u_str = std::unique_ptr<std::string>(new std::string(ss));
Or just copy the whole implementation from the proposal by S.T.L.:
How to put a string into unique_ptr.having it by value? –
Privation
It is documented here, so you can assume that the c_str() result is stable under some conditions.
You cannot however assume that c_str() will remain the same after move.
In practice it will stay in case of long string, but it won't stay for short strings.
© 2022 - 2024 — McMap. All rights reserved.
std::moveis just a cast. It doesn't do anything. – Cannular