Re: bison'd files don't compile under Microsoft VC++

[Hans Aberg]

At 11:50 -0800 2002/02/14, Paul Eggert wrote:
>> On the one hand there is the historical question who wrote the Bison parser
>> C dynamic stack; I thought it was Akim, but he says it was not.
>
>I believe it was originally Robert Corbett, though I think Richard
>Stallman was responsible for making it conform to standards (e.g. in
>the matter of name spaces).

I am only speaking about the dynamic stack part, not the whole Bison
program. -- Your history applies to the whole Bison program.

But I think somewhere a skeleton file without the dynamic stack
(bison.hairy), but only the stack array, so I think it was not with Bison
from the beginning.

>> So the failure does not have anything to do with the code as such, because
>> it could be easily made working,
>
>It depends on what you mean by "easily".  We have been trying this
>approach for a couple of months and it's still not working.

Just as you said in the other email, the namespace and headers issue could
be easily solved, but not the dynamic stack issue.

>  I
>initially approved of this approach because I thought it was a simple,
>portable change, but I am not a C++ expert and it's clear that I was
>mistaken.

I think you are just a bit confused by the C++ namespace issue. :-)

>If we had a lot of programmers who were willing to test this approach
>on a lot of different compilers, then I suppose it might be done
>"easily".  But I am skeptical that either your patch, or dgluss's
>patch (which merely fixes the problem for certain Microsoft
>platforms), will be widely portable; whereas the patch that I've
>proposed will basically revert to the way Bison used to do things, and
>this has apparently worked for many years, so I have more confidence
>in its portability.

As I said before, if now the genuine C++ support is around the corner,
within two months, then I do not see myself any need for the current to
support C++. Then all that stuff could be stripped out of it.

I do not use the compile C as C++ feature, as I wrote my own C++ stuff.

Basically, I do not care myself. If the real C++ support is coming soon
like less than two months, can't people just use their own patches in that
time?

If you do not want to strip out the namespace stuff, then the patch might
look like:
#ifdef __cplusplus && !defined YYNO_NAMESPACE
# define YYSTD(x) std::x
#else
# define YYSTD(x) x
#endif

and similarly:

#  ifdef __cplusplus && !defined YYC_HEADERS
#   include <cstdlib> /* INFRINGES ON USER NAME SPACE */
#   define YYSIZE_T YYSTD(size_t)
#  else
#   ifdef __STDC__
#    include <stdlib.h> /* INFRINGES ON USER NAME SPACE */
#    define YYSIZE_T YYSTD(size_t)
#   endif
#  endif

Then, #define YYNO_NAMESPACE will get rid of the std:: namespace, and
#define YYC_HEADERS will makes sure <stdlib.h> is included instead of
<cstdlib>.

Then dgluss's MS patch would be:
#ifdef _WIN32
# define YYNO_NAMESPACE
# define YYC_HEADERS
#endif

But I feel it is very improbable that a newly released C++ compiler does
not have namespaces, even if it is MS's. I just can't believe that is so.
And why can't MS users write in that themselves the next two months, if no
the compiler does not use namespaces?

But if you want to strip all that C++ stuff, that is OK.

I think though that the best strategy would be to make as few changes as
possible with respect to C++ right now, while awaiting the real C++
support. (But the namespace and headers issue would remain under the
genuine C++ support. So one might want some such macros still then.)

  Hans Aberg