Boost logo

Boost :

Subject: Re: [boost] [variant] match()
From: Larry Evans (cppljevans_at_[hidden])
Date: 2015-01-10 10:22:59

On 01/09/2015 04:05 PM, Matt Calabrese wrote:> On Fri, Jan 9, 2015 at
1:24 PM, Larry Evans <cppljevans_at_[hidden]>
> wrote:
>> Which seems simpler to me. After all, implementing the
> discriminated union involves, at first, just the "primitives":
> I've implemented variant on top of discriminated_union and I've
> discriminated_union on top of variant. To be honest, both solutions
leave a
> lot to be desired although neither is particularly difficult to do. The
> types I actually use aren't built on one another, but are built on shared,
> lower-level constructs.
> 1) calculating the size an alignment of a buffer
> You actually don't do this when implementing a discriminated union type
> (nor variant) anymore. You need to use an *actual* union underneath the
> hood in order for some degree of constexpr-ness in places that it is
> possible.

Where is constexpr-ness needed? I used it to calcutate both
the size and alignment; however, since you're using these
"actual unions", you don't need this( as you say above).

> This is one reason for the union_ and destructible_union
> templates in my earlier reply (they use a cons-like recursive union
> structure underneath the hood, which is an approach that Eric Niebler
> suggested and that I've seen done elsewhere as well).

I'm guessing that this method of using "a cons-like
recursive union" is somewhat like how fusion or mpl does it;
however, wouldn't this require using the preprocessor to,
for example, generate something like:

  union actual_union0
    T0 m0;
    T1 m1;
    T9 m9;
  union actual_union10
    actual_union0 au0;//the recursion
    T10 m10;
    T11 m11;
    T19 m19;

? Is that even close to what you're describing?



Boost list run by bdawes at, gregod at, cpdaniel at, john at