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
> 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
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
//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):
void forward(someparam, BOOST_IG_PASTE(BOOST_PERFECT_FWD_ARG_0, n))\
#define BOOST_PP_LOCAL_LIMITS (1, BOOST_PERFECT_FWD_MAX)
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
> 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:
>> 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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk