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.
> struct W
> X x;
> Y y;
> Z z;
void move_raw( underlying_type_traits<W>::type & d, W & s )
> 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
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
I think it fills a different need.
-- Eric Niebler BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk