[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with multiple parsers
From: |
Laurence Finston |
Subject: |
Re: Problem with multiple parsers |
Date: |
Fri, 30 Jan 2015 11:30:16 +0100 |
Hello,
I tried defining YY_DECL as you suggested, but I still couldn't get it to work.
The program is already fairly complex so it's not easy to test just the
problem of getting multiple parsers to work together. If I find the time, I'll
try to set up a minimal example.
One problem is a `friend' declaration in a class declaration:
friend int yylex(YYSTYPE*, YYLTYPE*, yyscan_t);
(I'm generating C scanners and parsers and using them in a C++ program.)
Using `%name-prefix', this works for the other scanners (xxlex and zzlex), too.
That is, this single `friend' declaration works for all three scanner
functions.
When I try to use `%define api.prefix', I get various errors pertaining to
YYSTYPE, YYLTYPE, YY_DO_BEFORE_ACTION, YY_NEW_FILE, etc. I've tried using
`typedef' and `#define' to get rid of the errors, but nothing I've tried so far
works.
Would it be possible to "undeprecate" `%name-prefix'? I've been using it for
several years now and have been happy with the results. `%define api.prefix'
doesn't work the same way and if `%name-prefix' were to disappear, upgrading to
a new version of Bison would break my code. I dont know how many other people
would be affected by this.
Thanks,
Laurence
> Gesendet: Donnerstag, 29. Januar 2015 um 21:15 Uhr
> Von: "Akim Demaille" <address@hidden>
> An: "Laurence Finston" <address@hidden>
> Cc: "Bison Bugs" <address@hidden>
> Betreff: Re: Problem with multiple parsers
>
>
> > Le 29 janv. 2015 à 10:32, Laurence Finston <address@hidden> a écrit :
> >
> > Hello,
> >
> >> What version of Bison are you using?
> >
> > 2.6.5 and 3.0.2. I plan on installing 3.0.4 before too long.
>
> 3.0.2 is close enough :)
>
> >> prefix I guess.
> >
> > No, I actually meant a suffix, e.g., MESSAGE_YY, MESSAGE_ZZ, MESSAGE_XX for
> > tokens in three different parsers. I was assuming that the tokens were
> > defined as preprocessor macros. I think this was once the case, but I'm
> > not completely sure.
>
> Yes it was, but it also depends on the skeleton you
> use.
>
> > At any rate, I've now checked and found that they are not now.
>
> Well, indeed, it's probably not needed, and if you really
> want something like that, I would recommend checking
> api.token.prefix.
>
> http://www.gnu.org/software/bison/manual/html_node/_0025define-Summary.html
>
>
>
- Problem with multiple parsers, Laurence Finston, 2015/01/28
- Re: Problem with multiple parsers, Akim Demaille, 2015/01/29
- Re: Problem with multiple parsers, Laurence Finston, 2015/01/29
- Re: Problem with multiple parsers, Akim Demaille, 2015/01/29
- Re: Problem with multiple parsers,
Laurence Finston <=
- Re: Problem with multiple parsers, Akim Demaille, 2015/01/30
- Re: Problem with multiple parsers, Laurence Finston, 2015/01/30
- Re: Problem with multiple parsers, Akim Demaille, 2015/01/30
- Re: Problem with multiple parsers, Laurence Finston, 2015/01/30
- Re: Problem with multiple parsers, Akim Demaille, 2015/01/30