On 05/02/2010 04:04 PM, Chad Nelson wrote:
On 05/02/2010 06:43 PM, Peter Dimov wrote:
Move semantics can optimize away some allocations that copy on write can't, such as for example
w = x * y + z;
(assuming that x*y already has enough bits to store x*y+z).
The copy-on-write code should optimize that allocation away too, under those circumstances.
I don't think so, unless your arithmetic operators use by-value parameters (allowing copies to be elided). Assuming you're not using expression templates, I would expect an implementation with no move semantics to translate "w = x * y + z" to be, effectively, T t0 = x * y; w = t0 + z; which requires 2 allocations minimum (one to store the result of x * y, another to store the result of t0 + z). But, again, if operator+ takes its parameters by-value, you can probably get some copies elided in practice and detect that the first argument to operator+ has unique ownership, hence is modifiable. What's your allocation count for this operation? Note that move semantics, on the other hand, can directly detect that t0 is just a temporary (by overloading operator+ on both a reference-to-const and an (emulated) rvalue reference), hence the t0 + z can be safely replaced with t0 += z (which will possibly avoid a reallocation), and the then the new t0 would be moved into w. - Jeff