Re: too many warnings from Bison CVS for Pike

[Hans Aberg]

On 22 Feb 2006, at 09:09, Akim Demaille wrote:

> Supporting non-PODs is really tough to do properly.  We need
> something like Boost's variants.
>
> http://www.boost.org/doc/html/variant.html
>
> The portability issues are a bit frightening :(  If you care to  
> read the
> excellent material from A. Alexandrescu, you'll see what I mean.
> Fortunately we need something less advanced than this, so it should be
> really doable, but does require some time.
>
> http://www.cuj.com/documents/s=7984/cujcexp2004alexandr/
> http://www.cuj.com/documents/s=7982/cujcexp2006alexandr/
> http://www.cuj.com/documents/s=7980/cujcexp2008alexandr/

It is unlikely that one C++ model will be suitable for everyone. For  
example, the reason that I use a polymorphic hierarchy is not as  
workaround of Bison's limitations and the absence of a discriminating  
unions, but that the output of the parser should be computed  
dynamically. Thus, I cannot do away with it.

If I take quote of from the first link above:
> However, solutions of this sort are highly error-prone, due to the  
> following:
>
> Downcast errors cannot be detected at compile-time. Thus, incorrect  
> usage of downcast constructs will lead to bugs detectable only at  
> run-time.

One should be able to use static_cast together with Bison's static  
typing system, but making sure the hierarchy isn't derived as  
virtual. Then type errors should be detectable at compile time. One  
can then still use a polymorphic runtime variable.

But even when using dynamic_cast, no Bison static typing, where the  
errors only are detectable at runtime, I have found it not difficult  
to do correct programming.

> Addition of new concrete types may be ignored. If a new concrete  
> type is added to the hierarchy, existing downcast code will  
> continue to work as-is, wholly ignoring the new type. Consequently,  
> the programmer must manually locate and modify code at numerous  
> locations, which often results in run-time errors that are  
> difficult to find.
In the programming I do, this is what I want to happen: I get a set  
of major classes with structures that should be taken into account,  
but also minor classes derived from these, where their additional  
structure should be ignored in the parser types.
> Furthermore, even when properly implemented, these solutions tend  
> to incur a relatively significant abstraction penalty due to the  
> use of the heap, virtual function calls, and polymorphic downcasts.
This is indeed complicated. But I found some good template classes,  
making it not to difficult to add the major classes above.

In summary, if one does not need a dynamic polymorphic variable in  
the extra-parser computations, then a discriminating union will be  
useful. But it does not serve as a replacement in the case a dynamic  
polymorphic variable is needed.

  Hans Aberg