[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(no subject)
From: |
haberg |
Subject: |
(no subject) |
Date: |
Sat, 11 Feb 2006 15:39:59 -0500 |
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
- Re: too many warnings from Bison CVS for Pike, Paul Eggert, 2006/02/11
- Re: too many warnings from Bison CVS for Pike, Paul Eggert, 2006/02/13
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/02/13
- Re: too many warnings from Bison CVS for Pike, Paul Eggert, 2006/02/13
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/02/14
- Re: too many warnings from Bison CVS for Pike, Paul Eggert, 2006/02/14
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/02/14
- Re: too many warnings from Bison CVS for Pike, Akim Demaille, 2006/02/20
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/02/20
- Re: too many warnings from Bison CVS for Pike, Akim Demaille, 2006/02/20
- Re: too many warnings from Bison CVS for Pike, Hans Aberg, 2006/02/20