On 21/08/2014 03:26 p.m., Peter Dimov wrote:
Agustín K-ballo Bergé wrote:
I can't really argue about the potential for misuse of the language.
This is not misuse. It is a correct literal interpretation of the standard. If a class is trivially copyable, I can copy it with memcpy and get a copy. That's what trivially copyable means.
We can be literal and we can be pragmatic, but switching from one to the other is not a consistent position.
You got me there, I live somewhere in between those worlds. I see trivially copyable as a permission to use memcpy/memmove to replace what would be a copy/move-construction, copy/move-assignment, and other operations derived from them (say swap) **if** the corresponding special member is provided and accessible. You are correct that this does not fit a strict view of either position.
Interesting. Why would the copy being private not result in a > compile-time error?
Why indeed? I guess it would have been a compiler bug, ...
The only case that comes to mind is when you copy the class inside its own member function. Which is, I suppose, a legitimate example in which a deleted copy is better than a private undefined one.
This particular behavior happened in some old MSVC version (2005 or 2008 I'd say). I no longer have access to those, and a quick check on more recent versions does not show the issue. It was likely a compiler bug fixed since then, I particularly remember 2005 skipping access control in certain scenarios. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com