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 ext
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
list
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 __c
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 add
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 zend_register_list_destructors
Why do we need an extern c before php.h? The relevant API functions in
php.h should be extern "c"d 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 fi
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 othe
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 l
