[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Token types with constructor
From: |
Laurence Finston |
Subject: |
Re: Token types with constructor |
Date: |
Fri, 27 Aug 2004 22:45:19 +0200 |
User-agent: |
IMHO/0.98.3+G (Webmail for Roxen) |
Hans Aberg 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.
> 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. C++ supports
this just as it supports your approach, and I'm pretty sure that I'm not
violating any of Stroustrup's recommendations for good practice in the use of
C++.
> 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.
Even if my recollection is faulty and the standards don't specify this so
strictly, I still want it to be possible.
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). If I were to use a custom skeleton file, I would be responsible for
maintaining it. 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. 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.
Laurence
- Token types with constructor, Martin Trautmann, 2004/08/25
- Re: Token types with constructor, Laurence Finston, 2004/08/25
- Re: Token types with constructor, Hans Aberg, 2004/08/27
- Re: Token types with constructor, Laurence Finston, 2004/08/26
- Re: Token types with constructor, Hans Aberg, 2004/08/27
- Re: Token types with constructor,
Laurence Finston <=
- Re: Token types with constructor, Martin Trautmann, 2004/08/28
- Re: Token types with constructor, Laurence Finston, 2004/08/28
- Re: Token types with constructor, Hans Aberg, 2004/08/29
- Message not available
- Re: Token types with constructor, Hans Aberg, 2004/08/31
- Message not available
- Re: Token types with constructor, Hans Aberg, 2004/08/29
Re: Token types with constructor, Hans Aberg, 2004/08/26