Boost logo

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