Re: [boost] Fwd: Re: [move] You can do it better: implementing push_back and handling implicit conversions

Subject: Re: [boost] Fwd: Re: [move] You can do it better: implementing push_back and handling implicit conversions
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2011-03-09 14:58:12

El 09/03/2011 2:25, Jeffrey Lee Hellrung, Jr. escribió:
> Ion, I count 5 overloads of push_back in C++03 and 4 overloads in C++0x
> for your solution. I believe one can get by with just 3 overloads in
> C++03, and 1 in C++0x, but the path to "T construction" in my solution
> is a little bit different than yours. I delay any T construction until
> the placement new statement in priv_push_back. I don't know what your
> requirements are in general, but for push_back, I think this should be
> fine. The solution I sent you has maybe a slight disadvantage over
> yours in that conversion errors would likely end up pointing to
> priv_push_back, but if this is a concern, the template overloads of
> push_back can be restricted (further) with enable_if (I think).

I count 5 overloads for C++03 and 2 for C++0x (usual const T & and T&&). 
I don't know if emulation "placement construction" is right for 
convertible types, at least it should not occur in standard C++0x 
containers. std::list in C++0x can contain non-movable and non-copyable 
types, (some functions like resize(), require DefaultConstructible and 
emplace() requires EmplaceConstructible, but no MoveConstructible or 
CopyConstructible) and in this case insert(position, value) should fail 
for convertible types. I guess we should mimick that behaviour in C++03 
containers with emulated move semantics.

Best,

Ion