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

[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 extension to PHP, they're probably going to know what 
__cplusplus, extern "C" and all that stuff means, but on the other hand, 
I've seen (and received) some pretty ridiculous questions on that sort of 
stuff dealing with PHP extensions directly.

J


Stig S. Bakken wrote:

> 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
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 __cplusplus

"[..] as being defined to the value 199711L when compiling
a C++ translation unit."

- Sascha


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 __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


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 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 replace them with the proper C++ 
> stuff or get rid of it altogether. I didn't want to make the extname.c 
> output any more complicated with #ifdef __cplusplus preprocessor nonsense, 
> 'cause having extension first-timers asking why there's C++ stuff in their 
> C file would suck.
> 
> Another slight change to skeleton.c just gets rid of the string named 
> "string" and replaces it with "str". This is just to get rid of any 
> conflict that might come up if someone #includes the C++ string library in 
> their extension, so they don't need to worry about C-string named "string" 
> being confused with the C++ data type "string".
> 
> Comments?
> 
> J
> 
> 
> __
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 zend_register_list_destructors.) 

On Windows, I'm not even sure if VC++ would compile, but it's been a while 
since I checked. I'm pretty sure it had kittens over the non-extern-c-ed 
stuff.

Fixing the API functions in php.h would definitely be the way to go, but I 
wasn't sure if I should go there, as I haven't had any problems yet with 
wrapping the whole thing up in extern C's. 

J


Zeev Suraski wrote:

> 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
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Zeev Suraski]

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 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 in this one for the sake of consistency.

J


Zeev Suraski wrote:

> Why not just use BEGIN_EXTERN_C() and END_EXTERN_C()?
>
> Zeev
>


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 in this one for the sake of consistency.

J


Zeev Suraski wrote:

> Why not just use BEGIN_EXTERN_C() and END_EXTERN_C()?
> 
> Zeev
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 like

/* __begin_extern_c__ */
/* __end_extern_c__ */

to skeleton.c and lets ext_skel either replace them with the proper C++
stuff or get rid of it altogether. I didn't want to make the extname.c
output any more complicated with #ifdef __cplusplus preprocessor nonsense,
'cause having extension first-timers asking why there's C++ stuff in their
C file would suck.

Another slight change to skeleton.c just gets rid of the string named
"string" and replaces it with "str". This is just to get rid of any
conflict that might come up if someone #includes the C++ string library in
their extension, so they don't need to worry about C-string named "string"
being confused with the C++ data type "string".

Comments?

J


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 replace them with the proper C++ 
stuff or get rid of it altogether. I didn't want to make the extname.c 
output any more complicated with #ifdef __cplusplus preprocessor nonsense, 
'cause having extension first-timers asking why there's C++ stuff in their 
C file would suck.

Another slight change to skeleton.c just gets rid of the string named 
"string" and replaces it with "str". This is just to get rid of any 
conflict that might come up if someone #includes the C++ string library in 
their extension, so they don't need to worry about C-string named "string" 
being confused with the C++ data type "string".

Comments?

J


Index: ext_skel
===
RCS file: /repository/php4/ext/ext_skel,v
retrieving revision 1.44
diff -u -3 -p -r1.44 ext_skel
--- ext_skel	18 Nov 2002 15:55:07 -	1.44
+++ ext_skel	2 Dec 2002 15:08:10 -
@@ -7,7 +7,7 @@ givup() {
 
 usage() {
 echo "$0 --extname=module [--proto=file] [--stubs=file] [--xml[=file]]"
-echo "   [--skel=dir] [--full-xml] [--no-help]"
+echo "   [--skel=dir] [--full-xml] [--no-help] [--cpp]"
 echo ""
 echo "  --extname=module   module is the name of your extension"
 echo "  --proto=file   file contains prototypes of functions to create"
@@ -18,6 +18,7 @@ echo "  --full-xml generate xml 
 echo " (not yet implemented)"
 echo "  --no-help  don't try to be nice and create comments in the code"
 echo " and helper functions to test if the module compiled"
+echo "  --cpp  create a C++ extension"
 exit 1
 }
 
@@ -58,6 +59,9 @@ while test $# -gt 0; do
 --skel=?*)
 	skel_dir=$optarg
 	;;
