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