[Top][All Lists]

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

Re: too many warnings from Bison CVS for Pike

From: Hans Aberg
Subject: Re: too many warnings from Bison CVS for Pike
Date: Thu, 23 Feb 2006 21:34:37 +0100

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.


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.


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

reply via email to

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