Re: [boost] [interest] underlying type library

Subject: Re: [boost] [interest] underlying type library
From: Eric Niebler (eric_at_[hidden])
Date: 2011-08-22 11:30:06

On 8/22/2011 3:34 AM, Nevin Liber wrote:
> 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.  

No, because UNDERLYING_TYPE and move_raw are part of the type's interface.

> Consider:
> 
> struct W
> {
>  X x;
>  Y y;
>  Z z;
> };

template<>
struct underlying_type_traits<W>
{
  struct type
  {
    underlying_type_traits<X>::type x;
    underlying_type_traits<Y>::type y;
    underlying_type_traits<Z>::type z;
  };
};

void move_raw( underlying_type_traits<W>::type & d, W & s )
{
  move_raw(d.x, s.x);
  move_raw(d.y, s.y);
  move_raw(d.z, s.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.

Yes. Stepanov argues that there should be compiler support. We could do
it with Fusion's adapt struct macros.

> 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?

I think it fills a different need.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com