[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: glr.c cleanup
From: |
Joel E. Denny |
Subject: |
Re: glr.c cleanup |
Date: |
Thu, 8 Dec 2005 02:58:56 -0500 (EST) |
On Thu, 8 Dec 2005, Hans Aberg wrote:
> On 8 Dec 2005, at 02:11, Joel E. Denny wrote:
>
> > > The "p" might be convenient if both variables are to be used side by side.
> > > However, also consider the multilingual issue: it won't be needed under
> > > C++.
> >
> > Because it will always be a pointer? Or because it will always be an
> > object?
>
> Under C++, I think one should have:
>
> namespace yy {
>
> class stack;
> ...
> }
This corresponds to yyGLRStack. yystack is *the* instance, and it's local
to yyparse(). For any function that needs a pointer to that yystack,
yystackp is the parameter name. For C, none of these are in the user
interface. Does this make sense?
> > > So in order to keep multilingual similarity, that suggests just naming it
> > > "yystack", without a "p". Names with a "p" added should then be reserved
> > > for C implementation variables, but not in the interface.
> >
> > I don't believe yystack is part of the interface.
>
> Under C++, one would be able to choose stack, with at least two standard
> choices: std::vector, and std::deque.
I see. I need to study this thing some day.
Joel
- Re: glr.c cleanup, (continued)
- Re: glr.c cleanup, Joel E. Denny, 2005/12/15
- Re: glr.c cleanup, Akim Demaille, 2005/12/16
- Re: glr.c cleanup, Joel E. Denny, 2005/12/30
- Re: glr.c cleanup, Paul Eggert, 2005/12/16
- Re: glr.c cleanup, Joel E. Denny, 2005/12/15
- Re: glr.c cleanup, Hans Aberg, 2005/12/07
- Re: glr.c cleanup, Joel E. Denny, 2005/12/07
- Re: glr.c cleanup, Hans Aberg, 2005/12/08
- Re: glr.c cleanup,
Joel E. Denny <=
- Re: glr.c cleanup, Hans Aberg, 2005/12/08
- Re: glr.c cleanup, Hans Aberg, 2005/12/08
- Re: glr.c cleanup, Hans Aberg, 2005/12/08
Re: glr.c cleanup, Paul Hilfinger, 2005/12/07
Re: glr.c cleanup, Paul Hilfinger, 2005/12/07