develooper Front page | perl.perl5.porters | Postings from January 2003

Re: Namespace Issues

Thread Next
Nick Ing-Simmons
January 26, 2003 09:46
Re: Namespace Issues
Message ID:
John Lenz <> writes:
>Hi.  We have been having a bunch of problems recently with SWIG 
>( and Perl 5.8.0.  I am running Debian unstable, 
>but we have also seen this problem on Solaris.  I have reduced the 
>problem to this short file
>#include "EXTERN.h"
>#include "perl.h"
>#include "XSUB.h"
>#include <iostream>
>int main() { return 42; }
>If you attempt to compile this file, a lot of errors having to do with 
>do_open are generated.  The problem is, <iostream> has a private 
>function of a class named do_open.  It took me a while to find because 
>here is private member of a class that is inside a namespace 
>conflicting with a define in the perl headers.  Normally, you could 
>just change the order of including the files, but for SWIG that is 
>difficult/impossible because the C++ file is generated and any input 
>file can tell SWIG to include <iostream> at any point in the file.

This is possibly a SWIG problem in that it could do a better job here.

I had not realized that:

/* NO_EMBED is no longer supported. i.e. EMBED is always active. */

made it into the mainline - this is a step backwards :-(

>So my question is, how can I get rid of all the macros polluting the 
>global namespace?  Since this is a generated file, we can take care of 
>the context stuff.  Really I just want a way to not include embed.h in 
>these files, and then use the perlapi though all the Perl_ and PL_ 
>macros so that perl stays in its own namespace.

The only thing I can suggest at present is to create a "noembed.h" 
and ask SWIG to include that before <iostream>. 
It would contain 

#undef do_open 


Nick Ing-Simmons

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About