On 21/08/2014 10:08 a.m., Peter Dimov wrote:
John Maddock wrote:
1) Why on earth is:
BOOST_CONSTEXPR noncopyable() = default;
Better than
noncopyable() {}
I can tell you what's the difference, but not why it's better. :-)
constexpr on the constructor enables noncopyable, and its descendants, to be statically initialized. I suppose this makes sense; a mutex, for example, is noncopyable but it may be desirable for it to support static initialization.
=default makes the constructor trivial. A trivial constructor can be omitted. It's not clear to me why a noncopyable class would need to have a trivial constructor.
The class inheriting from `noncopyable` is the one that should decide whether the constructor should be trivial or not. Defaulting the default constructor makes this decision possible.
Similarly, =default on the destructor instead of {} makes it trivial. A trivial destructor may be omitted. It makes approximately zero sense for a noncopyable class to have a trivial destructor.
Having a defaulted destructor is redundant, but explicit. I don't see why `noncopyable` ever needed to spell out a destructor. But the same point as above applies, specially since a literal class requires a trivial destructor, so a constexpr default constructor only makes sense with a trivial destructor (IIRC it's an error otherwise).
The funniest part is that =delete on the copy constructor makes the copy constructor trivial as well, in C++11. A trivial copy constructor means that the class is copyable with memcpy. :-)
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.
(There is a core defect report against that though, if I'm not mistaken.)
There is, but core wants to keep deleted special members trivial. I believe this to be the correct approach, and I don't think it's likely to change if anything else because it would be a breaking ABI change. This is off-topic anyway.
In summary, I don't see the new noncopyable as better than the old one in any significant way.
I disagree. The new implementation does not interfere with things other than copyability. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com