Re: [boost] [interest] underlying type library

Subject: Re: [boost] [interest] underlying type library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-08-22 13:55:47

Le 22/08/11 17:23, Eric Niebler a écrit :
> (Julian, I'm having a hard time following the discussion because you're
> replying to multiple people in a single email. Those of us with threaded
> readers would prefer if you replied to us individually.)
>
> On 8/22/2011 7:04 AM, Julian Gonggrijp wrote:
>> Eric Niebler wrote:
>>
>>> [...] However, I might prefer a more
>>> conservative approach whereby users must opt-in to the memcpy
>>> implementation instead of making it the default.
>> In fact I arrived at this same conclusion after I realised the bitwise
>> approach was not as general as I thought.
> Thought: the obvious default implementation should be to simply call
> move, but this gets complicated because move operations can throw. Then
> during unwinding you'll try to destruct an object that isn't in a
> destructible state. You would need to find a way to address the
> exception-safety issues. Perhaps the new noexcept keyword could help here.
>
Hi,

I agree with you Eric that the default implementation of move_raw the 
library shouldn't promote undefined behavior (memcpy). Instead it should 
use move when the type is movable, and copy/assign when 
copyable/assignable. Up to the end user to use memcpy for its own types 
when she considers that it works for him.

Julian, I don't know if you have take a look at the under review 
Boost.Conversion library. The move_raw function can follows the same 
design as the conversion::assign_to function. I don't know if the 
move_raw can be used to move unrelated types, but if this is the case, 
the issue raised during the Boost.Conversion pre/review, that is, ODR 
violation promotion will also be present. Maybe you pretend that the 
move_raw function must be overried only to move from one type to it self 
and its underlying type, but nothing in the interface prevents from 
using it to move from unrelated types.

In Boost.Enums and Boost.Opaque there is a underlying_type concept that 
match the one of this proposal. It will be nice if we can add it already 
on Boost.Utility. The library could define it for POD types as the 
identity and left the user to provide appropiated instantiations.

Best,
Vicente