Boost logo

Boost :

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;
> };

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

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