Re: Problems with multithreading and slow compilation

[Laurence Finston]

On Wed, 7 Jul 2004, Hans Aberg wrote:

> At 19:22 +0200 2004/07/07, Laurence Finston wrote:
> >> What C++ file are you speaking about: The C one compiled as C++, the one
> >> that comes with the distribution, the one I wrote, or someone else.
> >
> >The one generated by running Bison on the Bison input file.  Of
> >course, it's only a C++ file by virtue of the C++ code in the actions.
>
> This is the C one compiled as C++. (As discussed before) it will break if
> you use C++ classes with nontrivial constructors in the parser semantic
> value, as the C parser stack does not know how to invoke those when
> reallocating.
>

I don't.  It's not possible because I use `%union' and "... a union
may not have members with constructors or destructors."
(Stroustrup, _The C++ Programming Language_, p. 257).  I use `void*' instead and
cast pointers to objects back and forth as needed.

> >> >  I've been meaning to try to put
> >> >more code for the actions into functions to see if this will help,
> >> >but since the return values of the functions must be tested in the rules,
> >> >it makes things more complicated and interferes with hacking.
> >>
> >> I am not sure what you mean here: Under C++, I try to put as much action
> >> code as possible into functions. As long as you do not change the header
> >> files of the functions and classes you call, the parser unit need only know
> >> these prototypes.
> >>
> >
> >I have to test whether the function succeeded or not and decide what to
> >do in each case.   However, I'm convinced that this is the way to go.
> >I've just got a huge number of actions for which I'm going to have to
> >write functions.
>
> This is what I do: The tests which must be done in the actions are clearly
> put in the actions. The other stuff is, as is deemed convenient, put into
> functions. To me, it is merely a way to structure the code.
>

Yes.  I just wish I'd started to do so earlier.

Laurence