Re: [boost] [move] Library uploaded to sandbox

Subject: Re: [boost] [move] Library uploaded to sandbox
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2009-02-18 12:02:59

Mathias Gaunard wrote:
> Why is forwarding constructor specific? Shouldn't it work with any 
> function?
> 
> I suggest renaming BOOST_CONSTRUCT_FWD_REF to BOOST_FWD_REF and 
> boost::forward_constructor to boost::forward.
> 
> I suppose there is an issue to forward references vs const references. 
> Is that why it's limited to constructors?

I renamed then just recently, because the emulation is was limited. It 
works for every function but it does not forward non-const references, 
so it's not intended to implement bind / function -like perfect 
forwarding. It fits quite well for in-place construction. To avoid this 
workaround we could adopt boost::ref as a the way to pass non-const 
references so that forward returns a non-const reference. I personally 
don't have any problem to limit forwarding to this, but maybe other 
library writers don't think the same.

Eric kindly showed provided some C++03 perfect forwarding 
Boost.Preprocessor emulation code in but I'm too limited to implement 
more than really trivial preprocessor metaprogramming. And it could not 
find a way to it some easy to use, generic component that I could offer 
with Boost.Move. However I have some ideas to simplify a 
preprocessor-based perfect forwarding utility, with the help of some 
pre-preprocessing ;-):

1) We create a list of defines with parameters pre-preprocessed (created 
offline) up to a admissible number of parameters (maybe 5 which leads to 
64 overloads per function)

BOOST_PERFECT_FWD_ARG_0 const T0 &
BOOST_PERFECT_FWD_ARG_1 T0 &
BOOST_PERFECT_FWD_ARG_2 const T0 &, const T1 &
BOOST_PERFECT_FWD_ARG_3 T0 &, const T1 &
BOOST_PERFECT_FWD_ARG_4 const T0 &, T1 &
//and so on

BOOST_PERFECT_FWD_NUMPARAMS_0 1
BOOST_PERFECT_FWD_NUMPARAMS_1 1
BOOST_PERFECT_FWD_NUMPARAMS_2 2
BOOST_PERFECT_FWD_NUMPARAMS_3 2
BOOST_PERFECT_FWD_NUMPARAMS_4 2
//and so on

2) Have only a single preprocessor loop (since the previous 
pre-preprocessing unrolls the const non-const combination loop) that 
writes something like this (note that I have no Boost.PP idea so I'm, 
writing some imaginary PP functions named BOOST_IG_XXXX):

#define BOOST_PP_LOCAL_MACRO(n)\
\
template<\
   BOOST_PP_ENUM_PARAMS\
     (BOOST_IG_PASTE(BOOST_PERFECT_FWD_NUMPARAMS_, n),\
      class T)>\
void forward(someparam, BOOST_IG_PASTE(BOOST_PERFECT_FWD_ARG_0, n))\
{/**/}\
#define BOOST_PP_LOCAL_LIMITS (1, BOOST_PERFECT_FWD_MAX)
#include BOOST_PP_LOCAL_ITERATE()

Maybe this will also help with compile times but obviously, it won't 
avoid exponential overloading to achieve perfect forwarding in C++03. If 
any Boost.PP expert dares to write this, welcome. Boost.Move could offer 
the pre-preprocessed utilities BOOST_PERFECT_FWD_XXX and an easy guide 
to write perfect forwarding with the Boost.PP. But this is just a vague 
idea.

> Those containers probably have little to do in the interprocess namespace.
> Maybe it's time to make them first-class boost citizens?

I have no problem to isolate them and put them somewhere in Boost 
provided binary compatibility is guaranteed so that Interprocess users 
don't break their code. However, I won't have time to add new features 
or document more than they are (after all, everybody knows have to use a 
container). As a side note, non-standard containers like flat_map (what 
an horrible name for an ordered vector, isn't it?) will be much more 
efficient with move semantics.

>> And online documentation also here:
>>
>> http://www.drivehq.com/web/igaztanaga/libs/move_semantics/
>>
>> The documentation is not in english, it's in my own english dialect so 
>> be careful when reading ;-) Patches and corrections welcome. I've 
>> documented some functions to create a little boostbook reference.
> 
> The documentation doesn't really mention what are the limits of the 
> emulation, if there are any.

There are, of course. I'll add this information.

Thanks for the comments, best,

Ion