move-semantics

Will member subobjects of local variables be moved too if returned from a function?

由 元气小坏坏 提交于 2019-11-30 07:21:54
The C++11 standard states that, if the conditions for copy elision are met ( §12.8/31 ), the implementation shall treat a return ed local lvalue variable and function parameters, as an rvalue first (move), and if overload resolution doesn't succeed as detailed, shall then treat it as an lvalue (copy). §12.8 [class.copy] p32 When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed

When will a C++11 compiler make RVO and NRVO outperform move semantics and const reference binding?

由 流过昼夜 提交于 2019-11-30 06:45:18
Consider the case when "whole" objects with move semantics enabled are returned from functions, as with std::basic_string<> : std::wstring build_report() const { std::wstring report; ... return report; } Can I then realistically be expected to make the "best" choice whether to use the returned string with move semantics, as in const std::wstring report(std::move(build_report())); or if I should rely on (N)RVO to take place with const std::wstring report(build_report()); or even bind a const reference to the temporary with const std::wstring& report(build_report()); What scheme is there to make

Return values for active objects

由 吃可爱长大的小学妹 提交于 2019-11-30 06:41:31
问题 Back in 2010, Herb Sutter advocated the use of active objects instead of naked threads in an article on Dr. Dobb's. Here is a C++11 version: class Active { public: typedef std::function<void()> Message; Active(const Active&) = delete; void operator=(const Active&) = delete; Active() : done(false) { thd = std::unique_ptr<std::thread>(new std::thread( [=]{ this->run(); } ) ); } ~Active() { send( [&]{ done = true; } ); thd->join(); } void send(Message m) { mq.push_back(m); } private: bool done;

Move-assignment slower than copy-assignment — bug, feature, or unspecified?

由 这一生的挚爱 提交于 2019-11-30 04:42:51
I recently realized that the addition of move semantics in C++11 (or at least my implementation of it, Visual C++) has actively (and quite dramatically) broken one of my optimizations. Consider the following code: #include <vector> int main() { typedef std::vector<std::vector<int> > LookupTable; LookupTable values(100); // make a new table values[0].push_back(1); // populate some entries // Now clear the table but keep its buffers allocated for later use values = LookupTable(values.size()); return values[0].capacity(); } I followed this kind of pattern to perform container recycling : I would

C++11: Do move semantics get involved for pass by value?

由 末鹿安然 提交于 2019-11-30 03:30:42
问题 I've got an API that looks like this: void WriteDefaultFileOutput(std::wostream &str, std::wstring target) { //Some code that modifies target before printing it and such... } I'm wondering if it'd be sensible to enable move semantics by doing this: void WriteDefaultFileOutput(std::wostream &str, std::wstring&& target) { //As above } void WriteDefaultFileOutput(std::wostream &str, std::wstring const& target) { std::wstring tmp(target); WriteDefaultFileOutput(str, std::move(tmp)); } or is this

Why does std::forward discard constexpr-ness?

由 北城以北 提交于 2019-11-30 01:49:10
问题 Being not declared constexpr , std::forward will discard constexpr-ness for any function it forwards arguments to. Why is std::forward not declared constexpr itself so it can preserve constexpr-ness? Example: (tested with g++ snapshot-2011-02-19) #include <utility> template <typename T> constexpr int f(T x) { return -13;} template <typename T> constexpr int g(T&& x) { return f(std::forward<T>(x));} int main() { constexpr int j = f(3.5f); // next line does not compile: // error: ‘constexpr int

Can a move constructor be implicit?

由 冷暖自知 提交于 2019-11-30 01:46:02
问题 Consider the following class: class A { public: std::string field_a; std::string field_b; } Now consider the following copy construction: A a1(a2); The copy construction will adequately copy A despite the lack of of an explicit copy constructor because the copy constructors for std::string will be called by the compiler generated implicit copy constructor. What I wish to know is, is the same true for move construction? EDIT : Testing here shows that: A a2(std::move(a1)); Will actually result

Can `*this` be `move()`d?

由 无人久伴 提交于 2019-11-30 00:32:07
问题 I would like to define a class for marshalling data; when marshalling is finished, I would like to move the marshalled data out from within it, which will probably invalidate the marshalling object. I believe this is possible with the static function extractData below: class Marshaller { public: static DataType extractData(Marshaller&& marshaller) { return std::move(marshaller.data); } private: DataType data; } This is a bit inconvenient to call, though: Marshaller marshaller; // ... do some

Force a compile time error if std::move will result in an unintended copy?

由 喜夏-厌秋 提交于 2019-11-30 00:11:06
In his GoingNative 2013 talk, Scott Meyers pointed out that std::move is no guarantee that the generated code will actually perform a move. Example: void foo(std::string x, const std::string y) { std::string x2 = std::move(x); // OK, will be moved std::string y2 = std::move(y); // compiles, but will be copied } Here, the move constructor cannot be applied but because of overload resolution, the normal copy constructor will be used instead. This fallback option may be crucial for backward compatibility with C++98 code, but in the example above it is most likely not what the programmer intended.

Is unique_ptr guaranteed to store nullptr after move?

由 ≡放荡痞女 提交于 2019-11-30 00:05:39
问题 Is unique_ptr guaranteed to store nullptr after move? std::unique_ptr<int> p1{new int{23}}; std::unique_ptr<int> p2{std::move(p1)}; assert(!p1); // is this always true? 回答1: Yes, you can compare it to nullptr after the move and it is guaranteed to compare equal. From §20.8.1/4 [unique.ptr] Additionally, u can, upon request, transfer ownership to another unique pointer u2 . Upon completion of such a transfer, the following postconditions hold: — u2.p is equal to the pre-transfer u.p , — u.p is
订阅 move-semantics