rvalue - Page 3 - Developer IT

Search Results

Search found 52 results on 3 pages for 'rvalue'.

Why does virtual assignment behave differently than other virtual functions of the same signature?

- by David Rodríguez - dribeas

While playing with implementing a virtual assignment operator I have ended with a funny behavior. It is not a compiler glitch, since g++ 4.1, 4.3 and VS 2005 share the same behavior. Basically, the virtual operator= behaves differently than any other virtual function with respect to the code that is actually being executed. struct Base { virtual Base& f( Base const & ) { std::cout << "Base::f(Base const &)" << std::endl; return *this; } virtual Base& operator=( Base const & ) { std::cout << "Base::operator=(Base const &)" << std::endl; return *this; } }; struct Derived : public Base { virtual Base& f( Base const & ) { std::cout << "Derived::f(Base const &)" << std::endl; return *this; } virtual Base& operator=( Base const & ) { std::cout << "Derived::operator=( Base const & )" << std::endl; return *this; } }; int main() { Derived a, b; a.f( b ); // [0] outputs: Derived::f(Base const &) (expected result) a = b; // [1] outputs: Base::operator=(Base const &) Base & ba = a; Base & bb = b; ba = bb; // [2] outputs: Derived::operator=(Base const &) Derived & da = a; Derived & db = b; da = db; // [3] outputs: Base::operator=(Base const &) ba = da; // [4] outputs: Derived::operator=(Base const &) da = ba; // [5] outputs: Derived::operator=(Base const &) } The effect is that the virtual operator= has a different behavior than any other virtual function with the same signature ([0] compared to [1]), by calling the Base version of the operator when called through real Derived objects ([1]) or Derived references ([3]) while it does perform as a regular virtual function when called through Base references ([2]), or when either the lvalue or rvalue are Base references and the other a Derived reference ([4],[5]). Is there any sensible explanation to this odd behavior?

Read the article

Making swap faster, easier to use and exception-safe

- by FredOverflow

I could not sleep last night and started thinking about std::swap. Here is the familiar C++98 version: template <typename T> void swap(T& a, T& b) { T c(a); a = b; b = c; } If a user-defined class Foo uses external ressources, this is inefficient. The common idiom is to provide a method void Foo::swap(Foo& other) and a specialization of std::swap<Foo>. Note that this does not work with class templates since you cannot partially specialize a function template, and overloading names in the std namespace is illegal. The solution is to write a template function in one's own namespace and rely on argument dependent lookup to find it. This depends critically on the client to follow the "using std::swap idiom" instead of calling std::swap directly. Very brittle. In C++0x, if Foo has a user-defined move constructor and a move assignment operator, providing a custom swap method and a std::swap<Foo> specialization has little to no performance benefit, because the C++0x version of std::swap uses efficient moves instead of copies: #include <utility> template <typename T> void swap(T& a, T& b) { T c(std::move(a)); a = std::move(b); b = std::move(c); } Not having to fiddle with swap anymore already takes a lot of burden away from the programmer. Current compilers do not generate move constructors and move assignment operators automatically yet, but as far as I know, this will change. The only problem left then is exception-safety, because in general, move operations are allowed to throw, and this opens up a whole can of worms. The question "What exactly is the state of a moved-from object?" complicates things further. Then I was thinking, what exactly are the semantics of std::swap in C++0x if everything goes fine? What is the state of the objects before and after the swap? Typically, swapping via move operations does not touch external resources, only the "flat" object representations themselves. So why not simply write a swap template that does exactly that: swap the object representations? #include <cstring> template <typename T> void swap(T& a, T& b) { unsigned char c[sizeof(T)]; memcpy( c, &a, sizeof(T)); memcpy(&a, &b, sizeof(T)); memcpy(&b, c, sizeof(T)); } This is as efficient as it gets: it simply blasts through raw memory. It does not require any intervention from the user: no special swap methods or move operations have to be defined. This means that it even works in C++98 (which does not have rvalue references, mind you). But even more importantly, we can now forget about the exception-safety issues, because memcpy never throws. I can see two potential problems with this approach: First, not all objects are meant to be swapped. If a class designer hides the copy constructor or the copy assignment operator, trying to swap objects of the class should fail at compile-time. We can simply introduce some dead code that checks whether copying and assignment are legal on the type: template <typename T> void swap(T& a, T& b) { if (false) // dead code, never executed { T c(a); // copy-constructible? a = b; // assignable? } unsigned char c[sizeof(T)]; std::memcpy( c, &a, sizeof(T)); std::memcpy(&a, &b, sizeof(T)); std::memcpy(&b, c, sizeof(T)); } Any decent compiler can trivially get rid of the dead code. (There are probably better ways to check the "swap conformance", but that is not the point. What matters is that it's possible). Second, some types might perform "unusual" actions in the copy constructor and copy assignment operator. For example, they might notify observers of their change. I deem this a minor issue, because such kinds of objects probably should not have provided copy operations in the first place. Please let me know what you think of this approach to swapping. Would it work in practice? Would you use it? Can you identify library types where this would break? Do you see additional problems? Discuss!

Developer IT