|
Boost : |
From: Larry Evans (jcampbell3_at_[hidden])
Date: 2001-05-30 11:09:47
joel de guzman wrote:
> From: "Vladimir Prus" :
> >
> > 4. Polymorphism.
> >
> > >> If I understood Douglas correctly, he proposes just the opposite :-).
> > >> I really don't think that runtime polymorphism will cost much -- it is
> not
> > >> used in the most critical parts.
> >
> > >Actually, I'm agreeing with Joel on this :). We'd be better off with
> static
> > >(compile time) polymorphism as far as we can take it.
> >
> > What's motivation? As I stated in point 1 above, Grammar::Symbol is
> > completely non performace critical. The only other place where 'virtual'
> > appears is 'reduction' method. Think we need some profiling there.
> >
>
> It's not just the performance. It is also the flexibility. The Spirit
> framework uses compile time polymorphism as much as possible.
> My experience is that pointers (needed for runtime polymorphism)
> are *not* needed anymore. The type says it all. And arbitrary types
> can be composes and structured, using template techniques, to
> form more complex types.
>
> Thus there is no *encapsulating* class in the Spirit framework,
> such as the BNF class in your proposal, that is needed to manage
> the lifetime of the rules. Rules are stand-alone in the Spirit framework
> and are dealt with by value, instead of by pointer or reference, which
> would otherwise require garbage collection or reference counting,
> which is another potential performance problem to take into scrutiny.
>
You could probably do it some other way, but I think use of pointers would
be more programmer friendly. I think one problem with using just values is
that each instance of, say variable X (variable means non-terminal),
is distinct throughout all occurrences in the grammar. However, to create an
LL(1) parser, each variable needs to be annotated with FIRST and FOLLOW
and NILLABLE attributes. So if each X is distinct, in which X will these attributes be
stored? Or maybe in some map<X,LL1attributes> ?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk