Subject: Re: [boost] [core/noncopyable][test/boost::unit_test::singleton] massive test failures
From: AgustÃn K-ballo BergÃ© (kaballo86_at_[hidden])
Date: 2014-08-21 15:02:46
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.
-- AgustÃn K-ballo BergÃ©.- http://talesofcpp.fusionfenix.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk