From dave at boost-consulting.com  Thu Sep  1 02:56:14 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 31 Aug 2005 20:56:14 -0400
Subject: [C++-sig] what does this message mean?
References: <20050831173448.98873.qmail@web30704.mail.mud.yahoo.com>
Message-ID: <uirxlzjv5.fsf@boost-consulting.com>

"Alexis H. Rivera-Rios" <ahrivera at yahoo.com> writes:

> Can somebody explain why this message occurs?
>
> aclass.MyFunction(object1, object2)
> did not match C++ signature:
>     MyFunction(class A{lvalue}, class
> boost::shared_ptr<B> >)

That's not the actual message, is it?  The first line looks specific.

> I get the error when object2 is a python class that
> implements the interface specified by B.

the problem is that you're calling a C++ function.
"Implements the interface" isn't enough; it needs to be an instance of
the Python class that wraps B, and its __init__ function needs to have
been called to initialize the contained C++ B object.  IOW, there has
to be a real, C++ B object there.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From allenb at vrsource.org  Thu Sep  1 22:12:58 2005
From: allenb at vrsource.org (Allen Bierbaum)
Date: Thu, 01 Sep 2005 15:12:58 -0500
Subject: [C++-sig] Is there a way to automatically convert a smart_ptr to
	held type
Message-ID: <431760CA.3080101@vrsource.org>

I am wrapping a C++ library with boost.python that has multiple types of 
smart ptrs for it's objects.  It has a ptr<> type that holds the object 
and provides a ref counting interface (through and addRef()/subRef() 
interface).  It then has a ref_ptr<> type that acts like a "standard" 
smart pointer by holding a ptr<> internally and calling the ref handling 
operations upon construction and destruction.

To correctly handle the memory for the objects, I want my boost.python 
class wrappers for a class T to be held using ref_ptr<T>.  I can do this 
with:

class_<T, bases<...>, ref_ptr<T> >("T",...);

This all works fine.

I run into a problem though when I want to use wrapped method that 
return ptr<>'s to objects instead of a full ref_ptr<>.

For example if I wrap a method like this:

ptr<Base> createObject()
{ ... }

then when I call this from boost.python it needs to figure out that it 
should convert the ptr<Base> to a ref_ptr<Base>.  I know that I can use 
register_ptr_to_python<ptr<Base> > to register a to_python converter for 
the type, but as I understand it this will cause the python wrapper to 
store the C++ object using a ptr<> type internally.  This won't work 
correctly because it will not do any memory reference counting.

What I need is a way to tell boost python that anytime it needs to 
convert a ptr<Base> to python it should first convert it to a 
ref_ptr<Base>  (using a standard copy constructor in ref_ptr<>) and then 
use this ref_ptr as the held type like normal.

At first I thought that implicitly_convertible<> would help:

implicitly_convertible<ptr<Base>, ref_ptr<Base> >();

But this doesn't seem to do anything for me. (this really isn't too 
surprising since this isn't what implicitly_convertible is for, but it 
seemed worth a try).

Has anyone else ran into anything similar?  Any ideas?

Thanks,
Allen


From allenb at vrsource.org  Thu Sep  1 23:39:47 2005
From: allenb at vrsource.org (Allen Bierbaum)
Date: Thu, 01 Sep 2005 16:39:47 -0500
Subject: [C++-sig] Finalizing an entire class with Pyste and Boost.Python
Message-ID: <43177523.5070608@vrsource.org>

Is there any way with Pyste to mark an entire class as finalized (ie. 
not create a wrapper class for virtual methods)?

-Allen


From Nicolas.Rougier at loria.fr  Fri Sep  2 14:35:31 2005
From: Nicolas.Rougier at loria.fr (Nicolas P. Rougier)
Date: Fri, 2 Sep 2005 14:35:31 +0200
Subject: [C++-sig] c++ bool  to python bool
Message-ID: <20050902143531.16d4274b.Nicolas.Rougier@loria.fr>



Hello,

This is certainly a newbie question but how do I get boost python to
wrap a c++ bool type to a python bool type ?

Here is what I tried:

#include <boost/python.hpp>
class Boolean {
public:
    Boolean (bool v) : value(v) {}
    bool value;
};

BOOST_PYTHON_MODULE(boolean) {
    using namespace boost::python;
    class_<Boolean>("Boolean", init <bool>() ) 
        .def_readwrite ("value", &Boolean::value);
}

But the value property is considered as being an 'int' in python (and
it's important for me to get the right type). I saw that boost python
changelog indicates support for python's bool type but I found no
further documentation. Did I miss something ? 


Nicolas Rougier.


From rougier at loria.fr  Fri Sep  2 19:16:18 2005
From: rougier at loria.fr (Nicolas Rougier)
Date: Fri, 2 Sep 2005 19:16:18 +0200
Subject: [C++-sig] c++ bool to python bool: SOLVED
Message-ID: <20050902191618.3de586db.rougier@loria.fr>



I'm terribly sorry for the trouble because I just forgot to check that
I had the last version of the library (1.33) while it should have been
the first thing to check. It's now working like a charm.


Nicolas Rougier.


From price at ELLINGTON.com  Fri Sep  2 23:43:32 2005
From: price at ELLINGTON.com (Gregory Price)
Date: Fri, 2 Sep 2005 17:43:32 -0400
Subject: [C++-sig] gcc and explicit method types
Message-ID: <FDC9B82C8E33C346B223298B17C2D34E0E1030@emgmail1.ellington.com>

Thanks for this library.  I've been exposing
some of my company's C++ code base to Python,
controlling it from there, and it's already got
some people excited about what we'll be able to do.
As I port the wrapper from MSVC to GCC,
I'm having some unexpected trouble
that I hope you can help me with.


I'm compiling the following module:

---- begin foo.cpp ----
#include <boost/python.hpp>

using namespace boost::python;

class A {
public:
  A();
  int f();
};

BOOST_PYTHON_MODULE(foo)
{
  class_<A>("A")
    .def("f", A::f);
}
---- end foo.cpp ----

Using Visual Studio (with whatever enormous inscrutable
command line is produced by my project settings)[1],
this compiles and works fine.

Using GCC produces the following error:

---- begin transcript ----
$ g++ -I/usr/include/python2.4  -c foo.cpp
foo.cpp: In function `void init_module_foo()':
foo.cpp:15: no matching function for call to `boost::python::class_<A,
   boost::python::detail::not_specified,
boost::python::detail::not_specified,
   boost::python::detail::not_specified>::def(const char[2], <unknown
type>)'
/usr/include/boost/python/class.hpp:234: candidates are:
   boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1,
X2,
   X3>::def(const char*, F) [with F = int (A::*)(), W = A, X1 =
   boost::python::detail::not_specified, X2 =
   boost::python::detail::not_specified, X3 =
   boost::python::detail::not_specified]
---- end transcript ----

I observe in particular the `unknown type' bit.
I can fix that with an explicit cast:

  class_<A>("A")
    .def("f", (int (A::*)())A::f);

getting a less imposing message:

---- begin transcript ----
$ g++ -I/usr/include/python2.4  -c foo.cpp
foo.cpp: In function `void init_module_foo()':
foo.cpp:15: assuming pointer to member `int A::f()'
foo.cpp:15: (a pointer to member can only be formed with `&A::f()')
---- end transcript ----

which can be fixed as suggested with

  class_<A>("A")
    .def("f", (int (A::*)())&A::f);

for no message at all.



I could apply this fix to all the methods in my module.
But I believe the Boost.Python magic is supposed to
make these explicit type annotations unnecessary.
What should I be doing differently?


(I'm using Boost 1.32; but I checked Boost.Python's news file
  http://boost.org/libs/python/doc/news.html
and don't see anything pertinent since then.)


Thanks,
Greg



---- begin transcript ----
$ g++ --version | head -1
g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-42)

$ grep '#define BOOST_VERSION ' `locate boost/version.hpp`
#define BOOST_VERSION 103200
---- end transcript ----


[1] For completeness' sake, the command-line options follow:
/Od /Ob2 /I "..\." /I "c:\python24\include" /I
"c:\tools\boost_1_32_0\src" 
/D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D "_USRDLL" /D "_WINDLL" /FD /EHsc

/RTC1 /MDd /GS /Zc:forScope /GR /Fo".\Debug/" /Fd".\Debug/vc70.pdb" 
/FR".\Debug/" /W3 /nologo /c /Zi /TP



=============================================================================================
Email transmissions can not be guaranteed to be secure or error-free, as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain 
viruses.  The sender therefore does not accept liability for any errors or omissions in 
the contents of this message which arise as a result of email transmission.  In addition,
the information contained in this email message is intended only for use of the 
individual or entity named above.  If the reader of this message is not the intended
recipient, or the employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying of this communication,
disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it,
is strictly prohibited, and may be unlawful.  If you are not the intended recipient please
delete this email message. 
==============================================================================================



From seefeld at sympatico.ca  Fri Sep  2 23:56:18 2005
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 02 Sep 2005 17:56:18 -0400
Subject: [C++-sig] gcc and explicit method types
In-Reply-To: <FDC9B82C8E33C346B223298B17C2D34E0E1030@emgmail1.ellington.com>
References: <FDC9B82C8E33C346B223298B17C2D34E0E1030@emgmail1.ellington.com>
Message-ID: <4318CA82.907@sympatico.ca>

Gregory Price wrote:
> Thanks for this library.  I've been exposing
> some of my company's C++ code base to Python,
> controlling it from there, and it's already got
> some people excited about what we'll be able to do.
> As I port the wrapper from MSVC to GCC,
> I'm having some unexpected trouble
> that I hope you can help me with.
> 
> 
> I'm compiling the following module:
> 
> ---- begin foo.cpp ----
> #include <boost/python.hpp>
> 
> using namespace boost::python;
> 
> class A {
> public:
>   A();
>   int f();
> };
> 
> BOOST_PYTHON_MODULE(foo)
> {
>   class_<A>("A")
>     .def("f", A::f);

_______________^

that should be '&A::f'

> }
> ---- end foo.cpp ----
> 
> Using Visual Studio (with whatever enormous inscrutable
> command line is produced by my project settings)[1],
> this compiles and works fine.

Yeah, I noticed that MSVC accepted the above, even though
the correct syntax requires the address-of operator.

Regards,
		Stefan


From Yves_Secretan at inrs-ete.uquebec.ca  Sat Sep  3 00:13:36 2005
From: Yves_Secretan at inrs-ete.uquebec.ca (Yves Secretan)
Date: Fri, 2 Sep 2005 18:13:36 -0400
Subject: [C++-sig] gcc and explicit method types
In-Reply-To: <FDC9B82C8E33C346B223298B17C2D34E0E1030@emgmail1.ellington.com>
Message-ID: <IOENLEGGNAMHEFJODOADOEPNEBAA.Yves_Secretan@inrs-ete.uquebec.ca>

BOOST_PYTHON_MODULE(foo)
{
  class_<A>("A")
    .def("f", &A::f);
             ^^^^^^^		Should do the job
}




From rwgk at yahoo.com  Sat Sep  3 03:07:51 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 2 Sep 2005 18:07:51 -0700 (PDT)
Subject: [C++-sig] Is there a way to automatically convert a smart_ptr
	to held type
In-Reply-To: <431760CA.3080101@vrsource.org>
Message-ID: <20050903010751.55197.qmail@web31508.mail.mud.yahoo.com>

--- Allen Bierbaum <allenb at vrsource.org> wrote:

> I am wrapping a C++ library with boost.python that has multiple types of 
> smart ptrs for it's objects.  It has a ptr<> type that holds the object 
> and provides a ref counting interface (through and addRef()/subRef() 
> interface).  It then has a ref_ptr<> type that acts like a "standard" 
> smart pointer by holding a ptr<> internally and calling the ref handling 
> operations upon construction and destruction.

I am a bit confused by your ptr<> / ref_ptr<> interactions, but it seems
related to what I do routinely with my array types. The main trick is to use
custom to_python and from_python converters. E.g. here:

http://phenix-online.org/cctbx_sources/scitbx/include/scitbx/array_family/boost_python/ref_flex_conversions.h

http://phenix-online.org/cctbx_sources/scitbx/include/scitbx/array_family/boost_python/shared_flex_conversions.h

Read this first (the basic mechanism is exactly the same):

http://www.boost.org/libs/python/doc/v2/faq.html#custom_string

If I understood how you construct a ref_ptr<> from a ptr<> I could try to be
more specific. You wrote:

> ptr<Base> createObject()
>
> then when I call this from boost.python it needs to figure out that it 
> should convert the ptr<Base> to a ref_ptr<Base>.

If ptr<> owns the held Base object, but ptr<> is "a standard" smart pointer, I
don't understand under which conditions the Base object is constructed and
destroyed...

Cheers,
        Ralf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From dave at boost-consulting.com  Sat Sep  3 10:46:12 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 03 Sep 2005 04:46:12 -0400
Subject: [C++-sig] exporting __stdcall methods
References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com>
	<422DCDCD.8090803@paniq.org> <42334D12.2020608@paniq.org>
	<005101c52759$ee9cc030$37ce4e51@MIKESPC01> <42337D6E.2010505@paniq.org>
	<ud5u41l6n.fsf@boost-consulting.com>
	<024f01c52a4b$5caa5df0$0dc66b51@fuji>
	<uwts672h4.fsf@boost-consulting.com>
	<110901c5678f$814a1f70$de00a8c0@nico>
	<ubr4lg99z.fsf@boost-consulting.com>
	<015601c5a267$ab1af910$de00a8c0@nico>
Message-ID: <ubr3ak08b.fsf@boost-consulting.com>

"Nicolas Lelong" <nico_ml at mgdesign.org> writes:

> Hi Dave,
>
> sorry I linger in responding, I'm only getting back to business after some 
> holidays :)

Likewise, I'm sorry too.  I am not ignoring this post; it's marked
"important."  I am just overcommitted at the moment and have to wait
for the right opportunity to get back into things.  If Ralf has the
time and wants to review your patch, I'm willing to trust his
decisions in the matter and/or answer his questions about specific
areas of concern.

Regards,

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From dave at boost-consulting.com  Sat Sep  3 10:47:09 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 03 Sep 2005 04:47:09 -0400
Subject: [C++-sig] c++ bool to python bool: SOLVED
References: <20050902191618.3de586db.rougier@loria.fr>
Message-ID: <u64tik06q.fsf@boost-consulting.com>

Nicolas Rougier <rougier at loria.fr> writes:

> I'm terribly sorry for the trouble because I just forgot to check that
> I had the last version of the library (1.33) while it should have been
> the first thing to check. It's now working like a charm.

You shouldn't need that Bool class wrapper, by the way.  Conversions between
Python Bool and C++ bool should "just work."

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From n_habili at hotmail.com  Mon Sep  5 07:22:41 2005
From: n_habili at hotmail.com (Nariman Habili)
Date: Mon, 05 Sep 2005 05:22:41 +0000
Subject: [C++-sig] Memory allocation problem
Message-ID: <BAY102-F1421AF41CE69EC17ACB3E6F9A40@phx.gbl>

Hi,

I'm developing a Boost Python application that links with a number of other 
libraries. I'm using Python version 2.3, and bjam version 3.1.10. All of the 
libraries have been compiled with the /MDd option using the MVS IDE, 
compiler vc7. The first issue I had was a linking problem, with error 
messages such as:

LIBCMTD.lib(dosmap.obj) : error LNK2005: __errno already defined in 
MSVCRTD.lib(MSVCR70D.dll)
MSVCRTD.lib(MSVCR70D.dll) : error LNK2005: __open already defined in 
LIBCMTD.lib(open.obj)

I was able to eliminate the error messages by executing the linking command 
manually with the option /NODEFAULTLIB:LIBCMTD.lib.

I have come across another problem which I haven't been able to resolve. A 
struct, called ImageParams, is defined in a header file of library 
kernel.lib. Within my boost python application std::cout << 
sizeof(ImageParams) gives 240 bytes, while in kernel.lib, 
sizeof(ImageParams) is 248 bytes. Because of the discrepancy in the amount 
of memory allocated, I'm running into all sorts of trouble, and I can't work 
out why the allocated memories should be different. The only thing I can 
think of is that my boost python application is inlining the struct, and 
because of some option setting, the struct is padded differently to achieve 
word or paragraph alignment.

I've looked at the command that boost python executes to create the .obj 
files, and I've modified the compiler options for kernel.lib in the MVS IDE 
to match those executed by boost python, to no avail, however I might be 
missing something. I would be very grateful if anyone can help me to solve 
this problem, thanks.

Regards,
Nari




From schipo at dynamik.fb10.TU-Berlin.DE  Mon Sep  5 16:36:17 2005
From: schipo at dynamik.fb10.TU-Berlin.DE (Thomas Schipolowski)
Date: Mon, 05 Sep 2005 16:36:17 +0200
Subject: [C++-sig] How to implement a cross-module C-API
Message-ID: <431C57E1.4090900@dynamik.fb10.tu-berlin.de>

Hello,

I have a working C++ extension module for python that has been exported 
with boost::python. Now I am trying to embed the python interpreter in a 
plain C program and make it execute a script which will import my C++ 
module and do some calculations with it. The results will end up in a 
C++ object created by the extension module. In the enveloping C program, 
I would be able to retrieve a PyObject* reference to the Python wrapper 
of this result object from the interpreter global namespace after the 
script finished. But is there a way to get fast C-level access to the 
underlying C++ object?

I read the extending/embedding part of the standard python docu and 
tried to think up a possible solution. As it seems to be a bit involved, 
can please somebody tell me if I am on the right way, or what I could do 
better?

 

My idea so far:

I would add some free functions to my C++ module that offer a minimal 
C-API for some of the classes defined there. These functions would 
accept a PyObject* reference as argument. Internally, they would 
construct a boost::python::object from the PyObject* and try to extract 
the expected C++ object type from it. Once I have the C++ object back, I 
could call its methods to perform the desired operations. All results 
would be returned as plain C structs or arrays.

In order to get access to the API functions in my C program, I would 
package them in a static table of function pointers, place a void* ptr 
to the table in a Python CObject, and make the CObject visible to my C 
program by exporting a function (to python) that delivers the CObject on 
request.

Can this work? The fact that there is a "extern C" declaration for using 
C functions in C++ makes me wonder if it is possible/safe to access a 
function compiled with C++ from a program compiled with a C compiler?

 

Thanks in advance,

Thomas.




From seefeld at sympatico.ca  Mon Sep  5 17:31:56 2005
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 05 Sep 2005 11:31:56 -0400
Subject: [C++-sig] How to implement a cross-module C-API
In-Reply-To: <431C57E1.4090900@dynamik.fb10.tu-berlin.de>
References: <431C57E1.4090900@dynamik.fb10.tu-berlin.de>
Message-ID: <431C64EC.8060201@sympatico.ca>

Thomas Schipolowski wrote:

> I would add some free functions to my C++ module that offer a minimal 
> C-API for some of the classes defined there. These functions would 
> accept a PyObject* reference as argument. Internally, they would 
> construct a boost::python::object from the PyObject* and try to extract 
> the expected C++ object type from it. Once I have the C++ object back, I 
> could call its methods to perform the desired operations. All results 
> would be returned as plain C structs or arrays.
> 
> In order to get access to the API functions in my C program, I would 
> package them in a static table of function pointers, place a void* ptr 
> to the table in a Python CObject, and make the CObject visible to my C 
> program by exporting a function (to python) that delivers the CObject on 
> request.

That sounds plausible. You are essentially generating your own vtbls
in C that act as C wrappers around the C++ core. I'm not quite
sure I would embedd these vtbls into the objects you are wrapping, as that
is a bit invasive. Instead, you may create a dictionary that maps python
type objects to the structures holding your vtbl and provide a simple
lookup mechanism that queries the PyTypeObject pointer from a given python
object and look up the C vtbl with that.

> Can this work? The fact that there is a "extern C" declaration for using 
> C functions in C++ makes me wonder if it is possible/safe to access a 
> function compiled with C++ from a program compiled with a C compiler?

Yes, this should work.

Regards,
		Stefan



From schipo at dynamik.fb10.TU-Berlin.DE  Mon Sep  5 19:20:38 2005
From: schipo at dynamik.fb10.TU-Berlin.DE (Thomas Schipolowski)
Date: Mon, 05 Sep 2005 19:20:38 +0200
Subject: [C++-sig] How to implement a cross-module C-API
In-Reply-To: <431C64EC.8060201@sympatico.ca>
References: <431C57E1.4090900@dynamik.fb10.tu-berlin.de>
	<431C64EC.8060201@sympatico.ca>
Message-ID: <431C7E66.8070000@dynamik.fb10.tu-berlin.de>

Hello Stefan,

thank you for the quick response.

>I'm not quite
>sure I would embedd these vtbls into the objects you are wrapping, as that
>is a bit invasive. 
>
Uhm, I am not sure if this is what I meant to do. I intended to take the 
route suggested by the std. Python extending tutorial: 
http://docs.python.org/ext/using-cobjects.html So I want to put the 
whole table of API function ptrs in just one of these Python-API 
CObjects, to get the addresses across the C++/Python/C borders. This 
would leave the C++ objects which I intend to access with my API 
untouched. They would even be oblivious to the existence of the C-API, 
as the functions will only access the objects using their normal public 
interface.

But, yes, the CObject itself would be wrapped in order to get it out to 
python. I thought of something like:

static void* call_table[MY_API_PTRS];
.... put function pointers in table ...

object get_c_api() {
    return object(handle<>(*PyCObject_FromVoidPtr*((void*)call_table, 
NULL)));
}

Then I would export 'get_c_api' with the normal boost::python 
facilities. In the plain C part, I would call get_c_api via python, 
extract the void* ptr from the PyCObject* and cast it into the array of 
function pointers, whose prototypes are known thanks to a header file 
that describes the fixed layout of call_table.

>Instead, you may create a dictionary that maps python
>type objects to the structures holding your vtbl and provide a simple
>lookup mechanism that queries the PyTypeObject pointer from a given python
>object and look up the C vtbl with that.
>  
>
Ok, this would be a nice way to associate the functions with the 
corresponding objects. But still I need to use PyCObject_FromVoidPtr or 
something equivalent to be able to put the opaque C pointers, or the ptr 
to the vtable, into a python dict, do I? But don't worry, I will need 
only one vtable with a static structure for my few API functions. So it 
boils down to the problem of getting a single address safely from the 
C++ part to the C part. Each function will check with 
extract<expected_class>(...).check()  to make sure it is called with the 
C++ object type it is intended for.

Hope it still makes sense.
Regards,
Thomas.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050905/fe9c4db4/attachment.htm>

From allenb at vrsource.org  Mon Sep  5 20:16:02 2005
From: allenb at vrsource.org (Allen Bierbaum)
Date: Mon, 05 Sep 2005 13:16:02 -0500
Subject: [C++-sig] Boost.Python visibility fix for GCC 4.0
In-Reply-To: <430B96BF.3090506@vrsource.org>
References: <430B96BF.3090506@vrsource.org>
Message-ID: <431C8B62.90809@vrsource.org>

Hello all:

I haven't heard anything back about this patch.  As far as I know, boost 
python will not work with gcc 4.x and the visibility flags without 
changes similar to this.  Is this the correct place to post such a 
patch?  Is there some other known workaround that I am not aware of?

Thanks,
Allen

Allen Bierbaum wrote:

