Re: Problems with multithreading and slow compilation

[Hans Aberg]

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'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.

>> It sounds as though you have put too much code into the actions. As an
>> alternative, get hold of a faster computer. :-)
>>
>
>But I like the ENIAC!

I doubt Bison runs on ENIAC! :-)

  Hans Aberg