Re: [boost] [variant] match()

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
implemented
> 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?
[snip]

TIA.

-regards,
Larry