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