> On 9 Apr 2018, at 16:55, Frank Heckenbach <[email protected]> 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.