> It looks like the current version of Boost.Python has a small bug when 
> using the visibility options of gcc 4.0 (i.e. -fvisibility=hidden).  I 
> have attached a patch that will fix the problem.  It looks like when 
> the code was originally added to test for the GCC version it didn't 
> take into account non 3.x version numbers.  This patch should take 
> care of that.
>
> Note: This bug rears its head by hiding the extern C initmodule() when 
> you compile a Boost.Python module with "-fvisibility=hidden".  Thus 
> the module fails to import into python because the symbol is not found.
>
> Hopefully this should fix things up for everyone.
>
> -Allen
>
>------------------------------------------------------------------------
>
>Index: boost/python/module_init.hpp
>===================================================================
>RCS file: /cvsroot/boost/boost/boost/python/module_init.hpp,v
>retrieving revision 1.6
>diff -u -r1.6 module_init.hpp
>--- boost/python/module_init.hpp	20 Sep 2004 12:47:31 -0000	1.6
>+++ boost/python/module_init.hpp	23 Aug 2005 21:27:15 -0000
>@@ -42,7 +42,7 @@
> }                                                                       \
> void init_module_##name()
> 
>-# elif (defined(__GNUC__) && __GNUC__ >= 3 && __GNUC_MINOR__ >=5)
>+# elif (defined(__GNUC__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >=5)))
> 
> #   define BOOST_PYTHON_MODULE_INIT(name)                               \
> void init_module_##name();                                              \
>@@ -64,6 +64,6 @@
> 
> #  endif
> 
>-# endif 
>+# endif
> 
> #endif // MODULE_INIT_DWA20020722_HPP
>Index: boost/python/detail/config.hpp
>===================================================================
>RCS file: /cvsroot/boost/boost/boost/python/detail/config.hpp,v
>retrieving revision 1.37
>diff -u -r1.37 config.hpp
>--- boost/python/detail/config.hpp	29 Nov 2004 21:32:14 -0000	1.37
>+++ boost/python/detail/config.hpp	23 Aug 2005 21:27:15 -0000
>@@ -69,10 +69,10 @@
> #if defined(BOOST_PYTHON_DYNAMIC_LIB)
> 
> #  if !defined(_WIN32) && !defined(__CYGWIN__)                  \
>-    && defined(__GNUC__) && __GNUC__ >= 3 && __GNUC_MINOR__ >=5 \
>+    && defined(__GNUC__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >=5)) \
>     && !defined(BOOST_PYTHON_GCC_SYMBOL_VISIBILITY)
> #    define BOOST_PYTHON_USE_GCC_SYMBOL_VISIBILITY
>-#  endif 
>+#  endif
> 
> #  if defined(BOOST_PYTHON_USE_GCC_SYMBOL_VISIBILITY)
> #     if defined(BOOST_PYTHON_SOURCE)
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>C++-sig mailing list
>C++-sig at python.org
>http://mail.python.org/mailman/listinfo/c++-sig
>  
>



From s_sourceforge at nedprod.com  Mon Sep  5 23:01:25 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Mon, 05 Sep 2005 22:01:25 +0100
Subject: [C++-sig] Boost.Python visibility fix for GCC 4.0
In-Reply-To: <431C8B62.90809@vrsource.org>
References: <430B96BF.3090506@vrsource.org>
Message-ID: <431CC035.5137.3B8D5C@localhost>

On 5 Sep 2005 at 13:16, Allen Bierbaum wrote:

> Hello all:
> 
> I haven't heard anything back about this patch.  As far as I know,
> boost python will not work with gcc 4.x and the visibility flags
> without changes similar to this.  Is this the correct place to post
> such a patch?  Is there some other known workaround that I am not
> aware of?

Yeah it was a typo by me:

&& defined(__GNUC__) && __GNUC__ >= 3 && __GNUC_MINOR__ >=5 \

should be:

&& defined(__GNUC__) && __GNUC__ >= 4 \

Cheers,
Niall





From nico_ml at mgdesign.org  Tue Sep  6 10:16:55 2005
From: nico_ml at mgdesign.org (Nicolas Lelong)
Date: Tue, 6 Sep 2005 10:16:55 +0200
Subject: [C++-sig] exporting __stdcall methods
References: <20050308143928.36875.qmail@web31510.mail.mud.yahoo.com><422DCDCD.8090803@paniq.org>
	<42334D12.2020608@paniq.org><005101c52759$ee9cc030$37ce4e51@MIKESPC01>
	<42337D6E.2010505@paniq.org><ud5u41l6n.fsf@boost-consulting.com><024f01c52a4b$5caa5df0$0dc66b51@fuji><uwts672h4.fsf@boost-consulting.com><110901c5678f$814a1f70$de00a8c0@nico><ubr4lg99z.fsf@boost-consulting.com><015601c5a267$ab1af910$de00a8c0@nico>
	<ubr3ak08b.fsf@boost-consulting.com>
Message-ID: <002301c5b2bb$586e4fa0$de00a8c0@nico>

> Likewise, I'm sorry too.  I am not ignoring this post; it's marked
> "important."  I am just overcommitted at the moment and have to wait
> for the right opportunity to get back into things.

That's something I fully understand :)

> If Ralf has the time and wants to review your patch, I'm willing to trust 
> his
> decisions in the matter and/or answer his questions about specific
> areas of concern.

OK, I'm still willing to support this patch and I still have some time to 
work on it.
So let's say that if Ralf wishes to get involved, I'm open and available for 
comments !

Cheers,

Nicolas. 



From rwgk at yahoo.com  Tue Sep  6 13:35:19 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 6 Sep 2005 04:35:19 -0700 (PDT)
Subject: [C++-sig] exporting __stdcall methods
In-Reply-To: <002301c5b2bb$586e4fa0$de00a8c0@nico>
Message-ID: <20050906113519.32177.qmail@web31507.mail.mud.yahoo.com>

--- Nicolas Lelong <nico_ml at mgdesign.org> wrote:

> > Likewise, I'm sorry too.  I am not ignoring this post; it's marked
> > "important."  I am just overcommitted at the moment and have to wait
> > for the right opportunity to get back into things.
> 
> That's something I fully understand :)
> 
> > If Ralf has the time and wants to review your patch, I'm willing to trust 
> > his
> > decisions in the matter and/or answer his questions about specific
> > areas of concern.
> 
> OK, I'm still willing to support this patch and I still have some time to 
> work on it.
> So let's say that if Ralf wishes to get involved, I'm open and available for 
> comments !

I don't feel competent at all in this matter. I'd be happy to check in the
patches after verifying that nothing is broken, but I am not qualified to do
serious vetting of the new feature(s).
Nicolas, if you send me the patched files bundled in a zip or tar file (with
full path names relative to the top-level boost directory) I'll try them out
locally.
Cheers,
        Ralf

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From price at ELLINGTON.com  Tue Sep  6 20:06:52 2005
From: price at ELLINGTON.com (Gregory Price)
Date: Tue, 6 Sep 2005 14:06:52 -0400
Subject: [C++-sig] gcc and explicit method types
Message-ID: <FDC9B82C8E33C346B223298B17C2D34E09C242@emgmail1.ellington.com>


Stefan Seefeld wrote (as did Yves Secretan):
> >     .def("f", A::f);
> 
> _______________^
> 
> that should be '&A::f'

Thanks!  Fixed.

Greg

=============================================================================================
Email transmissions can not be guaranteed to be secure or error-free, as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain 
viruses.  The sender therefore does not accept liability for any errors or omissions in 
the contents of this message which arise as a result of email transmission.  In addition,
the information contained in this email message is intended only for use of the 
individual or entity named above.  If the reader of this message is not the intended
recipient, or the employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying of this communication,
disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it,
is strictly prohibited, and may be unlawful.  If you are not the intended recipient please
delete this email message. 
==============================================================================================



From 13640887 at sun.ac.za  Wed Sep  7 05:27:05 2005
From: 13640887 at sun.ac.za (Albert Strasheim)
Date: Wed, 7 Sep 2005 05:27:05 +0200
Subject: [C++-sig] VC 2005 error when wrapping constructor with const
	argument
Message-ID: <000001c5b35c$223292b0$aeb5e892@huisdiv.sun.ac.za>

Hello all

I recently came across a problem when wrapping classes with constructors 
that take const arguments with Visual C++ 2005 Express Edition Beta 2.

I am using Boost 1.33.0 with Python 2.4.1.

The test case (breaks on VC EE 2005, compiles on VC .NET 2003):

#include <boost/python.hpp>
class Foo {
public:
  Foo(){}
  Foo(const double){}
};
void Export_Foo()
{
  boost::python::class_<Foo>("Foo", boost::python::init<>())
    .def(boost::python::init<const double>())
    ;
}

>From the error I can see that the ArgList in the instantiation of 
make_keyword_range_constructor<...,ArgList,...>(...) still contains the 
const double. make_keyword_range_constructor then uses make_holder to 
convert the ArgList to a function pointer for make_keyword_range_function. 
However, I can see that F in make_keyword_range_function<F, Policies>(...) 
is missing the const qualifier.

It looks like whatever preprocessor magic is happening inside make_holder is 
dropping the const qualifier.

You can find the build log at:

http://albert.bagasie.com/make_holder_bug/make_holder_bug_BuildLog.htm

The complete preprocessed output is at:

http://albert.bagasie.com/make_holder_bug/make_holder_bug.i.gz

Cheers

Albert




From n_habili at hotmail.com  Wed Sep  7 09:31:33 2005
From: n_habili at hotmail.com (Nariman Habili)
Date: Wed, 07 Sep 2005 07:31:33 +0000
Subject: [C++-sig] debugging c++ extension
Message-ID: <BAY102-F2336B81AEDC704ADDE9D14F9A60@phx.gbl>

Hi,

I'm wondering how I can debug my c++ code that has been interfaced to python 
using python boost? I read somewhere that gdb can be used to debug, however 
the information provided to do this is limited. I would appreciate your 
help, thanks.

Regards,
Nari




From pierre.barbier at cirad.fr  Wed Sep  7 10:46:12 2005
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Wed, 07 Sep 2005 10:46:12 +0200
Subject: [C++-sig] debugging c++ extension
In-Reply-To: <BAY102-F2336B81AEDC704ADDE9D14F9A60@phx.gbl>
References: <BAY102-F2336B81AEDC704ADDE9D14F9A60@phx.gbl>
Message-ID: <431EA8D4.6060905@cirad.fr>

Hello,

Yes, gdb is really able to debug your code !
What I do to debug Python modules is :

1 - launch python with gdb (you don't need debug information in your
python executable to do so ...):

$ gdb python


2 - launch python and load your module

(gdb) run
Starting program: /usr/bin/python
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 1885)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Python 2.3.5 (#2, May  4 2005, 08:51:39)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
>>> import my_module
>>>

3 - Hit "Ctrl-C"

Program received signal SIGINT, Interrupt.
[Switching to Thread 16384 (LWP 1885)]
0x40039178 in read () from /lib/libpthread.so.0
(gdb)

4 - place your breakpoints and continue execution

(gdb) b my_module.cc:54
Breakpoint 1 at 0x804a205: file my_module.cc, line 54.
(gdb) cont

5 - Enter some Python commands and debug as you will do with any program
once your breakpoint is hit.

Hope that's help,

Pierre


Nariman Habili a ?crit :
> Hi,
> 
> I'm wondering how I can debug my c++ code that has been interfaced to python 
> using python boost? I read somewhere that gdb can be used to debug, however 
> the information provided to do this is limited. I would appreciate your 
> help, thanks.
> 
> Regards,
> Nari
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 

-- 
Pierre Barbier de Reuille

INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France

tel   : (33) 4 67 61 65 77    fax   : (33) 4 67 61 56 68


From dirgesh.patel at hp.com  Wed Sep  7 23:22:52 2005
From: dirgesh.patel at hp.com (Dirgesh Patel)
Date: Wed, 7 Sep 2005 14:22:52 -0700
Subject: [C++-sig] Boost function call error
References: <ddvos9$oae$1@sea.gmane.org><deicsa$f0g$1@sea.gmane.org>	<deil0f$93n$1@sea.gmane.org><deiln4$bbl$1@sea.gmane.org>
	<deisg2$u5c$1@sea.gmane.org>
Message-ID: <dfnlnd$1im$1@sea.gmane.org>

i am trying to wrap this function

bkimage* copy(bkimage *img, xint32_t pln0, xint32_t row0, xint32_t col0, 
xint32_t pln1, xint32_t row1, xint32_t col1)

and this is the line in the boost.cpp file
    def("copy", static_cast<bkimage* 
(*)(bkimage*,xint32_t,xint32_t,xint32_t,xint32_t,xint32_t,xint32_t)>(imageMorph_copy()) 
[return_value_policy<manage_new_object>() ]);


and i get this error:
../python/imageMorph_boost.cpp: In function `void init_module_imageMorph()':
../python/imageMorph_boost.cpp:107: error: invalid static_cast from type 
`imageMorph_copy' to type `bkimage*(*)(bkimage*, xint32_t, xint32_t, 
xint32_t, xint32_t, xint32_t, xint32_t)'

we are trying to return a ptr to bkimage. please advice.

thanks
dirgesh




"Mike Rovner" <mrovner at propel.com> wrote in message 
news:deisg2$u5c$1 at sea.gmane.org...
> Dirgesh Patel wrote:
>> i get the same error..i was told you have to cast the function name to a 
>> ptr
>> and can't use (&)
>
> right, delete one extra pointer then:
>
> def("copy", static_cast<bkimage
>  (*)(bkimage,xint32_t,xint32_t,xint32_t,xint32_t,xint32_t,xint32_t)>
>   (imageMorph_copy),
> return_value_policy<manage_new_object>() ); 





From mrovner at propel.com  Thu Sep  8 01:28:56 2005
From: mrovner at propel.com (Mike Rovner)
Date: Wed, 07 Sep 2005 16:28:56 -0700
Subject: [C++-sig] Boost function call error
In-Reply-To: <dfnlnd$1im$1@sea.gmane.org>
References: <ddvos9$oae$1@sea.gmane.org><deicsa$f0g$1@sea.gmane.org>	<deil0f$93n$1@sea.gmane.org><deiln4$bbl$1@sea.gmane.org>	<deisg2$u5c$1@sea.gmane.org>
	<dfnlnd$1im$1@sea.gmane.org>
Message-ID: <dfntbl$pjt$1@sea.gmane.org>

Dirgesh Patel wrote:
> i am trying to wrap this function
> 
> bkimage* copy(bkimage *img, xint32_t pln0, xint32_t row0, xint32_t col0, 
> xint32_t pln1, xint32_t row1, xint32_t col1)

If you have only one signature you don't need a cast.
def("copy", &imageMorph_copy, return_value_policy<manage_new_object>());

> and this is the line in the boost.cpp file
>     def("copy", static_cast<bkimage* 
> (*)(bkimage*,xint32_t,xint32_t,xint32_t,xint32_t,xint32_t,xint32_t)>(imageMorph_copy()) 
> [return_value_policy<manage_new_object>() ]);

try

def("copy", static_cast<bkimage* 
(*)(bkimage*,xint32_t,xint32_t,xint32_t,xint32_t,xint32_t,xint32_t)>(imageMorph_copy) 

[return_value_policy<manage_new_object>() ]);



From fractal97 at hotmail.com  Thu Sep  8 02:38:35 2005
From: fractal97 at hotmail.com (Vin Jovanovic)
Date: Wed, 07 Sep 2005 20:38:35 -0400
Subject: [C++-sig] MSVC++  boost python question
In-Reply-To: <dfnlnd$1im$1@sea.gmane.org>
Message-ID: <BAY101-F260AA85D094F4FEEE3FD62AE990@phx.gbl>

I built boost python with bjam (with all kind of options static dynamic 
single etc) and I am trying to use the libboost_python*.lib in my vc-7_1 
project to produce getting_started1.dll which I can load into Python so that 
I would not need boost_python.dll.  But no combination of libraries works.  
I am getting linking errors bellow ...  Is there a way around this?

Linking...
LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' 
specification
msvcprt.lib(MSVCP71.dll) : error LNK2005: "public: __thiscall 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >::~basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >(void)" 
(??1?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE at XZ) 
already defined in getting_started1.obj
msvcprt.lib(MSVCP71.dll) : error LNK2005: "public: __thiscall 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >(class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > const &)" 
(??0?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE at ABV01@@Z) 
already defined in libcpmtd.lib(string.obj)
msvcprt.lib(MSVCP71.dll) : error LNK2005: "public: __thiscall 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >(char const *)" 
(??0?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE at PBD@Z) 
already defined in getting_started1.obj
msvcprt.lib(MSVCP71.dll) : error LNK2005: "public: unsigned int __thiscall 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >::max_size(void)const " 
(?max_size@?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QBEIXZ) 
already defined in getting_started1.obj
msvcprt.lib(MSVCP71.dll) : error LNK2005: "public: class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > & __thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >::erase(unsigned 
int,unsigned int)" 
(?erase@?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAEAAV12 at II@Z) 
already defined in getting_started1.obj
MSVCRT.lib(MSVCR71.dll) : error LNK2005: "public: __thiscall 
bad_cast::bad_cast(char const *)" (??0bad_cast@@QAE at PBD@Z) already defined 
in LIBCMT.lib(stdexcpt.obj)
MSVCRT.lib(MSVCR71.dll) : error LNK2005: "public: int __thiscall 
type_info::operator==(class type_info const &)const " 
(??8type_info@@QBEHABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
MSVCRT.lib(MSVCR71.dll) : error LNK2005: "public: char const * __thiscall 
type_info::name(void)const " (?name at type_info@@QBEPBDXZ) already defined in 
LIBCMT.lib(typname.obj)
MSVCRT.lib(MSVCR71.dll) : error LNK2005: "public: virtual __thiscall 
exception::~exception(void)" (??1exception@@UAE at XZ) already defined in 
LIBCMT.lib(stdexcpt.obj)
MSVCRT.lib(MSVCR71.dll) : error LNK2005: "public: __thiscall 
exception::exception(void)" (??0exception@@QAE at XZ) already defined in 
LIBCMT.lib(stdexcpt.obj)
MSVCRT.lib(MSVCR71.dll) : error LNK2005: "public: __thiscall 
exception::exception(class exception const &)" (??0exception@@QAE at ABV0@@Z) 
already defined in LIBCMT.lib(stdexcpt.obj)
MSVCRT.lib(MSVCR71.dll) : error LNK2005: _memmove already defined in 
LIBCMT.lib(memmove.obj)
MSVCRT.lib(MSVCR71.dll) : error LNK2005: "public: int __thiscall 
type_info::before(class type_info const &)const " 
(?before at type_info@@QBEHABV1@@Z) already defined in LIBCMT.lib(typinfo.obj)
MSVCRT.lib(MSVCR71.dll) : error LNK2005: "public: virtual __thiscall 
bad_cast::~bad_cast(void)" (??1bad_cast@@UAE at XZ) already defined in 
LIBCMT.lib(stdexcpt.obj)
MSVCRT.lib(MSVCR71.dll) : error LNK2005: "public: __thiscall 
bad_cast::bad_cast(class bad_cast const &)" (??0bad_cast@@QAE at ABV0@@Z) 
already defined in LIBCMT.lib(stdexcpt.obj)
MSVCRT.lib(MSVCR71.dll) : error LNK2005: "public: __thiscall 
exception::exception(char const * const &)" (??0exception@@QAE at ABQBD@Z) 
already defined in LIBCMT.lib(stdexcpt.obj)
MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: __thiscall 
type_info::type_info(class type_info const &)" (??0type_info@@AAE at ABV0@@Z) 
already defined in LIBCMT.lib(typinfo.obj)
MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: class type_info & 
__thiscall type_info::operator=(class type_info const &)" 
(??4type_info@@AAEAAV0 at ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
msvcprt.lib(MSVCP71.dll) : warning LNK4006: "public: __thiscall 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >::~basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >(void)" 
(??1?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE at XZ) 
already defined in getting_started1.obj; second definition ignored
msvcprt.lib(MSVCP71.dll) : warning LNK4006: "public: __thiscall 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >(class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > const &)" 
(??0?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE at ABV01@@Z) 
already defined in libcpmtd.lib(string.obj); second definition ignored
msvcprt.lib(MSVCP71.dll) : warning LNK4006: "public: __thiscall 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >(char const *)" 
(??0?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE at PBD@Z) 
already defined in getting_started1.obj; second definition ignored
msvcprt.lib(MSVCP71.dll) : warning LNK4006: "public: unsigned int __thiscall 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >::max_size(void)const " 
(?max_size@?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QBEIXZ) 
already defined in getting_started1.obj; second definition ignored
msvcprt.lib(MSVCP71.dll) : warning LNK4006: "public: class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > & __thiscall std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> >::erase(unsigned 
int,unsigned int)" 
(?erase@?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAEAAV12 at II@Z) 
already defined in getting_started1.obj; second definition ignored
MSVCRT.lib(MSVCR71.dll) : warning LNK4006: "public: __thiscall 
bad_cast::bad_cast(char const *)" (??0bad_cast@@QAE at PBD@Z) already defined 
in LIBCMT.lib(stdexcpt.obj); second definition ignored
MSVCRT.lib(MSVCR71.dll) : warning LNK4006: "public: int __thiscall 
type_info::operator==(class type_info const &)const " 
(??8type_info@@QBEHABV0@@Z) already defined in LIBCMT.lib(typinfo.obj); 
second definition ignored
MSVCRT.lib(MSVCR71.dll) : warning LNK4006: "public: char const * __thiscall 
type_info::name(void)const " (?name at type_info@@QBEPBDXZ) already defined in 
LIBCMT.lib(typname.obj); second definition ignored
MSVCRT.lib(MSVCR71.dll) : warning LNK4006: "public: virtual __thiscall 
exception::~exception(void)" (??1exception@@UAE at XZ) already defined in 
LIBCMT.lib(stdexcpt.obj); second definition ignored
MSVCRT.lib(MSVCR71.dll) : warning LNK4006: "public: __thiscall 
exception::exception(void)" (??0exception@@QAE at XZ) already defined in 
LIBCMT.lib(stdexcpt.obj); second definition ignored
MSVCRT.lib(MSVCR71.dll) : warning LNK4006: "public: __thiscall 
exception::exception(class exception const &)" (??0exception@@QAE at ABV0@@Z) 
already defined in LIBCMT.lib(stdexcpt.obj); second definition ignored
MSVCRT.lib(MSVCR71.dll) : warning LNK4006: _memmove already defined in 
LIBCMT.lib(memmove.obj); second definition ignored
MSVCRT.lib(MSVCR71.dll) : warning LNK4006: "public: int __thiscall 
type_info::before(class type_info const &)const " 
(?before at type_info@@QBEHABV1@@Z) already defined in LIBCMT.lib(typinfo.obj); 
second definition ignored
MSVCRT.lib(MSVCR71.dll) : warning LNK4006: "public: virtual __thiscall 
bad_cast::~bad_cast(void)" (??1bad_cast@@UAE at XZ) already defined in 
LIBCMT.lib(stdexcpt.obj); second definition ignored
MSVCRT.lib(MSVCR71.dll) : warning LNK4006: "public: __thiscall 
bad_cast::bad_cast(class bad_cast const &)" (??0bad_cast@@QAE at ABV0@@Z) 
already defined in LIBCMT.lib(stdexcpt.obj); second definition ignored
MSVCRT.lib(MSVCR71.dll) : warning LNK4006: "public: __thiscall 
exception::exception(char const * const &)" (??0exception@@QAE at ABQBD@Z) 
already defined in LIBCMT.lib(stdexcpt.obj); second definition ignored
MSVCRT.lib(ti_inst.obj) : warning LNK4006: "private: __thiscall 
type_info::type_info(class type_info const &)" (??0type_info@@AAE at ABV0@@Z) 
already defined in LIBCMT.lib(typinfo.obj); second definition ignored
MSVCRT.lib(ti_inst.obj) : warning LNK4006: "private: class type_info & 
__thiscall type_info::operator=(class type_info const &)" 
(??4type_info@@AAEAAV0 at ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj); 
second definition ignored
   Creating library Debug/getting_started1.lib and object 
Debug/getting_started1.exp
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other 
libs; use /NODEFAULTLIB:library
getting_started1.obj : warning LNK4217: locally defined symbol 
??0py_function_impl_base at objects@python at boost@@QAE at XZ (public: __thiscall 
boost::python::objects::py_function_impl_base::py_function_impl_base(void)) 
imported in function "public: __thiscall 
boost::python::objects::caller_py_function_impl<struct 
boost::python::detail::caller<class std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > 
(__stdcall*)(void),struct boost::python::default_call_policies,struct 
boost::mpl::vector1<class std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > > > 
 >::caller_py_function_impl<struct boost::python::detail::caller<class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > (__stdcall*)(void),struct 
boost::python::default_call_policies,struct boost::mpl::vector1<class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > > > >(struct boost::python::detail::caller<class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > (__stdcall*)(void),struct 
boost::python::default_call_policies,struct boost::mpl::vector1<class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > > > const &)" 
(??0?$caller_py_function_impl at U?$caller at P6G?AV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@XZUdefault_call_policies at python@boost@@U?$vector1 at V?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@mpl at 5@@detail at python@boost@@@objects at python@boost@@QAE at ABU?$caller at P6G?AV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@XZUdefault_call_policies at python@boost@@U?$vector1 at V?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@mpl at 5@@detail at 23@@Z)
getting_started1.obj : warning LNK4217: locally defined symbol 
??1py_function_impl_base at objects@python at boost@@UAE at XZ (public: virtual 
__thiscall 
boost::python::objects::py_function_impl_base::~py_function_impl_base(void)) 
imported in function "public: virtual __thiscall 
boost::python::objects::caller_py_function_impl<struct 
boost::python::detail::caller<class std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > 
(__stdcall*)(void),struct boost::python::default_call_policies,struct 
boost::mpl::vector1<class std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > > > 
 >::~caller_py_function_impl<struct boost::python::detail::caller<class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > (__stdcall*)(void),struct 
boost::python::default_call_policies,struct boost::mpl::vector1<class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > > > >(void)" 
(??1?$caller_py_function_impl at U?$caller at P6G?AV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@XZUdefault_call_policies at python@boost@@U?$vector1 at V?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@mpl at 5@@detail at python@boost@@@objects at python@boost@@UAE at XZ)
getting_started1.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) void __stdcall 
boost::python::detail::init_module(char const *,void (__stdcall*)(void))" 
(__imp_?init_module at detail@python at boost@@YGXPBDP6GXXZ at Z) referenced in 
function _initgetting_started1 at 0
getting_started1.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) void __stdcall 
boost::python::detail::scope_setattr_doc(char const *,class 
boost::python::api::object const &,char const *)" 
(__imp_?scope_setattr_doc at detail@python at boost@@YGXPBDABVobject at api@23 at 0@Z) 
referenced in function "void __stdcall boost::python::def<class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > (__stdcall*)(void)>(char const *,class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > (__stdcall*)(void))" 
(??$def at P6G?AV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@XZ at python@boost@@YGXPBDP6G?AV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@XZ at Z)
getting_started1.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) class boost::python::api::object __stdcall 
boost::python::objects::function_object(struct 
boost::python::objects::py_function const &)" 
(__imp_?function_object at objects@python at boost@@YG?AVobject at api@23 at ABUpy_function@123@@Z) 
referenced in function "class boost::python::api::object __stdcall 
boost::python::detail::make_function_aux<class std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > 
(__stdcall*)(void),struct boost::python::default_call_policies,struct 
boost::mpl::vector1<class std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > > >(class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > (__stdcall*)(void),struct 
boost::python::default_call_policies const &,struct 
boost::mpl::vector1<class std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > > const &)" 
(??$make_function_aux at P6G?AV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@XZUdefault_call_policies at python@boost@@U?$vector1 at V?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@mpl at 5@@detail at python@boost@@YG?AVobject at api@12 at P6G?AV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@XZABUdefault_call_policies at 12@ABU?$vector1 at V?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@mpl at 2@@Z)
getting_started1.obj : error LNK2019: unresolved external symbol 
__imp__PyString_FromStringAndSize at 8 referenced in function "public: struct 
_object * __thiscall boost::python::to_python_value<class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > const &>::operator()(class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> > const &)const " 
(??R?$to_python_value at ABV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@python at boost@@QBEPAU_object@@ABV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@Z)
getting_started1.obj : error LNK2019: unresolved external symbol 
__imp__PyInt_FromLong at 4 referenced in function "public: struct _object * 
__thiscall boost::python::to_python_value<int const &>::operator()(int const 
&)const " (??R?$to_python_value at ABH@python at boost@@QBEPAU_object@@ABH at Z)
getting_started1.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) struct 
boost::python::converter::rvalue_from_python_stage1_data __stdcall 
boost::python::converter::rvalue_from_python_stage1(struct _object *,struct 
boost::python::converter::registration const &)" 
(__imp_?rvalue_from_python_stage1 at converter@python at boost@@YG?AUrvalue_from_python_stage1_data at 123@PAU_object@@ABUregistration at 123@@Z) 
referenced in function "public: __thiscall 
boost::python::converter::arg_rvalue_from_python<int>::arg_rvalue_from_python<int>(struct 
_object *)" 
(??0?$arg_rvalue_from_python at H@converter at python@boost@@QAE at PAU_object@@@Z)
getting_started1.obj : error LNK2019: unresolved external symbol 
"__declspec(dllimport) struct boost::python::converter::registration const & 
__stdcall boost::python::converter::registry::lookup(struct 
boost::python::type_info)" 
(__imp_?lookup at registry@converter at python@boost@@YGABUregistration at 234@Utype_info at 34@@Z) 
referenced in function "struct boost::python::converter::registration const 
& __stdcall boost::python::converter::detail::registry_lookup<int const 
volatile >(int const volatile & (__stdcall*)(void))" 
(??$registry_lookup@$$CDH at detail@converter at python@boost@@YGABUregistration at 123@P6GADHXZ at Z)
Debug/getting_started1.dll : fatal error LNK1120: 7 unresolved externals




