Re: [boost] [move][container] Review Request (new versions of Boost.Move and Boost.Container in sandbox and vault)

Subject: Re: [boost] [move][container] Review Request (new versions of Boost.Move and Boost.Container in sandbox and vault)
From: Jeffrey Bosboom (jbosboom_at_[hidden])
Date: 2009-08-24 03:18:25

Ion Gaztañaga wrote:
> Jeffrey Hellrung escribió:
>> Ion Gaztañaga wrote:
>> - What is the rationale for placing BOOST_COPYABLE_AND_MOVABLE and 
>> BOOST_MOVABLE_BUT_NOT_COPYABLE in the private section of a class 
>> definition?  IIRC, BOOST_ENABLE_MOVE_EMULATION was suppose to go in 
>> the public section, and I'm generally wondering what the motivations 
>> are for specifying public or private.
> 
> I just wanted to maintain public part as clean as possible, but there is 
> no strong argument for that.

I'm not familiar with this library, so I don't know what those macros 
do.  If they're used to define a type as movable, they should be in the 
public interface, as a type's movability is often a complexity guarantee 
(especially for containers where falling back to a copy would be a 
change from constant to linear time).

If they just declare scaffolding, they should be private.

Either way, their names ought to reflect what they do.  (If it generates 
implementation, put BOOST_MOVEABLE_NOT_COPYABLE_IMPL or something; 
otherwise the current names are probably fine.)

--Jeffrey Bosboom