+--cpp)
+cpp="yes"
+;;
 *)
 	usage
 	;;
@@ -94,7 +98,7 @@ if test -z "$stubs"; then
 fi
 
 if test -n "$proto"; then
-  cat $proto | awk -v extname=$extname -v stubs=$stubs -v stubfile=$stubfile -v xml=$xml -v full_xml=$full_xml -v i_know_what_to_do_shut_up_i_dont_need_your_help_mode=$no_help -f $skel_dir/create_stubs
+  cat $proto | awk -v extname=$extname -v stubs=$stubs -v stubfile=$stubfile -v xml=$xml -v full_xml=$full_xml -v i_know_what_to_do_shut_up_i_dont_need_your_help_mode=$no_help -v cpp=$cpp -f $skel_dir/create_stubs
 fi
 
 if test -z "$stubs"; then
@@ -165,11 +169,16 @@ if test "\$PHP_$EXTNAME" != "no"; then
   dnl ])
   dnl
   dnl PHP_SUBST(${EXTNAME}_SHARED_LIBADD)
+eof
 
-  PHP_NEW_EXTENSION($extname, $extname.c, \$ext_shared)
+if test "$cpp" = "yes"; then
+  echo "  PHP_REQUIRE_CXX()" >>config.m4
+  echo "  PHP_NEW_EXTENSION($extname, $extname.cpp, \$ext_shared)" >>config.m4
+else
+  echo "  PHP_NEW_EXTENSION($extname, $extname.c, \$ext_shared)" >>config.m4
 fi
-eof
 
+echo "fi" >>config.m4
 
 $ECHO_N " .cvsignore$ECHO_C"
 cat >.cvsignore <.cvsignore < sedscript
 echo "s/EXTNAME/$EXTNAME/g"  >> sedscript
+
+if test "$cpp" = "yes"; then
+echo "s/\/\* __begin_extern_c__ \*\//extern \"C\" {/" >> sedscript
+echo "s/\/\* __end_extern_c__ \*\//}/" >> sedscript 
+else
+echo "s/\/\* __begin_extern_c__ \*\///" >> sedscript
+echo "s/\/\* __end_extern_c__ \*\///" >> sedscript
+fi
+
 echo '/__function_entries_here__/r function_entries'  >> sedscript
 echo '/__function_stubs_here__/r function_stubs'  >> sedscript
 echo '/__header_here__/r ../../header'  >> sedscript
@@ -189,6 +211,7 @@ echo '/__function_entries_here__/D'  >> 
 echo '/__function_stubs_here__/D'  >> sedscript
 echo '/__header_here__/D'  >> sedscript
 echo '/__footer_here__/D'  >> sedscript
+
 if [ ! -z "$no_help" ]; then
 echo "/confirm_$extname_compiled/D" >> sedscript
 echo '/Remove the following/,/^\*\//D' >> sedscript
@@ -197,7 +220,11 @@ if [ ! -z "$no_help" ]; then
 echo '/^[[:space:]]*\/\*/,/^[[:space:]]*\*\//D' >> sedscript
 fi
 
-sed -f sedscript < $skel_dir/skeleton.c > $extname.c
+if test "$cpp" = "yes"; then
+sed -f sedscript < $skel_dir/skeleton.c > $extname.cpp
+else
+sed -f sedscript < $skel_dir/skeleton.c > $extname.c
+fi
 
 
 $ECHO_N " php_$extname.h$ECHO_C"
@@ -273,7 +300,15 @@ To use your new extension, you will have
 4.  $ ./configure --[with|enable]-$extname
 5.  $ make
 6.  $ ./php -f ext/$extname/$extname.php
-7.  $ vi ext/$extname/$extname.c
+eof
+
+  if test "$cpp" = "yes"; then
+  echo "7.  $ vi ext/$extname/$extname.cpp"
+  else
+  echo "7.  $ vi ext/$extname/$extname.c"
+  fi
+
+  cat <
-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php