From n_habili at hotmail.com  Thu Sep  8 04:39:47 2005
From: n_habili at hotmail.com (Nariman Habili)
Date: Thu, 08 Sep 2005 02:39:47 +0000
Subject: [C++-sig]  debugging c++ extension
Message-ID: <BAY102-F15B7548BA01FB0CB380801F9990@phx.gbl>

Thanks for your reply. I've followed your instructions and I get the 
following outputs:

$gdb python

GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...(no debugging symbols 
found)...
(gdb) run
Starting program: /cygdrive/c/Python23/python.exe
Enthought Edition build 1057
Python 2.3.3 (#51, Feb 16 2004, 04:07:52) [MSC v.1200 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.

(gdb) run

Starting program: /cygdrive/c/Python23/python.exe
Enthought Edition build 1057
Python 2.3.3 (#51, Feb 16 2004, 04:07:52) [MSC v.1200 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.

>>import my_module

Hit "Ctrl-C"

Program received signal SIGINT, Interrupt.
[Switching to thread 3920.0x6dc]
0x7c874fed in KERNEL32!GetConsoleCharType () from 
/cygdrive/c/WINDOWS/system32/kernel32.dll

(gdb) b my_module.cc:200

No symbol table is loaded.  Use the "file" command.

I'm using windows xp. I'm wondering, does my_module.cc have to be in the 
same directory as my_module.obj and my_module.pyd? I'm compiling my c++ 
extension with the "debug" flag set.

Regards,
Nari




From skottmckay at gmail.com  Thu Sep  8 23:20:32 2005
From: skottmckay at gmail.com (Scott McKay)
Date: Thu, 8 Sep 2005 15:20:32 -0600
Subject: [C++-sig] debugging c++ extension
In-Reply-To: <BAY102-F15B7548BA01FB0CB380801F9990@phx.gbl>
References: <BAY102-F15B7548BA01FB0CB380801F9990@phx.gbl>
Message-ID: <51d0178705090814205dc40ed7@mail.gmail.com>

What if you try the suggested methods in the FAQ?

http://www.boost.org/libs/python/doc/v2/faq.html

The basic steps required to initiate a gdb session to debug a c++ library 
via python are shown here. Note, however that you should start the gdb 
session in the directory that contains your BPL my_ext.so module.

(gdb) target exec python
(gdb) run
 >>> from my_ext import *
 >>> [C-c]
(gdb) break MyClass::MyBuggyFunction
(gdb) cont
 >>> pyobj = MyClass()
 >>> pyobj.MyBuggyFunction()
Breakpoint 1, MyClass::MyBuggyFunction ...
Current language:  auto; currently c++
(gdb) do debugging stuff



On 9/7/05, Nariman Habili <n_habili at hotmail.com> wrote:
> 
> Thanks for your reply. I've followed your instructions and I get the
> following outputs:
> 
> $gdb python
> 
> GNU gdb 2003-09-20-cvs (cygwin-special)
> Copyright 2003 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you 
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i686-pc-cygwin"...(no debugging symbols
> found)...
> (gdb) run
> Starting program: /cygdrive/c/Python23/python.exe
> Enthought Edition build 1057
> Python 2.3.3 (#51, Feb 16 2004, 04:07:52) [MSC v.1200 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> 
> (gdb) run
> 
> Starting program: /cygdrive/c/Python23/python.exe
> Enthought Edition build 1057
> Python 2.3.3 (#51, Feb 16 2004, 04:07:52) [MSC v.1200 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> 
> >>import my_module
> 
> Hit "Ctrl-C"
> 
> Program received signal SIGINT, Interrupt.
> [Switching to thread 3920.0x6dc]
> 0x7c874fed in KERNEL32!GetConsoleCharType () from
> /cygdrive/c/WINDOWS/system32/kernel32.dll
> 
> (gdb) b my_module.cc:200
> 
> No symbol table is loaded. Use the "file" command.
> 
> I'm using windows xp. I'm wondering, does my_module.cc have to be in the
> same directory as my_module.obj and my_module.pyd? I'm compiling my c++
> extension with the "debug" flag set.
> 
> Regards,
> Nari
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050908/087c5961/attachment.htm>

From anewtroll at free.fr  Fri Sep  9 12:15:14 2005
From: anewtroll at free.fr (anewtroll)
Date: Fri, 09 Sep 2005 12:15:14 +0200
Subject: [C++-sig] boost, const and problem
Message-ID: <432160B2.3030309@free.fr>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050909/59bc9e60/attachment.htm>

From anewtroll at free.fr  Fri Sep  9 13:17:29 2005
From: anewtroll at free.fr (anewtroll)
Date: Fri, 09 Sep 2005 13:17:29 +0200
Subject: [C++-sig] boost, const and problems
Message-ID: <43216F49.6000200@free.fr>


    Hi !

       As a newbie to boost.python, I would like to know why the "const" 
argument (i.e. void function(const float t){ ... }) causes an error when 
using the bjam (VC++6)

------------------------------------------------------------
C:\test_09_net>bjam -sTOOLS=msvc
...found 1598 targets...
...updating 4 targets...
vc-C++ bin\test_09_net\nlib.pyd\msvc\debug\threading-multi\nlib.obj
nlib.cpp
C:\boost_1_33_0\boost/python/class.hpp(543) : error C2665: 
'get_signature' : none of the 4 overloads can convert parameter 1 from 
type 'bool (__thiscall ncell::*)(const float,const class ntype &)'
C:\boost_1_33_0\boost/python/class.hpp(237) : see reference to function 
template instantiation 'void __cdecl boost::python::class_<class 
ncell,struct boost::python::detail::not_specified,struct 
boost::python::detail::not_specified,struct 
boost::python::detail::not_specified>::def_impl(class ncell *,const char 
*,bool (__thiscall ncell::*)(const float,const class ntype &),const 
struct boost::python::detail::def_helper<char const *,struct 
boost::python::detail::not_specified,struct 
boost::python::detail::not_specified,struct 
boost::python::detail::not_specified> &,...)' being compiled
C:\boost_1_33_0\boost/python/class.hpp(544) : error C2780: 'class 
boost::python::api::object __cdecl boost::python::make_function(F,const 
CallPolicies &,const KeywordsOrSignature &)' : expects 3 arguments - 4 
provided

[...]

...skipped <@test_09_net\nlib.pyd\msvc\debug\threading-multi>nlib.CMD 
for lack of <@test_09_net\nlib.pyd\msvc\debug\threading-multi>nlib.obj...
...skipped <@test_09_net\nlib.pyd\msvc\debug\threading-multi>nlib.pyd 
for lack of <@test_09_net\nlib.pyd\msvc\debug\threading-multi>nlib.CMD...
...skipped <@test_09_net\nlib.pyd\msvc\debug\threading-multi>nlib.lib 
for lack of <@test_09_net\nlib.pyd\msvc\debug\threading-multi>nlib.CMD...
...failed updating 1 target...
...skipped 3 targets...
------------------------------------------------------------

       Whereas when const is omitted no problem occurs.

       I also would like to know how to modify the C++ compilation 
parameters when calling the bjam command (where is the bjam config file 
?). Thanks a lot !

          ANT.


From ericjardim at gmail.com  Fri Sep  9 15:02:56 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Fri, 9 Sep 2005 10:02:56 -0300
Subject: [C++-sig] boost, const and problems
In-Reply-To: <43216F49.6000200@free.fr>
References: <43216F49.6000200@free.fr>
Message-ID: <432ec6c505090906024c791a3b@mail.gmail.com>

2005/9/9, anewtroll <anewtroll at free.fr>:
> 
> Hi !
> As a newbie to boost.python, I would like to know why the "const"
> argument (i.e. void function(const float t){ ... }) causes an error when
> using the bjam (VC++6)


Could you show some of the code you exposed and the class?

Or even better, can you reduce your problem to a single class with a single 
method and reproduce the error?
It would help.

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050909/f7415483/attachment.htm>

From rwgk at yahoo.com  Sat Sep 10 07:22:50 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 9 Sep 2005 22:22:50 -0700 (PDT)
Subject: [C++-sig] boost, const and problems
In-Reply-To: <432ec6c505090906024c791a3b@mail.gmail.com>
Message-ID: <20050910052250.78410.qmail@web31506.mail.mud.yahoo.com>

> 2005/9/9, anewtroll <anewtroll at free.fr>:
> > 
> > Hi !
> > As a newbie to boost.python, I would like to know why the "const"
> > argument (i.e. void function(const float t){ ... }) causes an error when
> > using the bjam (VC++6)

IIRC, this is a general VC6 bug; "const float" or similar doesn't work with
that compiler.
Ralf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From mark.dufour at gmail.com  Sun Sep 11 00:36:41 2005
From: mark.dufour at gmail.com (Mark Dufour)
Date: Sun, 11 Sep 2005 00:36:41 +0200
Subject: [C++-sig] First release of Shed Skin, a Python-to-C++ compiler.
Message-ID: <8180ef6905091015361d3ffdf7@mail.gmail.com>

After nine months of hard work, I am proud to introduce my baby to the
world: an experimental Python-to-C++ compiler. It can convert many
Python programs into optimized C++ code, without any user intervention
such as adding type declarations. It uses rather advanced static type
inference techniques to deduce type information by itself. In
addition, it determines whether deduced types may be parameterized,
and if so, it generates corresponding C++ generics. Based on deduced
type information, it also attempts to convert heap allocation into
stack and static preallocation (falling back to libgc in case this
fails.)

The compiler was motivated by the belief that in many cases it should
be possible to automatically deduce C++ versions of Python programs,
enabling users to enjoy both the productivity of Python and the
efficiency of C++. It works best for Python programs written in a
relatively static C++-style, in essence enabling users to specify C++
programs at a higher level.

At the moment the compiler correctly handles 124 unit tests, six of
which are serious programs of between 100 and 200 lines:

  -an othello player
  -two satisfiability solvers
  -a japanese puzzle solver
  -a sudoku solver
  -a neural network simulator

Unfortunately I am just a single person, and much work remains to be
done. At the moment, there are several limitations to the type of
Python programs that the compiler accepts. Even so, there is enough of
Python left to be able to remain highly productive in many cases.
However, for most larger programs, there are probably some minor
problems that need to be fixed first, and some external dependencies
to be implemented/bridged in C++.

With this initial release, I hope to attract other people to help me
locate remaining problems, help implement external dependencies, and
in the end hopefully even to contribute to the compiler itself. I
would be very happy to receive small programs that the compiler does
or should be able to handle. If you are a C++ template wizard, and you
would be interested in working on the C++ implementation of builtin
types, I would also love to get in contact with you. Actually, I'd
like to talk to anyone even slightly interested in the compiler, as
this would be highly motivating to me.

The source code is available at the following site. Please check the
README for simple installation/usage instructions. Let me know if you
would like to create ebuild/debian packages.

Sourceforge site: http://shedskin.sourceforge.net
Shed Skin blog: http://shed-skin.blogspot.com

Should you reply to this mail, please also reply to me directly. Thanks!


Credits

Parts of the compiler have been sponsored by Google, via its Summer of
Code program. I am very grateful to them for keeping me motivated
during a difficult period. I am also grateful to the Python Software
Foundation for chosing my project for the Summer of Code. Finally, I
would like to thank my university advisor Koen Langendoen for guiding
this project.


Details

The following describes in a bit more detail various aspects of the
compiler. Before seriously using the compiler, please make sure to
understand especially its limitations.

Main Features

  -very precise, efficient static type inference (iterative object
contour splitting, where each iteration performs the cartesian product
algorithm)
  -stack and static pre-allocation (libgc is used as a fall-back)
  -support for list comprehensions, tuple assignments, anonymous funcs
  -generation of arbitrarily complex class and function templates
(even member templates, or generic, nested list comprehensions)
  -binary tuples are internally analyzed 
  -some understanding of inheritance (e.g. list(dict/list) becomes
list<pyiter<A>>)
  -hierarchical project support: generation of corresponding C++
hierarchy, including (nested) Makefiles; C++ namespaces
  -annotation of source code with deduced types
  -builtin classes, functions (enumerate, sum, min, max, range, zip..)
  -polymorphic inline caches or virtual vars/calls (not well tested)
  -always unbox scalars (compiler bails out with error if scalars are
mixed with pointer types)
  -full source code available under the MIT license

Main Limitations/TODO's

  -Windows support (I don't have Windows, sorry)
  -reflection (getattr, hasattr), dynamic inheritance, eval, ..  
  -mixing scalars with pointer types (e.g. int and None in a single variable) 
  -mixing unrelated types in single container instance variable other
than tuple-2
  -holding different types of objects in tuples with length >2;
builtin 'zip' can only take 2 arguments.
  -exceptions, generators, nested functions, operator overloading
  -recursive types (e.g. a = []; a.append(a))
  -expect some problems when mixing floats and ints together
  -varargs (*x) are not very well supported; keyword args are not supported yet
  -arbitrary-size arithmetic
  -possible non-termination ('recursive customization', have not
encountered it yet)
  -profiling will be required for scaling to very large programs
  -combining binary-type tuples with single-type tuples (e.g. (1,1.0)+(2,))
  -unboxing of small tuples (should form a nice speedup)
  -foreign code has to be modeled and implemented/bridged in C++ 
  -some builtins are not implemented yet, e.g. 'reduce' and 'map'


From dave at boost-consulting.com  Mon Sep 12 00:19:57 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 12 Sep 2005 00:19:57 +0200
Subject: [C++-sig] boost, const and problems
References: <432ec6c505090906024c791a3b@mail.gmail.com>
	<20050910052250.78410.qmail@web31506.mail.mud.yahoo.com>
Message-ID: <ull23gsc2.fsf@boost-consulting.com>

"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:

>> 2005/9/9, anewtroll <anewtroll at free.fr>:
>> > 
>> > Hi !
>> > As a newbie to boost.python, I would like to know why the "const"
>> > argument (i.e. void function(const float t){ ... }) causes an error when
>> > using the bjam (VC++6)
>
> IIRC, this is a general VC6 bug; "const float" or similar doesn't work with
> that compiler.
> Ralf

Just remove it from the function declaration; it has no effect there
anyway other than to mess up Boost.Python.  You can leave the const on
the function definition.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From dave at boost-consulting.com  Mon Sep 12 00:22:22 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 12 Sep 2005 00:22:22 +0200
Subject: [C++-sig] VC 2005 error when wrapping constructor with const
	argument
References: <000001c5b35c$223292b0$aeb5e892@huisdiv.sun.ac.za>
Message-ID: <ufysbgs81.fsf@boost-consulting.com>

"Albert Strasheim" <13640887 at sun.ac.za> writes:

> Hello all
>
> I recently came across a problem when wrapping classes with constructors 
> that take const arguments with Visual C++ 2005 Express Edition Beta 2.
>
> I am using Boost 1.33.0 with Python 2.4.1.
>
> The test case (breaks on VC EE 2005, compiles on VC .NET 2003):
>
> #include <boost/python.hpp>
> class Foo {
> public:
>   Foo(){}
>   Foo(const double){}
> };
> void Export_Foo()
> {
>   boost::python::class_<Foo>("Foo", boost::python::init<>())
>     .def(boost::python::init<const double>())
>     ;
> }

Function parameters declared const are ignored by C++, except for the
purposes of function definitions.  Just remove the const; it doesn't
belong there.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From anewtroll at free.fr  Mon Sep 12 12:19:20 2005
From: anewtroll at free.fr (anewtroll)
Date: Mon, 12 Sep 2005 12:19:20 +0200
Subject: [C++-sig] C++-sig Digest, Vol 26, Issue 9
In-Reply-To: <mailman.0.1126346402.2748.c++-sig@python.org>
References: <mailman.0.1126346402.2748.c++-sig@python.org>
Message-ID: <43255628.9020909@free.fr>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050912/bf7e5492/attachment.htm>

From anewtroll at free.fr  Mon Sep 12 12:20:57 2005
From: anewtroll at free.fr (anewtroll)
Date: Mon, 12 Sep 2005 12:20:57 +0200
Subject: [C++-sig] C++-sig Digest, Vol 26, Issue 11
In-Reply-To: <mailman.0.1126519201.30715.c++-sig@python.org>
References: <mailman.0.1126519201.30715.c++-sig@python.org>
Message-ID: <43255689.3090402@free.fr>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050912/c55b501d/attachment.htm>

From dave at boost-consulting.com  Mon Sep 12 14:46:41 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 12 Sep 2005 14:46:41 +0200
Subject: [C++-sig] Posting Ettiquette
References: <mailman.0.1126346402.2748.c++-sig@python.org>
	<43255628.9020909@free.fr>
Message-ID: <ull221mj2.fsf_-_@boost-consulting.com>

anewtroll <anewtroll at free.fr> writes:

>     Dear Eric and Ralph, thanks a lot for your answers. It was quick and helpful !
>
>        ANT.
>

<snip entire digest>

1. Please don't reply to digests
2. Please don't overquote

http://www.boost.org/more/discussion_policy.htm#quoting

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From ericjardim at gmail.com  Mon Sep 12 17:02:07 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Mon, 12 Sep 2005 12:02:07 -0300
Subject: [C++-sig] Custodian and Ward doubts
Message-ID: <432ec6c50509120802641e859a@mail.gmail.com>

Hi,

I have some questions about "custodian and ward" policy that are not very 
clear on the docs.

Let's suppose we have a wrapped function "object* object::create(object* 
parent)", where the parent is the custodian (holds a internal pointer to) of 
the child, and we wrapped it correctly.

So, if in Python I do:
>>> a = create(None) # no parent
>>> b = create(a) # "a" is "b" parent and custodian
>>> del b # "b" is not deleted, because "a" is guarding it
>>> del a # no more refs, "a" and "b" are deleted

But what if I have another function "void object::setParent(object* 
parent)", where the parent is changed. So, the new parent now is going to be 
the custodian of the object. 
>>> a = create(None) 
>>> b = create(a) 
>>> c = create(None) 
>>> b.setParent(c) # c is the new parent (and should be the new custodian)
???

But what happens to the old parent (if it is not None)? Is it still a 
custodian of the child? Can a child have more than one custodian? Or is it 
like a ownership (only one is the custodian)?

I am asking it because I am having some problems with internal references 
(pointers) from C++ objects to another that Python don't see. So I get many 
objects being deleted prematurely, when they are actually being referenced 
(in C++).

Other problem that I have, is that aside from some "a" object being parent 
(custodian) of "b", internally, "a" deletes "b" and all of it's children 
recursivelly. So Python's "b" waits for Python's "a" to be deleted, and "a" 
is deleted in Python and C++. But with this C++'s "b" is deleted also, and 
when Python is going to be deleted the pointer is dangled. So, In Python "a" 
must die before "b", but in C++, "b" must die before "a". Now what?

The problem is that actually, both parent and child have references to each 
other. But I cannot make circular custodian and ward, because they would 
never get deleted. 

I manage the problem by referencing objects in Python manually, but this 
approach is not very interesting. Apart from this I can have C++ native (not 
created by Boost.Python extended classes contructors), and also, if someone 
may want to extend the library they would have to do a lot of dirty work.

I was thinking that implementing my custom call policies would be an elegant 
and less error prone solution. Basically, every time a function return a 
QObject pointer to Python, I use my custom return value policy, derived from 
reference_existing_object. Internally, I can make a list of objects and 
control when they must die. But I am afraid if this is the best solution.

Does anybody have a problem like this? Which solution do you sugest?

Thanks,

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050912/179b1970/attachment.htm>

From dave at boost-consulting.com  Mon Sep 12 17:33:47 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 12 Sep 2005 17:33:47 +0200
Subject: [C++-sig] Custodian and Ward doubts
References: <432ec6c50509120802641e859a@mail.gmail.com>
Message-ID: <u3boa1esk.fsf@boost-consulting.com>

Eric Jardim <ericjardim at gmail.com> writes:

> Can a child have more than one custodian? 

Yes, it is cumulative.


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From ericjardim at gmail.com  Mon Sep 12 18:48:54 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Mon, 12 Sep 2005 13:48:54 -0300
Subject: [C++-sig] Custodian and Ward doubts
In-Reply-To: <u3boa1esk.fsf@boost-consulting.com>
References: <432ec6c50509120802641e859a@mail.gmail.com>
	<u3boa1esk.fsf@boost-consulting.com>
Message-ID: <432ec6c505091209482f1c9218@mail.gmail.com>

2005/9/12, David Abrahams <dave at boost-consulting.com>:
> 
> Eric Jardim <ericjardim at gmail.com> writes:
> > Can a child have more than one custodian?
> 
> Yes, it is cumulative.
> 

Hmm... So, if I want to change the parent (who is also the custodian of the 
child), I need to say to Boost.Python that it is not a custodian anymore. Is 
it possible?

If not, the custodian and ward model will not fit the needs of the Qt 
library, and I need to it manually (like what I am doing now) or create my 
custom call policies/return value generators. Am I right?

Sugestions, please ;)

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050912/ad2fb435/attachment.htm>

From ron.clarke at hp.com  Mon Sep 12 19:44:04 2005
From: ron.clarke at hp.com (Ron Clarke)
Date: Mon, 12 Sep 2005 10:44:04 -0700
Subject: [C++-sig] Problem with FILE*
Message-ID: <dg4ep6$et1$1@sea.gmane.org>

I know there are some earlier postings similar to this topic, but I've tried 
what is shown there with no success. Perhaps I've missed an important point 
somewhere along the line. So, if you'll please indulge a question that has 
probably been answered somewhere before...

We have a C++ function (not a class member) that takes a pointer to a 
proprietary image format, a FILE*, and some optional arguments:
void planeMajor(bkimage *img, FILE *fp, xint32_t pln0 = 0, xint32_t row0 = 
0, xint32_t col0 = 0, xint32_t pln1 = -1, xint32_t row1 = -1, xint32_t , 
col1 = -1);

This code is wrapped via Boost like this:
struct FILE_to_pyfile
{
    static PyObject* convert(FILE* x)
    {
        return PyFile_FromFile(x, "", "", NULL);
    }
};

struct pyfile_to_FILE
{
    static FILE& execute(PyObject& o)
    {
        return *PyFile_AsFile(&o);
    }
};


BOOST_PYTHON_FUNCTION_OVERLOADS(pclModule_planeMajor, planeMajor, 2, 8)

BOOST_PYTHON_MODULE(pclModule)
{
to_python_converter<FILE*, FILE_to_pyfile>();
...
def("planeMajor", planeMajor, pclModule_planeMajor() );
...
}

And here is the Python code that calls the C++ function, where "im" is the 
Boost-wrapped proprietary image (no problems with the image and all its 
methods), and "f" is a file opened using the Python library:
     f = open(dict['fname'], 'wb')
     f.write(dict['head'])
     print 'opened file %s for pcl output' % dict['fname']

     pclModule.planeMajor(im, f)    <<===== this is the line that causes the 
error


When this is run, I get the following error:

opened file CRD2.pcl for pcl output  <<======the "print" statement from 
above
Traceback (most recent call last):
  File "tryCRD2.py", line 60, in ?
    PCLfns.CRD2PCL(im,dict=dict)
  File "D:\cvsbk\lib\bk\modules\PCLfns.py", line 29, in CRD2PCL
    makePCL(im, dict)
  File "D:\cvsbk\lib\bk\modules\PCLfns.py", line 231, in makePCL
    pclModule.planeMajor(im, f)
Boost.Python.ArgumentError: Python argument types in
    bk.modules.pclModule.planeMajor(bkimage, file)
did not match C++ signature:
    planeMajor(class bkimage *, struct _iobuf *)
    planeMajor(class bkimage *, struct _iobuf *, long)
    planeMajor(class bkimage *, struct _iobuf *, long, long)
    planeMajor(class bkimage *, struct _iobuf *, long, long, long)
    planeMajor(class bkimage *, struct _iobuf *, long, long, long, long)
    planeMajor(class bkimage *, struct _iobuf *, long, long, long, long, 
long)
    planeMajor(class bkimage *, struct _iobuf *, long, long, long, long, 
long, long)


I'm running Python 2.3, Boost.Python 1.31, on Windows XP. Everything is 
compiled under Visual Studio .NET 2003. I've re-built the environment to 
make sure the same C++ runtime is being used by Boost and our code.

Any ideas on what is causing this error?
Thanks in advance.

-- 
Ron Clarke
ron.clarke at hp.com 





From dave at boost-consulting.com  Tue Sep 13 00:30:44 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 12 Sep 2005 18:30:44 -0400
Subject: [C++-sig] Custodian and Ward doubts
References: <432ec6c50509120802641e859a@mail.gmail.com>
	<u3boa1esk.fsf@boost-consulting.com>
	<432ec6c505091209482f1c9218@mail.gmail.com>
Message-ID: <u8xy1x6jv.fsf@boost-consulting.com>

Eric Jardim <ericjardim at gmail.com> writes:

> 2005/9/12, David Abrahams <dave at boost-consulting.com>:
>> 
>> Eric Jardim <ericjardim at gmail.com> writes:
>> > Can a child have more than one custodian?
>> 
>> Yes, it is cumulative.
>> 
>
> Hmm... So, if I want to change the parent (who is also the custodian of the 
> child), I need to say to Boost.Python that it is not a custodian anymore. Is 
> it possible?

Not by using the public interface.

> If not, the custodian and ward model will not fit the needs of the Qt 
> library, and I need to it manually (like what I am doing now) or create my 
> custom call policies/return value generators. Am I right?

I don't know about the needs of the Qt library.

> Sugestions, please ;)

