Re: beta testing

[Hans Aberg]

At 12:43 +0100 2001/02/21, Philippe Bekaert wrote:
>> I do not use unions with C++: You could just as well make use of a derived
>> hierarchy, and have a few extra fields, if the items are not to big.
>Unfortunately, that's what bison and yacc generate. I would like to use
>that because in this way, the YYSTYPE data structure is automatically
>updated in all of my code whenever the union declaration in the bison
>script is changed.

If you like the unions, use them, but there is no requirement to use them.
(I think the point with unions is that one can get a type check, and ensure
that the YYSTYPE data becomes smaller.) If you write in a header that is
included from your .y file
  class my_type {
  ...
  };
  #define YYSTYPE my_type
that will be updated whenever you change a field in the class. Or what do
you mean?

>> Actually, I have absolutely no idea of what the final C++ support will look
>> like.
>Who decides about this? People on this list I hope??

I am not at the helms, so you will have to wait for a reply from Akim. I
think one problem is finding someone willing to do the job.

>> But before we know what will happen with Bison C++ support, your ideas are
>> as good as that of any. -- Please report here, if you succeed to implement
>Can you give me some information what others have proposed?

It is best looking in the archives of the Bison help & bugs list, I think.

>> a working version. (The easiest way would be to have a single unchanging
>I have a working version already! Just the documentation is lacking. But
>before I start writing that, I'd like to know whether it makes sense or
>not.

Well, it must be sufficiently general, so that it suits _everybodys_ needs.
This is some of the things Akim has been working on, removing restraints on
the code, so that one can have more general arguments, etc.

>> header file, like the Flex FlexLexer.h header. In my opinion, though, it
>> would be better to write a correct header for each program that Bison
>> produces. Then, producing a corresponding FlexLexer.h header file would be
>> the first step.)
>Nothing needs to be changed to FlexLexer.h.

You misunderstood, I meant the "BisonParser.h" file when I said "a
corresponding FlexLexer.h header file".

>Note that I can solve the problem of generating parser objects already.
>I am however working on a project which I'd like to distribute freely.
>The project an extensible scene graph library for computer graphics
>applications,  to be released under one of the GNU licenses. The ability
>to write your own importer filters is an essential part of this project,
>having bison generated parsers cleanly implemented and co-existing with
>each other in parser objects. Therefore, I need bison support for
>generating parser objects.

Check with Akim about that, he seems to know that licence stuff. :-)

>I will comply with whatever way to generate C++ parser objects you come
>up. I do not insist on you taking over the way I solved the problem. But
>please come up with something soon. I don't see why it should take so
>long: you get the job done with extremely simple and limited and
>compatible updates to the latest bison release.

I am not at the GNU helms. Most seems to be happy to compile the .tab.c
file as C++ (I do), which is perhaps one reason it takes so long getting
C++ classes written.

If you write something I would happy to see that; but wait till Akim (which
is the man working on the current version) gives a reply.

  Hans Aberg