|
Boost : |
Subject: Re: [boost] [variant] match()
From: Larry Evans (cppljevans_at_[hidden])
Date: 2015-01-09 16:24:25
On 01/09/2015 12:35 PM, Matt Calabrese wrote:
> On Fri, Jan 9, 2015 at 9:52 AM, Eelis <eelis_at_[hidden]> wrote:
>
[snip]
>
>> What we need is sum types. C++ unions are sort of sum types, but they're
>> crap, so variant<> is our C++ workaround.
>>
>
[snip]
>
> That's not why a variant has no repeated types.
I thought it didn't allow repeated types because accessing
by the type would then be ambiguous. IOW, for variant<T,T>,
which element would get<T>(variant<T,T>*) get, the 1st or
2nd?
[snip]
>> This means variant<> fails to be the building block that sum types
>> can/should be
>
>
> Not true. It is trivial to build a generalized discriminated union on top
> of variant. All you do is have the discriminated_union<T0, T1, T2, ...>
> template contain a variant<wrapper<T0, 0>, wrapper<T1, 1>, wrapper<T2,
> 2>...>.
Sure, but then all the template progamming designed to get
the discriminant based on type becomes redundant.
> It is also trivial to go the other way around -- build a variant on
> top of discriminated_union.
Which seems simpler to me. After all, implementing the
discriminated union involves, at first, just the "primitives":
1) calculating the size an alignment of a buffer
2) using the tag to find the right type in a type list as
in the mpl::at_c<tag>:
http://www.boost.org/doc/libs/1_31_0/libs/mpl/doc/ref/Reference/at_c.html
Using variant, step 1 is the same, but how is step 2
implemented? It seems it would involve a metaprogram to
search through the bounded types to find a match. Isn't
that more complicated and compile-time intensive? Why not
1st do the simpler discriminated union, and then, if someone
wants the type variant, implement that on top of the
discriminated union?
> That said, in practice, I've personally found
> it best to build them both from scratch on top of
> lower-level primitives
Could you describe the lower-level primitives?
[snip]
-regards,
Larry
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk