(no subject)

[haberg]

address@hidden> <address@hidden>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <address@hidden>
Cc: address@hidden
Content-Transfer-Encoding: 7bit
From: Hans Aberg <address@hidden>
Subject: Re: too many warnings from Bison CVS for Pike
Date: Sat, 11 Feb 2006 16:20:16 +0100
To: Paul Eggert <address@hidden>
X-Mailer: Apple Mail (2.746.2)

On 11 Feb 2006, at 07:38, Paul Eggert wrote:

>> Dynamic C-parserstack. This is what is Bison implements if
>> __cplusplus is not defined. However, this should work under C++ as
>> well
>
> Implementing that would be a feature enhancement, not a bug fix.
> I doubt whether it's worth the maintenance hassle.

I think so, too. It needs someone dedicated to the task, if tried.

> My advice, for someone who wants that sort of feature, is to use a
> C++-oriented skeleton instead of trying to limp along with yacc.c.
> yacc.c was not designed to work with C++, it does not work well with
> C++,

So I think, as well. People use, I think, the C-skeletons, because  
the C++ ones in the past have lagged behind.

> and I suspect it will never work well with C++.

It might work just as it should be, but one then ends up having to  
write a C++ container spread out in the C-code. One point with C++ is  
that one should not have to do such work, so one must find a  
programming fakir to do it.

>> - Also, there is an error in the comment of the block right above:
>> #  if defined (__STDC__) || defined (__cplusplus)
>> #   include <stdlib.h> /* INFRINGES ON USER NAME SPACE */
>> #   define YYSIZE_T size_t
>> I think this comment is due to the compiler I formerly used,
>
> No, it's because stdlib.h infringes on the C user's name space.  If
> you give bison -y a Posix-conforming yacc grammar, Bison normally
> attempts to impose no restrictions on user names, other than reserving
> YY* and yy*.  Including <stdlib.h> violates that rule, because
> stdlib.h defines names that begin with neither YY nor yy.

OK. When I see "namespace", I tend to forget this formal C++ concept  
comes from a technique used in C-programming as well. :-)

> I doubt whether including <stdlib.h> is 100% innocuous in C++, but
> that's not relevant here.

When the C++ "namespace" construction was new, some compilers, as a  
quick fix, added "using namespace std" to their C compatibility  
headers, which could cause radical name clashes. But one should only  
have additions to the names defined in those headers, making the  
problem not so big for correct compilers.

> yacc.c is designed for C, not C++,

I think this is how it should be, as well. :-)

There seems to be a not officially supported compile C as C++  
feature, though, by Akim's remark. I guess it will have to remain,  
for backwards compatibility. But the best for C++ programmers would  
be to switch entirely to a C++ skeleton, in view of the unusual C++  
semantics they will end up with in the case of the parser stack.

A thing that I do not know fully, is how C++ users that do use the  
compile C as C++ feature have their semantic type. I think that when  
you added the dynamic stack, some users using a non-POD semantic type  
ended up with a compile error due to the union you use, which is as  
it should be, due to the union hack you have, and so the dynamic  
stack was completely excluded from the compile C as C++ option.

But it could happen that some C++ users use a POD type, and would  
need a dynamic stack. If such a situation would occur, one might add  
that extra macro I suggested. The parser should then just work as is.

I can not pinpoint any specific user with this need, though, so just  
put this down as a just in case remark. Compile C as C++ users that  
use %union must have a POD semantic type, though.

> and its
> comments are aimed at C, not at C++.

OK. Fine.

   Hans Aberg