Re: Token types with constructor

[Hans Aberg]

At 22:45 +0200 2004/08/27, Laurence Finston wrote:
>> That is OK, but it will not deallocate during error recovery.
>
>As long as the errors don't cause dynamically allocated memory to become
>unreferenced, i.e., as long as I still have access to the objects represented
>by the `$<number>' symbols in the rule, either by means of those symbols or in
>other ways, I will be able to recover it.  I will have to see how this works
>in practice.

When doing this under C, one will have to use special implementations to
keep such references. This is why the %destructor option was created, to
simplify that.

>> 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 don't agree that I'm not using C++ "in full" just because I choose to handle
>allocation and deallocation explicitly in my parser actions.

I just tried to find a wording expressing the difference between the
approach of using C++ destructors and not using them in the parser stack.
Otherwise, few programmers use C++ in full in its literal sense, but tend
to select a subset useful to them.

>> 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.
>
>No, it doesn't. I believe that, according to the GNU Coding Standards, it
>should be possible for users to build GNU packages from the sources.

The normal thing is to set it up so that users do not have to have Bison,
but can use it if they insist. For example, Bison itself comes with
pre-compiled .y files, so that an earlier Bison version is not needed when
installing Bison.

>I do assume that Bison is present, as it should be on a normal GNU or
>GNU/Linux system (I'm assuming Bison has been ported to the Hurd;  I don't
>know).

It should, but as some of the Help-Bison queries have revealed, the
installation might be old, or M4 might be amiss. Assuming people use your
program, you will become flooded with a lot of repeat questions about this.

>If I were to use a custom skeleton file, I would be responsible for
>maintaining it.

Right, as you are responsible for maintaining all other files in the
distribution.

>While I have read the M4 manual, all I've done with M4 so far
>is to write a little code for my `configure.ac' file.

One does not need to know much about M4 if one merely modifies an existing
skeleton file a little.

>Nor do I have any
>understanding at all of Bison's internals.  Since I have plenty to do on my
>own project, I'm not about to start learning how to write skeleton files
>unless there's a really pressing reason to do so.

M4 was added to Bison so that it should be easy for individuals to write
customized skeleton files.

  Hans Aberg