[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C++17 skeleton with move semantics and std::variant

From: Hans Åberg
Subject: Re: C++17 skeleton with move semantics and std::variant
Date: Mon, 9 Apr 2018 17:55:21 +0200

> On 9 Apr 2018, at 16:55, Frank Heckenbach <address@hidden> wrote:
> Hans Åberg wrote:
>>>> Akim Demaille gave two motivations on not using this: avoiding the
>>>> external dependency, and the overhead of storing the type. I think
>>>> that the C++17 variants may have the latter, but it is not so
>>>> important on modern computers.
>>> Yes, they do, and it's needed. That's exactly what fixes the
>>> problems with $<type> -- the type must be stored somewhere.
>>> Not storing the type seems a nifty idea with Bison which knows about
>>> the type most of the time, but it breaks down just there.
>> Perhaps there is a bug in %union in the same place then, as it does not 
>> store the type.
> I'm not so familiar with the C skeleton, but I think the difference
> is that %union is completely unchecked. Store foo, retrieve foo, all
> is fine; store foo, retrieve bar, get garbage (UB).
> Whereas the C++ skeleton adds some checking (only statically) which
> results in $<type> not working at all. If it didn't do that (that's
> where I wrote "if not for the previous bug"), the behaviour would be
> similar to the C version, just a bit worse when types with
> non-trivial constructors/destructors come into play.
> So for C++ we could either go back and disable the static type
> checking completely, or do full dynamic checking (which std::variant
> does by itself). I choose the latter. As you said, the performance
> impact should be small, and the safety benefit substantial. (If
> someone doesn't want it, they might be able to use an alternative
> variant implementation without checks, or not use variant at all
> ...)

That might be the difference: C++, unlike C, needs the types to select the 
right constructors. To get those and not only PODs was one motivation for 
introducing the variants.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]