Boost logo

Boost :

Subject: Re: [boost] [Boost.Move] A few notes
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-01-13 15:25:41

On Fri, Jan 13, 2012 at 7:13 AM, Dan Ivy <danivy.mail_at_[hidden]> wrote:

> On Fri, Jan 13, 2012 at 1:04 AM, Jeffrey Lee Hellrung, Jr.
> <jeffrey.hellrung_at_[hidden]> wrote:

> >> Interesting. Could you provide a reference or an example?
> >
> > Here's the idea. In C++11, you can just get away with
> > [...]
> >
> Thanks for expanding. That's a clever trick :). I thought you were
> taking about something a bit different though, as this method doesn't
> scale to functions taking more than a single parameter (it's
> theoretically possible, but not practical), so it's not a general
> solution to forwarding.

No, only really practical for 1 or (maybe) 2 function parameters :(

Btw, if that's all you're trying to do, won't something like this be a
> lot simpler?
[...snip inheriting from movable<T>...]

Hmmm...indeed! Definitely a superior solution functionality-wise. The only
drawback I can think of is that it can't be easily added to the existing
Boost.Move move-enabling macros :( And I can't really think of a good way
to hide sometimes inheriting from movable<T> (depending on the presence or
absence of rvalue references) within some kind of macro framework. But this
might be something I will have to look into further...

>> So, it seems that you're already using the same thing I suggest...
> >>
> >
> > Well, any function using BOOST_FWD2_REF in its parameter list is only
> > passed parameters that are lvalues or the result of a boost::forward.
> So, I
> > guess I'm using the same thing, but it doesn't sound like it's in the
> same
> > context...?
> But since we only have one BOOST_FWD_REF, I belive it should be
> applicable to any context (and you belive that it should be
> "optimized" for the most common one, point is clear, let's not open
> that again ;) )

Hey, be my guest trying to convince Ion, he's the ultimate authority :)

- Jeff

Boost list run by bdawes at, gregod at, cpdaniel at, john at