I have nothing off the top of my head and I'm too busy to think about
it in depth at the moment.

sorry,

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From dave at boost-consulting.com  Tue Sep 13 00:31:57 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 12 Sep 2005 18:31:57 -0400
Subject: [C++-sig] Problem with FILE*
References: <dg4ep6$et1$1@sea.gmane.org>
Message-ID: <u3bo9x6hu.fsf@boost-consulting.com>

"Ron Clarke" <ron.clarke at hp.com> writes:

> I'm running Python 2.3, Boost.Python 1.31, on Windows XP. Everything is 
> compiled under Visual Studio .NET 2003. 

Including Python?

> I've re-built the environment to 
> make sure the same C++ runtime is being used by Boost and our code.

If you pass FILE* across the Python/C++ boundary, it had better mean
exactly the same thing on both sides.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From s_sourceforge at nedprod.com  Tue Sep 13 01:40:12 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 13 Sep 2005 00:40:12 +0100
Subject: [C++-sig] Custodian and Ward doubts
In-Reply-To: <u8xy1x6jv.fsf@boost-consulting.com>
Message-ID: <43261FEC.23284.50DC60@localhost>

On 12 Sep 2005 at 18:30, David Abrahams wrote:

> > If not, the custodian and ward model will not fit the needs of the
> > Qt library, and I need to it manually (like what I am doing now) or
> > create my custom call policies/return value generators. Am I right?
> 
> I don't know about the needs of the Qt library.

As I've previously said, custodian and ward won't help you here.

> > Sugestions, please ;)
> 
> I have nothing off the top of my head and I'm too busy to think about
> it in depth at the moment.

As I've also previously said, go learn from TnFOX's python bindings. 
It's the same style of GUI library. Of course, if you prefer to 
keeping banging along alone without examining existing 
implementations, please do feel free - but don't expect much help 
from anyone in here.

Cheers,
Niall





From ericjardim at gmail.com  Tue Sep 13 01:49:21 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Mon, 12 Sep 2005 20:49:21 -0300
Subject: [C++-sig] Custodian and Ward doubts
In-Reply-To: <u8xy1x6jv.fsf@boost-consulting.com>
References: <432ec6c50509120802641e859a@mail.gmail.com>
	<u3boa1esk.fsf@boost-consulting.com>
	<432ec6c505091209482f1c9218@mail.gmail.com>
	<u8xy1x6jv.fsf@boost-consulting.com>
Message-ID: <432ec6c505091216493cdd4d06@mail.gmail.com>

2005/9/12, David Abrahams <dave at boost-consulting.com>:
> 
> I have nothing off the top of my head and I'm too busy to think about
> it in depth at the moment.
> 
> sorry,
> 

Ok. I am studing the Boost.Python code. I think implementing custom call 
policies will help me controlling the references.

I just wanted to know if somebody dealed with this same situation before. Or 
any helpful sugestion. 

Thanks, anyway...

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050912/7b55f61b/attachment.htm>

From ericjardim at gmail.com  Tue Sep 13 01:58:22 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Mon, 12 Sep 2005 20:58:22 -0300
Subject: [C++-sig] Custodian and Ward doubts
In-Reply-To: <43261FEC.23284.50DC60@localhost>
References: <u8xy1x6jv.fsf@boost-consulting.com>
	<43261FEC.23284.50DC60@localhost>
Message-ID: <432ec6c505091216585680000f@mail.gmail.com>

2005/9/12, Niall Douglas <s_sourceforge at nedprod.com>:
> 
> As I've previously said, custodian and ward won't help you here.


I know, I know. I was using it as a workaround, before I find a better 
solution. I was trying to use and understand all Boost.Python before doing 
my custom converters.

As I've also previously said, go learn from TnFOX's python bindings.
> It's the same style of GUI library. 


Sure. At that time, I downloaded your code and studied it. But, maybe 
because I was too dumb, I cound't find the "things" I needed inside your 
code. I'll try it again, now that I am more confortable with Boost.Python.

Of course, if you prefer to
> keeping banging along alone without examining existing
> implementations, please do feel free - but don't expect much help
> from anyone in here.


Please, don't be so rude. You are being very unfair with me. I am doing my 
best to do this Qt bindings (sorry for being a bad hacker). I, in fact, 
looked at your code. I just did't find what I wanted. I just found some 
converters. I may look again to find something.

Thanks,

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050912/240c2801/attachment.htm>

From ericjardim at gmail.com  Tue Sep 13 03:16:45 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Mon, 12 Sep 2005 22:16:45 -0300
Subject: [C++-sig] Custom memory management
In-Reply-To: <42EADD6E.18893.2A65C95@localhost>
References: <432ec6c505072907287d0db36e@mail.gmail.com>
	<42EADD6E.18893.2A65C95@localhost>
Message-ID: <432ec6c5050912181625103cf3@mail.gmail.com>

Let's do some "flashback" here:

2005/7/29, Niall Douglas <s_sourceforge at nedprod.com>:
> 
> Custodian and ward won't help you here. This is happening because
> python likes to manage the lifetime of its objects and doesn't know
> when Qt deletes them from underneath it.


Hmm, so that was the problem. Python didn't notice when some objects where 
destroyed in C++.

> Besides, I suspect that I reference the same C++ object more than one
> > time which might be a problem.
> 
> Shouldn't be. BPL refcounts.


This was other problem. But now is solved.

Make your wrappers hold an auto_ptr to your Qt objects. This works as
> you'd expect it. Upcall when Qt deletes an object to the python layer
> so it zeros the auto_ptr so python won't delete anything later. If
> you want to see it in action, see how TnFOX does it at
> http://www.nedprod.com/TnFOX/ (get the most recent snapshot).
> 

So, do you think auto_ptr will do the trick. I'll try it.

What do you mean by "upcall"? I really did not understood this sentense 
(sorry).

Can you show me one of your classes in TnFOX that acts like QObject class in 
Qt (parent->child)?

Peace,

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050912/38bf7a6e/attachment.htm>

From dave at boost-consulting.com  Tue Sep 13 13:44:59 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 13 Sep 2005 07:44:59 -0400
Subject: [C++-sig] boost python memoryleak
In-Reply-To: <43269B19.40208@sigmatek.at> (Johann Obermayr's message of "Tue, 
	13 Sep 2005 11:25:45 +0200")
References: <43269B19.40208@sigmatek.at>
Message-ID: <uek7ttcn8.fsf@boost-consulting.com>

Johann Obermayr <johann.obermayr at sigmatek.at> writes:

> Hello,
>
> We have found a memory leak in the boost python.
> And we solved it with this.
>
> boost\python\converter\registrations.hpp
>
> struct BOOST_PYTHON_DECL registration
> {
> public: // member functions
>    explicit registration(type_info);
>
>    ~registration();            // <---- add this
> }
>   
> // and add this to registrations.hpp
>
> inline registration::~registration()
> {
>    delete lvalue_chain;
>    delete rvalue_chain;
> }
>
> Please can you add this for next relase.

Since Boost support is my profession, I do not accept requests for
free support at my personal email; I hope you understand.  Please post
to the appropriate mailing list
http://www.boost.org/more/mailing_lists.htm#cplussig

Boost.Python leaks many things from that point-of-view; it is not
compatible with PyFinalize.  Until that gets fixed there's no point in
trying to clean up things like this.  Also, your change doesn't
properly clean up the remainder of the chains, so it wouldn't be the
right one to make even if it were appropriate to try to fix it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


From vivid at frontfree.net  Tue Sep 13 14:53:42 2005
From: vivid at frontfree.net (=?gb2312?B?3PfEyA==?=)
Date: Tue, 13 Sep 2005 20:53:42 +0800
Subject: [C++-sig] SOS !
Message-ID: <20050913125751.6290D13183F@beastie.frontfree.net>

int main()

{

 

using namespace luabind;

 

 lua_State* L = lua_open();

 luabind::open( L );

object stateTable = get_globals(L);//["stateTable"]; 

 

 for( object::iterator curState = stateTable.begin

();curState != stateTable.end();

  curState++ )

 {

  printf("%d\n",object_cast<int>(stateTable

[curState.key()]));

 }

...

}

 

 

my lua file:

table.lua

stateTable=

{ IDLE = 1,

  APPROACH =2,

  ATTACK = 3,

  ESCAPE = 4,

} 

  

 

I am a teenager from China.

These days I was interested in luabind,especially 

getting the elements from a lua table .

Why can't I realize it or make it run on the Visual 

Studio?

It seems to be the problem of the conversion of types 

between the languages(lua and c++).

I am not skillful at using the "object_cast". 

Could you give me some advice or instruct me a little?

Thank you very much!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050913/8e426a74/attachment.htm>

From s_sourceforge at nedprod.com  Tue Sep 13 15:35:29 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 13 Sep 2005 14:35:29 +0100
Subject: [C++-sig] Custodian and Ward doubts
In-Reply-To: <432ec6c505091216585680000f@mail.gmail.com>
References: <43261FEC.23284.50DC60@localhost>
Message-ID: <4326E3B1.2490.92C240@localhost>

On 12 Sep 2005 at 20:58, Eric Jardim wrote:

> > Of course, if you prefer to
> > keeping banging along alone without examining existing
> > implementations, please do feel free - but don't expect much help
> > from anyone in here.
> 
> Please, don't be so rude. You are being very unfair with me. I am
> doing my best to do this Qt bindings (sorry for being a bad hacker).
> I, in fact, looked at your code. I just did't find what I wanted. I
> just found some converters. I may look again to find something.

Yeah I'm sorry about how I wrote that - it popped into my head last 
night when I was in bed that I was being too harsh. I apologise.

You're actually a *good* hacker, you have got your BPL bindings of Qt 
up to a level which took me far longer with TnFOX. And you've had far 
less questions than I had during the process. So you're doing very 
well.

However, to answer your question, what you need is a mechanism that 
when a Qt object dies, it upcalls to its BPL equivalent that it is 
dead now so the BPL equivalent can mark itself as useless. You can't 
delete the BPL equivalent because python maintains exclusive rights 
to do that, but you must make sure that when python does delete it it 
doesn't go trying to redelete your Qt object.

The way I handled this in TnFOX is to add a special virtual method to 
FXObject which detaches that FXObject instance from its BPL 
representation - if it has one. I then patched pyste to add an 
override for that virtual function to the generated virtual class 
wrapper which does the appropriate detaching. Obviously, non-BPL 
represented FXObject's don't do any detaching.

For Qt, you are slightly more stuck than I was here as you can't just 
go and add a special virtual function to QObject or maybe even the 
MOC (though if you were to ask Trolltech, they might just do so). You 
need some non-intrusive method.

All QObject's will have a virtual destructor, so perhaps in the 
wrapper you could detach from BPL there. I did try this in TnFOX, but 
I ran into problems I think because BPL thinks by then you're getting 
deleted so it's too late - I vaguely remember that the virtual 
function table had got reset by then, implying some class internally 
inherits again from the wrapper. I didn't persist with this solution 
though because having each FXObject make its python representation 
available to all TnFOX code was too attractive, and I have full 
control over the source, so I just went ahead and did that instead.

I hope this helps. BTW, use TnFOX from SVN rather than v0.85 - it has 
many python problems fixed.

Cheers,
Niall





From ericjardim at gmail.com  Tue Sep 13 16:02:42 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Tue, 13 Sep 2005 11:02:42 -0300
Subject: [C++-sig] Custodian and Ward doubts
In-Reply-To: <4326E3B1.2490.92C240@localhost>
References: <43261FEC.23284.50DC60@localhost>
	<432ec6c505091216585680000f@mail.gmail.com>
	<4326E3B1.2490.92C240@localhost>
Message-ID: <432ec6c5050913070239bcb58a@mail.gmail.com>

2005/9/13, Niall Douglas <s_sourceforge at nedprod.com>:
> 
> Yeah I'm sorry about how I wrote that - it popped into my head last
> night when I was in bed that I was being too harsh. I apologise.


Ok, let's forget it ;)

However, to answer your question, what you need is a mechanism that
> when a Qt object dies, it upcalls to its BPL equivalent that it is
> dead now so the BPL equivalent can mark itself as useless. 


That's easy. This could be implemented as a virtual function, but that would 
only handle Python wrappers (my custom QObject extensions). I wanto also to 
handle C++ pure object (i hope you understand what I am talking about).

The good news is that Qt4 QObjects have a signal "destroyed" that informs 
when *any* kind of object is deleted. So, this could be used to do the 
"upcall".

How can a Python object be "useless"? I mean, if I have "a" and "b" objects, 
where "a" is "b" parent, if I delete "a", then "b" is also deleted. But if I 
still have a reference to "b", what would it be holding? None?

You can't
> delete the BPL equivalent because python maintains exclusive rights
> to do that, but you must make sure that when python does delete it it
> doesn't go trying to redelete your Qt object.


Hmm, sure. That's what I am trying to do. One solution I thought is to 
detach the children (in Python's __del__) before the parent really dies (in 
C++ destructor). This would prevent the children from being deleted. If the 
children refcount to 0 they would be deleted alone.

The way I handled this in TnFOX is to add a special virtual method to
> FXObject which detaches that FXObject instance from its BPL
> representation - if it has one. 


How do you do this? That's the point.
 
For Qt, you are slightly more stuck than I was here as you can't just
> go and add a special virtual function to QObject or maybe even the
> MOC (though if you were to ask Trolltech, they might just do so). You
> need some non-intrusive method.


I don't, as I said before. I can use the signal.

I hope this helps. BTW, use TnFOX from SVN rather than v0.85 - it has
> many python problems fixed.
> 

Yes, you helped. Instead, I don't see any "auto_ptr" on you implementation. 
How are you holding you references?

BTW, I think I have a 0.86 snapshot at home.

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050913/03ea2cc7/attachment.htm>

From chris at commercialaquatics.com  Tue Sep 13 18:14:29 2005
From: chris at commercialaquatics.com (Chris Henry)
Date: Tue, 13 Sep 2005 11:14:29 -0500
Subject: [C++-sig]  Re: std::wstring availability
Message-ID: <200509131117611.SM01384@ALBSOUTH>

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050913/1a67791a/attachment.htm>

From s_sourceforge at nedprod.com  Tue Sep 13 21:27:20 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 13 Sep 2005 20:27:20 +0100
Subject: [C++-sig] Custodian and Ward doubts
In-Reply-To: <432ec6c5050913070239bcb58a@mail.gmail.com>
References: <4326E3B1.2490.92C240@localhost>
Message-ID: <43273628.19100.1D4E1DF@localhost>

On 13 Sep 2005 at 11:02, Eric Jardim wrote:

> However, to answer your question, what you need is a mechanism that >
> when a Qt object dies, it upcalls to its BPL equivalent that it is >
> dead now so the BPL equivalent can mark itself as useless. 
> 
> That's easy. This could be implemented as a virtual function, but that
> would only handle Python wrappers (my custom QObject extensions). I
> wanto also to handle C++ pure object (i hope you understand what I am
> talking about).

Yes you need the virtual function in the C++ object, not the python 
wrapper.

> The good news is that Qt4 QObjects have a signal "destroyed" that
> informs when *any* kind of object is deleted. So, this could be used
> to do the "upcall".

If that signal gets sent during the QObject destructor then it's no 
better (your virtual function table is still dead). And I'd kinda 
have to think that must be the case as who knows what the subclass 
does to destroy itself.

> How can a Python object be "useless"? I mean, if I have "a" and "b"
> objects, where "a" is "b" parent, if I delete "a", then "b" is also
> deleted. But if I still have a reference to "b", what would it be
> holding? None?

I forgot to mention last msg that in the code in FXShell in TnFOX 
where FXShell deletes the child windows, I added code which first 
calls that detach from BPL virtual function.

Sorry right now is not the best time. I'm moving country tomorrow 
morning.

> You can't
> > delete the BPL equivalent because python maintains exclusive rights
> > to do that, but you must make sure that when python does delete it
> > it doesn't go trying to redelete your Qt object.
> 
> Hmm, sure. That's what I am trying to do. One solution I thought is to
> detach the children (in Python's __del__) before the parent really
> dies (in C++ destructor). This would prevent the children from being
> deleted. If the children refcount to 0 they would be deleted alone.

I don't see how this helps. If Qt deletes a child and then python 
tries to access it, you still get a segfault.

> The way I handled this in TnFOX is to add a special virtual method to
> > FXObject which detaches that FXObject instance from its BPL >
> representation - if it has one. 
> 
> 
> How do you do this? That's the point.

You wrap auto_ptr's to the QObject subclasses. You simply release the 
auto_ptr to detach.
 
> Yes, you helped. Instead, I don't see any "auto_ptr" on you
> implementation. How are you holding you references?

I patch pyste to generate the appropriate wrapper code. See 
BoostPatches.zip in the TnFOX SVN.

As of tonight I'll be offline for a few days until I get set up in 
Scotland, but I'll reply when next I can.

Cheers,
Niall





From Hubert.Holin at meteo.fr  Wed Sep 14 17:46:41 2005
From: Hubert.Holin at meteo.fr (Hubert Holin)
Date: Wed, 14 Sep 2005 17:46:41 +0200
Subject: [C++-sig] Redirecting stdout for B.P extensions?
Message-ID: <EE243EAA-7D82-44EA-B7EA-DF7FE5FCF7DC@meteo.fr>

Somewhere in the E.U., le 14/09/2005

     Bonjour

         In a (perhaps perverse) project involving Objective-C  
(Cocoa), Python and C++, I have run into a difficulty for which I  
know an unpleasant workaround, and for which I am looking for a  
gentler cure.

         In essence, at some point a Python script is calling a  
function which is actually coded in C++ using Boost.Python (and began  
life as part of a terminal tool). Prior to the call, I redirect  
Python's output stream (by assigning to sys.stdout). From that point  
onward, Python does print where it is told to, but C++ code within  
the extension which "<<"'s to ::std::cout is not redirected (apart  
from that, the whole shebang works nicely).

         As I have full control over the C++ code, I can add another  
parameter to the extension function's call to represent the  
destination of outputs, and recode all over the place. That's the  
unpleasant workaround. What I would like would be for a mechanism to  
tell the extension to actually use Python's current sys.stdout. At  
any rate, there will necessarily come a time when I will use some C++  
code over which I will *not* have control, so a general cure would be  
best...

     Merci

             Hubert Holin

P.S.: sorry, I found no way to search the archive... pointers to that  
welcome as well!



From lists at nabble.com  Wed Sep 14 19:01:51 2005
From: lists at nabble.com (kooto (sent by Nabble.com))
Date: Wed, 14 Sep 2005 10:01:51 -0700 (PDT)
Subject: [C++-sig] Redirecting stdout for B.P extensions?
In-Reply-To: <EE243EAA-7D82-44EA-B7EA-DF7FE5FCF7DC@meteo.fr>
References: <EE243EAA-7D82-44EA-B7EA-DF7FE5FCF7DC@meteo.fr>
Message-ID: <862207.post@talk.nabble.com>



Hubert Holin wrote: 
> 
>              Hubert Holin
> P.S.: sorry, I found no way to search the archive... pointers to that  
> welcome as well!
> 

Nabble has an archive search but it only started archiving this list a few weeks ago, you can browse and search here c++ list here: http://www.nabble.com/Python---c%2B%2B-sig-f2927.html

Or you can browse or search all python lists archive here: http://www.nabble.com/Python-f2926.html

Gmane also has an archive search: http://dir.gmane.org/gmane.comp.python.c++ - for the c++ list it has much more historical data.
--
Sent from the Python - c++-sig forum at Nabble.com:
http://www.nabble.com/-C%2B%2B-sig-Redirecting-stdout-for-B.P-extensions--t308150.html#a862207
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050914/21f8d039/attachment.htm>

From pierre.barbier at cirad.fr  Wed Sep 14 19:23:58 2005
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Wed, 14 Sep 2005 19:23:58 +0200
Subject: [C++-sig] Redirecting stdout for B.P extensions?
In-Reply-To: <EE243EAA-7D82-44EA-B7EA-DF7FE5FCF7DC@meteo.fr>
References: <EE243EAA-7D82-44EA-B7EA-DF7FE5FCF7DC@meteo.fr>
Message-ID: <43285CAE.6020202@cirad.fr>

Hello,

Basically, sys.stdout is NOT the standard output of your program, it's
merely the Python wrapper used as stdout. So if you replace sys.stdout,
only Python-aware code explicitly using sys.stdout will see its output
redirected.

If you want to redirect the *real* stdout, you have to use the good old
C way ;) Basically, replace the file descriptor 1 (stdout) with any file
descriptor you have created (usually a pipe). But this becomes a system
question without relation to Python !

Pierre

Hubert Holin a ?crit :
> Somewhere in the E.U., le 14/09/2005
> 
>      Bonjour
> 
>          In a (perhaps perverse) project involving Objective-C  
> (Cocoa), Python and C++, I have run into a difficulty for which I  
> know an unpleasant workaround, and for which I am looking for a  
> gentler cure.
> 
>          In essence, at some point a Python script is calling a  
> function which is actually coded in C++ using Boost.Python (and began  
> life as part of a terminal tool). Prior to the call, I redirect  
> Python's output stream (by assigning to sys.stdout). From that point  
> onward, Python does print where it is told to, but C++ code within  
> the extension which "<<"'s to ::std::cout is not redirected (apart  
> from that, the whole shebang works nicely).
> 
>          As I have full control over the C++ code, I can add another  
> parameter to the extension function's call to represent the  
> destination of outputs, and recode all over the place. That's the  
> unpleasant workaround. What I would like would be for a mechanism to  
> tell the extension to actually use Python's current sys.stdout. At  
> any rate, there will necessarily come a time when I will use some C++  
> code over which I will *not* have control, so a general cure would be  
> best...
> 
>      Merci
> 
>              Hubert Holin
> 
> P.S.: sorry, I found no way to search the archive... pointers to that  
> welcome as well!
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 

-- 
Pierre Barbier de Reuille

INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France

tel   : (33) 4 67 61 65 77    fax   : (33) 4 67 61 56 68


From Hubert.Holin at free.fr  Wed Sep 14 23:31:22 2005
From: Hubert.Holin at free.fr (Hubert Holin)
Date: Wed, 14 Sep 2005 23:31:22 +0200
Subject: [C++-sig] Redirecting stdout for B.P extensions?
In-Reply-To: <43285CAE.6020202@cirad.fr>
References: <EE243EAA-7D82-44EA-B7EA-DF7FE5FCF7DC@meteo.fr>
	<43285CAE.6020202@cirad.fr>
Message-ID: <74A28DAC-CEE4-4F14-A61F-66698FA3735C@free.fr>

Paris (U.E.), le 14/09/2005

     Bonsoir

         That's interesting!

         However, were I to embed Python, I assume I could swap out  
cout's file descriptor and both the Python scripts and subsequent C++  
code would be none the wiser, but if instead I extend Python (as is  
the case in my current project), I either have to find a way to  
access the Python executable's cout file descriptor (how would I do  
that? by using a C extension?), or have to make every script and  
extension aware of an additional parameter (be it a pipe or whatever,  
to redirect to) and code explicitly for that (i.e. it would not be  
transparent at al).

         Is that correct?

     Merci

             Hubert Holin

On 14 sept. 2005, at 19:23, Pierre Barbier de Reuille wrote:

> Hello,
>
> Basically, sys.stdout is NOT the standard output of your program, it's
> merely the Python wrapper used as stdout. So if you replace  
> sys.stdout,
> only Python-aware code explicitly using sys.stdout will see its output
> redirected.
>
> If you want to redirect the *real* stdout, you have to use the good  
> old
> C way ;) Basically, replace the file descriptor 1 (stdout) with any  
> file
> descriptor you have created (usually a pipe). But this becomes a  
> system
> question without relation to Python !
>
> Pierre
>
> Hubert Holin a ?crit :
>
>> Somewhere in the E.U., le 14/09/2005
>>
>>      Bonjour
>>
>>          In a (perhaps perverse) project involving Objective-C
>> (Cocoa), Python and C++, I have run into a difficulty for which I
>> know an unpleasant workaround, and for which I am looking for a
>> gentler cure.
>>
>>          In essence, at some point a Python script is calling a
>> function which is actually coded in C++ using Boost.Python (and began
>> life as part of a terminal tool). Prior to the call, I redirect
>> Python's output stream (by assigning to sys.stdout). From that point
>> onward, Python does print where it is told to, but C++ code within
>> the extension which "<<"'s to ::std::cout is not redirected (apart
>> from that, the whole shebang works nicely).

[SNIP]

>> P.S.: sorry, I found no way to search the archive... pointers to that
>> welcome as well!

[SNIP]




From ericjardim at gmail.com  Wed Sep 14 19:10:00 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Wed, 14 Sep 2005 14:10:00 -0300
Subject: [C++-sig] ANN: python-qt4 0.0.3
Message-ID: <432ec6c505091410105999de0d@mail.gmail.com>

Qt4 bindings for Python using Boost.Python. The goal is to make a very 
pythonic API but taking advantage of thepower of Qt. Another goals are: 
QtDesigner integration, C++ embedded Python Widgets and an extensive 
documentation with demos and examples.

>>> Changelog for 0.0.3
- Support for unicode 
- Rewriten connection mechanism. Now we use QMetaObject.
- Added suppor for Layout classes
- Added a few examples (exmaples/layout) and some tests
- Better support for virtual methods (specially in QObject, QLayoutItem, 
QLayout)
- Better memory management (still unstable)
- Using custom Boost.Python policy to manage parent/child references
- QtDesigner plugin (just a scratch)
- C++ embedding (exemple, must become a library)

http://developer.berlios.de/projects/python-qt4/

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050914/94153ffd/attachment.htm>

From mrovner at propel.com  Thu Sep 15 01:24:16 2005
From: mrovner at propel.com (Mike Rovner)
Date: Wed, 14 Sep 2005 16:24:16 -0700
Subject: [C++-sig] Redirecting stdout for B.P extensions?
In-Reply-To: <74A28DAC-CEE4-4F14-A61F-66698FA3735C@free.fr>
References: <EE243EAA-7D82-44EA-B7EA-DF7FE5FCF7DC@meteo.fr>	<43285CAE.6020202@cirad.fr>
	<74A28DAC-CEE4-4F14-A61F-66698FA3735C@free.fr>
Message-ID: <dgabg1$old$1@sea.gmane.org>

Hubert Holin wrote:
> Paris (U.E.), le 14/09/2005
>          However, were I to embed Python, I assume I could swap out  
> cout's file descriptor and both the Python scripts and subsequent C++  
> code would be none the wiser, but if instead I extend Python (as is  
> the case in my current project), I either have to find a way to  
> access the Python executable's cout file descriptor (how would I do  
> that? by using a C extension?), or have to make every script and  
> extension aware of an additional parameter (be it a pipe or whatever,  
> to redirect to) and code explicitly for that (i.e. it would not be  
> transparent at al).
> 
>          Is that correct?

It will not be transparent in either case as you depend on Python notion 
of sys.stdout.

You can access the Python executable's cout file descriptor as (untested!):

{
using namespace boost::python;

object sys(PyImport_ImportModule("sys"));
object sys_stdout = sys.attr("stdout");

if( PyFile_Check(sys_stdout.ptr()) )
{
   FILE* cout_file = PyFile_AsFile(sys_stdout.ptr());
   // ...
}
else
{
   throw PythonStdoutNotAfile();
}
}



From jbrandmeyer at earthlink.net  Thu Sep 15 01:27:43 2005
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Wed, 14 Sep 2005 19:27:43 -0400
Subject: [C++-sig] Redirecting stdout for B.P extensions?
In-Reply-To: <74A28DAC-CEE4-4F14-A61F-66698FA3735C@free.fr>
References: <EE243EAA-7D82-44EA-B7EA-DF7FE5FCF7DC@meteo.fr>
	<43285CAE.6020202@cirad.fr>
	<74A28DAC-CEE4-4F14-A61F-66698FA3735C@free.fr>
Message-ID: <1126740463.15864.35.camel@localhost.localdomain>

On Wed, 2005-09-14 at 23:31 +0200, Hubert Holin wrote:
> Paris (U.E.), le 14/09/2005
> 
>      Bonsoir
> 
>          That's interesting!
> 
>          However, were I to embed Python, I assume I could swap out  
> cout's file descriptor and both the Python scripts and subsequent C++  
> code would be none the wiser, but if instead I extend Python (as is  
> the case in my current project), I either have to find a way to  
> access the Python executable's cout file descriptor (how would I do  
> that? by using a C extension?), or have to make every script and  
> extension aware of an additional parameter (be it a pipe or whatever,  
> to redirect to) and code explicitly for that (i.e. it would not be  
> transparent at al).

You can write a custom streambuf that dumps its data via
PyFile_WriteString() to sys.stderr, and redirect std::cerr to an
instance of your custom streambuf.  This way, redirection of sys.stderr
from within Python will have the intended effect on std::cerr.

You can do this whether you are embedding or extending Python.

HTH,
-Jonathan


> > Hubert Holin a ?crit :
> >
> >> Somewhere in the E.U., le 14/09/2005
> >>
> >>      Bonjour
> >>
> >>          In a (perhaps perverse) project involving Objective-C
> >> (Cocoa), Python and C++, I have run into a difficulty for which I
> >> know an unpleasant workaround, and for which I am looking for a
> >> gentler cure.
> >>
> >>          In essence, at some point a Python script is calling a
> >> function which is actually coded in C++ using Boost.Python (and began
> >> life as part of a terminal tool). Prior to the call, I redirect
> >> Python's output stream (by assigning to sys.stdout). From that point
> >> onward, Python does print where it is told to, but C++ code within
> >> the extension which "<<"'s to ::std::cout is not redirected (apart
> >> from that, the whole shebang works nicely).
> 
> [SNIP]
> 
> >> P.S.: sorry, I found no way to search the archive... pointers to that
> >> welcome as well!
> 
> [SNIP]
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig



From rwgk at yahoo.com  Thu Sep 15 04:06:49 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 14 Sep 2005 19:06:49 -0700 (PDT)
Subject: [C++-sig] Redirecting stdout for B.P extensions?
In-Reply-To: <1126740463.15864.35.camel@localhost.localdomain>
Message-ID: <20050915020649.45025.qmail@web31511.mail.mud.yahoo.com>

--- Jonathan Brandmeyer <jbrandmeyer at earthlink.net> wrote:
> You can write a custom streambuf that dumps its data via
> PyFile_WriteString() to sys.stderr, and redirect std::cerr to an
> instance of your custom streambuf.  This way, redirection of sys.stderr
> from within Python will have the intended effect on std::cerr.

Very interesting. I'd like to add some fragments of production code that show
how to use the Python C API to write to sys.stdout (or any other Python object
with write() and flush() methods). See below. The "python_out" class is wrapped
with Boost.Python and instantiated with sys.stdout as the argument.

Question: how can I redirect std::cout and std::cerr to use a custom streambuf
object? Can I simply write std::cout = my_custom_streambuf_instance? That would
be exciting.

Thanks!
        Ralf


struct python_out
{
  virtual ~python_out();
  virtual void write(const std::string& text);
  virtual void flush();

  python_out(boost::python::object const& file_object)
  :
    have_flush(false),
    write_method(file_object.attr("write"))
  {
    if (PyObject_HasAttrString(file_object.ptr(), "flush")) {
      flush_method = file_object.attr("flush");
      have_flush = true;
    }
  }

  bool have_flush;
  boost::python::object write_method;
  boost::python::object flush_method;
};

void
python_out::write(const std::string& text)
{
  write_method(text);
}

void
python_out::flush()
{
  if (have_flush) flush_method();
}

python_out::~python_out() {}


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From ericjardim at gmail.com  Thu Sep 15 14:56:53 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Thu, 15 Sep 2005 09:56:53 -0300
Subject: [C++-sig] Little question about ptr()
Message-ID: <432ec6c50509150556785c9c3c@mail.gmail.com>

Just a quick one,

Supposing I have exposed a non-copyable class "Widget", and somewhere in the 
wrapper class declarations, I have:

struct Widget_Wrapper, wrapper<Widget> {
... 
virtual bool 
mouseClicked(Widget* w) {
if(override o = this->get_override("mouseClicked")
return o( ptr(w) ); // <- look at this point
else
return this->Widget::mouseClicked(w);
}
...
};

I cannot pass "w" directly because "Widget*" is not registered to be passed 
by-value (but Widget is), so I must use "ptr()". That's ok, and is working 
fine, but I don't think it is very explicit in the docs. The "ptr" docs just 
say it is usefull to pass "expensive" objects. I think that "ptr()" is 
necessary when passing any unregistered pointer types. Copyable objects may 
be an exception.

I just want to know if this is the "right" approach, because I think that 
Pyste, for example, don't handle this. I know that are some other 
possibilites like defining a "implicitly_convertible<Widget*, object>()", 
but I must somewhere define it in the class wrapper first. I am dealing with 
a lot of classes that may be passes as pointer.

I, instead, use a different approach using a metafunction to find if it is a 
pointer or not, plus some macros to help my job:
http://svn.berlios.de/viewcvs/python-qt4/trunk/PythonQt/Wrapper.h?view=markup

I just want to know if using "ptr()" is the correct approach in this case, 
or if I am doing "overwork". 

Thanks,

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050915/d6a066a0/attachment.htm>

From meine at kogs1.informatik.uni-hamburg.de  Thu Sep 15 16:15:23 2005
From: meine at kogs1.informatik.uni-hamburg.de (Hans Meine)
Date: Thu, 15 Sep 2005 16:15:23 +0200
Subject: [C++-sig] Redirecting stdout for B.P extensions?
In-Reply-To: <43285CAE.6020202@cirad.fr>
References: <EE243EAA-7D82-44EA-B7EA-DF7FE5FCF7DC@meteo.fr>
	<43285CAE.6020202@cirad.fr>
Message-ID: <200509151615.23761.meine@kogs.informatik.uni-hamburg.de>

Hi everybody!

On Wednesday 14 September 2005 19:23, Pierre Barbier de Reuille wrote:
> Basically, sys.stdout is NOT the standard output of your program, it's
> merely the Python wrapper used as stdout. So if you replace sys.stdout,
> only Python-aware code explicitly using sys.stdout will see its output
> redirected.
>
> If you want to redirect the *real* stdout, you have to use the good old
> C way ;) Basically, replace the file descriptor 1 (stdout) with any file
> descriptor you have created (usually a pipe). But this becomes a system
> question without relation to Python !

AFAIK this is the whole truth, and you should do exactly that "good old C 
way", which involves os.dup and os.dup2.  Attached you'll find ready-to-use 
code (courtesy of Robert Kern from IPython-dev).

-- 
Ciao, /  /
     /--/
    /  / ANS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: redir.py
Type: application/x-python
Size: 890 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050915/1f7d4339/attachment.bin>

From jbrandmeyer at earthlink.net  Thu Sep 15 17:31:13 2005
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Thu, 15 Sep 2005 11:31:13 -0400
Subject: [C++-sig] Redirecting stdout for B.P extensions?
In-Reply-To: <20050915020649.45025.qmail@web31511.mail.mud.yahoo.com>
References: <20050915020649.45025.qmail@web31511.mail.mud.yahoo.com>
Message-ID: <1126798273.31444.9.camel@localhost.localdomain>

On Wed, 2005-09-14 at 19:06 -0700, Ralf W. Grosse-Kunstleve wrote:
> --- Jonathan Brandmeyer <jbrandmeyer at earthlink.net> wrote:
> > You can write a custom streambuf that dumps its data via
> > PyFile_WriteString() to sys.stderr, and redirect std::cerr to an
> > instance of your custom streambuf.  This way, redirection of sys.stderr
> > from within Python will have the intended effect on std::cerr.
> 
> Very interesting. I'd like to add some fragments of production code that show
> how to use the Python C API to write to sys.stdout (or any other Python object
> with write() and flush() methods). See below. The "python_out" class is wrapped
> with Boost.Python and instantiated with sys.stdout as the argument.
> 
> Question: how can I redirect std::cout and std::cerr to use a custom streambuf
> object? Can I simply write std::cout = my_custom_streambuf_instance? That would
> be exciting.

std::streambuf* old = std::cout.rdbuf( &my_custom_streambuf_instance);

Here is a start that adapts some of your code to suit.  

After importing sbuf_test, the program will crash on shutdown when cout
and cerr's destructors try to flush the Python stream that has already
been finalized.  Perhaps this would be a good point to add a PyFinalize
hook that restores the streambufs?

-Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py_ostreambuf.hpp
Type: text/x-c++hdr
Size: 1610 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050915/7d2a21d0/attachment.hpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sbuf_test.cpp
Type: text/x-c++src
Size: 777 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050915/7d2a21d0/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sbuf_test_run.py
Type: text/x-python
Size: 113 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050915/7d2a21d0/attachment.py>

From rwgk at yahoo.com  Thu Sep 15 21:33:48 2005
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 15 Sep 2005 12:33:48 -0700 (PDT)
Subject: [C++-sig] Redirecting stdout for B.P extensions?
In-Reply-To: <1126798273.31444.9.camel@localhost.localdomain>
Message-ID: <20050915193349.85747.qmail@web31511.mail.mud.yahoo.com>

--- Jonathan Brandmeyer <jbrandmeyer at earthlink.net> wrote:
> > Question: how can I redirect std::cout and std::cerr to use a custom
> streambuf
> > object? Can I simply write std::cout = my_custom_streambuf_instance? That
> would
> > be exciting.
> 
> std::streambuf* old = std::cout.rdbuf( &my_custom_streambuf_instance);

Cool. Thanks!

> Here is a start that adapts some of your code to suit.  
> 
> After importing sbuf_test, the program will crash on shutdown when cout
> and cerr's destructors try to flush the Python stream that has already
> been finalized.  Perhaps this would be a good point to add a PyFinalize
> hook that restores the streambufs?

I looked around a bit in the Python C API docs. The closest I could find is
Py_AtExit(), but to me it seems that the registered functions are called too
late, i.e. after sys.stdout is finalized already. Is there another hook I
missed?

Cheers,
        Ralf



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com


From Dennis.Brakhane at urz.uni-heidelberg.de  Fri Sep 16 01:23:10 2005
From: Dennis.Brakhane at urz.uni-heidelberg.de (Dennis Brakhane)
Date: Fri, 16 Sep 2005 01:23:10 +0200
Subject: [C++-sig] How to wrap many virtual function
Message-ID: <432A025E.7080808@ix.urz.uni-heidelberg.de>

Hello list!

I want to wrap an interface that uses many virtual functions, some of 
them pure virtual, with many derived classes. Consider the following 
example:


struct Foo
{
     Foo(int a, int b=42);

     virtual ~Foo();

     virtual void v() = 0;
     virtual void v2();

     void showab();
     int a,b;

};

void Foo::v2()
{cout<<"foo v2"<<endl;}

struct Bar : public Foo
{
     Bar(int a,int b=42) : Foo(a,b) {}
     virtual void v();

};


void Bar::v()
{
     cout << "v" << endl;
}

void call_v(Foo& foo)
{
     foo.v();
}

void call_v2(Foo& foo)
{
     foo.v2();
}

struct FooWrap : public Foo, wrapper<Foo>
{
     void v() {this->get_override("v")();}
     void v2() {
	if (override f = this->get_override("v2"))
	    f();
	else
	    Foo::v2();
     }
     void default_v2()
	{
	    this->Foo::v2();
	}

     FooWrap(int a, int b=42)
	: Foo(a,b)
	{}

};

struct BarWrap : public Bar, wrapper<Bar>
{
     void v()
     {
         if (override f = this->get_override("v"))
             f();
	else
	    Bar::v();
     }

     void v2() {
	if (override f = this->get_override("v2"))
	    f();
	else
	    Foo::v2();
     }
     void default_v2()
	{
	    this->Foo::v2();
	}


     BarWrap(int a, int b=42)
	: Bar(a,b)
	{}
};

Foo::~Foo()
{}

Foo::Foo(int a_, int b_)
     : a(a_),b(b_)
{}

void Foo::showab()
{
     cout << a << " " << b << endl;
}

BOOST_PYTHON_MODULE(foo)
{
     class_<FooWrap, boost::noncopyable>("Foo",init<int,optional<int> >())
	.def("v",pure_virtual(&Foo::v))
	.def("v2",&Foo::v2, &FooWrap::default_v2)
	.def("showab",&Foo::showab);

     class_<BarWrap, bases<Foo>, boost::noncopyable 
 >("Bar",init<int,optional<int> >())
	.def("v",&Bar::v)
	.def("v2",&Foo::v2, &FooWrap::default_v2); // ***

     def("call_v",call_v);
     def("call_v2",call_v2);
}



As you see, the only way to handle this I've found is to "re-wrap" each 
virtual function in any derived class. This is rather cumbersome and 
error-prone; for example, if I forget the line marked ***, the code will 
still compile cleanly, but when call_v2 is called with a Bar-derived 
class Baz defined in Python, it will call Bar's v2 instead of Baz'.

My question therefore: is there an easier way? Ie. not having to 
redeclare and wrap every virtual function?


From dave at boost-consulting.com  Fri Sep 16 12:45:58 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 16 Sep 2005 06:45:58 -0400
Subject: [C++-sig] [Boost.Python] Infinite recursion attempting
	to_python conversion
References: <ED67712627032740B15C91998D43FB4C0166FA30@corp-mail4.solidworks.swk>
Message-ID: <uek7pnvdl.fsf@boost-consulting.com>


This post belongs on the C++-sig; followups directed thence.

"Nat Goodspeed" <ngoodspeed at solidworks.com> writes:

