|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-11-05 21:43:39
Eric Friedman <ebf_at_[hidden]> writes:
> David Abrahams wrote:
>> Eric Friedman <efriedman_at_[hidden]> writes:
> [snip]
>>>Unfortunately, I don't have any better ideas. Maybe for now I'll just
>>>go with variant< variant_types<seq> >, as ugly as I find it.
>> I think I'm with Peter Dimov, if I understood him correctly. For
>> interoperability reasons, it has to be a metafunction.
>
> What do you mean by 'interoperability reasons'?
For example, what if I want to make an MPL lambda expression which
produces a variant from a list of types?
variant< variant_types<_1> >
might work on conforming compilers, provided neither variant nor
variant_types has a nested ::type member. It won't work if there is a
nested ::type, or at all on the more broken compilers.
> Regardless of whether the public interface is a metafunction or not,
> ultimately the created type will need to be some form of variant<
> ... > to retain compatibility with 'plain' variants.
Sure.
> (FYI, this is similar to the approach I use for the
> recursive_variant metafunction.)
>
>> boost::variant_over<type-seq>::type
>> ??
>
> Sure, that looks nice (for the public interface).
Good!
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk