Subject: Re: [boost] [move] new rvalue reference emulation
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-04-11 16:24:55
2011/4/11 Ion Gaztañaga <igaztanaga_at_[hidden]>
> El 11/04/2011 3:22, Jeffrey Lee Hellrung, Jr. escribió:
>> On Mon, Apr 4, 2011 at 10:36 AM, Jeffrey Lee Hellrung, Jr.<
>> jeffrey.hellrung_at_[hidden]> wrote:
>> [...snipping original description...]
> Sorry for the lack of feedaback! I tried to your example in some compilers
> and checked that MSVC7.1 does not like pointer to function storage in the
> generic rv (it's a msvc bug, but annoying, nevertheless).
It sounds like that could be easily worked around without too much
> I've been very busy with several interprocess issues and I couldn't take
> time to study this but I promise to dedicate some time soon.
Great, thanks; as long as I know that you've seen the message, I'm happy :)
> I was a bit confused as you use a function object in your example. Can't we
> take rid of that function object and apply it to free functions?
You can, but you would still need a function object to execute the visitor
pattern on the genrv object, since the visitor must be polymorphic (it must
accept many different argument types). Making the function object *both*
the visitor *and* the "housing" of the overload set is merely a convenience.
> How can we apply this to the constructor of an object?
Unfortunately, here the technique can get quite cumbersome. After thinking
a little about this, I think you'd have to be in one of the following
- Use no initializer lists, and perform the construction in an "init"
method. This should be okay for, e.g., pimpl classes.
- All member object(s) and base class(es) that receive the to-be-forwarded
argument can accept a genrv object.
- Use some kind of "typeless opaque storage" for all member object(s) that
receive the to-be-forwarded argument to delay initialization until the
constructor body. Should be strongly discouraged, but sometimes you gotta
do what you gotta do...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk