I still don't think the standard makes the guarantees you think it does, but in practise, you are much less likely to run into problems with
Martin wrote: that
limitation.
In practice, I have ported it to icc, gcc and visual studio, linux and windows operating systems, x86 and itanium instruction sets, 32 and 64 bit platforms. I am tempted to think that demonstrating portability should count for more than a theoretical argument about what the standard says or doesn't say. I've asked Gyuszi to weigh in on this issue, since his knowledge of C++ exceeds mine.
If the types are inherited (rather than composed) I still think you have problems if the derived class overrides virtuals in the base.
You are correct, and I am impressed by your knowledge, since I learned this one the hard way. I was syntactically unable to override the base class virtual declaration of an assignment operator because it was incorrectly returning void: virtual void operator=(const UglyPolygon &poly); The problem was that the overriding function differed only by return type, which was a problem only because the function being overridden was virtual, despite the fact that the function overriding it was non-virtual. The error the compiler gave was rather cryptic, but I eventually resolved it by removing the assignment operator in the derived class that accepts the base class type as the rvalue. Switching to composition might be preferable to prevent these problems and give me the effect of private inheritance, working around the Microsoft compiler's shortcoming. Luke