|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk