Boost logo

Boost :

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é.-

Boost list run by bdawes at, gregod at, cpdaniel at, john at