On 21/08/2014 11:54 a.m., Peter Dimov wrote:
Agustín K-ballo Bergé wrote:
This is not so funny once you accept that `TriviallyCopyable` does not imply `Copyable`. The apparent contradiction that `noncopyable` is `TriviallyCopyable` is not such, according to the language rules.
The fact that a class can be trivially copyable but not copyable is precisely what's funny. If you don't 'accept' that, there's nothing left to laugh at.
I guess we are saying the same thing.
And, while I can grudgingly accept the argument that the class deriving from noncopyable needs to decide whether to be trivially constructible or not, in this case, it is not that class that makes the decision. All classes deriving from noncopyable weren't trivially copyable with the old implementation and are now trivially copyable.
True, it is a breaking change for classes relying on an implementation provided default constructor. I'm having a hard time deciding where this matters outside of `is_trivially_default_constructible`. The only case I could think of is full initialization of a const object, but it fails in those cases now as it was failing before (hopefully this will change one day).
This is off-topic anyway.
It isn't. We're discussing whether noncopyable is or should be trivially copyable, and the decision on that defect report determines whether the current implementation is.
As I see it, since trivially copyable does not imply copyable, it is irrelevant for `noncopyable`. Even when it sounds funny.
Incidentally, the compilers I tried give 0 for is_trivial and is_trivially_copyable. They don't seem enlightened.
Only libc++ implements `is_trivially_copyable` (msvc pretends to but does a bad bad thing). See http://melpon.org/wandbox/permlink/BXhRw5DN8RhnNPw6 for a working example.
I disagree. The new implementation does not interfere with things other than copyability.
"Does not interfere" is not the same as "is better than".
I see "does not interfere" as "better than", because it means I don't have to go and implement my own version that does only what it's supposed to do. Whether this matters, I don't know. I wouldn't use `noncopyable` in C++11 code, and I stopped using it in C++03 code a long time ago because it would result in "error: undefined reference for blablabla" with absolutely no context on whether the copy attempt happens (not entirely `noncopyable`'s fault, but enough to make it useless for me). Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com