Boost logo

Boost :

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_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):

      class T)>\
void forward(someparam, BOOST_IG_PASTE(BOOST_PERFECT_FWD_ARG_0, n))\

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, gregod at, cpdaniel at, john at