[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: too many warnings from Bison CVS for Pike

From: Hans Aberg
Subject: Re: too many warnings from Bison CVS for Pike
Date: Mon, 20 Feb 2006 20:08:05 +0100

On 20 Feb 2006, at 15:39, Akim Demaille wrote:

"Hans" == Hans Aberg <address@hidden> writes:

On 13 Feb 2006, at 20:41, Paul Eggert wrote:
I said that I recall you use(d), under C, memcpy to reallocate the
parser stack.

No, not if the compiler defines __cplusplus. If the compiler defines
__cplusplus, yacc.c does not use memcpy at all.

(I don't remember why it's like this,

Because it has always been so, and you, according to you earlier comment about "an effort is made sure it compiles under C++", which I gather can only refer to your own checks, is giving support to it. Paul Eggert later extended this original static C-parserstack to becoming dynamic. Apparently is is used alos as C++ code automatically when invoking %union.

but it's already something that
seems to be too much in favor of C++: I would have used memcpy.)

I saw that, and that is also inherent in the comments I made: When
compiled using a C++ compiler, only the static C-parserstack is used,
which does not use memcpy. This leads to a non-standard C++ container
semantics, as the whole array is initialized when first created at
parser invocation, and when the stack shrinks, only a pointer to the
array is changed, so the C++ destructors will not be invoked. A
proper C++ container would do these things immediately at need only
as the stack grows and shrinks.

You're referring to yacc.c, and all your comments about how to do C++
using yacc.c is irrelevant and a pure waste of time.

You are one wasting time, then by making sure it compiles under C++.

If you want to
play C++, use lalr1.cc, period. If you don't like it, use another.

I can't use it, nor another one, because I did not get the code placement version of %define. Neither can I nor you use the Bison static type system with C++ non-POD's. What is happening there?

But let's stop this useless debate and go back to work.

I am in favor of dropping the compile C as C++ option altogether, and I figure so is Paul Eggert. You are then the one wasting other peoples time by insisting on having this option supported.

  Hans Aberg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]