-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/02/2010 07:17 PM, Jeffrey Lee Hellrung, Jr. wrote:
Move semantics can optimize away some allocations that copy on write can't [...]
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).
Hm... looking at it more closely, I think you're right. There's no way for the copy code to know that t0 isn't going to be used again, so it would still allocate a temporary for the addition.
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.
I'm not sure that's right, because if I set it to take its parameters by value, it would either have to deep-copy those parameters or use copy-on-write, making the reference count for copy-on-write two, and preventing it from detecting that either parameter is unique (and thus temporary). The variables used for the parameters could be used again later on, so it's still not safe to modify them.
What's your allocation count for this operation?
Exactly what you said: two allocations.
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.
I must be missing a trick then, because operator+ just takes constant references. The library would do those same allocations for the move stuff too, at present. operator+ and operator- would be the only ones that could use that trick, if I'm seeing things right. And it seems to me that I could emulate move semantics with my current design too, without going through Boost.Move... I was thinking about that before, when I thought I shouldn't use Boost.Move because it wasn't yet official. It might be worth reviving the thought. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkveJzoACgkQp9x9jeZ9/wRAqgCglNdO/gFhjcBctCrz1kgYD7IL NDEAoLJksHKJOZaEpv4H3jMdT7TI+OJI =YIBU -----END PGP SIGNATURE-----