From: dan marsden (danmarsden_at_[hidden])
Date: 2007-06-15 02:36:02
Eric Niebler wrote:
>Tobias Schwinger wrote:
>> Eric Niebler wrote:
>>>>> Is the sort of thing you are looking for?
>>>>> fused_ctor<T> fc;
>>>>> T t = fc(sequence);
>>> Yes, that's the thing.
>> OK, but why duplicate the unpacking of the Sequence?
>> All it takes is yet another adapter encapsulating a type's ctor(s) in a
>> function object to just use fusion::(invoke|fused)_function_object. E.g:
>> Client code (at function scope):
>> invoke_function_object( ctor<my_class>(), argseq );
>Yes, that's exactly it. Now, put it in Fusion so I don't have to write a
>function object with N overloads. :-)
So what is the interface that would be preferred. We can:
1) Provide class ctor<T> as part of the Fusion public interface, and let users
call invoke and create fused<ctor<T> > objects.
2) We can provide invoke_ctor<T> and fused_ctor<T>, implement them in terms of
a private detail::ctor<T>. This might be a bit more convenient for users, and
would give us more scope for optimizing this use case under the hood
3) Provide both
Personally I'd probably prefer 2 as its a bit less typing for users, and gives us
more implementation leeway, but I'm fine with 1 if others prefer it. I think the ctor shorthand
should be spelt construct as well, to make things a bit more friendly.
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk