Re: [boost] [core/noncopyable][test/boost::unit_test::singleton] massive test failures

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.

Regards,
-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com