> For some purposes we have a special string class derived from
> std::wstring. Simplified declaration:
>
> class cbstring: public std::wstring
> {
> public:
>     cbstring(const wchar_t* that): std::wstring(that) {}
>     cbstring(const std::wstring& that): std::wstring(that) {}
>     ...
> };
>
> I want to return such objects from C++ as Python Unicode strings, e.g.:
>
> cbstring produceWString()
> {
>     return L"This is a test Unicode string";
> }
>
> If produceWString() returns std::wstring, the conversion happens by
> magic. But with the cbstring return type, I get:
>
> TypeError: No to_python (by-value) converter found for C++ type: class
> cbstring
>
> The corresponding conversion problem (passing u"Foo" from Python to a
> function accepting const cbstring&) can be handled with the following
> call in the extension module:
>
>     implicitly_convertible<std::wstring, cbstring>();
>
> However,
>
>     implicitly_convertible<cbstring, std::wstring>();
>
> does NOT allow the produceWString() function to succeed: I still get the
> aforementioned TypeError.

Right. implicitly_convertible is only used when converting from Python
to C++.  

> So I declared a type converter:
>
> struct cbstring_to_python
> {
>     static PyObject* convert(const cbstring& cbs)
>     {
>         return PyUnicode_FromUnicode(cbs.c_str(), cbs.length());
>     }
> };
>
> and registered it with:
>
>     to_python_converter<cbstring, cbstring_to_python>();

Good.

> The result is a stack overflow. 

Bad.

> I'm not clear on exactly why it happens, but something inside the
> cbstring_to_python converter is apparently recursively invoking
> cbstring_to_python::convert().

It's hard to imagine; as you can see cbstring_to_python::convert just
calls Python's routine to create a new string.  There's no reason for
that function to call back into your code.  I'm guessing you are
blowing the stack somewhere else in your code.

I suggest you try to use a debugger and try to track down the real
cause of the error.  If you can't do that, I suggest you reduce your
example to a *minimal* but complete test case.  If the answer doesn't
jump out at you once you've done that, post it on the C++-sig and
someone (maybe me) can try to take a look at it.

> How *should* I go about returning our specialized string type as a
> Python Unicode string?

Your basic approach looks fine.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From ericjardim at gmail.com  Fri Sep 16 13:16:28 2005
From: ericjardim at gmail.com (Eric Jardim)
Date: Fri, 16 Sep 2005 08:16:28 -0300
Subject: [C++-sig] [Boost.Python] Infinite recursion attempting
	to_python conversion
In-Reply-To: <uek7pnvdl.fsf@boost-consulting.com>
References: <ED67712627032740B15C91998D43FB4C0166FA30@corp-mail4.solidworks.swk>
	<uek7pnvdl.fsf@boost-consulting.com>
Message-ID: <432ec6c505091604167da136ae@mail.gmail.com>

2005/9/16, David Abrahams <dave at boost-consulting.com>:
> 
> "Nat Goodspeed" <ngoodspeed at solidworks.com> writes:
> > I want to return such objects from C++ as Python Unicode strings, e.g.:
> 

We implemented Unicode support in python-qt4. Take a look at:
http://svn.berlios.de/viewcvs/python-qt4/trunk/Core/QString.cpp?view=markup

And we don't use implicitly_comvertible. You can adapt the code to work with 
wide strings.

Rgds,

[Eric Jardim]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050916/e01121d8/attachment.htm>

From Hubert.Holin at meteo.fr  Fri Sep 16 12:34:59 2005
From: Hubert.Holin at meteo.fr (Hubert Holin)
Date: Fri, 16 Sep 2005 12:34:59 +0200
Subject: [C++-sig] Redirecting stdout for B.P extensions?
References: <20050915020649.45025.qmail@web31511.mail.mud.yahoo.com>
	<1126798273.31444.9.camel@localhost.localdomain>
Message-ID: <Hubert.Holin-924C19.12345916092005@sea.gmane.org>

Somewhere in the E.U., le 16/09/2005

   Bonjour

In article <1126798273.31444.9.camel at localhost.localdomain>,
 Jonathan Brandmeyer <jbrandmeyer at earthlink.net> wrote:

> On Wed, 2005-09-14 at 19:06 -0700, Ralf W. Grosse-Kunstleve wrote:
> > --- Jonathan Brandmeyer <jbrandmeyer at earthlink.net> wrote:
> > > You can write a custom streambuf that dumps its data via
> > > PyFile_WriteString() to sys.stderr, and redirect std::cerr to an
> > > instance of your custom streambuf.  This way, redirection of sys.stderr
> > > from within Python will have the intended effect on std::cerr.
> > 
> > Very interesting. I'd like to add some fragments of production code that 
> > show
> > how to use the Python C API to write to sys.stdout (or any other Python 
> > object
> > with write() and flush() methods). See below. The "python_out" class is 
> > wrapped
> > with Boost.Python and instantiated with sys.stdout as the argument.
> > 
> > Question: how can I redirect std::cout and std::cerr to use a custom 
> > streambuf
> > object? Can I simply write std::cout = my_custom_streambuf_instance? That 
> > would
> > be exciting.
> 
> std::streambuf* old = std::cout.rdbuf( &my_custom_streambuf_instance);
> 
> Here is a start that adapts some of your code to suit.  
> 
> After importing sbuf_test, the program will crash on shutdown when cout
> and cerr's destructors try to flush the Python stream that has already
> been finalized.  Perhaps this would be a good point to add a PyFinalize
> hook that restores the streambufs?

[SNIP extremely useful code]

      Thank you (Jonathan Brandmeyer, Ralf W. Grosse-Kunstleve and 
Pierre Barbier de Reuille) for your suggestions and code (which has the 
added benefit of appearing to be perfectly portable). I will try to use 
them as the basis of my code.

      To attain the goal of transparency (to third-party code, even if 
the third party happens to bee one of the first two :-)   ), I am 
thinking to allocate a global custom streambuf in an extension (and 
bring it down explicitly later) to perform the redirection. Must I 
expose that object to Python to insure it will still be alive and active 
when another extension is called?

      Are there any actual guaranties about inter-extension 
non-Python-exposed, C++ object visibility? Or just about the lifetime of 
(C++) objects allocated in extensions (exposed to Python or not)?

   Merci

         Hubert Holin



From Hubert.Holin at meteo.fr  Fri Sep 16 12:08:51 2005
From: Hubert.Holin at meteo.fr (Hubert Holin)
Date: Fri, 16 Sep 2005 12:08:51 +0200
Subject: [C++-sig] Redirecting stdout for B.P extensions?
References: <EE243EAA-7D82-44EA-B7EA-DF7FE5FCF7DC@meteo.fr>
	<862207.post@talk.nabble.com>
Message-ID: <Hubert.Holin-111AD9.12085116092005@sea.gmane.org>

Somewhere in the E.U., le 16/09/2005

   Bonjour

In article <862207.post at talk.nabble.com>,
 "kooto (sent by Nabble.com)" <lists at nabble.com> wrote:

> Hubert Holin wrote: 
> > 
> >              Hubert Holin
> > P.S.: sorry, I found no way to search the archive... pointers to that  
> > welcome as well!
> > 
> 
> Nabble has an archive search but it only started archiving this list a few 
> weeks ago, you can browse and search here c++ list here: 
> http://www.nabble.com/Python---c%2B%2B-sig-f2927.html
> 
> Or you can browse or search all python lists archive here: 
> http://www.nabble.com/Python-f2926.html
> 
> Gmane also has an archive search: http://dir.gmane.org/gmane.comp.python.c++ 
> - for the c++ list it has much more historical data.

[SNIP]

      Bookmarked, thanks!

   Merci

         Hubert Holin



From Hubert.Holin at meteo.fr  Fri Sep 16 12:39:26 2005
From: Hubert.Holin at meteo.fr (Hubert Holin)
Date: Fri, 16 Sep 2005 12:39:26 +0200
Subject: [C++-sig] Redirecting stdout for B.P extensions?
References: <EE243EAA-7D82-44EA-B7EA-DF7FE5FCF7DC@meteo.fr>
	<43285CAE.6020202@cirad.fr>
	<200509151615.23761.meine@kogs.informatik.uni-hamburg.de>
Message-ID: <Hubert.Holin-79F9CD.12392616092005@sea.gmane.org>

Somewhere in the E.U., le 16/09/2005

   Bonjour

      Thank you. I will have to study the code to understand how it 
actually works (I am not too conversant with pipes).

In article <200509151615.23761.meine at kogs.informatik.uni-hamburg.de>,
 Hans Meine <meine at kogs1.informatik.uni-hamburg.de> wrote:

> Hi everybody!
> 
> On Wednesday 14 September 2005 19:23, Pierre Barbier de Reuille wrote:
> > Basically, sys.stdout is NOT the standard output of your program, it's
> > merely the Python wrapper used as stdout. So if you replace sys.stdout,
> > only Python-aware code explicitly using sys.stdout will see its output
> > redirected.
> >
> > If you want to redirect the *real* stdout, you have to use the good old
> > C way ;) Basically, replace the file descriptor 1 (stdout) with any file
> > descriptor you have created (usually a pipe). But this becomes a system
> > question without relation to Python !
> 
> AFAIK this is the whole truth, and you should do exactly that "good old C 
> way", which involves os.dup and os.dup2.  Attached you'll find ready-to-use 
> code (courtesy of Robert Kern from IPython-dev).
> 
> -- 
> Ciao, /  /
>      /--/
>     /  / ANS

[SNIP code]

   Merci

         Hubert Holin



From meine at kogs1.informatik.uni-hamburg.de  Fri Sep 16 15:13:16 2005
From: meine at kogs1.informatik.uni-hamburg.de (Hans Meine)
Date: Fri, 16 Sep 2005 15:13:16 +0200
Subject: [C++-sig] Redirecting stdout for B.P extensions?
In-Reply-To: <Hubert.Holin-79F9CD.12392616092005@sea.gmane.org>
References: <EE243EAA-7D82-44EA-B7EA-DF7FE5FCF7DC@meteo.fr>
	<200509151615.23761.meine@kogs.informatik.uni-hamburg.de>
	<Hubert.Holin-79F9CD.12392616092005@sea.gmane.org>
Message-ID: <200509161513.16214.meine@kogs.informatik.uni-hamburg.de>

On Friday 16 September 2005 12:39, Hubert Holin wrote:
>       Thank you. I will have to study the code to understand how it
> actually works (I am not too conversant with pipes).

Actually, the pipe part is not the most interesting one.  Even worse - the 
pipe will be buffered to some kilobytes only by the OS, and it will block 
afterwards if you don't read from it.  The important part is the redirection 
of the filedescriptors 1 and/or 2, which redirects *both* sys.stdout and 
sys.stderr.

Furthermore, Robert Kern just told me:
> [...] a maintained (not by me) version is in py.io . Apparently, it got
> checked in there a few days before I discovered the solution myself. If
> only I had updated my svn checkout a few days earlier, I could have
> saved myself some trouble. ?:-)
>
> http://codespeak.net/py/current/doc/

-- 
Ciao, /  /
     /--/
    /  / ANS


From dave at boost-consulting.com  Fri Sep 16 21:27:09 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 16 Sep 2005 15:27:09 -0400
Subject: [C++-sig] MSVC++  boost python question
References: <dfnlnd$1im$1@sea.gmane.org>
	<BAY101-F260AA85D094F4FEEE3FD62AE990@phx.gbl>
Message-ID: <uacicg6eq.fsf@boost-consulting.com>

"Vin Jovanovic" <fractal97 at hotmail.com> writes:

> I built boost python with bjam (with all kind of options static dynamic 
> single etc) and I am trying to use the libboost_python*.lib in my vc-7_1 
> project to produce getting_started1.dll which I can load into Python so that 
> I would not need boost_python.dll.  But no combination of libraries works.  
> I am getting linking errors bellow ...  Is there a way around this?
>
> Linking...
> LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' 
> specification
> msvcprt.lib(MSVCP71.dll) : error LNK2005: "public: __thiscall 
> std::basic_string<char,struct std::char_traits<char>,class 
> std::allocator<char> >::~basic_string<char,struct 
> std::char_traits<char>,class std::allocator<char> >(void)" 

These symbols are in your C++ runtime library, i.e. part of the
compiler.  Perhaps your project's build options are incompatible with
those used to build libboost_python.lib?

Try using bjam -o log.txt to "build" libboost_python.lib and look at
log.txt to see which compile options were used.  Then make your
project use the same ones.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From phan at grover.jpl.nasa.gov  Sun Sep 18 03:09:33 2005
From: phan at grover.jpl.nasa.gov (Linh.H.Phan@jpl.nasa.gov)
Date: Sat, 17 Sep 2005 18:09:33 -0700 (PDT)
Subject: [C++-sig] Returning std::vector<int*> to python
Message-ID: <200509180109.j8I19XL22821@simcat.jpl.nasa.gov>

Hi,

  I'm having a problem returning a std::vector<int*> to python:

#include <vector>
typedef std::vector<int*> intVec;
class Node
{
public:
  Node() {}
  intVec& getIntVec() {
    return intvec;
  }
  int computeSum(const intVec& intvec) {return 1;}
  intVec intvec;
};

#include <boost/python/module.hpp>
#include <boost/python/def.hpp>
#include <boost/python.hpp>
using namespace boost::python;

BOOST_PYTHON_MODULE(hello)
{
    class_<Node>("Node", init<>())
      .add_property("intvec"
        , make_getter(&Node::intvec, return_internal_reference<>()))
      .def("getIntVec", (intVec&(Node::*)())&Node::getIntVec,
	   return_internal_reference<>())
      .def("computeSum", &Node::computeSum)
    ;
}

>>> import hello
>>> test = hello.Node()
>>> test.computeSum(test.intvec)
TypeError: No Python class registered for C++ class std::vector<int*, std::allocator<int*> >
>>> test.computeSum(test.getIntVec())
TypeError: No Python class registered for C++ class std::vector<int*, std::allocator<int*> >
>>> 

Can someone please help?

Thank you very much!

Linh


From pierre.barbier at cirad.fr  Mon Sep 19 10:47:08 2005
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Mon, 19 Sep 2005 10:47:08 +0200
Subject: [C++-sig] Returning std::vector<int*> to python
In-Reply-To: <200509180109.j8I19XL22821@simcat.jpl.nasa.gov>
References: <200509180109.j8I19XL22821@simcat.jpl.nasa.gov>
Message-ID: <432E7B0C.1040800@cirad.fr>

Hi,

If you want to return a value, you need to export it (or be sure it is
exported by Boost.Python), so here you need to define your Python class
for intVec.

Then, you have to know that reference or pointer on Integer cannot
exists "as is" in Python. You'll have to wrap them ... that may be a
problem to export your intVec class.

Pierre


Linh.H.Phan at jpl.nasa.gov a ?crit :
> Hi,
> 
>   I'm having a problem returning a std::vector<int*> to python:
> 
> #include <vector>
> typedef std::vector<int*> intVec;
> class Node
> {
> public:
>   Node() {}
>   intVec& getIntVec() {
>     return intvec;
>   }
>   int computeSum(const intVec& intvec) {return 1;}
>   intVec intvec;
> };
> 
> #include <boost/python/module.hpp>
> #include <boost/python/def.hpp>
> #include <boost/python.hpp>
> using namespace boost::python;
> 
> BOOST_PYTHON_MODULE(hello)
> {
>     class_<Node>("Node", init<>())
>       .add_property("intvec"
>         , make_getter(&Node::intvec, return_internal_reference<>()))
>       .def("getIntVec", (intVec&(Node::*)())&Node::getIntVec,
> 	   return_internal_reference<>())
>       .def("computeSum", &Node::computeSum)
>     ;
> }
> 
> 
>>>>import hello
>>>>test = hello.Node()
>>>>test.computeSum(test.intvec)
> 
> TypeError: No Python class registered for C++ class std::vector<int*, std::allocator<int*> >
> 
>>>>test.computeSum(test.getIntVec())
> 
> TypeError: No Python class registered for C++ class std::vector<int*, std::allocator<int*> >
> 
> 
> Can someone please help?
> 
> Thank you very much!
> 
> Linh
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 

-- 
Pierre Barbier de Reuille

INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France

tel   : (33) 4 67 61 65 77    fax   : (33) 4 67 61 56 68


From allenb at vrsource.org  Mon Sep 19 21:56:28 2005
From: allenb at vrsource.org (Allen Bierbaum)
Date: Mon, 19 Sep 2005 14:56:28 -0500
Subject: [C++-sig] Patches for pyste
Message-ID: <432F17EC.8000401@vrsource.org>

I have a patch that makes a couple of small changes to pyste.

1. Fix bug (??) where using pyste with gcc 4.0 and gccxml throws an 
exception for trying to convert NoneType to string in declarations.py.  
It looks like there are some cases where self.name can be none and in 
these cases the code fails.  I modified the code to explicitly call 
str(self.name) when the name string is needed.  It works fine for me.

2. Added feature of declaring an entire class final.

I found myself often wanting to eliminate all polymorphic behavior for a 
class and the only way that is currently supported is to explicitly call 
final() on all virtual methods.  This change allows you to call final() 
on a class as a whole.

-Allen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pyste.patch
Type: text/x-patch
Size: 2027 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050919/c1704f59/attachment.bin>

From nicodemus at esss.com.br  Mon Sep 19 23:19:13 2005
From: nicodemus at esss.com.br (Nicodemus)
Date: Mon, 19 Sep 2005 19:19:13 -0200
Subject: [C++-sig] Patches for pyste
In-Reply-To: <432F17EC.8000401@vrsource.org>
References: <432F17EC.8000401@vrsource.org>
Message-ID: <432F2B51.1050908@esss.com.br>

Hi Allen.

Allen Bierbaum wrote:

> I have a patch that makes a couple of small changes to pyste.
>
> 1. Fix bug (??) where using pyste with gcc 4.0 and gccxml throws an 
> exception for trying to convert NoneType to string in 
> declarations.py.  It looks like there are some cases where self.name 
> can be none and in these cases the code fails.  I modified the code to 
> explicitly call str(self.name) when the name string is needed.  It 
> works fine for me.
>
> 2. Added feature of declaring an entire class final.

Patch applied. Thanks Allen!

Regards,
Bruno.


From phan at grover.jpl.nasa.gov  Tue Sep 20 20:55:54 2005
From: phan at grover.jpl.nasa.gov (Linh.H.Phan@jpl.nasa.gov)
Date: Tue, 20 Sep 2005 11:55:54 -0700
Subject: [C++-sig]  Returning std::vector<int*> to python
In-Reply-To: <200509180109.j8I19XL22821@simcat.jpl.nasa.gov>
References: <200509180109.j8I19XL22821@simcat.jpl.nasa.gov>
Message-ID: <17200.23354.860792.341863@simcat.jpl.nasa.gov>

Hi Pierre,

Is there a simple tutorial somewhere that shows this process?

Thank you,

Linh
>Hi,
>
>If you want to return a value, you need to export it (or be sure it is
>exported by Boost.Python), so here you need to define your Python class
>for intVec.
>
>Then, you have to know that reference or pointer on Integer cannot
>exists "as is" in Python. You'll have to wrap them ... that may be a
>problem to export your intVec class.
>
>Pierre
>
>
> Linh.H.Phan at jpl.nasa.gov a e'crit :
> > Hi,
> > 
> >   I'm having a problem returning a std::vector<int*> to python:
> > 
> > #include <vector>
> > typedef std::vector<int*> intVec;
> > class Node
> > {
> > public:
> >   Node() {}
> >   intVec& getIntVec() {
> >     return intvec;
> >   }
> >   int computeSum(const intVec& intvec) {return 1;}
> >   intVec intvec;
> > };
> > 
> > #include <boost/python/module.hpp>
> > #include <boost/python/def.hpp>
> > #include <boost/python.hpp>
> > using namespace boost::python;
> > 
> > BOOST_PYTHON_MODULE(hello)
> > {
> >     class_<Node>("Node", init<>())
> >       .add_property("intvec"
> >         , make_getter(&Node::intvec, return_internal_reference<>()))
> >       .def("getIntVec", (intVec&(Node::*)())&Node::getIntVec,
> > 	   return_internal_reference<>())
> >       .def("computeSum", &Node::computeSum)
> >     ;
> > }
> > 
>>> 
>>>>>>import hello
>>>>>>test = hello.Node()
> >>>>test.computeSum(test.intvec)
> > 
> > TypeError: No Python class registered for C++ class std::vector<int*, std::allocator<int*> >
>>> 
> >>>>test.computeSum(test.getIntVec())
> > 
> > TypeError: No Python class registered for C++ class std::vector<int*, std::allocator<int*> >
> > 
> > 
> > Can someone please help?
> > 
> > Thank you very much!
> > 
> > Linh
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig at python.org
> > http://mail.python.org/mailman/listinfo/c++-sig
> 

-- 
Pierre Barbier de Reuille

INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France

tel   : (33) 4 67 61 65 77    fax   : (33) 4 67 61 56 68


From pierre.barbier at cirad.fr  Wed Sep 21 10:15:08 2005
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Wed, 21 Sep 2005 10:15:08 +0200
Subject: [C++-sig] Returning std::vector<int*> to python
In-Reply-To: <17200.23354.860792.341863@simcat.jpl.nasa.gov>
References: <200509180109.j8I19XL22821@simcat.jpl.nasa.gov>
	<17200.23354.860792.341863@simcat.jpl.nasa.gov>
Message-ID: <4331168C.6090103@cirad.fr>

You should have a look there :
 http://www.boost.org/libs/python/doc/v2/indexing.html

Otherwise, just export the instance of the class template as any other
class.

Pierre

Linh.H.Phan at jpl.nasa.gov a ?crit :
> Hi Pierre,
> 
> Is there a simple tutorial somewhere that shows this process?
> 
> Thank you,
> 
> Linh
> 
>>Hi,
>>
>>If you want to return a value, you need to export it (or be sure it is
>>exported by Boost.Python), so here you need to define your Python class
>>for intVec.
>>
>>Then, you have to know that reference or pointer on Integer cannot
>>exists "as is" in Python. You'll have to wrap them ... that may be a
>>problem to export your intVec class.
>>
>>Pierre
>>
>>
>>Linh.H.Phan at jpl.nasa.gov a e'crit :
>>
>>>Hi,
>>>
>>>  I'm having a problem returning a std::vector<int*> to python:
>>>
>>>#include <vector>
>>>typedef std::vector<int*> intVec;
>>>class Node
>>>{
>>>public:
>>>  Node() {}
>>>  intVec& getIntVec() {
>>>    return intvec;
>>>  }
>>>  int computeSum(const intVec& intvec) {return 1;}
>>>  intVec intvec;
>>>};
>>>
>>>#include <boost/python/module.hpp>
>>>#include <boost/python/def.hpp>
>>>#include <boost/python.hpp>
>>>using namespace boost::python;
>>>
>>>BOOST_PYTHON_MODULE(hello)
>>>{
>>>    class_<Node>("Node", init<>())
>>>      .add_property("intvec"
>>>        , make_getter(&Node::intvec, return_internal_reference<>()))
>>>      .def("getIntVec", (intVec&(Node::*)())&Node::getIntVec,
>>>	   return_internal_reference<>())
>>>      .def("computeSum", &Node::computeSum)
>>>    ;
>>>}
>>>
>>>
>>>>>>>import hello
>>>>>>>test = hello.Node()
>>>>>>
>>>>>>test.computeSum(test.intvec)
>>>
>>>TypeError: No Python class registered for C++ class std::vector<int*, std::allocator<int*> >
>>>
>>>>>>test.computeSum(test.getIntVec())
>>>
>>>TypeError: No Python class registered for C++ class std::vector<int*, std::allocator<int*> >
>>>
>>>
>>>Can someone please help?
>>>
>>>Thank you very much!
>>>
>>>Linh
>>>_______________________________________________
>>>C++-sig mailing list
>>>C++-sig at python.org
>>>http://mail.python.org/mailman/listinfo/c++-sig
>>
> 

-- 
Pierre Barbier de Reuille

INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France

tel   : (33) 4 67 61 65 77    fax   : (33) 4 67 61 56 68


From price at ELLINGTON.com  Thu Sep 22 00:20:33 2005
From: price at ELLINGTON.com (Gregory Price)
Date: Wed, 21 Sep 2005 18:20:33 -0400
Subject: [C++-sig] how to handle bare references with a shared_ptr HeldType
Message-ID: <FDC9B82C8E33C346B223298B17C2D34E0E103D@emgmail1.ellington.com>

