Denis Koroskin wrote:
On Tue, 30 Dec 2008 22:26:19 +0300, Andrei Alexandrescu
<[email protected]> wrote:
Don wrote:
Frits van Bommel wrote:
Don wrote:
Frits van Bommel wrote:
Don wrote:
A straightforward first step would be to state in the spec that
"the compiler is entitled to assume that X+=Y yields the same
result as X=X+Y"
That doesn't hold for reference types, does it?
I thought it does? Got any counter examples?
For any class type, with += modifying the object and + returning a
new one:
Sure, you can do it (behaviour inherited from C++), but is that
_EVER_ a good idea? I can't think of any cases where that's anything
other than a bug-breeder.
You can't just arbitrarily substitute between these two.
I'm still looking for a use case where that substitution doesn't make
sense. No-one has yet come up with such a use case. I postulate that
it doesn't exist.
Well I forgot whether BigInt is a class, is it? Anyhow, suppose it
*is* a class and as such has reference semantics. Then a += b modifies
an object in-situ, whereas a = a + b creates a whole new object and
happens to bind a to that new object.
Andrei
It was suggested 2 posts up the thread. I believe Don is looking for a
use case where given
a1 = a + b;
a2 = a;
a2 += b;
the following check intentionally fails:
assert(a1 == a2); // not "a1 is a2"
He postulates that none exists.
Well then the post situated 2 posts up the thread was right because "is"
vs. "==" is a red herring. For class types the two are not equivalent.
The following two could be equivalent assuming correct definitions:
a1 = a + b;
and
a2 = deepCopy(a);
a2 += b;
This also suggests that it may sometimes be inefficient to define + in
terms of += (which is a tad counterintuitive in C++ circles).
Andrei
