Re: [PHP-DEV] [PATCH] New changes to ext_skel for C++

2002-12-04 Thread Stig S. Bakken
Isn't __cplusplus defined for all C++ compilers? #ifdef __cplusplus extern C { #endif #ifdef __cplusplus } #endif This is pretty common in library header files at least. - Stig On Mon, 2002-12-02 at 16:18, J Smith wrote: Taking a few comments into consideration, here's a new patch for

RE: [PHP-DEV] [PATCH] New changes to ext_skel for C++

2002-12-04 Thread Preston L. Bannister
That would be a big YES - as in practically all C++ compilers. It was a part of the draft ANSI standard for C++ for rather a long time (but not in the final standard?). -Original Message- From: Stig S. Bakken [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 1:23 AM Isn't

RE: [PHP-DEV] [PATCH] New changes to ext_skel for C++

2002-12-04 Thread Sascha Schumann
On Wed, 4 Dec 2002, Preston L. Bannister wrote: That would be a big YES - as in practically all C++ compilers. It was a part of the draft ANSI standard for C++ for rather a long time (but not in the final standard?). Page 309, 16.8 Predefined macro names, of ISO/IEC 14882:1998 lists

Re: [PHP-DEV] [PATCH] New changes to ext_skel for C++

2002-12-04 Thread J Smith
As others have pointed out, it is, but I think it would be better to simply have the code there in the generated C++ source and not at all in the C source. It would lead to less confusion imho. I guess it should kind of be assumed that if someone is going the distance to actually create an

[PHP-DEV] [PATCH] New changes to ext_skel for C++

2002-12-02 Thread J Smith
Taking a few comments into consideration, here's a new patch for adding C++ code-generating abilities to ext_skel. The new patch doesn't use a separate skeleton.cpp file. Instead, it adds some lines like /* __begin_extern_c__ */ /* __end_extern_c__ */ to skeleton.c and lets ext_skel either

Re: [PHP-DEV] [PATCH] New changes to ext_skel for C++

2002-12-02 Thread Zeev Suraski
Why not just use BEGIN_EXTERN_C() and END_EXTERN_C()? Zeev At 17:18 02/12/2002, J Smith wrote: Taking a few comments into consideration, here's a new patch for adding C++ code-generating abilities to ext_skel. The new patch doesn't use a separate skeleton.cpp file. Instead, it adds some lines

Re: [PHP-DEV] [PATCH] New changes to ext_skel for C++

2002-12-02 Thread J Smith
For the second instance where extern C is used, that would be possible, but in the first instance, BEGIN/END_EXTERN_C() aren't defined yet, as they're in zend.h. The compiler would totally barf. I had used BEGIN/END_EXTERN_C() in the first patch I sent out, but decided to use one or the other

Re: [PHP-DEV] [PATCH] New changes to ext_skel for C++

2002-12-02 Thread Zeev Suraski
Why do we need an extern c before php.h? The relevant API functions in php.h should be extern cd in my opinion, wrapping php.h up in extern c is not very clean. Zeev At 17:32 02/12/2002, J Smith wrote: For the second instance where extern C is used, that would be possible, but in the first

Re: [PHP-DEV] [PATCH] New changes to ext_skel for C++

2002-12-02 Thread J Smith
I seem to remember having problems the last time I tried that. With gcc, you get relocation errors, missing symbols, all sorts of craziness. (I just checked with an extension compiled as a shared objected -- without extern c-ing php.h, I got an undefined symbol on