I'm wrapping a library where many things are held
through a custom reference-counted-pointer class
rather like shared_ptr.  For discussion I'll pretend
they're shared_ptr's.

In this library are classes like this:

"""
class A {
    // ... lots of stuff ...
};

class B {
    shared_ptr<A> a;
public:
    A& getA() { return *a; };
};
"""

I'm exposing A with a HeldType of shared_ptr<A>.

Now here's the problem that worries me.
If Boost.Python creates a new shared_ptr from
the returned A&, then it'll have its own 
separate reference counts.
Then when either count gets to zero, the A instance
will die even though references still exist.

I could use copy_non_const_reference to make a
new copy of the A instance.  That'd be safe,
but A instances are big and I'd rather not copy them.


Can anyone suggest a better way to wrap this function?


Thanks for your help.

Greg

=============================================================================================
Email transmissions can not be guaranteed to be secure or error-free, as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain 
viruses.  The sender therefore does not accept liability for any errors or omissions in 
the contents of this message which arise as a result of email transmission.  In addition,
the information contained in this email message is intended only for use of the 
individual or entity named above.  If the reader of this message is not the intended
recipient, or the employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying of this communication,
disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it,
is strictly prohibited, and may be unlawful.  If you are not the intended recipient please
delete this email message. 
==============================================================================================



From hans_meine at gmx.net  Thu Sep 22 00:34:47 2005
From: hans_meine at gmx.net (Hans Meine)
Date: Thu, 22 Sep 2005 00:34:47 +0200
Subject: [C++-sig] how to handle bare references with a shared_ptr
	HeldType
In-Reply-To: <FDC9B82C8E33C346B223298B17C2D34E0E103D@emgmail1.ellington.com>
References: <FDC9B82C8E33C346B223298B17C2D34E0E103D@emgmail1.ellington.com>
Message-ID: <200509220034.47953.hans_meine@gmx.net>

