Re: Token types with constructor

[Hans Aberg]

At 23:44 +0200 2004/08/26, Laurence Finston wrote:
>> Yes, your approach essentially avoids using C++ constructors. One
>> shortcoming with this approach is that one cannot use C++ automatics to
>> deallocate free store objects. So if one uses such objects pointed at by
>> void*, one has to deallocate them by hand in the rule actions, plus using
>> the experimental %destructor option to deallocate them during error
>> recovery, that is, if it is essential for your program to avoid memory
>> leaks.
>
>I don't use `%destructor'.  I haven't checked whether it's in the version I'm
>using (1.875, I believe).  My manual is a bit out-of-date.  I haven't started
>working on recovery from parse errors, but I may do deallocation  there by
>hand, anyway, assuming this is possible.

Not really. That is why the %destructor(s) option was invented.

>I use `new' and `delete' explicitly in the actions, so I am using constructors
>and destructors, it's just under my control rather than under that of
>`yyparse()'.  I like to program this way.

That is OK, but it will not deallocate during error recovery.

>  Others who don't should probably
>use your patch.

Right. That is one of the conveniences that C++ offer. Doing it by hand
should produce somewhat faster code, though.

>> Even though my parser is not thread safe, it should be easy to make it so,
>> by merely moving the parser stack into the function. Also, perhaps change
>> std::vector to std::deque.
>
>I'm not criticizing your approach, but I'm happy with mine.

There is nothing wrong with your approach: It is essentially the C-doing it
by hand, which is preferred by some as it should produce somewhat more
efficient code. My C++-in-full approach is more convenient, as one will
have to do less coding by hand.

>I believe that my approach has advantages, too, but what really clinches the
>matter for me is that I must use a stable release.
>If your changes are merged into a stable release, then one could decide which
>approach was most suitable to the given task.
>Until then, people who need to use stable releases won't be able to use your
>approach.

Bison is now in its M4 skeleton approach sufficiently stable that writing
ones own version is no stranger than writing ones own source file for any
compiler. And a program distribution should normally come with an already
Bison compiled parser, so installer do not need Bison installed on the
system. This makes your concerns for a stable Bison release going away.

The big hurdle for fixing a proper C++ skeleton file is that I had to tweak
Bison enabling one to put C++ code in various places. For efficient C++
implementations, I need to add a %code option, that allows one to put code
in even more places. I can't do that right now, so my C++ skeleton ideas
will have to be put onto the future for now.

  Hans Aberg