Re: [boost] Re: Automata builder -- interface

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2001-05-30 12:47:21

joel de guzman wrote:

> From: "Larry Evans":
>
> > joel de guzman wrote:
> >
> > > 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> ?
>
> Aggregates need not store subjects by value. A reference is fine since we
> know that the subject has a lifetime equal to or greater than the aggregate.
> Rules<> are composed by reference in Spirit. I such cases, the aggregate
> does not own the subject(s).

This will work for FIRST and NILABLE because they are synthesized attributes.
However, FOLLOW requires an inherited attribute, which can be stored as part
of some type of smart pointer.

Also, if references are stored in a rule, then wouldn't this cause a problem if
Rule1 references Rule2 and Rule2 references Rule1?  One or the other
must be created before a reference can be returned to it.  Am I missing something?