On Thursday 22 September 2005 00:20, Gregory Price wrote:
> class A {
>     // ... lots of stuff ...
> };
>
> class B {
>     shared_ptr<A> a;
> public:
>     A& getA() { return *a; };
> };
> """
>
> I'm exposing A with a HeldType of shared_ptr<A>.
>
> [...]
> I could use copy_non_const_reference to make a
> new copy of the A instance.  That'd be safe,
> but A instances are big and I'd rather not copy them.

Hmm.  What about return_internal_reference (which I am using a lot)?
AFAICS, the C++ A object will not be deleted as long as B is not deleted,  
because of the shared ptr.  OTOH, during the lifetime of the A python 
wrapper, B will not get deleted because of the custodian-ward relationship 
initialized via return_internal_reference.  Does that make sense?

-- 
Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo


From price at ELLINGTON.com  Thu Sep 22 16:37:52 2005
From: price at ELLINGTON.com (Gregory Price)
Date: Thu, 22 Sep 2005 10:37:52 -0400
Subject: [C++-sig] how to handle bare references with a shared_ptr
	HeldType
Message-ID: <FDC9B82C8E33C346B223298B17C2D34E0E103E@emgmail1.ellington.com>

Hans Meine wrote:
> Hmm.  What about return_internal_reference (which I am using a lot)?
> AFAICS, the C++ A object will not be deleted as long as B is not
deleted,  
> because of the shared ptr.  OTOH, during the lifetime of the A python 
> wrapper, B will not get deleted because of the custodian-ward
relationship 
> initialized via return_internal_reference.  Does that make sense?

I agree with the second half of that -- return_internal_reference
will keep the B instance alive as long as the wrapped A instance exists.

But now say the wrapped A instance dies; the HeldType=shared_ptr<A>
instance
will think it's the only shared_ptr for that A instance, and will delete
it.
Now the shared_ptr<A> inside the B instance is dangling.

I've lost as soon as I let Boost.Python create a new shared_ptr<A>
from the bare A& -- the only way to avoid a dangling pointer then
is to ensure that the A instance never dies at all.

Is there a way to tell Boost.Python not to make a shared_ptr
for this return value -- to override the HeldType just for this
function's return value?  Alternatively, to tell Boost.Python
always to leave bare A references as they are?

Or perhaps there's a simpler solution that I'm missing.

Thanks,
Greg

=============================================================================================
Email transmissions can not be guaranteed to be secure or error-free, as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain 
viruses.  The sender therefore does not accept liability for any errors or omissions in 
the contents of this message which arise as a result of email transmission.  In addition,
the information contained in this email message is intended only for use of the 
individual or entity named above.  If the reader of this message is not the intended
recipient, or the employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying of this communication,
disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it,
is strictly prohibited, and may be unlawful.  If you are not the intended recipient please
delete this email message. 
==============================================================================================



From meine at kogs1.informatik.uni-hamburg.de  Thu Sep 22 19:32:32 2005
From: meine at kogs1.informatik.uni-hamburg.de (Hans Meine)
Date: Thu, 22 Sep 2005 19:32:32 +0200
Subject: [C++-sig] how to handle bare references with a shared_ptr
	HeldType
In-Reply-To: <FDC9B82C8E33C346B223298B17C2D34E0E103E@emgmail1.ellington.com>
References: <FDC9B82C8E33C346B223298B17C2D34E0E103E@emgmail1.ellington.com>
Message-ID: <200509221932.33058.meine@kogs.informatik.uni-hamburg.de>

On Thursday 22 September 2005 16:37, Gregory Price wrote:
> Is there a way to tell Boost.Python not to make a shared_ptr
> for this return value -- to override the HeldType just for this
> function's return value?  Alternatively, to tell Boost.Python
> always to leave bare A references as they are?
>
> Or perhaps there's a simpler solution that I'm missing.

Ah.  I knew I was overlooking something.
Is changing the HeldType an option for you?

OTOH, if you use return_internal_reference, BP should know that creating a 
shared_ptr with a refcount of 1 is evil..  is that really what it does?

-- 
Ciao, /  /
     /--/
    /  / ANS


From skottmckay at gmail.com  Fri Sep 23 01:52:52 2005
From: skottmckay at gmail.com (Scott McKay)
Date: Thu, 22 Sep 2005 17:52:52 -0600
Subject: [C++-sig] preventing a copy of the vector when using the
	vector_indexing_suite
In-Reply-To: <51d01787050819144518e8b1ce@mail.gmail.com>
References: <51d01787050809193534085538@mail.gmail.com>
	<ull39snr7.fsf@boost-consulting.com>
	<51d01787050810180311b1d0ad@mail.gmail.com>
	<ufytbnu69.fsf@boost-consulting.com>
	<51d01787050819144518e8b1ce@mail.gmail.com>
Message-ID: <51d01787050922165227896e80@mail.gmail.com>

FWIW Finally had a chance to get back to this and found a way to make it
work.

If I remove the implicit conversion from smart_ptr<Factory> to
smart_ptr<Factory_wrapper> in the base class export all is good.

Not sure why that leads to the loop and seg fault if you derive from
BasicFactory in python though.


On 8/19/05, Scott McKay <skottmckay at gmail.com> wrote:
>
>
> That has led me to a question on what is required in terms of implicit
> conversion calls to handle classes in the same hierarchy that are
> wrapped with wrapper<> and held by smart pointers. I can't seem to
> find a combination to allow derivation from both Factory and
> BasicFactory.
>
> void Export_Factory()
> {
> class_< Factory_Wrapper, smart_ptr< Factory_Wrapper > >("Factory",
> init< >())
> .def("generate", &Factory::generate,
> &Factory_Wrapper::default_generate, return_self<>())
> .def(init< const Factory& >())
> ;
>
> implicitly_convertible< smart_ptr< Factory_Wrapper >, smart_ptr<
> Factory > >();
> implicitly_convertible< smart_ptr< Factory >, smart_ptr<
> Factory_Wrapper > >();
> }
>
>
>
> void Export_BasicFactory()
> {
> class_< BasicFactory_Wrapper, bases< Factory > , smart_ptr<
> BasicFactory_Wrapper > >("BasicFactory", init< >())
> .def("generate", (Factory& (BasicFactory::*)(SourceGroup&)
> )&BasicFactory::generate, (Factory&
>
> (BasicFactory_Wrapper::*)(SourceGroup&))&BasicFactory_Wrapper::default_generate,
> return_self<>())
> .def(init< const BasicFactory& >())
> ;
>
> implicitly_convertible< smart_ptr< BasicFactory_Wrapper >,
> smart_ptr< Factory > >();
> implicitly_convertible< smart_ptr< Factory >, smart_ptr<
> BasicFactory_Wrapper > >();
> }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050922/7259874b/attachment.htm>

From dave at boost-consulting.com  Sat Sep 24 00:38:02 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 23 Sep 2005 18:38:02 -0400
Subject: [C++-sig] how to handle bare references with a shared_ptr
	HeldType
References: <FDC9B82C8E33C346B223298B17C2D34E0E103E@emgmail1.ellington.com>
	<200509221932.33058.meine@kogs.informatik.uni-hamburg.de>
Message-ID: <uhdcbl8ad.fsf@boost-consulting.com>

Hans Meine <meine at kogs1.informatik.uni-hamburg.de> writes:

> On Thursday 22 September 2005 16:37, Gregory Price wrote:
>> Is there a way to tell Boost.Python not to make a shared_ptr
>> for this return value -- to override the HeldType just for this
>> function's return value?  Alternatively, to tell Boost.Python
>> always to leave bare A references as they are?
>>
>> Or perhaps there's a simpler solution that I'm missing.
>
> Ah.  I knew I was overlooking something.
> Is changing the HeldType an option for you?
>
> OTOH, if you use return_internal_reference, BP should know that creating a 
> shared_ptr with a refcount of 1 is evil..  is that really what it does?

No, that's not what it does.  When you use return_internal_reference
it creates a Python object holding the C++ object with a raw pointer.
Isn't that in the documentation?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From hans_meine at gmx.net  Sat Sep 24 13:29:15 2005
From: hans_meine at gmx.net (Hans Meine)
Date: Sat, 24 Sep 2005 13:29:15 +0200
Subject: [C++-sig] how to handle bare references with a shared_ptr
	HeldType
In-Reply-To: <uhdcbl8ad.fsf@boost-consulting.com>
References: <FDC9B82C8E33C346B223298B17C2D34E0E103E@emgmail1.ellington.com>
	<200509221932.33058.meine@kogs.informatik.uni-hamburg.de>
	<uhdcbl8ad.fsf@boost-consulting.com>
Message-ID: <200509241329.15613.hans_meine@gmx.net>

On Saturday 24 September 2005 00:38, David Abrahams wrote:
> Hans Meine <meine at kogs1.informatik.uni-hamburg.de> writes:
> > OTOH, if you use return_internal_reference, BP should know that creating
> > a shared_ptr with a refcount of 1 is evil..  is that really what it does?
>
> No, that's not what it does.  When you use return_internal_reference
> it creates a Python object holding the C++ object with a raw pointer.
> Isn't that in the documentation?

That's how I understood it in the past, but I am not experienced with 
customized HeldTypes, and Gregory seemed to be concerned that it does so:

> > On Thursday 22 September 2005 16:37, Gregory Price wrote:
> >> Is there a way to tell Boost.Python not to make a shared_ptr
> >> for this return value -- to override the HeldType just for this
> >> function's return value?

So the answer really is: Use return_internal_reference.

Concerning the documentation question:  The class_ documentation reads 
"Heldtype [...] Specifies the type which is actually embedded in a Python 
object wrapping a T instance. More details below."
So I would've assumed that every T wrapper actually contains a smart_ptr if 
that's the HeldType.  One could then make more clear that it's not always the 
case.

The return_internal_reference docs say "Note that if the target Python object 
type doesn't support weak references, a Python TypeError exception will be 
raised when the function being wrapped is called."  The longer I think about 
that sentence, it could actually indicate the use of weakrefs. ;-)

Finally, I propose the attached (not-too-related) patch to the documentation, 
which basically reorders some HeldType explanations to make their overall 
relation more clear.

Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bpclass.diff
Type: text/x-diff
Size: 2714 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050924/2087586e/attachment.diff>

From roman.yakovenko at gmail.com  Sun Sep 25 07:27:26 2005
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Sun, 25 Sep 2005 08:27:26 +0300
Subject: [C++-sig] How to export non virtual protected functions?
Message-ID: <7465b61705092422276a6486eb@mail.gmail.com>

Good morning. I have a question regardless exposing protected functions.


1. What is the right way to export do_it function ?

struct S1{
    protected:
        void do_it(){}
};

User should be able to derive in Python from S1 and to use do_it function.

This is the code that pyplusplus generates right now. Pyste doesn't
treat this use case too.
( So can't use it for solution ).

namespace bp = boost::python;

BOOST_PYTHON_MODULE(pyplusplus){
    bp::class_< S1 >( "S1" );
    bp::class_< S2, bp::bases< S1 > >( "S2" );
}

There are a few possible solutions, also all of them includes creating
wrapper class.
I created this wrapper for S1.

namespace bp = boost::python;
struct S1_wrapper : S1, bp::wrapper< S1 > {

    void do_it( ){
        if( bp::override do_it = this->get_override( "do_it" ) )
            do_it( );
        else
            S1::do_it( );
    }

    void default_do_it( ){
        S1::do_it( );
    }
};

solution 1:
    1. S1_wrapper::do_it should be deleted
    2.  bp::class_< S1 >( "S1" );
         becomes
         bp::class_< S1_wrapper >( "S1" )
             .def( "do_it", &S1_wrapper::default_do_it );
solution 2:
    To treat do_it as virtual function.
solution 3:
    Your solution comes here.

Thanks for the help.

Roman Yakovenko


From ezrihen at gmail.com  Mon Sep 26 17:36:03 2005
From: ezrihen at gmail.com (Eli Zrihen)
Date: Mon, 26 Sep 2005 18:36:03 +0300
Subject: [C++-sig] exporting c++ function arguments
Message-ID: <9c01b59605092608367264f2b7@mail.gmail.com>

Hi,

I'm a boost.python newbie.
I'm trying to export some c++ function types, but I'm not sure how to do it.
my function prototype is as follows:
int func(unsigned int x, unsigned int *y, unsigned char *)

I can't just export the function since I get an error that tells me that the
parameters expected in boost.python and what I give from python doesn't
match. So I'm trying to add a wrapping function to do the conversion but I
didn't succeed so far.

I would really appreciate some help here.

Thanks,
Eli.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20050926/961f3c8c/attachment.htm>

From Dennis.Brakhane at urz.uni-heidelberg.de  Mon Sep 26 18:51:01 2005
From: Dennis.Brakhane at urz.uni-heidelberg.de (Dennis Brakhane)
Date: Mon, 26 Sep 2005 18:51:01 +0200
Subject: [C++-sig] How to wrap method taking ownership of a raw pointer to
 an _abstract_ Class
Message-ID: <433826F5.1020507@ix.urz.uni-heidelberg.de>

Hello list.

I have a method with the following signature:
void Bar::set(Foo* foo)

The method takes ownership of Foo*; however, unlike the example in the 
FAQ, Foo is an abstract Base class. Now, if I try to wrap it similary to 
the FAQ example:

-------8<--------------8<------------

#include <iostream>
using namespace std;

struct Foo
{
     Foo() {cerr << "created" << endl;}
     virtual ~Foo() {cerr << "destroyed" << endl;}
     virtual void Baz() = 0;
};

struct Bar
{
     void s(Foo* f)
	{
	    fp = f;
	}

     ~Bar()
	{
	    delete fp;
	}
private:
     Foo* fp;

};


#include <boost/python.hpp>

using namespace boost::python;

struct FooWrap : Foo, wrapper<Foo>
{
     void Baz()
	{
	    this->get_override("Baz")();
	}

};

void Bar_s(Bar& b, std::auto_ptr<Foo> f)
{
     b.s(f.get());
     f.release();
}

BOOST_PYTHON_MODULE(mod)
{
     class_<FooWrap,std::auto_ptr<FooWrap>,boost::noncopyable>("Foo")
	.def("FICKEN", pure_virtual(&Foo::Baz))
	;
     class_<Bar>("Bar")
	.def("s", &Bar_s)
	;
}

-------8<--------------8<------------

It does not work in python:
 >>> import mod
 >>> class Baz(mod.Foo): pass
 >>> a = Baz()
 >>> b = Bar()
 >>> b.s(a)
Python argument types in
     Bar.s(Bar, Baz)
did not match C++ signature:
     s(Bar {lvalue}, std::auto_ptr<Foo>)



If I change std::auto_ptr<FooWrap> to std::auto_ptr<Foo>, I cannot compile:
/usr/include/boost/python/object/pointer_holder.hpp:128: error: invalid 
conversion from 'Foo*' to 'FooWrap*'

Any suggestions?

Thanks in advance,
   Dennis


From Dennis.Brakhane at urz.uni-heidelberg.de  Mon Sep 26 19:09:10 2005
From: Dennis.Brakhane at urz.uni-heidelberg.de (Dennis Brakhane)
Date: Mon, 26 Sep 2005 19:09:10 +0200
Subject: [C++-sig] Ooops :-o
In-Reply-To: <433826F5.1020507@ix.urz.uni-heidelberg.de>
References: <433826F5.1020507@ix.urz.uni-heidelberg.de>
Message-ID: <43382B36.8020609@ix.urz.uni-heidelberg.de>

Oops. Of course the program was:

#include <iostream>
using namespace std;

struct Foo
{
     Foo() {cerr << "created" << endl;}
     virtual ~Foo() {cerr << "destroyed" << endl;}
     virtual void Baz() = 0;
};

struct Bar
{
     void s(Foo* f)
	{
	    fp = f;
	}

     ~Bar()
	{
	    delete fp;
	}
private:
     Foo* fp;

};


#include <boost/python.hpp>

using namespace boost::python;

struct FooWrap : Foo, wrapper<Foo>
{
     void Baz()
	{
	    this->get_override("Baz")();
	}

};

void Bar_s(Bar& b, std::auto_ptr<Foo> f)
{
     b.s(f.get());
     f.release();
}

BOOST_PYTHON_MODULE(mod)
{
     class_<FooWrap,std::auto_ptr<FooWrap>,boost::noncopyable>("Foo")
	.def("Baz", pure_virtual(&Foo::Baz))
	;
     class_<Bar>("Bar")
	.def("s", &Bar_s)
	;
}

(I was kinda irritated when I wrote the previous version, sorry for the 
german speaking part of this list if I offended anyone)


From Dennis.Brakhane at urz.uni-heidelberg.de  Mon Sep 26 19:41:12 2005
From: Dennis.Brakhane at urz.uni-heidelberg.de (Dennis Brakhane)
Date: Mon, 26 Sep 2005 19:41:12 +0200
Subject: [C++-sig] Ooops :-o
In-Reply-To: <43382B36.8020609@ix.urz.uni-heidelberg.de>
References: <433826F5.1020507@ix.urz.uni-heidelberg.de>
	<43382B36.8020609@ix.urz.uni-heidelberg.de>
Message-ID: <433832B8.30700@ix.urz.uni-heidelberg.de>

I think I've got it:

implicitly_convertible<std::auto_ptr<FooWrap>,std::auto_ptr<Foo> >();

does the trick; however, I have to write this for every class that 
inherits from Foo(*), so I wonder wheter this is the correct way to do.



(*) class Baz : Foo {...};
class_<Baz, bases<Foo>, std::auto_ptr<Baz> >("Baz")...;
implicitly_convertible<std::auto_ptr<Baz>, std::auto_ptr<Foo> >();



From price at ELLINGTON.com  Mon Sep 26 19:52:40 2005
From: price at ELLINGTON.com (Gregory Price)
Date: Mon, 26 Sep 2005 13:52:40 -0400
Subject: [C++-sig] how to handle bare references with a
	shared_ptrHeldType
Message-ID: <FDC9B82C8E33C346B223298B17C2D34E0E1043@emgmail1.ellington.com>


David Abrahams wrote:
> > OTOH, if you use return_internal_reference, BP should know that 
> > creating a
> > shared_ptr with a refcount of 1 is evil..  is that really 
> what it does?
> 
> No, that's not what it does.  When you use 
> return_internal_reference it creates a Python object holding 
> the C++ object with a raw pointer. Isn't that in the documentation?

That's good news.

But I'm puzzled how that can be.
Perhaps it'd be clearer if you explain how
the following code can work:

----- begin test.cpp -----
#include <boost/shared_ptr.hpp>
#include <boost/python.hpp>

using namespace boost::python;

struct A {
  int x;
};

int
get_x(boost::shared_ptr<A> a)
{
  return a->x;
}

A&
make_A(int x)
{
  static A a;
  a.x = x;
  return a;
}

BOOST_PYTHON_MODULE(test)
{
  class_<A, boost::shared_ptr<A> >("A");
  def("get_x", &get_x);
  def("make_A", &make_A, return_internal_reference<>());
}
----- end test.cpp -----

  $ python
  >>> from test import make_A, get_x
  >>> a = make_A(3)
  >>> get_x(a)
  3

Here I use return_internal_reference on make_A;
so I should get a Python object "a" holding the C++ A
as a raw pointer.  But there's no trouble passing "a"
to get_x, which wants a shared_ptr<A>.
What is Boost.Python doing that makes this work?


Thanks for your help and patience.

Greg

=============================================================================================
Email transmissions can not be guaranteed to be secure or error-free, as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain 
viruses.  The sender therefore does not accept liability for any errors or omissions in 
the contents of this message which arise as a result of email transmission.  In addition,
the information contained in this email message is intended only for use of the 
individual or entity named above.  If the reader of this message is not the intended
recipient, or the employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying of this communication,
disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it,
is strictly prohibited, and may be unlawful.  If you are not the intended recipient please
delete this email message. 
==============================================================================================



From dave at boost-consulting.com  Mon Sep 26 22:14:32 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 Sep 2005 16:14:32 -0400
Subject: [C++-sig] how to handle bare references with a
	shared_ptrHeldType
References: <FDC9B82C8E33C346B223298B17C2D34E0E1043@emgmail1.ellington.com>
Message-ID: <u3bnr8u3b.fsf@boost-consulting.com>

"Gregory Price" <price at ELLINGTON.com> writes:

> Here I use return_internal_reference on make_A;
> so I should get a Python object "a" holding the C++ A
> as a raw pointer.  But there's no trouble passing "a"
> to get_x, which wants a shared_ptr<A>.
> What is Boost.Python doing that makes this work?

It creates a shared_ptr whose custom deleter decrements the refcount
on the Python object owning the A.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From price at ELLINGTON.com  Tue Sep 27 00:56:46 2005
From: price at ELLINGTON.com (Gregory Price)
Date: Mon, 26 Sep 2005 18:56:46 -0400
Subject: [C++-sig] how to handle bare references with ashared_ptrHeldType
Message-ID: <FDC9B82C8E33C346B223298B17C2D34E0E1045@emgmail1.ellington.com>

David Abrahams wrote:
> > Here I use return_internal_reference on make_A;
> > so I should get a Python object "a" holding the C++ A
> > as a raw pointer.  But there's no trouble passing "a"
> > to get_x, which wants a shared_ptr<A>.
> > What is Boost.Python doing that makes this work?
> 
> It creates a shared_ptr whose custom deleter decrements the 
> refcount on the Python object owning the A.

Ah, very slick.  And when I try the same code
using the custom shared pointers I've actually got,
it tells me::

  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
  Boost.Python.ArgumentError: Python argument types in
      test.get_x(A)
  did not match C++ signature:
      get_x(Common::SmartPtr<A>)

since, naturally enough, it doesn't know how to
do something so smart with these custom pointers.


I think I understand now what's going on.
So as Hans said, the answer is to use return_internal_reference.
Thanks to both of you!

I'd understood the opposite behavior from the documentation,
namely that Boost.Python would create a new shared_ptr
(or HeldType generally) from a returned A&.
Most pertinent is the passage (in the class.hpp docs)

  Because Boost.Python will always allow wrapped 
  instances of T to be passed in place of HeldType 
  arguments, specifying a smart pointer for HeldType
  allows users to pass Python T instances where a 
  smart pointer-to-T is expected.

which I now see is making exactly the point you say, David,
but which I'd read as saying that Boost.Python would
convert instances of T to instances of HeldType. (In hindsight
I see there's no way it could have known how to do that,
not for the custom shared-pointers I've been using.)

I think this reading was encouraged by the suggestion in
the paragraph just above it that this is exactly
what's done when HeldType is derived from T.

Here's another version of that passage:

  HeldType may be a smart pointer to T.  In this case
  Boost.Python will allow Python T instances to hold
  either a C++ T instance or a C++ HeldType instance.
  If HeldType is shared_ptr<T>, a from_python converter
  will be registered to accept a Python T instance holding 
  a C++ T instance and return a shared_ptr<T> instance
  with a custom deleter that decrements the Python refcount.

Is this right?

In particular, have I correctly gathered the following
about how Boost.Python works (and about its terminology):

 When a Boost.Python function is called (in Python),
 it finds a from_python converter to convert each
 of the arguments to a C++ object of the required type.
 Similarly, after invoking the underlying C++ function,
 a to_python converter is found to convert its return value
 into a Python object.

Where in the documentation is this sort of orientation 
material found?  (Or where should it be?)

Thanks for all your help.

Greg

=============================================================================================
Email transmissions can not be guaranteed to be secure or error-free, as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain 
viruses.  The sender therefore does not accept liability for any errors or omissions in 
the contents of this message which arise as a result of email transmission.  In addition,
the information contained in this email message is intended only for use of the 
individual or entity named above.  If the reader of this message is not the intended
recipient, or the employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying of this communication,
disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it,
is strictly prohibited, and may be unlawful.  If you are not the intended recipient please
delete this email message. 
==============================================================================================



From nico_ml at mgdesign.org  Wed Sep 28 14:28:25 2005
From: nico_ml at mgdesign.org (Nicolas Lelong)
Date: Wed, 28 Sep 2005 14:28:25 +0200
Subject: [C++-sig] Ooops :-o
References: <433826F5.1020507@ix.urz.uni-heidelberg.de><43382B36.8020609@ix.urz.uni-heidelberg.de>
	<433832B8.30700@ix.urz.uni-heidelberg.de>
Message-ID: <008a01c5c428$204054b0$de00a8c0@nico>

You could also take a look at "register_ptr_to_python" which may help you.

see : http://www.boost.org/libs/python/doc/v2/register_ptr_to_python.html

Cheers,

Nicolas.


From Dennis.Brakhane at urz.uni-heidelberg.de  Wed Sep 28 15:01:22 2005
From: Dennis.Brakhane at urz.uni-heidelberg.de (Dennis Brakhane)
Date: Wed, 28 Sep 2005 15:01:22 +0200
Subject: [C++-sig] Ooops :-o
In-Reply-To: <008a01c5c428$204054b0$de00a8c0@nico>
References: <433826F5.1020507@ix.urz.uni-heidelberg.de><43382B36.8020609@ix.urz.uni-heidelberg.de>	<433832B8.30700@ix.urz.uni-heidelberg.de>
	<008a01c5c428$204054b0$de00a8c0@nico>
Message-ID: <433A9422.6040500@ix.urz.uni-heidelberg.de>

Nicolas Lelong wrote:
> You could also take a look at "register_ptr_to_python" which may help you.
> 
> see : http://www.boost.org/libs/python/doc/v2/register_ptr_to_python.html

Thanks! Looks good.

Dennis


From dirgesh.patel at hp.com  Wed Sep 28 16:22:35 2005
From: dirgesh.patel at hp.com (Dirgesh Patel)
Date: Wed, 28 Sep 2005 07:22:35 -0700
Subject: [C++-sig] Issues with Overloading with Boost
Message-ID: <dhe8vd$vka$1@sea.gmane.org>

I have listed many questions about overloading in the gmane.comp.python.c++ 
newsgroup.

Yet i still have not found a cure for my issue. The problem that I am having 
is I have a function called

bkimage* copy(bkimage *img,
              xint32_t pln0, xint32_t row0, xint32_t col0,
              xint32_t pln1, xint32_t row1, xint32_t col1)

then i have a boost.cpp file which is running this line

BOOST_PYTHON_FUNCTION_OVERLOADS(imageMorph_copy, copy, 1, 7)
and
def("copy", copy, imageMorph_copy() 
[return_value_policy<manage_new_object>()] );

yet i still get errors





From s_sourceforge at nedprod.com  Thu Sep 29 13:43:26 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 29 Sep 2005 12:43:26 +0100
Subject: [C++-sig] Regression in Boost.Python v1.33
Message-ID: <433BE16E.2953.13913164@localhost>

The TnFOX Python bindings are failing to compile on MSVC7.1 in BPL 
v1.33 when they worked in v1.32:

D:\Tornado\Tn\TClient\boost\boost\python\converter\registered.hpp(88) 
: error C2784: 'const boost::python::converter::registration 
&boost::python::converter::detail::registry_lookup(T &(__cdecl 
*)(void))' : could not deduce template argument for 'T1 &(__cdecl 
*)(void)' from 'volatile const boost::add_reference<T>::type (__cdecl 
*)(void)'

I see some changes have been made in converter/registered.hpp, 
namely:

  template <class T>
  registration const& registered_base<T>::converters
     = registry::lookup(type_id<T>());

... has become:

  template <class T>
  registration const& registered_base<T>::converters = 
detail::registry_lookup((T(*)())0);

Is this known about, and why was it done when the old code seems 
perfectly fine?

Cheers,
Niall





From dave at boost-consulting.com  Fri Sep 30 13:49:18 2005
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 30 Sep 2005 07:49:18 -0400
Subject: [C++-sig] Regression in Boost.Python v1.33
References: <433BE16E.2953.13913164@localhost>
Message-ID: <uoe6adbcx.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> The TnFOX Python bindings are failing to compile on MSVC7.1 in BPL 
> v1.33 when they worked in v1.32:
>
> D:\Tornado\Tn\TClient\boost\boost\python\converter\registered.hpp(88) 
> : error C2784: 'const boost::python::converter::registration 
> &boost::python::converter::detail::registry_lookup(T &(__cdecl 
> *)(void))' : could not deduce template argument for 'T1 &(__cdecl 
> *)(void)' from 'volatile const boost::add_reference<T>::type (__cdecl 
> *)(void)'
>
> I see some changes have been made in converter/registered.hpp, 
> namely:
>
>   template <class T>
>   registration const& registered_base<T>::converters
>      = registry::lookup(type_id<T>());
>
> ... has become:
>
>   template <class T>
>   registration const& registered_base<T>::converters = 
> detail::registry_lookup((T(*)())0);
>
> Is this known about, 

No, all the tests passed for vc7.1 upon release of 1.33.0, so it's
surprising to see a problem here.  Do you have any idea what T is in
this case?  A full instantiation backtrace might help.

> and why was it done when the old code seems 
> perfectly fine?

According to cvs annotate and cvs log, it was:

  revision 1.6
  date: 2005/05/16 14:54:12;  author: david_abrahams;  state: Exp;  lines: +8 -24
  Workarounds for vc6 and 7.

> Cheers,
> Niall

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



From s_sourceforge at nedprod.com  Fri Sep 30 17:55:08 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 30 Sep 2005 16:55:08 +0100
Subject: [C++-sig] Regression in Boost.Python v1.33
In-Reply-To: <uoe6adbcx.fsf@boost-consulting.com>
Message-ID: <433D6DEC.947.199DF8F1@localhost>

On 30 Sep 2005 at 7:49, David Abrahams wrote:

> > I see some changes have been made in converter/registered.hpp,
> > namely:
> >
> >   template <class T>
> >   registration const& registered_base<T>::converters
> >      = registry::lookup(type_id<T>());
> >
> > ... has become:
> >
> >   template <class T>
> >   registration const& registered_base<T>::converters = 
> > detail::registry_lookup((T(*)())0);
> >
> > Is this known about, 
> 
> No, all the tests passed for vc7.1 upon release of 1.33.0, so it's
> surprising to see a problem here.  Do you have any idea what T is in
> this case?  A full instantiation backtrace might help.

Putting the old code back makes everything work fine again.

I believe the type is 'void' as BPL strips off any pointers. 
Originally the type was FXID which is 'typedef void *FXID'. Hence 
this is not a case where I can force pyste to cast to 'void_ *' like 
usual. It could just be that MSVC7.1 won't deduce for a void &.

However I'll derive a test case and get back to you.

Cheers,
Niall





From s_sourceforge at nedprod.com  Fri Sep 30 22:45:50 2005
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 30 Sep 2005 21:45:50 +0100
Subject: [C++-sig] Regression in Boost.Python v1.33
In-Reply-To: <uoe6adbcx.fsf@boost-consulting.com>
Message-ID: <433DB20E.3205.577B33@localhost>

On 30 Sep 2005 at 7:49, David Abrahams wrote:

> No, all the tests passed for vc7.1 upon release of 1.33.0, so it's
> surprising to see a problem here.  Do you have any idea what T is in
> this case?  A full instantiation backtrace might help.

Here's the testcase:

#include "boost/python.hpp"

using namespace boost::python;

typedef void *FXID;

class FXWindow
{
public:
	void attach(FXID w) { }
};

int main(void)
{
    class_<FXWindow>("FXWindow")
        .def("attach", &FXWindow::attach);
	return 0;
}

This compiles on v1.32 but not v1.33. Here's the compiler error:

Compiling...
main.cpp
d:\Tornado\Tn\TClient\boost\boost\python\converter\registered.hpp(88) 
: error C2784: 'const boost::python::converter::registration 
&boost::python::converter::detail::registry_lookup(T &(__cdecl 
*)(void))' : could not deduce template argument for 'T1 &(__cdecl 
*)(void)' from 'volatile const boost::add_reference<T>::type (__cdecl 
*)(void)'
        with
        [
            T=volatile const 
boost::add_cv<boost::remove_pointer<boost::remove_cv<boost::mpl::v_ite
r<boost::mpl::vector3<void,boost::mpl::if_<boost::is_convertible<boost
::python::objects::class_metadata<FXWindow,boost::python::detail::not_
specified,boost::python::detail::not_specified,boost::python::detail::
not_specified>::held_type *,FXWindow *>,FXWindow,FXWindow>::type 
&,FXID>::type,2>::type >::type>::type>::type
        ]
        
d:\Tornado\Tn\TClient\boost\boost\python\converter\registered.hpp(81) 
: see declaration of 
'boost::python::converter::detail::registry_lookup'
        d:\Program Files\Microsoft Visual Studio .NET 
2003\Vc7\include\utility(32) : while compiling class-template static 
data member 'const boost::python::converter::registration 
&boost::python::converter::detail::registered_base<T>::converters'
        with
        [
            T=volatile const boost::add_reference<volatile const 
boost::add_cv<boost::remove_pointer<boost::remove_cv<boost::mpl::v_ite
r<boost::mpl::vector3<void,boost::mpl::if_<boost::is_convertible<boost
::python::objects::class_metadata<FXWindow,boost::python::detail::not_
specified,boost::python::detail::not_specified,boost::python::detail::
not_specified>::held_type *,FXWindow *>,FXWindow,FXWindow>::type 
&,FXID>::type,2>::type >::type>::type>::type>::type
        ]
        
d:\Tornado\Tn\TClient\boost\boost\python\converter\registered.hpp(41) 
: see reference to class template instantiation 
'boost::python::converter::detail::registered_base<T>' being compiled
        with
        [
            T=volatile const boost::add_reference<volatile const 
boost::add_cv<boost::remove_pointer<boost::remove_cv<boost::mpl::v_ite
r<boost::mpl::vector3<void,boost::mpl::if_<boost::is_convertible<boost
::python::objects::class_metadata<FXWindow,boost::python::detail::not_
specified,boost::python::detail::not_specified,boost::python::detail::
not_specified>::held_type *,FXWindow *>,FXWindow,FXWindow>::type 
&,FXID>::type,2>::type >::type>::type>::type>::type
        ]
        
d:\Tornado\Tn\TClient\boost\boost\python\converter\registered_pointee.
hpp(27) : see reference to class template instantiation 
'boost::python::converter::registered<T>' being compiled
        with
        [
            
T=boost::remove_pointer<boost::remove_cv<boost::mpl::v_iter<boost::mpl
::vector3<void,boost::mpl::if_<boost::is_convertible<boost::python::ob
jects::class_metadata<FXWindow,boost::python::detail::not_specified,bo
ost::python::detail::not_sp
ecified,boost::python::detail::not_specified>::held_type *,FXWindow 
*>,FXWindow,FXWindow>::type &,FXID>::type,2>::type >::type>::type
        ]
        
d:\Tornado\Tn\TClient\boost\boost\python\converter\arg_from_python.hpp
(269) : see reference to class template instantiation 
'boost::python::converter::registered_pointee<T>' being compiled
        with
        [
            
T=boost::remove_cv<boost::mpl::v_iter<boost::mpl::vector3<void,boost::
mpl::if_<boost::is_convertible<boost::python::objects::class_metadata<
FXWindow,boost::python::detail::not_specified,boost::python::detail::n
ot_specified,boost::python::detail::not_specified>::held_type 
*,FXWindow *>,FXWindow,FXWindow>::type &,FXID>::type,2>::type >::type 

        ]
        d:\Program Files\Microsoft Visual Studio .NET 
2003\Vc7\include\utility(32) : while compiling class-template member 
function 
'boost::python::converter::pointer_arg_from_python<T>::pointer_arg_fro
m_python(PyObject *)'
        with
        [
            
T=boost::remove_cv<boost::mpl::v_iter<boost::mpl::vector3<void,boost::
mpl::if_<boost::is_convertible<boost::python::objects::class_metadata<
FXWindow,boost::python::detail::not_specified,boost::python::detail::n
ot_specified,boost::python::detail::not_specified>::held_type 
*,FXWindow *>,FXWindow,FXWindow>::type &,FXID>::type,2>::type >::type 

        ]
        
d:\Tornado\Tn\TClient\boost\boost\detail\compressed_pair.hpp(200) : 
while compiling class-template member function 
'boost::python::arg_from_python<T>::arg_from_python(PyObject *)'
        with
        [
            
T=boost::mpl::v_iter<boost::mpl::vector3<void,boost::mpl::if_<boost::i
s_convertible<boost::python::objects::class_metadata<FXWindow,boost::p
ython::detail::not_specified,boost::python::detail::not_specified,boos
t::python::detail::not_specified>::held_type *,FXWindow 
*>,FXWindow,FXWindow>::type &,FXID>::type,2>::type
        ]
        
d:\Tornado\Tn\TClient\boost\boost\preprocessor\iteration\detail\local.
hpp(37) : see reference to class template instantiation 
'boost::python::arg_from_python<T>' being compiled
        with
        [
            
T=boost::mpl::v_iter<boost::mpl::vector3<void,boost::mpl::if_<boost::i
s_convertible<boost::python::objects::class_metadata<FXWindow,boost::p
ython::detail::not_specified,boost::python::detail::not_specified,boos
t::python::detail::not_specified>::held_type *,FXWindow 
*>,FXWindow,FXWindow>::type &,FXID>::type,2>::type
        ]
        
d:\Tornado\Tn\TClient\boost\boost\python\detail\caller.hpp(176) : 
while compiling class-template member function 'PyObject 
*boost::python::detail::caller_arity<2>::impl<F,Policies,Sig>::operato
r ()(PyObject *,PyObject *)'
        with
        [
            F=void (__thiscall FXWindow::* )(FXID),
            
Policies=boost::python::detail::tuple_extract_impl<false>::apply<boost
::python::detail::def_helper<const char 
*>::all_t,boost::mpl::lambda<boost::mpl::and_<boost::mpl::not_<boost::
is_same<const boost::python::detail::not_specified 
&,boost::mpl::_1>>,boost::detail::indirect_traits::is_reference_to_cla
ss<boost::mpl::_1>,boost::mpl::not_<boost::python::detail::is_referenc
e_to_keywords<boost::mpl::_1>>>>::type>::result_type,
            
Sig=boost::mpl::vector3<void,boost::mpl::if_<boost::is_convertible<boo
st::python::objects::class_metadata<FXWindow,boost::python::detail::no
t_specified,boost::python::detail::not_specified,boost::python::detail
::not_specified>::held_type *,FXWindow *>,FXWindow,FXWindow>::type 
&,FXID>
        ]
        
d:\Tornado\Tn\TClient\boost\boost\python\detail\caller.hpp(145) : see 
reference to class template instantiation 
'boost::python::detail::caller_arity<2>::impl<F,Policies,Sig>' being 
compiled
        with
        [
            F=void (__thiscall FXWindow::* )(FXID),
            
Policies=boost::python::detail::tuple_extract_impl<false>::apply<boost
::python::detail::def_helper<const char 
*>::all_t,boost::mpl::lambda<boost::mpl::and_<boost::mpl::not_<boost::
is_same<const boost::python::detail::not_specified 
&,boost::mpl::_1>>,boost::detail::indirect_traits::is_reference_to_cla
ss<boost::mpl::_1>,boost::mpl::not_<boost::python::detail::is_referenc
e_to_keywords<boost::mpl::_1>>>>::type>::result_type,
            
Sig=boost::mpl::vector3<void,boost::mpl::if_<boost::is_convertible<boo
st::python::objects::class_metadata<FXWindow,boost::python::detail::no
t_specified,boost::python::detail::not_specified,boost::python::detail
::not_specified>::held_type *,FXWindow *>,FXWindow,FXWindow>::type 
&,FXID>
        ]
        
d:\Tornado\Tn\TClient\boost\boost\python\make_function.hpp(61) : see 
reference to class template instantiation 
'boost::python::detail::caller<F,CallPolicies,Sig>' being compiled
        with
        [
            F=void (__thiscall FXWindow::* )(FXID),
            
CallPolicies=boost::python::detail::tuple_extract_impl<false>::apply<b
oost::python::detail::def_helper<const char 
*>::all_t,boost::mpl::lambda<boost::mpl::and_<boost::mpl::not_<boost::
is_same<const boost::python::detail::not_specified 
&,boost::mpl::_1>>,boost::detail::indirect_traits::is_reference_to_cla
ss<boost::mpl::_1>,boost::mpl::not_<boost::python::detail::is_referenc
e_to_keywords<boost::mpl::_1>>>>::type>::result_type,
            
Sig=boost::mpl::vector3<void,boost::mpl::if_<boost::is_convertible<boo
st::python::objects::class_metadata<FXWindow,boost::python::detail::no
t_specified,boost::python::detail::not_specified,boost::python::detail
::not_specified>::held_type *,FXWindow *>,FXWindow,FXWindow>::type 
&,FXID>
        ]
        
d:\Tornado\Tn\TClient\boost\boost\python\make_function.hpp(146) : see 
reference to function template instantiation 
'boost::python::api::object 
boost::python::detail::make_function_aux<F,CallPolicies,Signature,boos
t::mpl::int_<N>>(F,const CallPolicies &,const Sig &,const 
boost::python::detail::keyword_range &,NumKeywords)' being compiled
        with
        [
            F=void (__thiscall FXWindow::* )(FXID),
            
CallPolicies=boost::python::detail::tuple_extract_impl<false>::apply<b
oost::python::detail::def_helper<const char 
*>::all_t,boost::mpl::lambda<boost::mpl::and_<boost::mpl::not_<boost::
is_same<const boost::python::detail::not_specified 
&,boost::mpl::_1>>,boost::detail::indirect_traits::is_reference_to_cla
ss<boost::mpl::_1>,boost::mpl::not_<boost::python::detail::is_referenc
e_to_keywords<boost::mpl::_1>>>>::type>::result_type,
            
Signature=boost::mpl::vector3<void,boost::mpl::if_<boost::is_convertib
le<boost::python::objects::class_metadata<FXWindow,boost::python::deta
il::not_specified,boost::python::detail::not_specified,boost::python::
detail::not_specified>::held_type *,FXWindow 
*>,FXWindow,FXWindow>::type &,FXID>,
            N=0,
            
Sig=boost::mpl::vector3<void,boost::mpl::if_<boost::is_convertible<boo
st::python::objects::class_metadata<FXWindow,boost::python::detail::no
t_specified,boost::python::detail::not_specified,boost::python::detail
::not_specified>::held_type *,FXWindow *>,FXWindow,FXWindow>::type 
&,FXID>,
            NumKeywords=boost::mpl::int_<0>
        ]
        d:\Tornado\Tn\TClient\boost\boost\python\class.hpp(544) : see 
reference to function template instantiation 
'boost::python::api::object 
boost::python::make_function<Fn,boost::python::detail::tuple_extract_i
mpl<false>::apply<Tuple,Predicate>::result_type,boost::python::detail:
:tuple_extract_impl<false>::apply<Tuple,boost::mpl::protect<T>>::resul
t_type,boost::mpl::vector3<T0,T1,T2>>(F,const CallPolicies &,const 
Keywords &,const Signature &)' being compiled
        with
        [
            Fn=void (__
thiscall FXWindow::* )(FXID),
            Tuple=boost::python::detail::def_helper<const char 
*>::all_t,
            
Predicate=boost::mpl::lambda<boost::mpl::and_<boost::mpl::not_<boost::
is_same<const boost::python::detail::not_specified 
&,boost::mpl::_1>>,boost::detail::indirect_traits::is_reference_to_cla
ss<boost::mpl::_1>,boost::mpl::not_<boost::python::detail::is_referenc
e_to_keywords<boost::mpl::_1>>>>::type,
            
T=boost::mpl::aux::le_result1<boost::mpl::lambda<boost::python::detail
::is_reference_to_keywords<boost::mpl::_1>>::is_le,boost::mpl::void_,b
oost::python::detail::is_reference_to_keywords,boost::mpl::lambda<boos
t::python::detail::is_reference_to_keywords<boost::mpl::_1>>::l1>::res
ult_,
            T0=void,
            
T1=boost::mpl::if_<boost::is_convertible<boost::python::objects::class
_metadata<FXWindow,boost::python::detail::not_specified,boost::python:
:detail::not_specified,boost::python::detail::not_specified>::held_typ
e *,FXWindow *>,FXWindow,FXWindow>::type &,
            T2=FXID,
            F=void (__thiscall FXWindow::* )(FXID),
            
CallPolicies=boost::python::detail::tuple_extract_impl<false>::apply<b
oost::python::detail::def_helper<const char 
*>::all_t,boost::mpl::lambda<boost::mpl::and_<boost::mpl::not_<boost::
is_same<const boost::python::detail::not_specified 
&,boost::mpl::_1>>,boost::detail::indirect_traits::is_reference_to_cla
ss<boost::mpl::_1>,boost::mpl::not_<boost::python::detail::is_referenc
e_to_keywords<boost::mpl::_1>>>>::type>::result_type,
            
Keywords=boost::python::detail::tuple_extract_impl<false>::apply<boost
::python::detail::def_helper<const char 
*>::all_t,boost::mpl::lambda<boost::python::detail::is_reference_to_ke
ywords<boost::mpl::_1>>::type>::result_type,
            
Signature=boost::mpl::vector3<void,boost::mpl::if_<boost::is_convertib
le<boost::python::objects::class_metadata<FXWindow,boost::python::deta
il::not_specified,boost::python::detail::not_specified,boost::python::
detail::not_specified>::held_type *,FXWindow 
*>,FXWindow,FXWindow>::type 
&,FXID>
        ]
        d:\Tornado\Tn\TClient\boost\boost\python\class.hpp(237) : see 
reference to function template instantiation 'void 
boost::python::class_<W>::def_impl<W,F,boost::python::detail::def_help
er<T1>>(T *,const char *,Fn,const Helper &,...)' being compiled
        with
        [
            W=FXWindow,
            F=void (__thiscall FXWindow::* )(FXID),
            T1=const char *,
            T=FXWindow,
            Fn=void (__thiscall FXWindow::* )(FXID),
            Helper=boost::python::detail::def_helper<const char *>
        ]
        d:\Tornado\Tn\TClient\BoostBug\main.cpp(15) : see reference 
to function template instantiation 'boost::python::class_<W>::self 
&boost::python::class_<W>::def<void(__thiscall FXWindow::* 
)(FXID)>(const char *,F)' being compiled
        with
        [
            W=FXWindow,
            F=void (__thiscall FXWindow::* )(FXID)
        ]

Cheers,
Niall