Re: [boost] [interest] underlying type library

Subject: Re: [boost] [interest] underlying type library
From: Nevin Liber (nevin_at_[hidden])
Date: 2011-08-22 03:34:57

On 21 August 2011 21:15, Eric Niebler <eric_at_[hidden]> wrote:

> However, I might prefer a more
> conservative approach whereby users must opt-in to the memcpy
> implementation instead of making it the default.

The problem is, you are adding in a dependency on the *implementation*, not
the interface of objects.  Consider:

struct W
{
 X x;
 Y y;
 Z z;
};

1.  What are the requirements on implementations of X, Y and Z?  Is
trivially copyable enough?  How about trivially copyable and isn't moveable
(unless you want to second guess the move constructor)?  Of course, if it is
trivially copyable and not moveable, there is probably a reason...
2.. How are you going to enforce that?  Maybe you create some type trait
with the defaults based upon the requirements you've identified above.
 Because C++ doesn't have introspection, you still end up having to write
code that examines all the member variables to see if they meet that type
trait.

Do you still think that is easier than writing the move constructor and
assignment operator for classes where the compiler generated one is wrong or
deleted?
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]