From nidoizo at yahoo.com  Wed Dec  1 17:33:24 2004
From: nidoizo at yahoo.com (Nicolas Fleury)
Date: Wed, 01 Dec 2004 11:33:24 -0500
Subject: [C++-sig] Boost 1.32 and Python 2.4
Message-ID: <cokroj$g77$1@sea.gmane.org>

Finally, does boost 1.32 supports Python 2.4?
Thx and regards,
Nicolas



From dan.eloff at gmail.com  Thu Dec  2 00:19:41 2004
From: dan.eloff at gmail.com (Dan Eloff)
Date: Wed, 1 Dec 2004 15:19:41 -0800
Subject: [C++-sig] C++ new/delete with python
In-Reply-To: <loom.20041125T100808-369@post.gmane.org>
References: <loom.20041125T100808-369@post.gmane.org>
Message-ID: <4817b6fc041201151957ca5ff7@mail.gmail.com>

So you want a class member defined as an array allocated dynamically
on the heap. You can do this, but you may or may not be able to access
it directly in python. I don't know if boost::python has an array
wrapper, check the docs, that's what they are there for. As for
deleting the array, you will have to do that in C++ (in the objects
destructor??). Your code is invalid btw, it should be test::objects =
new int[10]; But i would recommend you intialize dynamic arrays in
test's constructor, it just makes more sense.

-Dan


On Thu, 25 Nov 2004 09:15:52 +0000 (UTC), Chris Targett <xin at xlevus.net> wrote:
> I've got some code.
> 
>   class test {
>      test(*int);
>      int *objects;
>   };
> 
>   objects = new int[10];
> 
> I want to expose my class `test` to python via Boost, Is there anything special
> I have to do to get this to expose properly?
> 
> I'm not too fussed about the constructor but if its workable then thats cool.
> 
> Is it possible to have a `new` defined array work within python?
> 
> Thanks
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>


From ahrivera at yahoo.com  Thu Dec  2 00:52:10 2004
From: ahrivera at yahoo.com (Alexis H. Rivera-Rios)
Date: Wed, 1 Dec 2004 15:52:10 -0800 (PST)
Subject: [C++-sig] can I add properties and python iterator support using
	pyste?
Message-ID: <20041201235210.98716.qmail@web12824.mail.yahoo.com>

Hi I want to add python iterator support to a class.
The boost.python documentation says that I can do
this:
class_<F>("Field")
    .property("pions", range(&F::p_begin, &F::p_end))
    .property("bogons", range(&F::b_begin, F::b_end));

Is there an equivalent command in Pyste?  I didn't
find any.

Thanks,
Alexis

=====
Programming Tutorial:
In Python: To do this, do this
In Perl: To do this, do this or this or this or this...
In C: To do this, do this, but be careful
In C++: To do this, do this, but don't do this, be careful of this, watch out for this, and whatever you do, don't do this


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 


From jeff.holle at verizon.net  Thu Dec  2 01:32:03 2004
From: jeff.holle at verizon.net (Jeffrey Holle)
Date: Wed, 01 Dec 2004 16:32:03 -0800
Subject: [C++-sig] new pyste problem with boost v1.32.0
Message-ID: <colnk0$3dc$1@sea.gmane.org>

In running pyste against my python extension module I am running into 
compilation errors in the pyste generated code that is a new feature of 
1.32.0.

The problem is that for methods that have a default parameter, like:
   void setConst(bool val = true);

pyste will generate two BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS 
statements where only one is needed.

Can someone point out the python script change that will fix this?



From ahrivera at yahoo.com  Thu Dec  2 01:47:10 2004
From: ahrivera at yahoo.com (Alexis H. Rivera-Rios)
Date: Wed, 1 Dec 2004 16:47:10 -0800 (PST)
Subject: [C++-sig] how to specify a class with 2 types of iterators
Message-ID: <20041202004710.73377.qmail@web12822.mail.yahoo.com>

Hi,

Say I have a class like the following:

class Mesh
{
    VertexIterator VerticesBegin();
    VertexIterator VerticesEnd();

    FaceIterator FacesBegin();
    FaceIterator FacesEnd();
};

I want to export these iterators the "python way" so
I'm doing something like this (trying to follow the
example in the tutorial):

class_< Mesh, boost::noncopyable >("Mesh")
      .add_property("Faces", range(&Mesh::FacesBegin,
&Mesh::FacesEnd))
      .add_property("Vertices",
range(&Mesh::VerticesBegin, &Mesh::VerticesEnd))
    ;

When I try to do something like this in Python:
for v in mesh.Vertices():
    print v.SomeMethod()

I get an error that says: 
TypeError: 'iterator' object is not callable

I suppose it has to do with not defining the __iter__
function, but how can I do that for two different
iterators?  Definetly, I'm missing something.

(By the way, I couldn't compile the code using the
commands from the tutorial ie. using .property instead
of .add_property above)


I'll appreciate your help,
Alexis


=====
Programming Tutorial:
In Python: To do this, do this
In Perl: To do this, do this or this or this or this...
In C: To do this, do this, but be careful
In C++: To do this, do this, but don't do this, be careful of this, watch out for this, and whatever you do, don't do this


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 


From gmeeker at ilm.com  Thu Dec  2 03:49:20 2004
From: gmeeker at ilm.com (Garrick Meeker)
Date: Wed, 01 Dec 2004 18:49:20 -0800
Subject: [C++-sig] bypassing boost::python's keyword handling
Message-ID: <41AE82B0.2000708@ilm.com>

Is it possible to use boost to wrap a function that expects args and 
keywords as two PyObject's?  This is old C-style Python code that could 
be written but the python syntax must be the same.  Imagine I'm 
implementing some sort of dictionary class in C++.  The easiest way 
might be to wrap this in python, so this may be purely an academic 
question.  Something like:

void f(PyObject *args, PyObject *kw);
def("f_base", &f);

def f(*args, **kw):
  f_base(args, kw)

f(a=1, b=2, c=3)




From dave at boost-consulting.com  Thu Dec  2 05:05:16 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 01 Dec 2004 23:05:16 -0500
Subject: [C++-sig] Re: bypassing boost::python's keyword handling
In-Reply-To: <41AE82B0.2000708@ilm.com>
References: <41AE82B0.2000708@ilm.com>
Message-ID: <com4an$ras$1@sea.gmane.org>

Garrick Meeker wrote:
> Is it possible to use boost to wrap a function that expects args and 
> keywords as two PyObject's?  This is old C-style Python code that could 
> be written but the python syntax must be the same.  Imagine I'm 
> implementing some sort of dictionary class in C++.  The easiest way 
> might be to wrap this in python, so this may be purely an academic 
> question.  Something like:
> 
> void f(PyObject *args, PyObject *kw);
> def("f_base", &f);
> 
> def f(*args, **kw):
>  f_base(args, kw)
> 
> f(a=1, b=2, c=3)

Does
http://www.boost.org/libs/python/doc/v2/raw_function.html
help?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Thu Dec  2 05:01:55 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 01 Dec 2004 23:01:55 -0500
Subject: [C++-sig] Re: how to specify a class with 2 types of iterators
In-Reply-To: <20041202004710.73377.qmail@web12822.mail.yahoo.com>
References: <20041202004710.73377.qmail@web12822.mail.yahoo.com>
Message-ID: <com44f$r12$1@sea.gmane.org>

Alexis H. Rivera-Rios wrote:
> Hi,
> 
> Say I have a class like the following:
> 
> class Mesh
> {
>     VertexIterator VerticesBegin();
>     VertexIterator VerticesEnd();
> 
>     FaceIterator FacesBegin();
>     FaceIterator FacesEnd();
> };
> 
> I want to export these iterators the "python way" so
> I'm doing something like this (trying to follow the
> example in the tutorial):
> 
> class_< Mesh, boost::noncopyable >("Mesh")
>       .add_property("Faces", range(&Mesh::FacesBegin,
> &Mesh::FacesEnd))
>       .add_property("Vertices",
> range(&Mesh::VerticesBegin, &Mesh::VerticesEnd))
>     ;
> 
> When I try to do something like this in Python:
> for v in mesh.Vertices():
>     print v.SomeMethod()
> 
> I get an error that says: 
> TypeError: 'iterator' object is not callable
> 
> I suppose it has to do with not defining the __iter__
> function, but how can I do that for two different
> iterators?  Definetly, I'm missing something.

Yep.  Or rather, you have too much of something.  Drop the parentheses in:

   for v in mesh.Vertices():

Or, if you want a function call interface, instead of using 
.add_property( ... ) just write:

        .def("Vertices", range( ... ))


> (By the way, I couldn't compile the code using the
> commands from the tutorial ie. using .property instead
> of .add_property above)

Thanks.  All of the tutorial examples are supposed to have been tested; 
I'm not sure why this one slipped through.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Paul_Kunz at slac.stanford.edu  Thu Dec  2 17:34:47 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Thu, 2 Dec 2004 08:34:47 -0800
Subject: [C++-sig] Deriving Python function from C++ base class with
	pure virtual function
In-Reply-To: <1100471714.18970.21.camel@illuvatar> (message from Jonathan
	Brandmeyer on Sun, 14 Nov 2004 17:35:14 -0500)
References: <cn2mf2$vht$1@sea.gmane.org> <4194E059.30809@cenix-bioscience.com>
	<200411130953.iAD9rI323669@libra3.slac.stanford.edu>
	<1100471714.18970.21.camel@illuvatar>
Message-ID: <200412021634.iB2GYlY08753@libra3.slac.stanford.edu>

>>>>> On Sun, 14 Nov 2004 17:35:14 -0500, Jonathan Brandmeyer <jbrandmeyer at earthlink.net> said:

> See the PEP 311 interface PyGILState_Ensure()/PyGILState_Release(),
> which you will use to wrap around the callback function in your C++
> code.  This interface solves the thread bootstrap problem.
> Furthermore, the lock is recursive, so locking the GIL is safe when
> you already have the lock.

   I tried this with Boost-1.32.0 and Python 2.4 as follows...

double
FunctionWrap::
operator () ( double x ) const
{
  PyGILState_STATE state = PyGILState_Ensure ();
  double value =  call_method < double, double > ( m_self, "valueAt", x );
  PyGILState_Release ( state );

  return value;
}

I still get SIGSEGV with different traceback as follows...

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1117453104 (LWP 16757)]
0x40030dca in sem_post at GLIBC_2.0 () from /lib/tls/libpthread.so.0
(gdb) up
#1  0x080e7be1 in PyThread_release_lock (lock=0x0) at thread_pthread.h:332
332	in thread_pthread.h
(gdb) up
#2  0x080b5cd3 in PyEval_ReleaseLock () at Python/ceval.c:234
(gdb) 
#3  0x080e1b63 in PyGILState_Release (oldstate=142794840)
    at Python/pystate.c:264
(gdb) 
#4  0x407ffb8e in FunctionWrap::operator() (this=0x0, x=0)
    at ../../hippodraw/python/FunctionWrap.cxx:113
Current language:  auto; currently c++
(gdb) 

Note `lock=0x0' in the call to release_lock.

   Any suggestions?


From jbrandmeyer at earthlink.net  Thu Dec  2 21:34:15 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Thu, 02 Dec 2004 15:34:15 -0500
Subject: [C++-sig] Deriving Python function from C++ base class with
	pure virtual function
In-Reply-To: <200412021634.iB2GYlY08753@libra3.slac.stanford.edu>
References: <cn2mf2$vht$1@sea.gmane.org> <4194E059.30809@cenix-bioscience.com>
	<200411130953.iAD9rI323669@libra3.slac.stanford.edu>
	<1100471714.18970.21.camel@illuvatar>
	<200412021634.iB2GYlY08753@libra3.slac.stanford.edu>
Message-ID: <1102019655.9867.21.camel@illuvatar>

On Thu, 2004-12-02 at 08:34 -0800, Paul F. Kunz wrote:
> >>>>> On Sun, 14 Nov 2004 17:35:14 -0500, Jonathan Brandmeyer <jbrandmeyer at earthlink.net> said:
> 
> > See the PEP 311 interface PyGILState_Ensure()/PyGILState_Release(),
> > which you will use to wrap around the callback function in your C++
> > code.  This interface solves the thread bootstrap problem.
> > Furthermore, the lock is recursive, so locking the GIL is safe when
> > you already have the lock.
> 
>    I tried this with Boost-1.32.0 and Python 2.4 as follows...
> 
> double
> FunctionWrap::
> operator () ( double x ) const
> {
>   PyGILState_STATE state = PyGILState_Ensure ();
>   double value =  call_method < double, double > ( m_self, "valueAt", x );
>   PyGILState_Release ( state );
> 
>   return value;
> }

This isn't safe since call_method() can throw, which would prevent
releasing the GIL.  I made a small lock class that calls
PyGILState_Ensure() in its constructor, and PyGILState_Release() in the
destructor for this purpose.

> I still get SIGSEGV with different traceback as follows...
> 
[snipped]
>    Any suggestions?

Execute PyExec_InitThreads() in your module initialization function, and
see if that helps (it does for me).  Python does not do this
automatically.

HTH,
-Jonathan






From Paul_Kunz at slac.stanford.edu  Thu Dec  2 22:40:46 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Thu, 2 Dec 2004 13:40:46 -0800
Subject: [C++-sig] Deriving Python function from C++ base class with
	pure virtual function
In-Reply-To: <1102019655.9867.21.camel@illuvatar> (message from Jonathan
	Brandmeyer on Thu, 02 Dec 2004 15:34:15 -0500)
References: <cn2mf2$vht$1@sea.gmane.org> <4194E059.30809@cenix-bioscience.com>
	<200411130953.iAD9rI323669@libra3.slac.stanford.edu>
	<1100471714.18970.21.camel@illuvatar>
	<200412021634.iB2GYlY08753@libra3.slac.stanford.edu>
	<1102019655.9867.21.camel@illuvatar>
Message-ID: <200412022140.iB2Leka06318@libra3.slac.stanford.edu>

>>>>> On Thu, 02 Dec 2004 15:34:15 -0500, Jonathan Brandmeyer <jbrandmeyer at earthlink.net> said:


> Execute PyExec_InitThreads() in your module initialization function,
> and see if that helps (it does for me).  Python does not do this
> automatically.

   I assumed you meant PyEval_InitThreads().   If so, that works!
Thanks a million.


From gaiacrtn at free.fr  Thu Dec  2 21:11:15 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Thu, 2 Dec 2004 21:11:15 +0100
Subject: [C++-sig] pyste + wrapping + overloads
References: <m3u0s0dyj8.fsf@peds-pc311.bsd.uchicago.edu>
Message-ID: <000201c4d8bc$12e90990$0200a8c0@lain>

This is a pyste limitation. You can never specify special behavior for a
given overload.

Here is what I suggest doing (that's how I deal with stuff like this in
pyogre):
- exclude all the overloaded functions
- inject your code to export those functions correctly using
declaration_code() and class_code().

This way you can keep using pyste to generate most of the binding.

Baptiste.

----- Original Message ----- 
From: "John Hunter" <jdhunter at nitace.bsd.uchicago.edu>
To: <c++-sig at python.org>
Sent: Monday, November 08, 2004 6:46 PM
Subject: [C++-sig] pyste + wrapping + overloads


>
> I am trying to wrap a class method in pyste that has a signature
>
>     void path_storage::add_poly(const double* vertices, unsigned num,
>                                 bool solid_path, unsigned end_flags)
>
> vertices is a length 2*num array of x,y doubles x0, y0, x1, y1, ....
>
> I am using the following wrapper
>
>   void add_poly_wrapper(agg::path_storage* ps, list vertices,
> bool solid_path = false,
> unsigned end_flags = agg::path_flags_none) {
>     size_t N = extract<size_t>(vertices.attr("length")());
>     double * pverts = new double[2*N];
>     for (size_t i=0; i<N; i++) {
>       tuple xy  = extract<tuple>(vertices[i]);
>       *pverts++ = extract<double>(xy[0]);
>       *pverts++ = extract<double>(xy[1]);
>     }
>     pverts -= 2*N;  //rewind
>     ps->add_poly(pverts, N, solid_path, end_flags);
>
>   }
>
> The first problem I've encountered in pyste is that the standard way of
> specifying wrappers
>
>     Include("path_storage_wrap.h")
>     PS = Class("agg::path_storage", "agg_path_storage.h")
>     set_wrapper(PS.add_poly, "add_poly_wrapper")
>
> doesn't work because there is no PS.add_poly, since pyste defines it
> with the overload macro
>
>
>
BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(agg_path_storage_add_poly_overloads_2
_4, add_poly, 2, 4)
>
>
> How does one specify wrappers for overloaded functions?  I don't know
> enough about the overload macro internals to figure out how to
> proceed...
>
> Thanks,
> JDH
>
> boost_python 1.31.0 with pyste and gccxml-0.6.0
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>



From gmeeker at ilm.com  Fri Dec  3 01:18:13 2004
From: gmeeker at ilm.com (Garrick Meeker)
Date: Thu, 02 Dec 2004 16:18:13 -0800
Subject: [C++-sig] Re: bypassing boost::python's keyword handling
Message-ID: <41AFB0C5.40305@ilm.com>

Oh, I didn't see that.  I would like to use this for a python class 
__init__ method, but I'm not sure how this interacts with the init<> 
stuff.  Since __init__ is always defined, can I just add def("__init__", 
raw_pointer<&MyClass::init>), or can I have a C++ constructor that takes 
PyObject arg and keyword arguments?

Garrick Meeker wrote:
 >/ Is it possible to use boost to wrap a function that expects args and
/>/ keywords as two PyObject's? This is old C-style Python code that could
/>/ be written but the python syntax must be the same. Imagine I'm
/>/ implementing some sort of dictionary class in C++. The easiest way
/>/ might be to wrap this in python, so this may be purely an academic
/>/ question. Something like:
/>/
/>/ void f(PyObject *args, PyObject *kw);
/>/ def("f_base", &f);
/>/
/>/ def f(*args, **kw):
/>/ f_base(args, kw)
/>/
/>/ f(a=1, b=2, c=3)
/
Does
http://www.boost.org/libs/python/doc/v2/raw_function.html
help?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From dave at boost-consulting.com  Fri Dec  3 09:02:21 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 03 Dec 2004 03:02:21 -0500
Subject: [C++-sig] Re: bypassing boost::python's keyword handling
In-Reply-To: <41AFB0C5.40305@ilm.com>
References: <41AFB0C5.40305@ilm.com>
Message-ID: <cop6j3$dfl$1@sea.gmane.org>

Garrick Meeker wrote:

 > Oh, I didn't see that.  I would like to use this for a python
 > class __init__ method, but I'm not sure how this interacts with
 > the init<> stuff.  Since __init__ is always defined, can I just
 > add def("__init__", raw_pointer<&MyClass::init>),

You must mean raw_function(&MyClass::init).  Yes, you can do that
if MyClass::init is a static member function:

     void MyClass::init(tuple args, dict kw)

Be aware that the first element of args will be the "self"
object and it will be uninitialized, just as in Python.  So
you'll need to pass those arguments on to some other wrapped
constructor.  See the enclosed for an example


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: raw_ctor.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041203/55497c8f/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: raw_ctor.py
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041203/55497c8f/attachment-0001.txt>

From marco at bubke.de  Fri Dec  3 21:28:46 2004
From: marco at bubke.de (Marco Bubke)
Date: Fri, 3 Dec 2004 21:28:46 +0100
Subject: [C++-sig] multiple * operators does'nt work
Message-ID: <200412032128.46724.marco@bubke.de>

Hi, I have this code generated from pyste:

...

        .def( self *= other< GLfloat >() )
        .def( self /= other< GLfloat >() )
        .def( self += self )
        .def( self -= self )
        .def( self * self )
        .def( self *= self )
        .def( self * other< GLVector4<float> >() )
        .def( self * other< GLfloat >() )
        .def( self * other< GLVector3<float> >() )

...

and than I get this compiler error:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes 
-fPIC -Iinclude -I/usr/local/inpython2.3 -c src/gl.cpp -o 
build/temp.linux-i686-2.3/src/gl.o
/usr/local/include/boost/python/operators.hpp: In static member function `
   static PyObject* boost::python::detail::operator_l<op_mul>::apply<L,
   R>::execute(L&, const R&) [with L = GLMatrix<GLfloat>, R = GLfloat]':
/usr/local/include/boost/python/operators.hpp:151:   instantiated from `void 
boost::python::detail::operato L, R>::visit(ClassT&) const [with ClassT = 
boost::python::class_<GLMatrix<GLfloat>, boost::python::detail:pecified, 
boost::python::detail::not_specified, boost::python::detail::not_specified>, 
boost::python::detairator_id id = op_mul, L = boost::python::self_ns::self_t, 
R = boost::python::other<GLfloat>]'
/usr/local/include/boost/python/def_visitor.hpp:31:   instantiated from 
`static void boost::python::def_visccess::visit(const V&, classT&) [with V = 
boost::python::def_visitor<boost::python::detail::operator_<op_must::python::self_ns::self_t, 
boost::python::other<GLfloat> > >, classT = 
boost::python::class_<GLMatrix<GLf boost::python::detail::not_specified, 
boost::python::detail::not_specified, boost::python::detail::not_spe>]'
/usr/local/include/boost/python/def_visitor.hpp:67:   instantiated from `void 
boost::python::def_visitor<Deisitor>::visit(classT&) const [with classT = 
boost::python::class_<GLMatrix<GLfloat>, boost::python::detailspecified, 
boost::python::detail::not_specified, boost::python::detail::not_specified>, 
DerivedVisitor = boython::detail::operator_<op_mul, 
boost::python::self_ns::self_t, boost::python::other<GLfloat> >]'
/usr/local/include/boost/python/class.hpp:225:   instantiated from 
`boost::python::class_<T, X1, X2, X3>& bpython::class_<T, X1, X2, 
X3>::def(const boost::python::def_visitor<Derived>&) [with Derived = 
boost::pythoail::operator_<op_mul, boost::python::self_ns::self_t, 
boost::python::other<GLfloat> >, W = GLMatrix<GLfloa = 
boost::python::detail::not_specified, X2 = 
boost::python::detail::not_specified, X3 = boost::python::detot_specified]'
src/gl.cpp:233:   instantiated from here
/usr/local/include/boost/python/operators.hpp:209: error: ambiguous overload
   for 'operator*' in 'l * r'
include/GLMatrix.h:74: error: candidates are: GLMatrix<T>
   GLMatrix<T>::operator*(const GLMatrix<T>&) [with T = GLfloat]
include/GLMatrix.h:155: error:                 GLVector4<T>
   GLMatrix<T>::operator*(const GLVector4<T>&) [with T = GLfloat]
include/GLMatrix.h:263: error:                 GLVector3<T>
   GLMatrix<T>::operator*(const GLVector3<T>&) [with T = GLfloat]
include/GLVector.h: At global scope:
include/GLVector.h:78: warning: inline function `void GLVector2<T>::glScale()
   const [with T = GLfloat]' used but never defined
include/GLVector.h:80: warning: inline function `void 
GLVector2<T>::glRotate(T)
   const [with T = GLfloat]' used but never defined
include/GLVector.h:82: warning: inline function `void
   GLVector2<T>::glTranslate() const [with T = GLfloat]' used but never 
defined
include/GLVector.h:84: warning: inline function `void GLVector2<T>::glVertex()
   const [with T = GLfloat]' used but never defined
include/GLVector.h:86: warning: inline function `void GLVector2<T>::glNormal()
   const [with T = GLfloat]' used but never defined
include/GLVector.h:532: warning: inline function `void GLVector4<T>::glScale()
   const [with T = GLfloat]' used but never defined
include/GLVector.h:534: warning: inline function `void
   GLVector4<T>::glRotate(T) const [with T = GLfloat]' used but never defined
include/GLVector.h:536: warning: inline function `void
   GLVector4<T>::glTranslate() const [with T = GLfloat]' used but never 
defined
include/GLVector.h:538: warning: inline function `void 
GLVector4<T>::glVertex()
   const [with T = GLfloat]' used but never defined
include/GLVector.h:540: warning: inline function `void 
GLVector4<T>::glNormal()
   const [with T = GLfloat]' used but never defined
error: command 'gcc' failed with exit status 1

I don't use bjam but distutil. But I believe thats not the problem. I really 
have no clue whats wrong. Maybe someone can help me. 

tnx and regards

marco 


From gaiacrtn at free.fr  Sat Dec  4 16:07:36 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Sat, 4 Dec 2004 16:07:36 +0100
Subject: [C++-sig] How to expose virtual function with default arguments in
	boost.python ?
Message-ID: <00a801c4da13$014e77d0$0200a8c0@lain>

I'm trying to fix a bug in Pyste regarding exposure of virtual function with
default arguments, but I can't figure out what is the correct code to
generate (e.g. this is a question regarding boost.python, not pyste).

I'm basically trying to expose the virtual member function 'set' of the
following code:

----
class VirtualNonCopyable {
public:
   virtual void set( const std::string &name_, int size_ = 10, int width_ =
12 ) {
      name = name_;
      size = size_;
      width = width_;
   }

   std::string name;
   int size;
   int width;
};

inline VirtualNonCopyable &getVirtualNonCopyable() {
   static VirtualNonCopyable instance;
   return instance;
}
----

Pyste generate the following binding code (full source attached):

----
    class_< VirtualNonCopyable, py::VirtualNonCopyable_Wrapper
>("VirtualNonCopyable", init<  >())
        .def("set", &VirtualNonCopyable::set,
&py::VirtualNonCopyable_Wrapper::default_set_3)
        .def("set", &py::VirtualNonCopyable_Wrapper::default_set_1)
        .def("set", &py::VirtualNonCopyable_Wrapper::default_set_2)
        .def(init< const VirtualNonCopyable& >())
        .def_readwrite("name", &VirtualNonCopyable::name)
        .def_readwrite("size", &VirtualNonCopyable::size)
        .def_readwrite("width", &VirtualNonCopyable::width)
    ;
----
Pyste is still using old-style polymorphism. default_set_1, default_set_2
and default_set_3 are methods forwarding to the base class implementation.
The binding for default_set_1 should be the one triggered by the python code
below.

The bug is demonstrated by the following python code:

object = getVirtualNonCopyable()   # Get a instance of VirtualNonCopyable
from C++
object.set( 'abc' )                             # use overloading resolution
to apply the default values

Which produces the following error:

    object.set( 'abc' )
Boost.Python.ArgumentError: Python argument types in
    VirtualNonCopyable.set(VirtualNonCopyable, str)
did not match C++ signature:
    set(struct py::VirtualNonCopyable_Wrapper {lvalue}, class
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> >, int)
    set(struct py::VirtualNonCopyable_Wrapper {lvalue}, class
std::basic_string<char,struct std::char_traits<char>,class
 std::allocator<char> >)
    set(struct py::VirtualNonCopyable_Wrapper {lvalue}, class
std::basic_string<char,struct std::char_traits<char>,class
 std::allocator<char> >, int, int)
    set(class VirtualNonCopyable {lvalue}, class
std::basic_string<char,struct std::char_traits<char>,class std::allocat
or<char> >, int, int)

The issue only occurs when the object is returned from C++ and all the
parameters are not specified. The following python code works correctly:
object = getVirtualNonCopyable()
object.set( 'abc', 1, 2 )                        # works with all parameters
specified

object = VirtualNonCopyable()
object.set( 'abc' )                                # works on instance
created in python

I couldn't find any example of combining default argument handling with
default virtual method implementation. Does anyone know how to do so ?

Baptiste.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: main.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041204/eaf38169/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestOverload.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041204/eaf38169/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestOverload.h
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041204/eaf38169/attachment-0002.txt>

From dave at boost-consulting.com  Sun Dec  5 00:18:15 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 04 Dec 2004 18:18:15 -0500
Subject: [C++-sig] Re: How to expose virtual function with default arguments
 in boost.python ?
In-Reply-To: <00a801c4da13$014e77d0$0200a8c0@lain>
References: <00a801c4da13$014e77d0$0200a8c0@lain>
Message-ID: <cotgkh$jql$1@sea.gmane.org>

Baptiste Lepilleur wrote:

 > I'm basically trying to expose the virtual member function
 > 'set' of the following code:
 >
 > ----
 > class VirtualNonCopyable {
 > public:
 >    virtual void set( const std::string &name_, int size_ = 10, int 
width_ =
 > 12 ) {
 >       name = name_;
 >       size = size_;
 >       width = width_;
 >    }
 >
 >    std::string name;
 >    int size;
 >    int width;
 > };
 >
 > inline VirtualNonCopyable &getVirtualNonCopyable() {
 >    static VirtualNonCopyable instance;
 >    return instance;
 > }
 > ----
 >
 > Pyste generate the following binding code (full source attached):
 >
 > ----
 >     class_< VirtualNonCopyable, py::VirtualNonCopyable_Wrapper
 >
 >>("VirtualNonCopyable", init<  >())
 >
 >         .def("set", &VirtualNonCopyable::set,
 > &py::VirtualNonCopyable_Wrapper::default_set_3)
 >         .def("set", &py::VirtualNonCopyable_Wrapper::default_set_1)
 >         .def("set", &py::VirtualNonCopyable_Wrapper::default_set_2)

<snip>

 > ----
 > Pyste is still using old-style polymorphism. default_set_1, 
default_set_2
 > and default_set_3 are methods forwarding to the base class 
implementation.
 > The binding for default_set_1 should be the one triggered by the 
python code
 > below.
 >
 > The bug is demonstrated by the following python code:
 >
 > object = getVirtualNonCopyable()   # Get a instance of 
VirtualNonCopyable
 > from C++
 > object.set( 'abc' )                # use overloading resolution to 
apply the default values

Right.  The problem here is that all the overloads for handling
default arguments take a first argument of

    py::VirtualNonCopyable_Wrapper {lvalue}

(because they are member functions of VirtualNonCopyable_Wrapper)
but the object you're creating in C++ is only of type

   VirtualNonCopyable {lvalue}

You can see most of this in the overload set described in the error
message below, if you look carefully (using an initial type
other than std::string would make it clearer).

So one way to make it work is to add some functions that can be
called for VirtualNonCopyable objects:

   void set_2(VirtualNonCopyable& self, std::string s, int p1)
   { self.set(s,p1); }

   void set_1(VirtualNonCopyable&& self, std::string s)
   { self.set(s); }

And before any of the other defs (so if the object is actually a
VirtualNonCopyable_Wrapper the other overloads will take
priority), but in any order, you do:

      .def("set", set_1)
      .def("set", set_2)

Alternatively, you should be able to avoid defining any helper
functions this way:

      .def(
          "set"
        , make_function(
              &VirtualNonCopyable::set
            , mpl::vector<void,std::string,int,int>())
      )
      .def(
          "set"
        , make_function(
              &VirtualNonCopyable::set
            , mpl::vector<void,std::string,int>())
      )

Incidentally, all this applies just as well even after you fix
Pyste to use new-style polymorphism.

HTH,

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From gaiacrtn at free.fr  Sun Dec  5 12:30:55 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Sun, 5 Dec 2004 12:30:55 +0100
Subject: [C++-sig] Re: How to expose virtual function with default
	arguments in boost.python ?
References: <00a801c4da13$014e77d0$0200a8c0@lain> <cotgkh$jql$1@sea.gmane.org>
Message-ID: <012801c4dabd$e2cb60b0$0200a8c0@lain>


----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Sunday, December 05, 2004 12:18 AM
Subject: [C++-sig] Re: How to expose virtual function with default arguments
in boost.python ?


> Baptiste Lepilleur wrote:
> [...]
>
> Right.  The problem here is that all the overloads for handling
> default arguments take a first argument of
>
>     py::VirtualNonCopyable_Wrapper {lvalue}
>
> (because they are member functions of VirtualNonCopyable_Wrapper)
> but the object you're creating in C++ is only of type
>
>    VirtualNonCopyable {lvalue}
>
> You can see most of this in the overload set described in the error
> message below, if you look carefully (using an initial type
> other than std::string would make it clearer).

I though it might be something along those lines, but I was confused by the
following things:
- the type dumped on the overloading error message is always the C++ type,
even if the object is actually the wrapper
- the wrapper overload are displayed even though they are not taken in
account in the overload resolution.

Not a major issue, but somewhat confusing...

> So one way to make it work is to add some functions that can be
> called for VirtualNonCopyable objects:
>
>    void set_2(VirtualNonCopyable& self, std::string s, int p1)
>    { self.set(s,p1); }
>
>    void set_1(VirtualNonCopyable&& self, std::string s)
>    { self.set(s); }
>
> And before any of the other defs (so if the object is actually a
> VirtualNonCopyable_Wrapper the other overloads will take
> priority), but in any order, you do:
>
>       .def("set", set_1)
>       .def("set", set_2)

This works great. It basically replace the default_set_1/2 binding, right ?

> Alternatively, you should be able to avoid defining any helper
> functions this way:
>
>       .def(
>           "set"
>         , make_function(
>               &VirtualNonCopyable::set
>             , mpl::vector<void,std::string,int,int>())
>       )
>       .def(
>           "set"
>         , make_function(
>               &VirtualNonCopyable::set
>             , mpl::vector<void,std::string,int>())
>       )

Could get that version to compile, even after adding the (missing ?) policy:
      .def(
          "set"
        , make_function(
              &VirtualNonCopyable::set
            , boost::python::default_call_policies()
            , boost::mpl::vector<void,std::string,int,int>())
      )

Here is the lastest error message...

include\boost\python\detail\invoke.hpp(94) : error C2647: '.*' : cannot
dereference a 'boost::details::compressed_pair_i
mp<T1,T2,Version>::first_type ' on a 'boost::remove_cv<T>::type'
        with
        [
            T1=void (__thiscall VirtualNonCopyable::* )(const std::string
&,int,int),
            T2=boost::python::default_call_policies,
            Version=2
        ]
        and
        [

T=boost::mpl::v_iter<boost::mpl::vector4<void,std::string,int,int>::type,1>:
:type
        ]

Both solutions are of similar complexity to implement in pyste, so it's not
an issue (though, the mpl::vector one avoid a forwarding function, right ?).

> Incidentally, all this applies just as well even after you fix
> Pyste to use new-style polymorphism.

I'll probably look into adding new-style polymorphism sometime in the
future. For now, I'm focusing on fixing all the bugs and getting everything
to work...

Thanks for helping,
Baptiste.



From dave at boost-consulting.com  Sun Dec  5 13:46:17 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 05 Dec 2004 07:46:17 -0500
Subject: [C++-sig] Re: How to expose virtual function with default arguments
 in boost.python ?
In-Reply-To: <012801c4dabd$e2cb60b0$0200a8c0@lain>
References: <00a801c4da13$014e77d0$0200a8c0@lain> <cotgkh$jql$1@sea.gmane.org>
	<012801c4dabd$e2cb60b0$0200a8c0@lain>
Message-ID: <couvvj$h7$1@sea.gmane.org>

Baptiste Lepilleur wrote:
> ----- Original Message ----- 
> From: "David Abrahams" <dave at boost-consulting.com>
> To: <c++-sig at python.org>
> Sent: Sunday, December 05, 2004 12:18 AM
> Subject: [C++-sig] Re: How to expose virtual function with default arguments
> in boost.python ?
> 
> 
> 
>>Baptiste Lepilleur wrote:
>>[...]
>>
>>Right.  The problem here is that all the overloads for handling
>>default arguments take a first argument of
>>
>>    py::VirtualNonCopyable_Wrapper {lvalue}
>>
>>(because they are member functions of VirtualNonCopyable_Wrapper)
>>but the object you're creating in C++ is only of type
>>
>>   VirtualNonCopyable {lvalue}
>>
>>You can see most of this in the overload set described in the error
>>message below, if you look carefully (using an initial type
>>other than std::string would make it clearer).
> 
> 
> I though it might be something along those lines, but I was confused by the
> following things:
> - the type dumped on the overloading error message is always the C++ type,
> even if the object is actually the wrapper

What object?  There are quite a few objects running around here.  Also 
what do you mean by "the wrapper?"

> - the wrapper overload are displayed even though they are not taken in
> account in the overload resolution.

All displayed overloads are taken into account.

> Not a major issue, but somewhat confusing...
> 
> 
>>So one way to make it work is to add some functions that can be
>>called for VirtualNonCopyable objects:
>>
>>   void set_2(VirtualNonCopyable& self, std::string s, int p1)
>>   { self.set(s,p1); }
>>
>>   void set_1(VirtualNonCopyable&& self, std::string s)
>>   { self.set(s); }
>>
>>And before any of the other defs (so if the object is actually a
>>VirtualNonCopyable_Wrapper the other overloads will take
>>priority), but in any order, you do:
>>
>>      .def("set", set_1)
>>      .def("set", set_2)
> 
> 
> This works great. It basically replace the default_set_1/2 binding, right ?

Uhm... yes, as a matter of fact I think it does.  Somehow I failed to 
imagine that.

>>Alternatively, you should be able to avoid defining any helper
>>functions this way:
>>
>>      .def(
>>          "set"
>>        , make_function(
>>              &VirtualNonCopyable::set
>>            , mpl::vector<void,std::string,int,int>())
>>      )
>>      .def(
>>          "set"
>>        , make_function(
>>              &VirtualNonCopyable::set
>>            , mpl::vector<void,std::string,int>())
>>      )
> 
> 
> Could get that version to compile, even after adding the (missing ?) policy:
>       .def(
>           "set"
>         , make_function(
>               &VirtualNonCopyable::set
>             , boost::python::default_call_policies()
>             , boost::mpl::vector<void,std::string,int,int>())
>       )
> 
> Here is the lastest error message...
> 
> include\boost\python\detail\invoke.hpp(94) : error C2647: '.*' : cannot
> dereference a 'boost::details::compressed_pair_i
> mp<T1,T2,Version>::first_type ' on a 'boost::remove_cv<T>::type'
>         with
>         [
>             T1=void (__thiscall VirtualNonCopyable::* )(const std::string
> &,int,int),
>             T2=boost::python::default_call_policies,
>             Version=2
>         ]
>         and
>         [
> 
> T=boost::mpl::v_iter<boost::mpl::vector4<void,std::string,int,int>::type,1>:
> :type
>         ]

Uhm, right.  Insert "VirtualNonCopyable&," after "void," in each of 
those vectors.  Sorry.

> Both solutions are of similar complexity to implement in pyste, so it's not
> an issue (though, the mpl::vector one avoid a forwarding function, right ?).

Correct.  Although if those forwarding functions are inline functions it 
may not make any difference.

>>Incidentally, all this applies just as well even after you fix
>>Pyste to use new-style polymorphism.
> 
> 
> I'll probably look into adding new-style polymorphism sometime in the
> future. For now, I'm focusing on fixing all the bugs and getting everything
> to work...

Are you taking over maintainership of Pyste?  I haven't heard from Bruno 
in a long time.

> Thanks for helping,

Thank you!

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From yaoheling at yahoo.com  Sun Dec  5 15:06:16 2004
From: yaoheling at yahoo.com (Yao Heling)
Date: Sun, 5 Dec 2004 06:06:16 -0800 (PST)
Subject: [C++-sig] a working example of wrapping an instantiated c++ object
Message-ID: <20041205140616.37699.qmail@web40821.mail.yahoo.com>


Hi,

As I'm rather new to boost::python, I have spent quite
some time to find
solutions to this problem. I havn't spotted similar
examples in the
libs/python/test dir. By the way, it's based on a
previous mailing list
discussion; what I did was basically put everything
together. (a cpp
file and a py test file).

Could someone pls add it to the example dir of boost
if there's no such
example?

Regards,

Joseph H. Yao





		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: object_only.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041205/0852f181/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: object_only.py
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041205/0852f181/attachment-0001.txt>

From gaiacrtn at free.fr  Sun Dec  5 17:33:08 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Sun, 5 Dec 2004 17:33:08 +0100
Subject: [C++-sig] Re: How to expose virtual function with default
	arguments in boost.python ?
References: <00a801c4da13$014e77d0$0200a8c0@lain>
	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>
	<couvvj$h7$1@sea.gmane.org>
Message-ID: <016301c4dae8$1acfcb70$0200a8c0@lain>

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Sunday, December 05, 2004 1:46 PM
Subject: [C++-sig] Re: How to expose virtual function with default arguments
in boost.python ?


> Baptiste Lepilleur wrote:
> > ----- Original Message ----- 
> > From: "David Abrahams" <dave at boost-consulting.com>
> > To: <c++-sig at python.org>
> > Sent: Sunday, December 05, 2004 12:18 AM
> > Subject: [C++-sig] Re: How to expose virtual function with default
arguments
> > in boost.python ?
> >
> >
> >
> >>Baptiste Lepilleur wrote:
> >>[...]
> >>
> >>Right.  The problem here is that all the overloads for handling
> >>default arguments take a first argument of
> >>
> >>    py::VirtualNonCopyable_Wrapper {lvalue}
> >>
> >>(because they are member functions of VirtualNonCopyable_Wrapper)
> >>but the object you're creating in C++ is only of type
> >>
> >>   VirtualNonCopyable {lvalue}
> >>
> >>You can see most of this in the overload set described in the error
> >>message below, if you look carefully (using an initial type
> >>other than std::string would make it clearer).
> >
> >
> > I though it might be something along those lines, but I was confused by
the
> > following things:
> > - the type dumped on the overloading error message is always the C++
type,
> > even if the object is actually the wrapper
>
> What object?  There are quite a few objects running around here.  Also
> what do you mean by "the wrapper?"
>
> > - the wrapper overload are displayed even though they are not taken in
> > account in the overload resolution.
>
> All displayed overloads are taken into account.

Sorry, I was not clear enough. Here is an example of overload error message
generated by the following python code:
object = VirtualNonCopyable()
object.set( 1 )

Boost.Python.ArgumentError: Python argument types in
    VirtualNonCopyable.set(VirtualNonCopyable, int)
did not match C++ signature:
[...]

There is nothing indicating that the VirtualNonCopyable is actually a
VirtualNonCopyable_Wrapper (the error message header is the same as when
using the object returned by getVirtualNonCopyable() ).

The issue I was refering about the error message is that when the member
function is called on the C++ object (VirtualNonCopyable {lvalue}) it also
displays overload for (py::VirtualNonCopyable_Wrapper {lvalue}) which are
not compatible.

> > Not a major issue, but somewhat confusing...
> >
> >
> >>So one way to make it work is to add some functions that can be
> >>called for VirtualNonCopyable objects:
> >>
> >>   void set_2(VirtualNonCopyable& self, std::string s, int p1)
> >>   { self.set(s,p1); }
> >>
> >>   void set_1(VirtualNonCopyable&& self, std::string s)
> >>   { self.set(s); }
> >>
> >>And before any of the other defs (so if the object is actually a
> >>VirtualNonCopyable_Wrapper the other overloads will take
> >>priority), but in any order, you do:
> >>
> >>      .def("set", set_1)
> >>      .def("set", set_2)
> >
> >
> > This works great. It basically replace the default_set_1/2 binding,
right ?
>
> Uhm... yes, as a matter of fact I think it does.  Somehow I failed to
> imagine that.

I implemented this in pyste, but realized when running more complex tests
that it doesn't work well with call policy:
you can not wrap a virtual method with a return_internal_reference< 1 > this
ways (it result in run-time error about dangling pointer).

> >>Alternatively, you should be able to avoid defining any helper
> >>functions this way:
> >>
> >>      .def(
> >>          "set"
> >>        , make_function(
> >>              &VirtualNonCopyable::set
> >>            , mpl::vector<void,std::string,int,int>())
> >>      )
> [...]
> Uhm, right.  Insert "VirtualNonCopyable&," after "void," in each of
> those vectors.  Sorry.

Still can't get this to compile. Here is the code:
  .def( "set"
       , make_function(
            &VirtualNonCopyable::set
            , boost::python::default_call_policies()
            , boost::mpl::vector<void,VirtualNonCopyable&,std::string>())
     )

And the top-most error message (full error attached):
include\boost\python\detail\invoke.hpp(94) : error C2198:
'boost::details::compressed_pair_imp<T1,T2,Version>::first_typ
e ' : too few arguments for call through pointer-to-function
        with
        [
            T1=void (__thiscall VirtualNonCopyable::* )(const std::string
&,int,int),
            T2=boost::python::default_call_policies,
            Version=2
        ]

The only way to get it to compile is to specify all the arguments...

make_function and the signature trick seems to be the way to go for a
generic solution  since we can use the call policy provided by the user.

> Are you taking over maintainership of Pyste?  I haven't heard from Bruno
> in a long time.

It wouldn't be reasonable, I have already trouble finding enough time for
all my project. But I will certainly contribute patches, and Bruno seems to
integrate them as time go (with a certain delay tough ;-) ).

Baptiste.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mplvector_compiler_error.txt
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041205/91162fab/attachment.txt>

From dave at boost-consulting.com  Sun Dec  5 18:05:12 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 05 Dec 2004 12:05:12 -0500
Subject: [C++-sig] Re: How to expose virtual function with default arguments
 in boost.python ?
In-Reply-To: <016301c4dae8$1acfcb70$0200a8c0@lain>
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org>
	<016301c4dae8$1acfcb70$0200a8c0@lain>
Message-ID: <covf54$1mq$1@sea.gmane.org>

Baptiste Lepilleur wrote:

 > Sorry, I was not clear enough. Here is an example of overload error 
message
 > generated by the following python code:
 > object = VirtualNonCopyable()
 > object.set( 1 )
 >
 > Boost.Python.ArgumentError: Python argument types in
 >     VirtualNonCopyable.set(VirtualNonCopyable, int)
 > did not match C++ signature:
 > [...]
 >
 > There is nothing indicating that the VirtualNonCopyable is actually a
 > VirtualNonCopyable_Wrapper

It is not.  Note that the message says "Python argument types."
VirtualNonCopyable_Wrapper is a C++ type.

 > (the error message header is the same as when
 > using the object returned by getVirtualNonCopyable() ).
 >
 > The issue I was refering about the error message is that when the member
 > function is called on the C++ object (VirtualNonCopyable {lvalue}) it 
also
 > displays overload for (py::VirtualNonCopyable_Wrapper {lvalue}) which 
are
 > not compatible.

Yes, they are not compatible.  But then, none of the overloads
are compatible by definition.  If any were compatible, you
wouldn't be seeing an error message.

 >>>Not a major issue, but somewhat confusing...

I don't see how any other choices I could make would make it any
less confusing, other than possibly attempting to display the
C++ object types underlying any Python object.

 > I implemented this in pyste, but realized when running more complex 
tests
 > that it doesn't work well with call policy:
 > you can not wrap a virtual method with a return_internal_reference< 1 
 > this
 > ways (it result in run-time error about dangling pointer).

Too many missing details for me to imagine it.  If you could
reduce it to an absolute minimum case that would be very helpful.

 >>>>Alternatively, you should be able to avoid defining any helper
 >>>>functions this way:
 >>>>
 >>>>     .def(
 >>>>         "set"
 >>>>       , make_function(
 >>>>             &VirtualNonCopyable::set
 >>>>           , mpl::vector<void,std::string,int,int>())
 >>>>     )
 >>
 >>[...]
 >>Uhm, right.  Insert "VirtualNonCopyable&," after "void," in each of
 >>those vectors.  Sorry.
 >
 >
 > Still can't get this to compile. Here is the code:
 >   .def( "set"
 >        , make_function(
 >             &VirtualNonCopyable::set
 >             , boost::python::default_call_policies()
 >             , 
boost::mpl::vector<void,VirtualNonCopyable&,std::string>())
 >      )
 >
 > And the top-most error message (full error attached):
 > include\boost\python\detail\invoke.hpp(94) : error C2198:
 > 'boost::details::compressed_pair_imp<T1,T2,Version>::first_typ
 > e ' : too few arguments for call through pointer-to-function
 >         with
 >         [
 >             T1=void (__thiscall VirtualNonCopyable::* )(const 
std::string
 > &,int,int),
 >             T2=boost::python::default_call_policies,
 >             Version=2
 >         ]

Argh.  Of course you're right.

 > The only way to get it to compile is to specify all the arguments...
 >
 > make_function and the signature trick seems to be the way to go for a
 > generic solution  since we can use the call policy provided by the user.

That's not going to work if you want overloads that take fewer
arguments (the whole point of this exercise).

 >>Are you taking over maintainership of Pyste?  I haven't heard from Bruno
 >>in a long time.
 >
 > It wouldn't be reasonable, I have already trouble finding
 > enough time for all my project. But I will certainly contribute
 > patches, and Bruno seems to integrate them as time go (with a
 > certain delay tough ;-) ).

Okay, thanks.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Sun Dec  5 18:24:32 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 05 Dec 2004 12:24:32 -0500
Subject: [C++-sig] Re: a working example of wrapping an instantiated c++
	object
In-Reply-To: <20041205140616.37699.qmail@web40821.mail.yahoo.com>
References: <20041205140616.37699.qmail@web40821.mail.yahoo.com>
Message-ID: <covg9c$4cd$1@sea.gmane.org>

Yao Heling wrote:
 > Hi,
 >
 > As I'm rather new to boost::python, I have spent quite
 > some time to find
 > solutions to this problem. I havn't spotted similar
 > examples in the
 > libs/python/test dir. By the way, it's based on a
 > previous mailing list
 > discussion; what I did was basically put everything
 > together. (a cpp
 > file and a py test file).
 >
 > Could someone pls add it to the example dir of boost
 > if there's no such
 > example?


I'd be happy to, but...

 > ------------------------------------------------------------------------
 >
 > //based on c++sig mailing list discussions
 > //http://thread.gmane.org/gmane.comp.python.c++/6980
 >
 > //It's often quite common, especially in gui programs, to export an 
instantiated c++ object to python instead of the class. e.g. to add 
scripting to an gui program, it's sometimes necessary to export the 
window handle to python
 >
 > #include <boost/python.hpp>
 > namespace bp = boost::python;
 >
 > class A {
 >     public:
 >         A(int x): _x(x) {}
 >         int f() { return 100; }
 >         int value() {return _x;}
 >     private:
 >         int _x;
 > };
 >
 > // this is the object to export
 > A a(99);
 >
 > // a helper function
 > A* get_existing()
 > {
 >     return &a;
 > }
 >
 > //turn a c++ func to a boost::python func
 > bp::object py_get_existing = bp::make_function(
 >         &get_existing,
 >         bp::return_value_policy<bp::reference_existing_object>()
 >         );
 >
 >
 > BOOST_PYTHON_MODULE(object_only_ext)
 > {
 >     //wrapping the functions of A as usual
 >     bp::class_<A, A*, boost::noncopyable> classA("A",bp::no_init);
 >
 >     classA
 >         .def("f", &A::f)
 >         .def("value", &A::value);
 >
 >     //gain access to a boost::python object to wrap it
 >     bp::object py_a = py_get_existing();
 >     bp::def("a", py_a);

Doesn't something like:

       bp::scope().attr("a") = object(ptr(&a));

Work just as well, with no need to build wierd helper functions?

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From gaiacrtn at free.fr  Mon Dec  6 00:09:52 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Mon, 6 Dec 2004 00:09:52 +0100
Subject: [C++-sig] Re: How to expose virtual function with default
	arguments in boost.python ?
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain>
	<covf54$1mq$1@sea.gmane.org>
Message-ID: <001301c4db1f$882742c0$0200a8c0@lain>

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Sunday, December 05, 2004 6:05 PM
Subject: [C++-sig] Re: How to expose virtual function with default arguments
in boost.python ?


> Baptiste Lepilleur wrote:
>
>  > Sorry, I was not clear enough. Here is an example of overload error
> message
>  > generated by the following python code:
>  > object = VirtualNonCopyable()
>  > object.set( 1 )
>  >
>  > Boost.Python.ArgumentError: Python argument types in
>  >     VirtualNonCopyable.set(VirtualNonCopyable, int)
>  > did not match C++ signature:
>  > [...]
>  >
>  > There is nothing indicating that the VirtualNonCopyable is actually a
>  > VirtualNonCopyable_Wrapper
>
> It is not.  Note that the message says "Python argument types."
> VirtualNonCopyable_Wrapper is a C++ type.

Clearly a proof that I can't read :-(

>  > (the error message header is the same as when
>  > using the object returned by getVirtualNonCopyable() ).
>  >
>  > The issue I was refering about the error message is that when the
member
>  > function is called on the C++ object (VirtualNonCopyable {lvalue}) it
> also
>  > displays overload for (py::VirtualNonCopyable_Wrapper {lvalue}) which
> are
>  > not compatible.
>
> Yes, they are not compatible.  But then, none of the overloads
> are compatible by definition.  If any were compatible, you
> wouldn't be seeing an error message.
>
>  >>>Not a major issue, but somewhat confusing...
>
> I don't see how any other choices I could make would make it any
> less confusing, other than possibly attempting to display the
> C++ object types underlying any Python object.

Yes that would be the only way. Though, I'm not sure it's worth the time.
This should be optional as well, since it's only really useful when
developping some python binding.

>  > I implemented this in pyste, but realized when running more complex
> tests
>  > that it doesn't work well with call policy:
>  > you can not wrap a virtual method with a return_internal_reference< 1
>  > this
>  > ways (it result in run-time error about dangling pointer).
>
> Too many missing details for me to imagine it.  If you could
> reduce it to an absolute minimum case that would be very helpful.

Well, I hoped there was a simple solution with the make_function tricks. Too
bad it can't be used.

Anyway attached is the new simplified test case.



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: main.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041206/0a39feae/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestOverload.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041206/0a39feae/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestOverload.h
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041206/0a39feae/attachment-0002.txt>

From gaiacrtn at free.fr  Mon Dec  6 00:25:05 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Mon, 6 Dec 2004 00:25:05 +0100
Subject: [C++-sig] Re: How to expose virtual function with
	defaultarguments in boost.python ?
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain><covf54$1mq$1@sea.gmane.org>
	<001301c4db1f$882742c0$0200a8c0@lain>
Message-ID: <004501c4db21$a6da8900$0200a8c0@lain>


----- Original Message ----- 
From: "Baptiste Lepilleur" <gaiacrtn at free.fr>
To: "Development of Python/C++ integration" <c++-sig at python.org>
Sent: Monday, December 06, 2004 12:09 AM
Subject: Re: [C++-sig] Re: How to expose virtual function with
defaultarguments in boost.python ?


> ----- Original Message ----- 
> From: "David Abrahams" <dave at boost-consulting.com>
> To: <c++-sig at python.org>
> Sent: Sunday, December 05, 2004 6:05 PM
> Subject: [C++-sig] Re: How to expose virtual function with default
arguments
> in boost.python ?
>
>
> > Baptiste Lepilleur wrote:
> >
> >  > Sorry, I was not clear enough. Here is an example of overload error
> > message
> >  > generated by the following python code:
> >  > object = VirtualNonCopyable()
> >  > object.set( 1 )
> >  >
> >  > Boost.Python.ArgumentError: Python argument types in
> >  >     VirtualNonCopyable.set(VirtualNonCopyable, int)
> >  > did not match C++ signature:
> >  > [...]
> >  >
> >  > There is nothing indicating that the VirtualNonCopyable is actually a
> >  > VirtualNonCopyable_Wrapper
> >
> > It is not.  Note that the message says "Python argument types."
> > VirtualNonCopyable_Wrapper is a C++ type.
>
> Clearly a proof that I can't read :-(
>
> >  > (the error message header is the same as when
> >  > using the object returned by getVirtualNonCopyable() ).
> >  >
> >  > The issue I was refering about the error message is that when the
> member
> >  > function is called on the C++ object (VirtualNonCopyable {lvalue}) it
> > also
> >  > displays overload for (py::VirtualNonCopyable_Wrapper {lvalue}) which
> > are
> >  > not compatible.
> >
> > Yes, they are not compatible.  But then, none of the overloads
> > are compatible by definition.  If any were compatible, you
> > wouldn't be seeing an error message.
> >
> >  >>>Not a major issue, but somewhat confusing...
> >
> > I don't see how any other choices I could make would make it any
> > less confusing, other than possibly attempting to display the
> > C++ object types underlying any Python object.
>
> Yes that would be the only way. Though, I'm not sure it's worth the time.
> This should be optional as well, since it's only really useful when
> developping some python binding.
>
> >  > I implemented this in pyste, but realized when running more complex
> > tests
> >  > that it doesn't work well with call policy:
> >  > you can not wrap a virtual method with a return_internal_reference< 1
> >  > this
> >  > ways (it result in run-time error about dangling pointer).
> >
> > Too many missing details for me to imagine it.  If you could
> > reduce it to an absolute minimum case that would be very helpful.
>
> Well, I hoped there was a simple solution with the make_function tricks.
Too
> bad it can't be used.
>
> Anyway attached is the new simplified test case.

Sorry, I messed up with the keyboard resulting in the mail begin sent too
early.

Here is the result of the python test:

>>> from testvirtualdefarg_ import *
>>> object = VirtualReturnValuePolicy()
>>> object.set( 'dummy', 2, 3 )
<testvirtualdefarg_.ValueHolder object at 0x007E1BC8>
>>> print object.size
2
>>> object.set( 'dummy' )
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ReferenceError: Attempt to return dangling pointer to object of type: struct
ValueHolder

The call to the virtual member function set() executes correctly if all the
parameters are passed, but fails with the above error message if we used the
overload defined to handle default parameters.

VirtualReturnValuePolicy  is rougly defined as follow:

class VirtualReturnValuePolicy {
//...
   virtual ValueHolder *set( const std::string &name_, int size_ = 10, int
width_ = 12 ) {
    return &value;
   }

 ValueHolder value;
};

And exposed like this:

static ValueHolder*
VirtualReturnValuePolicy_Wrapper_set_1(VirtualReturnValuePolicy &self, const
std::string& p0) {
    return self.set(p0);
}
//...

void Export_src_testvirtualdefarg_TestOverload()
{
    class_< VirtualReturnValuePolicy, py::VirtualReturnValuePolicy_Wrapper
>("VirtualReturnValuePolicy", init<  >())
        // Virtual Methods
        .def("set", py::VirtualReturnValuePolicy_Wrapper_set_1,
return_internal_reference< 1 >())
        .def("set", py::VirtualReturnValuePolicy_Wrapper_set_2,
return_internal_reference< 1 >())
        .def("set", &VirtualReturnValuePolicy::set,
&py::VirtualReturnValuePolicy_Wrapper::default_set,
return_internal_reference< 1 >())
//..

The free function VirtualReturnValuePolicy_Wrapper_set_1 is the one that
should handle the failing call.

Baptiste.



From dave at boost-consulting.com  Mon Dec  6 01:09:15 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 05 Dec 2004 19:09:15 -0500
Subject: [C++-sig] Re: How to expose virtual function with defaultarguments
 in boost.python ?
In-Reply-To: <004501c4db21$a6da8900$0200a8c0@lain>
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain><covf54$1mq$1@sea.gmane.org>	<001301c4db1f$882742c0$0200a8c0@lain>
	<004501c4db21$a6da8900$0200a8c0@lain>
Message-ID: <cp080a$hnp$1@sea.gmane.org>

Baptiste Lepilleur wrote:

>>>>object.set( 'dummy' )
> 
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ReferenceError: Attempt to return dangling pointer to object of type: struct
> ValueHolder
> 
> The call to the virtual member function set() executes correctly if all the
> parameters are passed, but fails with the above error message if we used the
> overload defined to handle default parameters.

This can be solved two ways:

1. Use new-style polymorphism.

and...

> VirtualReturnValuePolicy  is rougly defined as follow:
> 
> class VirtualReturnValuePolicy {
> //...
>    virtual ValueHolder *set( const std::string &name_, int size_ = 10, int
> width_ = 12 ) {
>     return &value;
>    }
> 
>  ValueHolder value;
> };
> 
> And exposed like this:
> 
> static ValueHolder*
> VirtualReturnValuePolicy_Wrapper_set_1(VirtualReturnValuePolicy &self, const
> std::string& p0) {
>     return self.set(p0);
> }
> //...

2. qualify your calls to  set:

	return self.VirtualReturnValuePolicy::set(p0);


HTH,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From yaoheling at yahoo.com  Mon Dec  6 06:13:48 2004
From: yaoheling at yahoo.com (Yao Heling)
Date: Sun, 5 Dec 2004 21:13:48 -0800 (PST)
Subject: [C++-sig] Re: a working example of wrapping an instantiated
	c++	object
Message-ID: <20041206051348.83293.qmail@web40809.mail.yahoo.com>


On Sun, Dec 05, 2004 at 12:24:32PM -0500, David
Abrahams wrote:
> 
> Doesn't something like:
> 
>       bp::scope().attr("a") = object(ptr(&a));
> 
> Work just as well, with no need to build wierd
helper functions?
> 
Thanks for the tip. I guess there might be people like
me working
better with minimal examples. so once again, I'm
attaching the modified
examples (much shorter too!). 

Regards,

Joseph 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: object_only.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041205/d7b0f824/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: object_only.py
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041205/d7b0f824/attachment-0001.txt>

From gaiacrtn at free.fr  Mon Dec  6 09:39:28 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Mon, 6 Dec 2004 09:39:28 +0100
Subject: [C++-sig] Re: How to expose virtual function with
	defaultarguments in boost.python ?
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain><covf54$1mq$1@sea.gmane.org>	<001301c4db1f$882742c0$0200a8c0@lain><004501c4db21$a6da8900$0200a8c0@lain>
	<cp080a$hnp$1@sea.gmane.org>
Message-ID: <007a01c4db6f$19aff030$0200a8c0@lain>

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Monday, December 06, 2004 1:09 AM
Subject: [C++-sig] Re: How to expose virtual function with defaultarguments
in boost.python ?


> Baptiste Lepilleur wrote:
>
> >>>>object.set( 'dummy' )
> >
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > ReferenceError: Attempt to return dangling pointer to object of type:
struct
> > ValueHolder
> >
> > The call to the virtual member function set() executes correctly if all
the
> > parameters are passed, but fails with the above error message if we used
the
> > overload defined to handle default parameters.
>
> This can be solved two ways:
>
> 1. Use new-style polymorphism.

Okay, it seems to work. Before I go and change pyste even more, can you
confirm that:
- new-style polymorphism can be used to replace old-style polymorphism in
all cases (there will not be any regressions, or some odd case where I
should preserve old-style polymorphism)
- the only things that need to be changed in the generated code are:
     (below, wrapper_class refer to a class like
VirtualReturnValuePolicy_Wrapper in my example)
    - wrapper_class inheritance: should derive from wrapper<BaseClass> in
addition to BaseClass.
    - constructor no longer need Py_Object * to be passed
    - overridden virtual method implementation need to be changed to use
'override'.
    - class_ template instation no longer need the base class, only the
wrapper_class.

Is there a performance hit if I always use the VC6/7 work-around in the
overridden virtual method ? (=> should I used the #if BOOST_WORKAROUND all
over the place ?)

> and...
>
> > VirtualReturnValuePolicy  is rougly defined as follow:
> >
> > class VirtualReturnValuePolicy {
> > //...
> >    virtual ValueHolder *set( const std::string &name_, int size_ = 10,
int
> > width_ = 12 ) {
> >     return &value;
> >    }
> >
> >  ValueHolder value;
> > };
> >
> > And exposed like this:
> >
> > static ValueHolder*
> > VirtualReturnValuePolicy_Wrapper_set_1(VirtualReturnValuePolicy &self,
const
> > std::string& p0) {
> >     return self.set(p0);
> > }
> > //...
>
> 2. qualify your calls to  set:
>
> return self.VirtualReturnValuePolicy::set(p0);

I don't see how this would change anything. self is already of type
'VirtualReturnValuePolicy &'.

>
>
> HTH,
It sure does !

Baptiste.



From dave at boost-consulting.com  Mon Dec  6 15:11:40 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 06 Dec 2004 09:11:40 -0500
Subject: [C++-sig] Re: How to expose virtual function with defaultarguments
 in boost.python ?
In-Reply-To: <007a01c4db6f$19aff030$0200a8c0@lain>
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain><covf54$1mq$1@sea.gmane.org>	<001301c4db1f$882742c0$0200a8c0@lain><004501c4db21$a6da8900$0200a8c0@lain>	<cp080a$hnp$1@sea.gmane.org>
	<007a01c4db6f$19aff030$0200a8c0@lain>
Message-ID: <cp1pbp$s76$1@sea.gmane.org>

Baptiste Lepilleur wrote:
> ----- Original Message ----- 
> From: "David Abrahams" <dave at boost-consulting.com>


>>1. Use new-style polymorphism.
> 
> 
> Okay, it seems to work. Before I go and change pyste even more, can you
> confirm that:
> - new-style polymorphism can be used to replace old-style polymorphism in
> all cases (there will not be any regressions, or some odd case where I
> should preserve old-style polymorphism)

As far as I know, it is always at least as good as the old style, and 
often better (faster, some dangling reference problems avoided).

> - the only things that need to be changed in the generated code are:
>      (below, wrapper_class refer to a class like
> VirtualReturnValuePolicy_Wrapper in my example)
>     - wrapper_class inheritance: should derive from wrapper<BaseClass> in
> addition to BaseClass.
>     - constructor no longer need Py_Object * to be passed
>     - overridden virtual method implementation need to be changed to use
> 'override'.
>     - class_ template instation no longer need the base class, only the
> wrapper_class.

Right.

> Is there a performance hit if I always use the VC6/7 work-around in the
> overridden virtual method ? (=> should I used the #if BOOST_WORKAROUND all
> over the place ?)

No performance hit; it's just uglier.  But if you need portable code, 
just use the vc6/7 method.

>>and...
>>
>>
>>>VirtualReturnValuePolicy  is rougly defined as follow:
>>>
>>>class VirtualReturnValuePolicy {
>>>//...
>>>   virtual ValueHolder *set( const std::string &name_, int size_ = 10,
> 
> int
> 
>>>width_ = 12 ) {
>>>    return &value;
>>>   }
>>>
>>> ValueHolder value;
>>>};
>>>
>>>And exposed like this:
>>>
>>>static ValueHolder*
>>>VirtualReturnValuePolicy_Wrapper_set_1(VirtualReturnValuePolicy &self,
> 
> const
> 
>>>std::string& p0) {
>>>    return self.set(p0);
>>>}
>>>//...
>>
>>2. qualify your calls to  set:
>>
>>return self.VirtualReturnValuePolicy::set(p0);
> 
> 
> I don't see how this would change anything. self is already of type
> 'VirtualReturnValuePolicy &'.

It prevents VirtualReturnValuePolicy_Wrapper::set from being called instead.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Mon Dec  6 15:26:51 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 06 Dec 2004 09:26:51 -0500
Subject: [C++-sig] Re: a working example of wrapping an instantiated c++
	object
In-Reply-To: <20041206051348.83293.qmail@web40809.mail.yahoo.com>
References: <20041206051348.83293.qmail@web40809.mail.yahoo.com>
Message-ID: <41B46C2B.9090608@boost-consulting.com>

Yao Heling wrote:
 > On Sun, Dec 05, 2004 at 12:24:32PM -0500, David
 > Abrahams wrote:
 >
 >>Doesn't something like:
 >>
 >>      bp::scope().attr("a") = object(ptr(&a));
 >>
 >>Work just as well, with no need to build wierd
 >
 > helper functions?
 >
 > Thanks for the tip. I guess there might be people like
 > me working
 > better with minimal examples. so once again, I'm
 > attaching the modified
 > examples (much shorter too!).

Two questions remain:

1. Does it work?

2. Is the test/ directory really the right place for this?
    That's not really supposed to be a repository of helpful
    examples.  Maybe this should go in the tutorial instead?

 > ------------------------------------------------------------------------
 >
 > //It's often quite common, especially in gui programs, to export an 
instantiated c++ object to python instead of the class. e.g. to add 
scripting to an gui program, it's sometimes necessary to export the 
window handle to python

This line is awfully long!  Code should be wrapped at 80 columns
or so.

 > #include <boost/python.hpp>
 > namespace bp = boost::python;
 >
 > class A {
 >     public:
 >         A(int x): _x(x) {}
 >         int f() { return 100; }
 >         int value() {return _x;}
 >     private:
 >         int _x;
 > };
 >
 > // this is the object to wrap and expose to python
 > A a(99);
 >
 > BOOST_PYTHON_MODULE(object_only_ext)
 > {
 >     //wrapping the member functions of A as usual
 >     bp::class_<A, A*, boost::noncopyable> classA("A",bp::no_init);
 >
 >     classA
 >         .def("f", &A::f)
 >         .def("value", &A::value);
 >
 >     //expose object a to python
 >     bp::scope().attr("a") = bp::object(bp::ptr(&a));
 > }
 >
 >
 >
 >
 > ------------------------------------------------------------------------
 >
 > '''
 >
 >>>>from object_only_ext import a
 >>>>a.f()
 >
 > 100
 >
 >>>>a.value()
 >
 > 99
 > '''
 >
 > def run(args = None):
 >     import sys
 >     import doctest
 >
 >     if args is not None:
 >         sys.argv = args
 >     return doctest.testmod(sys.modules.get(__name__))
 >
 > if __name__ == '__main__':
 >     print "running..."
 >     import sys
 >     status = run()[0]
 >     if (status == 0): print "Done."
 >     sys.exit(status)
 >
 >
 > ------------------------------------------------------------------------
 >
 > _______________________________________________
 > C++-sig mailing list
 > C++-sig at python.org
 > http://mail.python.org/mailman/listinfo/c++-sig


--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From qhf at oce.nl  Mon Dec  6 15:50:42 2004
From: qhf at oce.nl (Fred Houben)
Date: Mon, 6 Dec 2004 15:50:42 +0100
Subject: [C++-sig] Re: problem with overloaded address operator
References: <002e01c4d3c8$d6a89970$6bf6bc86@oce.nl>
	<upt20bnco.fsf@boost-consulting.com>
Message-ID: <005101c4dba2$f5d5c930$6bf6bc86@oce.nl>


----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Friday, November 26, 2004 5:12 PM
Subject: [C++-sig] Re: problem with overloaded address operator


> "Fred Houben" <qhf at oce.nl> writes:
>
> > I solved the problem by editing pointer_holder.hpp. Replacing Value*
> > p = &*this->m_p; with boost::addressof(*this->m_p);.
>
> That's exactly the right fix.
>
> > This way I avoid using the address operator. This works fine, but
> > maybe there's something I'm missing here, any input is welcome.
>
> You didn't miss anything.
>
> > I'm forced to uses boost.python for now 1.30.2, but is this problem
> > solved in other releases?
>
> It is not.  If you'd like to do a survey of the current CVS for uses
> of operator& and submit a patch that replaces all of them, I'd be
> happy to apply it, though.
>
> -- 
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>

I've downloaded the latest version of boost.python from the cvs server.
It seems that the problem of overloaded address operators shifts from
pointer_holder.hpp( v1.30.2) to to_python_indirect.hpp (latest cvs).
Replacing U* const p = &const_cast<U&>(x) with U* const p =
const_cast<U*>(boost::addressof(x)) fixes the problem.
I'm really not that familiar with the boost.python library, but this seems
the only change needed.
If someone can point out other possible problems with overloaded address
operators in boost.python, let me know.

I've included the patched to_python_indirect.hpp.

Fred Houben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pointer_holder.hpp
Type: application/octet-stream
Size: 5254 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041206/12d1814c/attachment.obj>

From nidoizo at yahoo.com  Mon Dec  6 16:12:02 2004
From: nidoizo at yahoo.com (Nicolas Fleury)
Date: Mon, 06 Dec 2004 10:12:02 -0500
Subject: [C++-sig] Re: Boost 1.32 and Python 2.4
In-Reply-To: <cokroj$g77$1@sea.gmane.org>
References: <cokroj$g77$1@sea.gmane.org>
Message-ID: <cp1ss2$8an$1@sea.gmane.org>

Nicolas Fleury wrote:
> Finally, does boost 1.32 supports Python 2.4?

So I guess there's no official answer.
If I plan to switch to 1.32 and 2.4, is it recommended to use a more 
recent version of Boost.Python?  Is the CVS version suppose to work with 
1.32?  Does it use the relatively "stable" public interface of other 
Boost libraries, or does it use some internals that may have changed 
since 1.32 branching?  Any help on direction to take is very appreciated.
Thx and regards,
Nicolas



From yaoheling at yahoo.com  Mon Dec  6 16:30:39 2004
From: yaoheling at yahoo.com (Yao Heling)
Date: Mon, 6 Dec 2004 07:30:39 -0800 (PST)
Subject: [C++-sig] Re: a working example of wrapping an instantiated
	c++	object
Message-ID: <20041206153039.35191.qmail@web40808.mail.yahoo.com>

On Mon, Dec 06, 2004 at 09:26:51AM -0500, David
Abrahams wrote:
> Two questions remain:
> 
> 1. Does it work?
> 

Yes. At least it passes the attached python test.

> 2. Is the test/ directory really the right place for
this?
>    That's not really supposed to be a repository of
helpful
>    examples.  Maybe this should go in the tutorial
instead?

Maybe test dir is not really the right place for this.
I just want to
put it somewhere centralized, so that people can find
it easily.
Tutorial would be a great place (or an example dir
somewhere with the
distribution so people can contribute more examples;
not all python
folks are good at c/c++ and I believe very small
examples do have a
place in boost::python). I spent hours searching for a
solution to my
very simple problem (wrapping an object), and I hate
anyone else to
repeat such efforts.

> This line is awfully long!  Code should be wrapped
at 80 columns
> or so.
> 
Thanks for the hint.


Best regards,

Joseph H. Yao



		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 


From Paul_Kunz at slac.stanford.edu  Mon Dec  6 16:37:49 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Mon, 6 Dec 2004 07:37:49 -0800
Subject: [C++-sig] Re: Boost 1.32 and Python 2.4
In-Reply-To: <cp1ss2$8an$1@sea.gmane.org> (message from Nicolas Fleury on Mon, 
	06 Dec 2004 10:12:02 -0500)
References: <cokroj$g77$1@sea.gmane.org> <cp1ss2$8an$1@sea.gmane.org>
Message-ID: <200412061537.iB6Fbni03327@libra3.slac.stanford.edu>

>>>>> On Mon, 06 Dec 2004 10:12:02 -0500, Nicolas Fleury <nidoizo at yahoo.com> said:

> Nicolas Fleury wrote:
>> Finally, does boost 1.32 supports Python 2.4?

> So I guess there's no official answer.  If I plan to switch to 1.32
> and 2.4, is it recommended to use a more recent version of
> Boost.Python?  Is the CVS version suppose to work with 1.32?  Does
> it use the relatively "stable" public interface of other Boost
> libraries, or does it use some internals that may have changed since
> 1.32 branching?  Any help on direction to take is very appreciated.
> Thx and regards, Nicolas

   I switched to boost 1.32.0 and Python 2.4 with no problems.   I
least, I think I did, but did not get the warnings about
_POSIX_C_SOURCE when I compiled boost.   This makes me think that
maybe seting the environment variable PYTHON_VERSION to 2.4 didn't
actually work.   I don't know how to verify that boost really did
compile with Python 2.4 installed in /usr/local instead of Python 2.2
in /usr.



From dave at boost-consulting.com  Mon Dec  6 16:58:33 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 06 Dec 2004 10:58:33 -0500
Subject: [C++-sig] Re: a working example of wrapping an instantiated c++
	object
In-Reply-To: <20041206153039.35191.qmail@web40808.mail.yahoo.com>
References: <20041206153039.35191.qmail@web40808.mail.yahoo.com>
Message-ID: <cp1vk7$ham$1@sea.gmane.org>

Yao Heling wrote:
 > On Mon, Dec 06, 2004 at 09:26:51AM -0500, David
 > Abrahams wrote:
 >
 >>Two questions remain:
 >>
 >>1. Does it work?
 >>
 >
 > Yes. At least it passes the attached python test.
 >
 >
 >>2. Is the test/ directory really the right place for this?
 >
 >>   That's not really supposed to be a repository of helpful
 >>   examples.  Maybe this should go in the tutorial instead?
 >
 > Maybe test dir is not really the right place for this.  I just
 > want to put it somewhere centralized, so that people can find
 > it easily.  Tutorial would be a great place

Joel, can you incorporate this in the tutorial somewhere?

 > (or an example dir
 > somewhere with the distribution so people can contribute more
 > examples;

Would http://www.python.org/cgi-bin/moinmoin/boost_2epython be a
good place for that?

 > not all python folks are good at c/c++ and I believe very small
 > examples do have a place in boost::python).

I agree.

 > I spent hours searching for a solution to my very simple
 > problem (wrapping an object), and I hate anyone else to repeat
 > such efforts.

I understand.  The documentation should be better, for sure.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Mon Dec  6 16:51:21 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 06 Dec 2004 10:51:21 -0500
Subject: [C++-sig] Re: Boost 1.32 and Python 2.4
In-Reply-To: <200412061537.iB6Fbni03327@libra3.slac.stanford.edu>
References: <cokroj$g77$1@sea.gmane.org> <cp1ss2$8an$1@sea.gmane.org>
	<200412061537.iB6Fbni03327@libra3.slac.stanford.edu>
Message-ID: <cp1v6m$fhs$2@sea.gmane.org>

Paul F. Kunz wrote:
>>>>>> On Mon, 06 Dec 2004 10:12:02 -0500, Nicolas Fleury
>>>>>> <nidoizo at yahoo.com> said:
> 
> 
>> Nicolas Fleury wrote:
>> 
>>> Finally, does boost 1.32 supports Python 2.4?
> 
> 
>> So I guess there's no official answer.  If I plan to switch to 1.32
>>  and 2.4, is it recommended to use a more recent version of 
>> Boost.Python?  Is the CVS version suppose to work with 1.32?  Does 
>> it use the relatively "stable" public interface of other Boost 
>> libraries, or does it use some internals that may have changed
>> since 1.32 branching?  Any help on direction to take is very
>> appreciated. Thx and regards, Nicolas
> 
> 
> I switched to boost 1.32.0 and Python 2.4 with no problems.   I 
> least, I think I did, but did not get the warnings about 
> _POSIX_C_SOURCE when I compiled boost.   This makes me think that 
> maybe seting the environment variable PYTHON_VERSION to 2.4 didn't 
> actually work.   I don't know how to verify that boost really did 
> compile with Python 2.4 installed in /usr/local instead of Python 2.2
>  in /usr.

You can always run bjam with -n to see what command lines will be issued 
(and -a to rebuild everything).

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Mon Dec  6 17:06:04 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 06 Dec 2004 11:06:04 -0500
Subject: [C++-sig] Re: problem with overloaded address operator
In-Reply-To: <005101c4dba2$f5d5c930$6bf6bc86@oce.nl>
References: <002e01c4d3c8$d6a89970$6bf6bc86@oce.nl>	<upt20bnco.fsf@boost-consulting.com>
	<005101c4dba2$f5d5c930$6bf6bc86@oce.nl>
Message-ID: <cp2029$j03$1@sea.gmane.org>

Fred Houben wrote:

> I've downloaded the latest version of boost.python from the cvs server.
> It seems that the problem of overloaded address operators shifts from
> pointer_holder.hpp( v1.30.2) to to_python_indirect.hpp (latest cvs).
> Replacing U* const p = &const_cast<U&>(x) with U* const p =
> const_cast<U*>(boost::addressof(x)) fixes the problem.
> I'm really not that familiar with the boost.python library, but this seems
> the only change needed.
> If someone can point out other possible problems with overloaded address
> operators in boost.python, let me know.
> 
> I've included the patched to_python_indirect.hpp.

?? This appears to be pointer_holder.hpp ??

Do you know how to create a patch file?  One easy way is to make
changes in your CVS image and then do a "cvs diff -du" from the
top directory.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Mon Dec  6 17:02:41 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 06 Dec 2004 11:02:41 -0500
Subject: [C++-sig] Re: Boost 1.32 and Python 2.4
In-Reply-To: <cp1ss2$8an$1@sea.gmane.org>
References: <cokroj$g77$1@sea.gmane.org> <cp1ss2$8an$1@sea.gmane.org>
Message-ID: <cp1vrt$i69$1@sea.gmane.org>

Nicolas Fleury wrote:
 > Nicolas Fleury wrote:
 >
 >> Finally, does boost 1.32 supports Python 2.4?
 >
 >
 > So I guess there's no official answer.
 > If I plan to switch to 1.32 and 2.4, is it recommended to use a more
 > recent version of Boost.Python?  Is the CVS version

of what?  If you mean Boost.Python, there's certainly no
guarantee that you can somehow just grab the code from the CVS
HEAD of boost/python and libs/python/src and use that with the
Version_1_32_0 state of Boost.  If you mean Python, I won't make
any promises about how Boost.Python works with a non-released
state of Python.

 > suppose to work with 1.32?  Does it use the relatively "stable"
 > public interface of other Boost libraries, or does it use some
 > internals that may have changed since 1.32 branching?

I have no clue what this means.  Can you clarify please?


--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Paul_Kunz at slac.stanford.edu  Mon Dec  6 17:23:43 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Mon, 6 Dec 2004 08:23:43 -0800
Subject: [C++-sig] Re: Boost 1.32 and Python 2.4
In-Reply-To: <cp1v6m$fhs$2@sea.gmane.org> (message from David Abrahams on Mon, 
	06 Dec 2004 10:51:21 -0500)
References: <cokroj$g77$1@sea.gmane.org> <cp1ss2$8an$1@sea.gmane.org>
	<200412061537.iB6Fbni03327@libra3.slac.stanford.edu>
	<cp1v6m$fhs$2@sea.gmane.org>
Message-ID: <200412061623.iB6GNh003426@libra3.slac.stanford.edu>

>>>>> On Mon, 06 Dec 2004 10:51:21 -0500, David Abrahams <dave at boost-consulting.com> said:

> Paul F. Kunz wrote:
>>>>>>> On Mon, 06 Dec 2004 10:12:02 -0500, Nicolas Fleury
>>>>>>> <nidoizo at yahoo.com> said:
>>
>>> Nicolas Fleury wrote:
>>> 
>>>> Finally, does boost 1.32 supports Python 2.4?
>>
>>> So I guess there's no official answer.  If I plan to switch to
>>> 1.32 and 2.4, is it recommended to use a more recent version of
>>> Boost.Python?  Is the CVS version suppose to work with 1.32?  Does
>>> it use the relatively "stable" public interface of other Boost
>>> libraries, or does it use some internals that may have changed
>>> since 1.32 branching?  Any help on direction to take is very
>>> appreciated. Thx and regards, Nicolas
>> 
>> 
>> I switched to boost 1.32.0 and Python 2.4 with no problems.  I
>> least, I think I did, but did not get the warnings about
>> _POSIX_C_SOURCE when I compiled boost.  This makes me think that
>> maybe seting the environment variable PYTHON_VERSION to 2.4 didn't
>> actually work.  I don't know how to verify that boost really did
>> compile with Python 2.4 installed in /usr/local instead of Python
>> 2.2 in /usr.

> You can always run bjam with -n to see what command lines will be
> issued (and -a to rebuild everything).

   Tried that.   Indeed using Python 2.4.


From ahrivera at yahoo.com  Mon Dec  6 19:03:02 2004
From: ahrivera at yahoo.com (Alexis H. Rivera-Rios)
Date: Mon, 6 Dec 2004 10:03:02 -0800 (PST)
Subject: [C++-sig] exposing C structures in pyste (modifying copyable
	attribute?)
Message-ID: <20041206180302.3219.qmail@web12821.mail.yahoo.com>

Hi,

I have some C data structures that I want to expose in
python. For example,

struct Point
{
int a;
int b;
};

I do the following in pyste to expose the structure:
Class("Point","my_header.h")

But by default, pyste generates this code:
 class_< Point, boost::noncopyable>("Point", no_init)
        .def_readwrite("a", &Point::x)
        .def_readwrite("b", &Point::y)

My questions are: 
-Is there a way to tell pyste that I want this
structure to be copyable? (Without having to modify
the generated c++ code)
- Out of curiosity, is there a way to modify the
read/write attributes from Pyste
- Is this an acceptable thing to do? Or should I
create a c++ wrapper class to my structures and expose
that?

Thanks
Alexis


=====
Programming Tutorial:
In Python: To do this, do this
In Perl: To do this, do this or this or this or this...
In C: To do this, do this, but be careful
In C++: To do this, do this, but don't do this, be careful of this, watch out for this, and whatever you do, don't do this


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250


From nidoizo at yahoo.com  Mon Dec  6 20:03:34 2004
From: nidoizo at yahoo.com (Nicolas Fleury)
Date: Mon, 06 Dec 2004 14:03:34 -0500
Subject: [C++-sig] Re: Boost 1.32 and Python 2.4
In-Reply-To: <cp1vrt$i69$1@sea.gmane.org>
References: <cokroj$g77$1@sea.gmane.org> <cp1ss2$8an$1@sea.gmane.org>
	<cp1vrt$i69$1@sea.gmane.org>
Message-ID: <cp2ae5$l33$1@sea.gmane.org>

David Abrahams wrote:

> Nicolas Fleury wrote:
>  > If I plan to switch to 1.32 and 2.4, is it recommended to use a more
>  > recent version of Boost.Python?  Is the CVS version
> 
> of what?  If you mean Boost.Python, there's certainly no

Yes, I mean Boost.Python, so that answer my question.

>  > suppose to work with 1.32?  Does it use the relatively "stable"
>  > public interface of other Boost libraries, or does it use some
>  > internals that may have changed since 1.32 branching?
> 
> I have no clue what this means.  Can you clarify please?

Nevermind.  I was just trying to understand if Boost.Python evolution 
was in some way independant of the rest of Boost.  But it doesn't matter 
since I'll stick with 1.32.

Thx to you and Paul for your answers,
Nicolas




From gaiacrtn at free.fr  Mon Dec  6 23:35:36 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Mon, 6 Dec 2004 23:35:36 +0100
Subject: [C++-sig] Re: How to expose virtual function with
	defaultarguments in boost.python ?
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain><covf54$1mq$1@sea.gmane.org>	<001301c4db1f$882742c0$0200a8c0@lain><004501c4db21$a6da8900$0200a8c0@lain>	<cp080a$hnp$1@sea.gmane.org><007a01c4db6f$19aff030$0200a8c0@lain>
	<cp1pbp$s76$1@sea.gmane.org>
Message-ID: <00f701c4dbe3$e7e721c0$0200a8c0@lain>

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Monday, December 06, 2004 3:11 PM
Subject: [C++-sig] Re: How to expose virtual function with defaultarguments
in boost.python ?


> Baptiste Lepilleur wrote:
> > ----- Original Message ----- 
> > From: "David Abrahams" <dave at boost-consulting.com>
>
>
> >>1. Use new-style polymorphism.
> [...]
> > Is there a performance hit if I always use the VC6/7 work-around in the
> > overridden virtual method ? (=> should I used the #if BOOST_WORKAROUND
all
> > over the place ?)
>
> No performance hit; it's just uglier.  But if you need portable code,
> just use the vc6/7 method.

This solution passes all my simple test cases. I'm now tackling a full
generation of the pyogre binding to "polish" the generator. When compiling
the full binding, I stumbled on the following warning (I'm compiling with
VC++ 7.1):

build\pyogre_\BillboardSet.cpp(303) : warning C4172: returning address of
local variable or temporary

Ogre::String is just a typedef on std::string. This code is the
implementation of the overriden virtual method in the wrapper class. The
code generation the warning follow:

---
    const Ogre::String& getMaterialName() const {
        if (override f = this->get_override("getMaterialName"))
#if BOOST_WORKAROUND(BOOST_MSVC, <= 1300) // Workaround for vc6/vc7
            return call< const Ogre::String& >( f.ptr());
#else
            return f(  );   /// <<< *** warning on this line ***
#endif
        return Ogre::BillboardSet::getMaterialName();
    }
---

Do you have any idea on how to "remove" this warning ? The old-style way:
return call_method< const Ogre::String& >(py_self, "getMaterialName");
does not generate that warning.

By the way, what is the "right" way to retrieve the PyObject* associated to
the wrapper ? The only thing I found is:
boost::python::detail::wrapper_base_::get_owner(). Seems to be hidden too
deeply to be of legal use. Anyway, would replacing the line causing the
warning by:

PyObject *py_self = boost::python::detail::wrapper_base_::get_owner(
*this );
return call_method< const Ogre::String& >(py_self, "getMaterialName");

works correctly ?

> >>and...
[...]
> >>2. qualify your calls to  set:
> >>
> >>return self.VirtualReturnValuePolicy::set(p0);
> >
> >
> > I don't see how this would change anything. self is already of type
> > 'VirtualReturnValuePolicy &'.
>
> It prevents VirtualReturnValuePolicy_Wrapper::set from being called
instead.

Somehow, I managed to forget that 'set' is a virtual function (nothing short
of amazing!). Will try this later.

Baptiste.



From dave at boost-consulting.com  Tue Dec  7 00:11:39 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 06 Dec 2004 18:11:39 -0500
Subject: [C++-sig] Re: How to expose virtual function with defaultarguments
 in boost.python ?
In-Reply-To: <00f701c4dbe3$e7e721c0$0200a8c0@lain>
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain><covf54$1mq$1@sea.gmane.org>	<001301c4db1f$882742c0$0200a8c0@lain><004501c4db21$a6da8900$0200a8c0@lain>	<cp080a$hnp$1@sea.gmane.org><007a01c4db6f$19aff030$0200a8c0@lain>	<cp1pbp$s76$1@sea.gmane.org>
	<00f701c4dbe3$e7e721c0$0200a8c0@lain>
Message-ID: <cp2ovf$tfj$1@sea.gmane.org>

Baptiste Lepilleur wrote:
> ----- Original Message ----- 
> From: "David Abrahams" <dave at boost-consulting.com>
> To: <c++-sig at python.org>
> Sent: Monday, December 06, 2004 3:11 PM
> Subject: [C++-sig] Re: How to expose virtual function with defaultarguments
> in boost.python ?
> 
> 
> 
>>Baptiste Lepilleur wrote:
>>
>>>----- Original Message ----- 
>>>From: "David Abrahams" <dave at boost-consulting.com>
>>
>>
>>>>1. Use new-style polymorphism.
>>
>>[...]
>>
>>>Is there a performance hit if I always use the VC6/7 work-around in the
>>>overridden virtual method ? (=> should I used the #if BOOST_WORKAROUND
> 
> all
> 
>>>over the place ?)
>>
>>No performance hit; it's just uglier.  But if you need portable code,
>>just use the vc6/7 method.
> 
> 
> This solution passes all my simple test cases. I'm now tackling a full
> generation of the pyogre binding to "polish" the generator. When compiling
> the full binding, I stumbled on the following warning (I'm compiling with
> VC++ 7.1):
> 
> build\pyogre_\BillboardSet.cpp(303) : warning C4172: returning address of
> local variable or temporary
> 
> Ogre::String is just a typedef on std::string. This code is the
> implementation of the overriden virtual method in the wrapper class. The
> code generation the warning follow:
> 
> ---
>     const Ogre::String& getMaterialName() const {
>         if (override f = this->get_override("getMaterialName"))
> #if BOOST_WORKAROUND(BOOST_MSVC, <= 1300) // Workaround for vc6/vc7
>             return call< const Ogre::String& >( f.ptr());
> #else
>             return f(  );   /// <<< *** warning on this line ***
> #endif

Why not just

               return call< const Ogre::String& >( f.ptr());

??

>         return Ogre::BillboardSet::getMaterialName();
>     }
> ---
> 
> Do you have any idea on how to "remove" this warning? 

The warning is a compiler bug; I reported it late in the vc7.1 release 
cycle and they were not inclined to fix it.

> The old-style way:
> return call_method< const Ogre::String& >(py_self, "getMaterialName");
> does not generate that warning.

  Just write what I suggested above.

> By the way, what is the "right" way to retrieve the PyObject* associated to
> the wrapper ? The only thing I found is:
> boost::python::detail::wrapper_base_::get_owner(). Seems to be hidden too
> deeply to be of legal use. 

I didn't want to publish it until I was sure someone needed it.  Why do 
you want it?

> Anyway, would replacing the line causing the
> warning by:
> 
> PyObject *py_self = boost::python::detail::wrapper_base_::get_owner(
> *this );
> return call_method< const Ogre::String& >(py_self, "getMaterialName");
> 
> works correctly ?

Blick!  What's wrong with just using the vc6/7 workaround code?

> 
> [...]
> 
>>>>2. qualify your calls to  set:
>>>>
>>>>return self.VirtualReturnValuePolicy::set(p0);
>>>
>>>
>>>I don't see how this would change anything. self is already of type
>>>'VirtualReturnValuePolicy &'.
>>
>>It prevents VirtualReturnValuePolicy_Wrapper::set from being called
> 
> instead.
> 
> Somehow, I managed to forget that 'set' is a virtual function (nothing short
> of amazing!). Will try this later.

You don't need to do both things, I don't think.  One or the other will do.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From yaoheling at yahoo.com  Tue Dec  7 19:15:27 2004
From: yaoheling at yahoo.com (Yao Heling)
Date: Tue, 7 Dec 2004 10:15:27 -0800 (PST)
Subject: [C++-sig] Re: a working example of wrapping an instantiated
	c++	object
Message-ID: <20041207181527.49901.qmail@web40822.mail.yahoo.com>

Ok, I'll try to write a small tutorial for this. I'll
post it here when
it's ready.

Thanks for your help,

Joseph 



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 


From nicolas.kowenski at softogo.com  Tue Dec  7 18:07:08 2004
From: nicolas.kowenski at softogo.com (Nicolas Kowenski)
Date: Tue, 07 Dec 2004 17:07:08 +0000
Subject: [C++-sig] 'module' object has no attribute 'suma' ?? yes it have!
Message-ID: <41B5E33C.8030407@softogo.com>

mi c Source is:
-------------------------------------------------------------------------------------------------------------------
/#include </home/dev/Python/Python-2.4/Include/Python.h>

int num=0;

int suma(int b)
   {
      printf("sumando....");
      num+=b;
      return (num); 
   }
int resta(int b)
   { 
      printf("restando...");
      num-=b;
      return (num); 
   }
int setnum(int b)
   { 
      printf("seteando ...");
      num=b;
      return (num); 
   }
  
   int traenum()
   { 
      return (num); 
   }

  
static PyObject *test_suma(PyObject *self, PyObject *args)
{
    int b;
    int sts;
    if (!PyArg_ParseTuple(args, "i",&b))
         {
         puts("dio nulll el traductor python-c, sumador");
        return NULL;
         }
    sts = suma(b);
    return Py_BuildValue("i", sts);
}
/*******************************************************************************************/
static PyObject *test_resta(PyObject *self, PyObject *args)
{
    int b;
    int sts;
    if (!PyArg_ParseTuple(args, "i", &b))
       return NULL;
    sts = resta(b);
    return Py_BuildValue("i", sts);
}
/*******************************************************************************************/
static PyObject *test_setnum(PyObject *self, PyObject *args)
{
    int b;
    int sts;
    if (!PyArg_ParseTuple(args, "i", &b))
        return NULL;
    sts = setnum(b);
    return Py_BuildValue("i", sts);
}
/*******************************************************************************************/
static PyObject *test_traenum(PyObject *self, PyObject *args)
{
    int sts;
    sts = traenum();
    return Py_BuildValue("i", sts);
}
/*******************************************************************************************/

static PyMethodDef TestMeth[] = {
    {"suma",  test_suma, METH_VARARGS,"Suma un numero"},
    {"resta",  test_resta, METH_VARARGS,"Resta un numero"},
    {"setnum",  test_setnum, METH_VARARGS,"Setea el numero"},
    {"traenum",  test_traenum, METH_NOARGS,"Trae el numero"},
    {NULL, NULL, 0, NULL}        /* Sentinel */
};
/*******************************************************************************************/
PyMODINIT_FUNC inittest(void)
{
    (void) Py_InitModule("test", TestMeth);
}


int main(int argc, char *argv[])
{
    /* Pass argv[0] to the Python interpreter */
    Py_SetProgramName(argv[0]);

    /* Initialize the Python interpreter.  Required. */
    Py_Initialize();

    /* Add a static module */
    inittest();
}/
-------------------------------------------------------------------------------------------------------------------

/
Compiled with Clases.py:

from distutils.core import setup, Extension

module2 = Extension('test',
                    sources = ['CLASES.c'])

setup (name = 'PackageName',
       version = '2.0',
       description = 'probando claes en piton',
       ext_modules = [module2])

-----------------------------------------------------------------------------------------------------------------
/then:
 >>> import test
 >>> test.suma(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'suma'
 >>>




Thankz bye!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041207/a6a1c1bd/attachment.htm>

From sseefeld at art.ca  Tue Dec  7 21:04:36 2004
From: sseefeld at art.ca (Stefan Seefeld)
Date: Tue, 7 Dec 2004 15:04:36 -0500 
Subject: [C++-sig] 'module' object has no attribute 'suma' ?? yes it h ave!
Message-ID: <20DCDD8F0FCED411AC4D001083CF504502380D22@MTL-EXCHANGE>

Hi Nicolas,

From: Nicolas Kowenski [mailto:nicolas.kowenski at softogo.com]

I'd bet you are not seeing the right test module:

$ python
Python 2.3.4 (#1, Jun 13 2004, 11:21:03)
[GCC 3.3.1 (cygming special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import test
>>> print test.__file__
/usr/lib/python2.3/test/__init__.pyc
>>>


...

'test' is a dangerous name to use ;-)

HTH,
		Stefan


From gaiacrtn at free.fr  Tue Dec  7 22:47:49 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Tue, 7 Dec 2004 22:47:49 +0100
Subject: [C++-sig] Re: How to expose virtual function with
	defaultarguments in boost.python ?
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain><covf54$1mq$1@sea.gmane.org>	<001301c4db1f$882742c0$0200a8c0@lain><004501c4db21$a6da8900$0200a8c0@lain>	<cp080a$hnp$1@sea.gmane.org><007a01c4db6f$19aff030$0200a8c0@lain>	<cp1pbp$s76$1@sea.gmane.org><00f701c4dbe3$e7e721c0$0200a8c0@lain>
	<cp2ovf$tfj$1@sea.gmane.org>
Message-ID: <014a01c4dca6$71451090$0200a8c0@lain>

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Tuesday, December 07, 2004 12:11 AM
Subject: [C++-sig] Re: How to expose virtual function with defaultarguments
in boost.python ?


> Baptiste Lepilleur wrote:
> > ----- Original Message ----- 
> > From: "David Abrahams" <dave at boost-consulting.com>
> > To: <c++-sig at python.org>
> > Sent: Monday, December 06, 2004 3:11 PM
> > Subject: [C++-sig] Re: How to expose virtual function with
defaultarguments
> > in boost.python ?
> >
> >
> >
> >>Baptiste Lepilleur wrote:
> >>
> >>>----- Original Message ----- 
> >>>From: "David Abrahams" <dave at boost-consulting.com>
> >>
> >>
> >>>>1. Use new-style polymorphism.
> >>
> >>[...]
>
> Why not just
>
>                return call< const Ogre::String& >( f.ptr());

>
> ??
>
> >         return Ogre::BillboardSet::getMaterialName();
> >     }
> > ---
> >
> > Do you have any idea on how to "remove" this warning?
>
> The warning is a compiler bug; I reported it late in the vc7.1 release
> cycle and they were not inclined to fix it.


I changed the generator to generate the "vc6/7 work-around" code. I wanted
to see if there was a difference, and there is ! There should definitely be
a note about this warning in either the tutorial or the reference
documentation.

It worries me that such a serious warning is bugged. It's one of a few that
I really look out for. By the way, how do you manage to return a reference
on something that is temporary (return value of the python function call) ?
I'm curious...

[...]

> > By the way, what is the "right" way to retrieve the PyObject* associated
to
> > the wrapper ? The only thing I found is:
> > boost::python::detail::wrapper_base_::get_owner(). Seems to be hidden
too
> > deeply to be of legal use.
>
> I didn't want to publish it until I was sure someone needed it.  Why do
> you want it?

Forget this, was just trying to find some work-around assuming the warning
was "real".

Well, I finally got pyogre binding to compile (fixed most generator bug I
introduced).

I just have one last issue remaining. It concerns the binding of *protected*
virtual function with default parameters.

Take the following code excerpt:

---
struct Ogre_SceneManager_Wrapper: Ogre::SceneManager
                                , wrapper< Ogre::SceneManager > {
//...
    void renderSingleObject(
               Ogre::Renderable* p0,
               Ogre::Pass* p1,
               bool p2,
               const Ogre::LightList* p3) {
        if (override f = this->get_override("renderSingleObject"))
            call< void >( f.ptr(), p0, p1, p2, p3);
        Ogre::SceneManager::renderSingleObject(p0, p1, p2, p3);
    }

    static void default_renderSingleObject_3(
                  Ogre::SceneManager &self,
                  Ogre::Renderable* p0,
                  Ogre::Pass* p1,
                  bool p2) {
        self.renderSingleObject(p0, p1, p2);        // <<<= problem there
    }

    void default_renderSingleObject(
                Ogre::Renderable* p0,
                Ogre::Pass* p1,
                bool p2,
                const Ogre::LightList* p3) {
        Ogre::SceneManager::renderSingleObject(p0, p1, p2, p3);
    }
};
---

The virtual member function renderSingleObject is defined has protected in
the wrapped class Ogre::SceneManager. This means that we can't call the base
class member function using "self.". I'm not aware of any tricks to work
around this, do you know any ?

Baptiste.



From gaiacrtn at free.fr  Tue Dec  7 23:12:38 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Tue, 7 Dec 2004 23:12:38 +0100
Subject: [C++-sig] exposing C structures in pyste (modifying
	copyableattribute?)
References: <20041206180302.3219.qmail@web12821.mail.yahoo.com>
Message-ID: <015e01c4dca9$dcc72940$0200a8c0@lain>

----- Original Message ----- 
From: "Alexis H. Rivera-Rios" <ahrivera at yahoo.com>
To: <c++-sig at python.org>
Sent: Monday, December 06, 2004 7:03 PM
Subject: [C++-sig] exposing C structures in pyste (modifying
copyableattribute?)


> Hi,
>
> I have some C data structures that I want to expose in
> python. For example,
>
> struct Point
> {
> int a;
> int b;
> };
>
> I do the following in pyste to expose the structure:
> Class("Point","my_header.h")
>
> But by default, pyste generates this code:
>  class_< Point, boost::noncopyable>("Point", no_init)
>         .def_readwrite("a", &Point::x)
>         .def_readwrite("b", &Point::y)

I've recently stumbled on this issue myself when integrating the lastest
change from pyste. Previously pyste generated both a default constructor and
a copy constructor for simple structure such as the one below.

I tracked it down to the following change made in GCCXMLParser:

-        ctor = Constructor(name, classname, params, visib)
+        artificial = element.get('artificial', False)
+        if not artificial:
+            ctor = Constructor(name, classname, params, visib)
+        else:
+            # we don't want artificial constructors
+            ctor = Unknown('__Unknown_Element_%s' % id)


>From what i saw in the generated xml, artificial constructor are those
created automatically by the compiler. We DO want them. I personally
consider this change a bug as it break a lot of previously running code
(e.g. no_init, non_copyable) with no way around it.

Just grab revision 1.3 of this file in the cvs, it should fix your problem.

>
> My questions are:
> -Is there a way to tell pyste that I want this
> structure to be copyable? (Without having to modify
> the generated c++ code)

No, but pyste should generate the copy constructor automatically. If
anything we should be able to indicate that we don't want a copy
constructor.

> - Out of curiosity, is there a way to modify the
> read/write attributes from Pyste

It is not currently supported by pyste, but it's very easy to implement.
Have a look at ClassExport.py, method ExportVariables, and infos.py. See how
the rename/exclude mecanism works. Just add a new function in info.py to set
some attribute on the variable info (if you want it to be read-only for
example). You'll also need to "register" your function in pyste.py.

> - Is this an acceptable thing to do? Or should I
> create a c++ wrapper class to my structures and expose
> that?

Try to generate as much as possible. When I need to do specific things not
supported by pyste, I use the exclude()/class_code() combo to inject my one
code in the generated class binding.

>
> Thanks
> Alexis

Baptiste.



From dave at boost-consulting.com  Wed Dec  8 04:50:14 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 07 Dec 2004 22:50:14 -0500
Subject: [C++-sig] Re: How to expose virtual function with defaultarguments
 in boost.python ?
In-Reply-To: <014a01c4dca6$71451090$0200a8c0@lain>
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain><covf54$1mq$1@sea.gmane.org>	<001301c4db1f$882742c0$0200a8c0@lain><004501c4db21$a6da8900$0200a8c0@lain>	<cp080a$hnp$1@sea.gmane.org><007a01c4db6f$19aff030$0200a8c0@lain>	<cp1pbp$s76$1@sea.gmane.org><00f701c4dbe3$e7e721c0$0200a8c0@lain>	<cp2ovf$tfj$1@sea.gmane.org>
	<014a01c4dca6$71451090$0200a8c0@lain>
Message-ID: <cp5tm6$tgj$1@sea.gmane.org>

Baptiste Lepilleur wrote:
>>
>> Why not just
>>
>>                return call< const Ogre::String& >( f.ptr());
> 
>>
>> ??
>>
>> >         return Ogre::BillboardSet::getMaterialName();
>> >     }
>> > ---
>> >
>> > Do you have any idea on how to "remove" this warning?
>>
>> The warning is a compiler bug; I reported it late in the vc7.1 release
>> cycle and they were not inclined to fix it.
> 
> 
> I changed the generator to generate the "vc6/7 work-around" code. I wanted
> to see if there was a difference, and there is ! 

What sort of a difference?

> There should definitely be
> a note about this warning in either the tutorial or the reference
> documentation.

Where, precisely, do you think the note could go that would be helpful?
 The warning shows up in all kinds of places, and not only with
Boost.Python.  If it will be helpful, I'm all for adding a note, but in
general I'm disinclined to devote much attention to suppressing buggy
warnings.  I don't want the documentation to become a pile of notes
about quirky compiler bugs.

> It worries me that such a serious warning is bugged. It's one of a few that
> I really look out for. By the way, how do you manage to return a reference
> on something that is temporary (return value of the python function call) ?
> I'm curious...

I am not returning a reference to a temporary; that's why I say the
warning is a compiler bug.  The warning is just incorrect.

> I just have one last issue remaining. It concerns the binding of *protected*
> virtual function with default parameters.
> 
> Take the following code excerpt:
> 
> ---
> struct Ogre_SceneManager_Wrapper: Ogre::SceneManager
>                                 , wrapper< Ogre::SceneManager > {
> //...
>     void renderSingleObject(
>                Ogre::Renderable* p0,
>                Ogre::Pass* p1,
>                bool p2,
>                const Ogre::LightList* p3) {
>         if (override f = this->get_override("renderSingleObject"))
>             call< void >( f.ptr(), p0, p1, p2, p3);
>         Ogre::SceneManager::renderSingleObject(p0, p1, p2, p3);
>     }
> 
>     static void default_renderSingleObject_3(
>                   Ogre::SceneManager &self,
>                   Ogre::Renderable* p0,
>                   Ogre::Pass* p1,
>                   bool p2) {
>         self.renderSingleObject(p0, p1, p2);        // <<<= problem there
>     }
> 
>     void default_renderSingleObject(
>                 Ogre::Renderable* p0,
>                 Ogre::Pass* p1,
>                 bool p2,
>                 const Ogre::LightList* p3) {
>         Ogre::SceneManager::renderSingleObject(p0, p1, p2, p3);
>     }
> };
> ---
> 
> The virtual member function renderSingleObject is defined has protected in
> the wrapped class Ogre::SceneManager. This means that we can't call the base
> class member function using "self.". I'm not aware of any tricks to work
> around this, do you know any ?


Nope.  As with private non-pure virtual functions, this may be one of
those corner cases where you have to forcibly violate the encapsulation
of the code you're wrapping (usually by adding friend declarations).

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From gaiacrtn at free.fr  Wed Dec  8 10:05:10 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Wed, 8 Dec 2004 10:05:10 +0100
Subject: [C++-sig] Re: How to expose virtual function with
	defaultarguments in boost.python ?
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain><covf54$1mq$1@sea.gmane.org>	<001301c4db1f$882742c0$0200a8c0@lain><004501c4db21$a6da8900$0200a8c0@lain>	<cp080a$hnp$1@sea.gmane.org><007a01c4db6f$19aff030$0200a8c0@lain>	<cp1pbp$s76$1@sea.gmane.org><00f701c4dbe3$e7e721c0$0200a8c0@lain>	<cp2ovf$tfj$1@sea.gmane.org><014a01c4dca6$71451090$0200a8c0@lain>
	<cp5tm6$tgj$1@sea.gmane.org>
Message-ID: <01a701c4dd05$0570a5a0$0200a8c0@lain>


----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Wednesday, December 08, 2004 4:50 AM
Subject: [C++-sig] Re: How to expose virtual function with defaultarguments
in boost.python ?


> Baptiste Lepilleur wrote:
> >>
> >> Why not just
> >>
> >>                return call< const Ogre::String& >( f.ptr());
> >
> >>
> >> ??
> >>
> >> >         return Ogre::BillboardSet::getMaterialName();
> >> >     }
> >> > ---
> >> >
> >> > Do you have any idea on how to "remove" this warning?
> >>
> >> The warning is a compiler bug; I reported it late in the vc7.1 release
> >> cycle and they were not inclined to fix it.
> >
> >
> > I changed the generator to generate the "vc6/7 work-around" code. I
wanted
> > to see if there was a difference, and there is !
>
> What sort of a difference?

You don't get the warning anymore. In addition to that, I have run into a
case where you get a compilation error. So the vc6/7 work-around also apply
to vc7.1. Here is the code generating the error:
    Ogre::ConfigOptionMap& getConfigOptions() {
        return this->get_override("getConfigOptions")();   // << error there
    }

build\pyogre_\RenderSystem.cpp(29) : error C2440: 'return' : cannot convert
from 'boost::python::detail::method_result'
to 'Ogre::ConfigOptionMap &'
        A reference that is not to 'const' cannot be bound to a non-lvalue

It compiles without error when using the work-around syntax.

> > There should definitely be
> > a note about this warning in either the tutorial or the reference
> > documentation.
>
> Where, precisely, do you think the note could go that would be helpful?
>  The warning shows up in all kinds of places, and not only with
> Boost.Python.  If it will be helpful, I'm all for adding a note, but in
> general I'm disinclined to devote much attention to suppressing buggy
> warnings.  I don't want the documentation to become a pile of notes
> about quirky compiler bugs.

I never run into that bugged warning before. Given the compilation error I
run into above, I would simply suggest that the work-around should be used
on vc6/7/7.1.

> > It worries me that such a serious warning is bugged. It's one of a few
that
> > I really look out for. By the way, how do you manage to return a
reference
> > on something that is temporary (return value of the python function
call) ?
> > I'm curious...
>
> I am not returning a reference to a temporary; that's why I say the
> warning is a compiler bug.  The warning is just incorrect.

I understood that you were not returning a reference to a temporary. My
question is how you managed to achieve that, since a return value is by
essence temporary.

> [...]
> > The virtual member function renderSingleObject is defined has protected
in
> > the wrapped class Ogre::SceneManager. This means that we can't call the
base
> > class member function using "self.". I'm not aware of any tricks to work
> > around this, do you know any ?
>
>
> Nope.  As with private non-pure virtual functions, this may be one of
> those corner cases where you have to forcibly violate the encapsulation
> of the code you're wrapping (usually by adding friend declarations).

OK. I have disabled support for default parameters for protected virtual
member functions (those are very rare anyway).

Baptiste.



From dave at boost-consulting.com  Wed Dec  8 13:19:35 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 08 Dec 2004 07:19:35 -0500
Subject: [C++-sig] Re: How to expose virtual function with defaultarguments
 in boost.python ?
In-Reply-To: <01a701c4dd05$0570a5a0$0200a8c0@lain>
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain><covf54$1mq$1@sea.gmane.org>	<001301c4db1f$882742c0$0200a8c0@lain><004501c4db21$a6da8900$0200a8c0@lain>	<cp080a$hnp$1@sea.gmane.org><007a01c4db6f$19aff030$0200a8c0@lain>	<cp1pbp$s76$1@sea.gmane.org><00f701c4dbe3$e7e721c0$0200a8c0@lain>	<cp2ovf$tfj$1@sea.gmane.org><014a01c4dca6$71451090$0200a8c0@lain>	<cp5tm6$tgj$1@sea.gmane.org>
	<01a701c4dd05$0570a5a0$0200a8c0@lain>
Message-ID: <cp6rgu$2uk$1@sea.gmane.org>

Baptiste Lepilleur wrote:

> From: "David Abrahams" <dave at boost-consulting.com>

>> Baptiste Lepilleur wrote:


>> > There should definitely be
>> > a note about this warning in either the tutorial or the reference
>> > documentation.
>>
>> Where, precisely, do you think the note could go that would be helpful?
>>  The warning shows up in all kinds of places, and not only with
>> Boost.Python.  If it will be helpful, I'm all for adding a note, but in
>> general I'm disinclined to devote much attention to suppressing buggy
>> warnings.  I don't want the documentation to become a pile of notes
>> about quirky compiler bugs.
> 
> I never run into that bugged warning before. Given the compilation error I
> run into above, I would simply suggest that the work-around should be used
> on vc6/7/7.1.
> 
>> > It worries me that such a serious warning is bugged. It's one of a few
> that
>> > I really look out for. By the way, how do you manage to return a
> reference
>> > on something that is temporary (return value of the python function
> call) ?
>> > I'm curious...

Hint: http://home.in.tum.de/~jain/software/oe-quotefix/

>> I am not returning a reference to a temporary; that's why I say the
>> warning is a compiler bug.  The warning is just incorrect.
> 
> I understood that you were not returning a reference to a temporary. My
> question is how you managed to achieve that, since a return value is by
> essence temporary.

A conversion operator is invoked that converts the temporary into the
reference type.  If the temporary has only a single reference to its
underlying Python object, an exception occurs at runtime.  Otherwise we
can be assured that the referent will persist past the return statement.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Wed Dec  8 13:20:38 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 08 Dec 2004 07:20:38 -0500
Subject: [C++-sig] Re: How to expose virtual function with defaultarguments
 in boost.python ?
In-Reply-To: <01a701c4dd05$0570a5a0$0200a8c0@lain>
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain><covf54$1mq$1@sea.gmane.org>	<001301c4db1f$882742c0$0200a8c0@lain><004501c4db21$a6da8900$0200a8c0@lain>	<cp080a$hnp$1@sea.gmane.org><007a01c4db6f$19aff030$0200a8c0@lain>	<cp1pbp$s76$1@sea.gmane.org><00f701c4dbe3$e7e721c0$0200a8c0@lain>	<cp2ovf$tfj$1@sea.gmane.org><014a01c4dca6$71451090$0200a8c0@lain>	<cp5tm6$tgj$1@sea.gmane.org>
	<01a701c4dd05$0570a5a0$0200a8c0@lain>
Message-ID: <41B6F196.8090404@boost-consulting.com>

Baptiste Lepilleur wrote:
> ----- Original Message ----- 

> OK. I have disabled support for default parameters for protected virtual
> member functions (those are very rare anyway).

You could always use keyword argument support to achieve a similar effect.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From dave at boost-consulting.com  Wed Dec  8 13:20:38 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 08 Dec 2004 07:20:38 -0500
Subject: [C++-sig] Re: How to expose virtual function with defaultarguments
 in boost.python ?
In-Reply-To: <01a701c4dd05$0570a5a0$0200a8c0@lain>
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain><covf54$1mq$1@sea.gmane.org>	<001301c4db1f$882742c0$0200a8c0@lain><004501c4db21$a6da8900$0200a8c0@lain>	<cp080a$hnp$1@sea.gmane.org><007a01c4db6f$19aff030$0200a8c0@lain>	<cp1pbp$s76$1@sea.gmane.org><00f701c4dbe3$e7e721c0$0200a8c0@lain>	<cp2ovf$tfj$1@sea.gmane.org><014a01c4dca6$71451090$0200a8c0@lain>	<cp5tm6$tgj$1@sea.gmane.org>
	<01a701c4dd05$0570a5a0$0200a8c0@lain>
Message-ID: <41B6F196.8090404@boost-consulting.com>

Baptiste Lepilleur wrote:
> ----- Original Message ----- 

> OK. I have disabled support for default parameters for protected virtual
> member functions (those are very rare anyway).

You could always use keyword argument support to achieve a similar effect.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From pjdurai2000 at hotmail.com  Wed Dec  8 18:46:40 2004
From: pjdurai2000 at hotmail.com (PJ Durai)
Date: Wed, 08 Dec 2004 10:46:40 -0700
Subject: [C++-sig] How to extract a sublist from a list in C++ ?
Message-ID: <BAY23-F1022AC4B18922FDE1DDB30BCB60@phx.gbl>

Greetings,

I couldnt figure out the following bit.

Say I am passing a list of lists.   [ [a, b] , [c,d]]  to a method in a C++ 
object.

In the C++ class,

void ParseList (list lst)
{
   object o = lst[0];
   // how do I conver 'o' to a list again?
   list l1  = extract<list> (o);   <- naive attempt. but doesnt work.
}

Appreciate your time.

thanks
pj




From dave at boost-consulting.com  Wed Dec  8 19:10:14 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 08 Dec 2004 13:10:14 -0500
Subject: [C++-sig] Re: How to extract a sublist from a list in C++ ?
In-Reply-To: <BAY23-F1022AC4B18922FDE1DDB30BCB60@phx.gbl>
References: <BAY23-F1022AC4B18922FDE1DDB30BCB60@phx.gbl>
Message-ID: <cp7g2f$7kh$1@sea.gmane.org>

PJ Durai wrote:
> Greetings,
> 
> I couldnt figure out the following bit.
> 
> Say I am passing a list of lists.   [ [a, b] , [c,d]]  to a method in a C++ 
> object.
> 
> In the C++ class,
> 
> void ParseList (list lst)
> {
>    object o = lst[0];

What about

     list l1(lst[0])

??

>    // how do I conver 'o' to a list again?
>    list l1  = extract<list> (o);   <- naive attempt. but doesnt work.

What happens?

> }


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Paul_Kunz at slac.stanford.edu  Wed Dec  8 19:58:03 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Wed, 8 Dec 2004 10:58:03 -0800
Subject: [C++-sig] Making copy of function derived from C++
	pure virtual function
Message-ID: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>

   I have a function written in Python derived from C++.   Now I want
to clone this function in C++.   What should I do in the copy
constructor of the function wrapper?   I have...

FunctionWrap::
FunctionWrap ( const FunctionWrap & wrap )
  : FunctionBase ( wrap ),
    m_self ( wrap.m_self )
{
// what should be here to create a new PyObject that is copy of old one?
}

FunctionBase *
FunctionWrap::
clone () const
{
  return new FunctionWrap ( *this );
}


From dave at boost-consulting.com  Wed Dec  8 20:44:52 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 08 Dec 2004 14:44:52 -0500
Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual
	function
In-Reply-To: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>
Message-ID: <cp7ljt$p9p$1@sea.gmane.org>

Paul F. Kunz wrote:
>    I have a function written in Python derived from C++.   Now I want
> to clone this function in C++.   What should I do in the copy
> constructor of the function wrapper?   I have...

Way too much detail missing for me to say anything useful.

Start by defining your terms (or used established terminology):

What does it mean to have a "function written in Python derived from
C++?"  What does it mean to clone a function?

> FunctionWrap::
> FunctionWrap ( const FunctionWrap & wrap )
>   : FunctionBase ( wrap ),
>     m_self ( wrap.m_self )
> {
> // what should be here to create a new PyObject that is copy of old one?

What old one?

> }
> 
> FunctionBase *
> FunctionWrap::
> clone () const
> {
>   return new FunctionWrap ( *this );
> }


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Paul_Kunz at slac.stanford.edu  Wed Dec  8 21:14:21 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Wed, 8 Dec 2004 12:14:21 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cp7ljt$p9p$1@sea.gmane.org> (message from David Abrahams on Wed, 
	08 Dec 2004 14:44:52 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>
	<cp7ljt$p9p$1@sea.gmane.org>
Message-ID: <200412082014.iB8KELf13038@libra3.slac.stanford.edu>

>>>>> On Wed, 08 Dec 2004 14:44:52 -0500, David Abrahams <dave at boost-consulting.com> said:

> Paul F. Kunz wrote:
>> I have a function written in Python derived from C++.  Now I want
>> to clone this function in C++.  What should I do in the copy
>> constructor of the function wrapper?  I have...

> Way too much detail missing for me to say anything useful.

   Sorry, I'll be more verbose.

> Start by defining your terms (or used established terminology):

> What does it mean to have a "function written in Python derived from
> C++?"  What does it mean to clone a function?

   Following the Boost.Python tutorial, I have a abstract C++ base
class, FunctionBase,  with pure virtual functions.   Derived from it
is my wrapper class, FunctionWrap, which contains the implementation
of the pure virtual functins of the base that uses call_method<> ()
(...) to call the Python function.   I then implement a function in
Python that derives from FunctionBase, FunctionWrap...

   export_FunctionBase ()
    {
      class_ < FunctionBase, FunctionWrap, boost::noncopyable  >
	( "FunctionBase" )


>> FunctionWrap:: FunctionWrap ( const FunctionWrap & wrap )
>>  : FunctionBase ( wrap ),
>>    m_self ( wrap.m_self )
>>  { // what should be here to create a new PyObject that is copy of old one?

> What old one?

The object wrap.m_self which is pointer to PyObject in the constructor...

FunctionWrap::
FunctionWrap ( PyObject * self )
  : FunctionBase (),
    m_self ( self )
{
}


The C++ code makes a copy of the function by calling virtual method
clone(), which is implemented as ...

FunctionBase *
FunctionWrap::
clone () const
{
  return new FunctionWrap ( *this );
}

   So in the FunctionWrap copy constructor, I should make a copy of
the Python * object held by the FunctionWrap object being copied,
otherwise I get a shallow copy.


FunctionWrap::
FunctionWrap ( const FunctionWrap & wrap )
  : FunctionBase ( wrap )
{
m_self = ????(wrap.m_self)???
}

   Complete source code for FunctionWrap with its boost.python module
use can be found here...

http://www.slac.stanford.edu/grp/ek/hippodraw/FunctionWrap_8cxx-source.html


From pjd at hotmail.com  Wed Dec  8 22:51:34 2004
From: pjd at hotmail.com (pj)
Date: Wed, 8 Dec 2004 14:51:34 -0700
Subject: [C++-sig] Re: How to extract a sublist from a list in C++ ?
References: <BAY23-F1022AC4B18922FDE1DDB30BCB60@phx.gbl>
	<cp7g2f$7kh$1@sea.gmane.org>
Message-ID: <BAY23-DAV76372F4F4FC4449278AA2BCB60@phx.gbl>

> PJ Durai wrote:
> > Greetings,
> >
> > I couldnt figure out the following bit.
> >
> > Say I am passing a list of lists.   [ [a, b] , [c,d]]  to a method in a
C++
> > object.
> >
> > In the C++ class,
> >
> > void ParseList (list lst)
> > {
> >    object o = lst[0];
>
> What about
>
>      list l1(lst[0])

Cool! That works. Thanks !

>
> ??
>
> >    // how do I conver 'o' to a list again?
> >    list l1  = extract<list> (o);   <- naive attempt. but doesnt work.
>
> What happens?

Compiler error.

UnittestGlue.cpp
C:\Pioneer\ADAPTERS\NOTES\UnittestGlue.cpp(367) : error C2440:
'initializing' : cannot convert from 'struct boost::python::extract<class
boost::python::list>' to 'class boost::python::list'
        No constructor could take the source type, or constructor overload
resolution was ambiguous

My setup:

Visual C++ 6  SP4
Windows 2000 Pro SP4
Boost 1.2.30

thanks
pj


From gaiacrtn at free.fr  Wed Dec  8 23:02:48 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Wed, 8 Dec 2004 23:02:48 +0100
Subject: [C++-sig] Re: How to expose virtual function with
	defaultarguments in boost.python ?
References: <00a801c4da13$014e77d0$0200a8c0@lain>	<cotgkh$jql$1@sea.gmane.org><012801c4dabd$e2cb60b0$0200a8c0@lain>	<couvvj$h7$1@sea.gmane.org><016301c4dae8$1acfcb70$0200a8c0@lain><covf54$1mq$1@sea.gmane.org>	<001301c4db1f$882742c0$0200a8c0@lain><004501c4db21$a6da8900$0200a8c0@lain>	<cp080a$hnp$1@sea.gmane.org><007a01c4db6f$19aff030$0200a8c0@lain>	<cp1pbp$s76$1@sea.gmane.org><00f701c4dbe3$e7e721c0$0200a8c0@lain>	<cp2ovf$tfj$1@sea.gmane.org><014a01c4dca6$71451090$0200a8c0@lain>	<cp5tm6$tgj$1@sea.gmane.org><01a701c4dd05$0570a5a0$0200a8c0@lain>
	<cp6rgu$2uk$1@sea.gmane.org>
Message-ID: <005901c4dd71$aac3ad10$0200a8c0@lain>

David Abrahams wrote:
> Baptiste Lepilleur wrote:
>
>> From: "David Abrahams" <dave at boost-consulting.com>
>
>>> Baptiste Lepilleur wrote:
>  [...]
>>> I am not returning a reference to a temporary; that's why I say the
>>> warning is a compiler bug.  The warning is just incorrect.
>>
>> I understood that you were not returning a reference to a temporary.
>> My question is how you managed to achieve that, since a return value
>> is by essence temporary.
>
> A conversion operator is invoked that converts the temporary into the
> reference type.  If the temporary has only a single reference to its
> underlying Python object, an exception occurs at runtime.  Otherwise
> we can be assured that the referent will persist past the return
> statement.

Thanks for the explanation. I add figured the first part out, but the second
part was bothering me. I wasn't looking at the problem at the correct
distance...

Baptiste.



From gaiacrtn at free.fr  Wed Dec  8 23:29:57 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Wed, 8 Dec 2004 23:29:57 +0100
Subject: [C++-sig] Pyste patch: fix 3 bugs and add new-style polymorphism
Message-ID: <007101c4dd75$72b28230$0200a8c0@lain>

The attached patch fixes the following bugs in pyste:
- boost::non_copyable was not always inserted at the end of the class_
template declaration (resolved by changing the call order of the Export*
methods)
- policy for overloaded member functions was passed as another parameters to
def() instead of using [policy]. Fix in ExportMethods.
- default parameters overload resolution failed on virtual when using an
instance of the base C++ object (see VirtualNonCopyableTest for detail).

New-polymorphism is now used for virtual member function wrapper (it was the
easiest way to get everything working for the last bug).

It should be noted that default parameter for *protected* virtual member
functions has been disabled (no simple robust solution at the current time).

The attached file main.cpp/TestOverload.cpp is an output of the new code
generated by pyste for the attached test cases.

TestOverLoad.pyste/h and overloadtest.py demonstrates the bugs.

The code generated by this patches has been successfully compiled on VC++
2003 with boost 1.32. The generator has been tested on pyogre (100 classes,
3800 methods/variables) with success.

Baptiste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newpolymorphism_and_virtualbugs.patch
Type: application/octet-stream
Size: 15399 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041208/eb5f777e/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: main.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041208/eb5f777e/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestOverload.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041208/eb5f777e/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestOverload.h
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041208/eb5f777e/attachment-0002.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestOverload.pyste
Type: application/octet-stream
Size: 793 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041208/eb5f777e/attachment-0001.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: overloadtest.py
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041208/eb5f777e/attachment-0003.txt>

From dave at boost-consulting.com  Thu Dec  9 00:30:13 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 08 Dec 2004 18:30:13 -0500
Subject: [C++-sig] Re: How to extract a sublist from a list in C++ ?
In-Reply-To: <BAY23-DAV76372F4F4FC4449278AA2BCB60@phx.gbl>
References: <BAY23-F1022AC4B18922FDE1DDB30BCB60@phx.gbl>	<cp7g2f$7kh$1@sea.gmane.org>
	<BAY23-DAV76372F4F4FC4449278AA2BCB60@phx.gbl>
Message-ID: <cp82qg$tp8$2@sea.gmane.org>

pj wrote:
>> PJ Durai wrote:
>> > Greetings,
>> >
>> > I couldnt figure out the following bit.
>> >
>> > Say I am passing a list of lists.   [ [a, b] , [c,d]]  to a method in a
> C++
>> > object.
>> >
>> > In the C++ class,
>> >
>> > void ParseList (list lst)
>> > {
>> >    object o = lst[0];
>>
>> What about
>>
>>      list l1(lst[0])
> 
> Cool! That works. Thanks !
> 
>>
>> ??
>>
>> >    // how do I conver 'o' to a list again?
>> >    list l1  = extract<list> (o);   <- naive attempt. but doesnt work.
>>
>> What happens?
> 
> Compiler error.
> 
> UnittestGlue.cpp
> C:\Pioneer\ADAPTERS\NOTES\UnittestGlue.cpp(367) : error C2440:
> 'initializing' : cannot convert from 'struct boost::python::extract<class
> boost::python::list>' to 'class boost::python::list'
>         No constructor could take the source type, or constructor overload
> resolution was ambiguous
> 
> My setup:
> 
> Visual C++ 6  SP4
> Windows 2000 Pro SP4
> Boost 1.2.30

Oh, well... with vc6 lots of otherwise-valid usages are crippled.  Try

   list l1  = extract<list>(o)();
                              ^^
Cheers :)
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Thu Dec  9 04:06:37 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 08 Dec 2004 22:06:37 -0500
Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual
	function
In-Reply-To: <200412082014.iB8KELf13038@libra3.slac.stanford.edu>
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>
	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>
Message-ID: <cp8fgb$pi8$1@sea.gmane.org>

Paul F. Kunz wrote:
>>>>>> On Wed, 08 Dec 2004 14:44:52 -0500, David Abrahams
<dave at boost-consulting.com> said:
>
>> Paul F. Kunz wrote:
>>> I have a function written in Python derived from C++.  Now I want
>>> to clone this function in C++.  What should I do in the copy
>>> constructor of the function wrapper?  I have...
>
>> Way too much detail missing for me to say anything useful.
>
>    Sorry, I'll be more verbose.
>
>> Start by defining your terms (or used established terminology):
>
>> What does it mean to have a "function written in Python derived from
>> C++?"  What does it mean to clone a function?
>
>    Following the Boost.Python tutorial, I have a abstract C++ base
> class, FunctionBase,  with pure virtual functions.   Derived from it
> is my wrapper class, FunctionWrap, which contains the implementation
> of the pure virtual functins of the base that uses call_method<> ()
> (...) to call the Python function.   I then implement a function in
> Python that derives from FunctionBase, FunctionWrap...

Functions in Python generally don't derive from anything.  You
implement a _class_ derived from FunctionBase?

>    export_FunctionBase ()
>     {
>       class_ < FunctionBase, FunctionWrap, boost::noncopyable  >
>         ( "FunctionBase" )

Uhh, that's just the Python representation of FunctionBase, not
anything derived from FunctionBase.

>
>>> FunctionWrap:: FunctionWrap ( const FunctionWrap & wrap )
>>>  : FunctionBase ( wrap ),
>>>    m_self ( wrap.m_self )
>>>  { // what should be here to create a new PyObject that is copy of
old one?


What you probably want is something like this:

  FunctionWrap:: FunctionWrap ( PyObject* self, const FunctionBase& f )
    : FunctionBase ( f ),
      m_self ( self )
  {}

So you can write

  .def(init<FunctionBase const&>())

When wrapping FunctionBase.  This all looks a lot simpler when you are
using new-style polymorphism, though.

>> What old one?
>
> The object wrap.m_self which is pointer to PyObject in the constructor...


> FunctionWrap::
> FunctionWrap ( PyObject * self )
>   : FunctionBase (),
>     m_self ( self )
> {
> }
>
>
> The C++ code makes a copy of the function by calling virtual method
> clone(), which is implemented as ...
>
> FunctionBase *
> FunctionWrap::
> clone () const
> {
>   return new FunctionWrap ( *this );
> }

clone is a virtual function, right?  Normally you should be wrapping
it just like any other virtual function; something like:

  FunctionBase* FunctionWrap::clone() const
  {
      return call_method<FunctionBase*>(m_self, "clone");
  }

And then in Python you'd write:

  class MyFunction(FunctionBase):
     def clone(self):
         return MyFunction(self)

But you're going to have a big ownership problem if this clone() is
ever called from C++ because the new C++ FunctionWrap object will be
owned by the newly-created Python MyFunction object.  When call_method
returns the last reference to that Python object will go away and
destroy the C++ object so you'll be returning a dangling pointer.

Okay, here's what I suggest, using new-style polymorphism, untested:

  template <class T>
  object get_owner(T* me)
  {
      // Use secret interface to get the Python object
      // that owns *this.  I guess I will have to make that
      // interface public.
      return
object(handle<>(borrowed(python::detail::wrapper_base_::get_owner(this))));
  }


  class FunctionWrap : public FunctionBase, public wrapper<FunctionBase>
  {
      // expose this with def(init<FunctionBase const&>())
      FunctionWrap(FunctionBase const& other)
        : FunctionBase(other)
      {}

      FunctionBase* clone()
      {
           object py_result;

           if (override clone = this->get_override("clone"))
           {
                // The Python class author overrode clone; do
                // whatever she says
                py_result = clone();
           }
           else
           {
                object self = get_owner(this);

                // Find its most-derived Python class
                object my_class = self.attr("__class__");

                // call the copy ctor through Python.
                py_result = my_class(self);
           }
           FunctionWrap* result = extract<FunctionBase*>(py_result);

           // Make the C++ result control the destiny of the Python result.
           result->invert_ownership = py_result;
           return result;
      }

      // Make sure that destroying the Python object doesn't cause an
      // attempt to destroy this one again.
      ~FunctionBase()
      {
            extract<std::auto_ptr<FunctionWrap>&> x(get_owner(this));

            if (x)
                x().release();
      }

   private:
      object invert_ownership;
  };

  ...

  class_<std::auto_ptr<FunctionWrap> >("FunctionBase", init<FunctionBase
const&>())
       ...


I hope this makes sense (and works!)

And I hope that you'll make it into an instructive example that can
be included in the tutorial.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From qhf at oce.nl  Thu Dec  9 07:53:42 2004
From: qhf at oce.nl (Fred Houben)
Date: Thu, 9 Dec 2004 07:53:42 +0100
Subject: [C++-sig] Re: problem with overloaded address operator
References: <002e01c4d3c8$d6a89970$6bf6bc86@oce.nl>	<upt20bnco.fsf@boost-consulting.com><005101c4dba2$f5d5c930$6bf6bc86@oce.nl>
	<cp2029$j03$1@sea.gmane.org>
Message-ID: <016501c4ddbb$d2839c80$6bf6bc86@oce.nl>


----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Monday, December 06, 2004 5:06 PM
Subject: [C++-sig] Re: problem with overloaded address operator


> Fred Houben wrote:
>
> > I've downloaded the latest version of boost.python from the cvs server.
> > It seems that the problem of overloaded address operators shifts from
> > pointer_holder.hpp( v1.30.2) to to_python_indirect.hpp (latest cvs).
> > Replacing U* const p = &const_cast<U&>(x) with U* const p =
> > const_cast<U*>(boost::addressof(x)) fixes the problem.
> > I'm really not that familiar with the boost.python library, but this
seems
> > the only change needed.
> > If someone can point out other possible problems with overloaded address
> > operators in boost.python, let me know.
> >
> > I've included the patched to_python_indirect.hpp.
>
> ?? This appears to be pointer_holder.hpp ??
>
> Do you know how to create a patch file?  One easy way is to make
> changes in your CVS image and then do a "cvs diff -du" from the
> top directory.
>
> -- 
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>

Okay I've created a patch to fix the problem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: addressOperator_patch
Type: application/octet-stream
Size: 941 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041209/0f4669a2/attachment.obj>

From dave at boost-consulting.com  Thu Dec  9 14:34:48 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 09 Dec 2004 08:34:48 -0500
Subject: [C++-sig] Re: problem with overloaded address operator
In-Reply-To: <016501c4ddbb$d2839c80$6bf6bc86@oce.nl>
References: <002e01c4d3c8$d6a89970$6bf6bc86@oce.nl>	<upt20bnco.fsf@boost-consulting.com><005101c4dba2$f5d5c930$6bf6bc86@oce.nl>	<cp2029$j03$1@sea.gmane.org>
	<016501c4ddbb$d2839c80$6bf6bc86@oce.nl>
Message-ID: <cp9ka0$cbm$1@sea.gmane.org>

Fred Houben wrote:

> From: "David Abrahams" <dave at boost-consulting.com>
>>
>> > I've downloaded the latest version of boost.python from the cvs server.
>> > It seems that the problem of overloaded address operators shifts from
>> > pointer_holder.hpp( v1.30.2) to to_python_indirect.hpp (latest cvs).
>> > Replacing U* const p = &const_cast<U&>(x) with U* const p =
>> > const_cast<U*>(boost::addressof(x)) fixes the problem.
>> > I'm really not that familiar with the boost.python library, but this seems
>> > the only change needed.
>> > If someone can point out other possible problems with overloaded address
>> > operators in boost.python, let me know.
>> >
>> > I've included the patched to_python_indirect.hpp.
>>
>> ?? This appears to be pointer_holder.hpp ??
>>
>> Do you know how to create a patch file?  One easy way is to make
>> changes in your CVS image and then do a "cvs diff -du" from the
>> top directory.
>
> Okay I've created a patch to fix the problem.

Thanks; are you sure that's all that's needed?  The pointer_holder.hpp
you sent also was using addressof().

Also, would you mind contributing a testcase for libs/python/test that
fails to compile without your patch?

Thanks again,

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Paul_Kunz at slac.stanford.edu  Thu Dec  9 17:18:06 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Thu, 9 Dec 2004 08:18:06 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cp8fgb$pi8$1@sea.gmane.org> (message from David Abrahams on Wed, 
	08 Dec 2004 22:06:37 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>
	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>
	<cp8fgb$pi8$1@sea.gmane.org>
Message-ID: <200412091618.iB9GI6S26256@libra3.slac.stanford.edu>

>>>>> On Wed, 08 Dec 2004 22:06:37 -0500, David Abrahams <dave at boost-consulting.com> said:


> Okay, here's what I suggest, using new-style polymorphism, untested:

   Okay, I'll give it a try.


From Paul_Kunz at slac.stanford.edu  Thu Dec  9 18:45:20 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Thu, 9 Dec 2004 09:45:20 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cp8fgb$pi8$1@sea.gmane.org> (message from David Abrahams on Wed, 
	08 Dec 2004 22:06:37 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>
	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>
	<cp8fgb$pi8$1@sea.gmane.org>
Message-ID: <200412091745.iB9HjKe26551@libra3.slac.stanford.edu>

I'm stuck with the first function suggested by Dave.   I have...

template <class T>
object
FunctionWrap::
get_owner(T* me)
{
      // Use secret interface to get the Python object
      // that owns *this.  I guess I will have to make that
      // interface public.
      return
object ( handle<> ( borrowed ( detail::wrapper_base_::get_owner(this))));
}

and get...

g++ -DQT_THREAD_SUPPORT -DHAVE_CONFIG_H -I. -I../../hippodraw/python -I.. -I../../hippodraw -I../../hippodraw/qt -I.. -I../qt -I/usr/local/include -I/usr/local/include/boost-1_32 -ftemplate-depth-120 -I/usr/local/include/python2.4 -I/usr/local/qt/include -g -O2 -Wall -c ../../hippodraw/python/FunctionWrap.cxx -MT FunctionWrap.lo -MD -MP -MF .deps/FunctionWrap.TPlo  -fPIC -DPIC
../../hippodraw/python/FunctionWrap.cxx: In member function `boost::python::api::object FunctionWrap::get_owner(T*)':
../../hippodraw/python/FunctionWrap.cxx:86: error: invalid initialization of reference of type 'const volatile boost::python::detail::wrapper_base&' from expression of type 'FunctionWrap* const'
/usr/local/include/boost-1_32/boost/python/detail/wrapper_base.hpp:72: error: in passing argument 1 of `PyObject* boost::python::detail::wrapper_base_::get_owner(const volatile boost::python::detail::wrapper_base&)'
../../hippodraw/python/FunctionWrap.cxx:86: error: no matching function for call to `borrowed(<type error>)'
make[2]: *** [FunctionWrap.lo] Error 1

Compiler is gcc 3.4.3 on Red Hat 9 Linux.   I've looked at the
wrapper_base.hpp file, but don't understand it.




From Paul_Kunz at slac.stanford.edu  Thu Dec  9 19:46:44 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Thu, 9 Dec 2004 10:46:44 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cp8fgb$pi8$1@sea.gmane.org> (message from David Abrahams on Wed, 
	08 Dec 2004 22:06:37 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>
	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>
	<cp8fgb$pi8$1@sea.gmane.org>
Message-ID: <200412091846.iB9IkiV26683@libra3.slac.stanford.edu>

  In response to my previsous item concerning compiler error.   I
found the problem.   I needed `*this' instead of `this' in the
argument.


From Paul_Kunz at slac.stanford.edu  Fri Dec 10 00:55:12 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Thu, 9 Dec 2004 15:55:12 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cp8fgb$pi8$1@sea.gmane.org> (message from David Abrahams on Wed, 
	08 Dec 2004 22:06:37 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>
	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>
	<cp8fgb$pi8$1@sea.gmane.org>
Message-ID: <200412092355.iB9NtCS30340@libra3.slac.stanford.edu>

>>>>> On Wed, 08 Dec 2004 22:06:37 -0500, David Abrahams <dave at boost-consulting.com> said:


>   class_<std::auto_ptr<FunctionWrap> >("FunctionBase",
> init<FunctionBase const&>()) ...

   I tried.   Maybe I have typo I can't see.   I have ...


      class_ < std::auto_ptr < FunctionWrap > >
	( "FunctionBase",
	  init < FunctionBase & > () )


and get ...

../../hippodraw/python/FunctionWrap.cxx:37:   instantiated from here
/usr/local/include/boost-1_32/boost/python/object/value_holder.hpp:133: error: no matching function for call to `std::auto_ptr<FunctionWrap>::auto_ptr(FunctionBase&)'
/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/memory:351: note: candidates are: std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr_ref<_Tp>) [with _Tp = FunctionWrap]
/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/memory:200: note:                 std::auto_ptr<_Tp>::auto_ptr(std::auto_ptr<_Tp>&) [with _Tp = FunctionWrap]
/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/memory:191: note:                 std::auto_ptr<_Tp>::auto_ptr(_Tp*) [with _Tp = FunctionWrap]

where


class FunctionWrap : public FunctionBase,
		     public boost::python::wrapper < FunctionBase >
{


Any suggestions?




From dave at boost-consulting.com  Fri Dec 10 02:37:18 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 09 Dec 2004 20:37:18 -0500
Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual
	function
In-Reply-To: <200412092355.iB9NtCS30340@libra3.slac.stanford.edu>
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>
	<200412092355.iB9NtCS30340@libra3.slac.stanford.edu>
Message-ID: <cpaukt$k4j$1@sea.gmane.org>

Paul F. Kunz wrote:
>>>>>> On Wed, 08 Dec 2004 22:06:37 -0500, David Abrahams <dave at boost-consulting.com> said:
> 
> 
>>   class_<std::auto_ptr<FunctionWrap> >("FunctionBase",
>> init<FunctionBase const&>()) ...

Sorry, this should be:

     class_<FunctionWrap, std::auto_ptr<FunctionWrap> >(
	"FunctionBase", init<FunctionBase const&>())


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From beyer at imb-jena.de  Fri Dec 10 12:13:05 2004
From: beyer at imb-jena.de (Andreas Beyer)
Date: Fri, 10 Dec 2004 12:13:05 +0100
Subject: [C++-sig] Overloading + different argument types
Message-ID: <41B984C1.5060305@imb-jena.de>

Hi.

Hope I didn't miss something in the tutorial.

I would like to mix different numbers of arguments with different 
argument types. Consider the following example:


int f(int i, bool flag=true) { return i; }
int f(string s, bool flag=true) { return atoi(s.c_str()); }


The naive way to transfer this to python fails:

BOOST_PYTHON_FUNCTION_OVERLOADS(f_overloads, f, 1, 2);
BOOST_PYTHON_MODULE(overload_test)
{
     def("f", &f, f_overloads());
}

This fails at compile time with:

gcc-C++-action bin\example\overload_test.pyd\mingw\runtime\overload_test.obj
overload_test.cpp: In function `void init_module_overload_test()':
overload_test.cpp:21: error: no matching function for call to `def(const 
char[2], <unknown type>, f_overloads)'

Using thin wrappers works:

int f1(int i, bool flag=true) { return f(i, flag); }
int f2(string s, bool flag=true) { return f(s, flag); }

BOOST_PYTHON_FUNCTION_OVERLOADS(f1_overloads, f1, 1, 2);
BOOST_PYTHON_FUNCTION_OVERLOADS(f2_overloads, f2, 1, 2);

BOOST_PYTHON_MODULE(overload_test)
{
     def("f", &f1, f1_overloads());
     def("f", &f2, f2_overloads());
}


Is there a more elegant variant without thin wrappers? (E.g. I played 
with function pointers, but so far I had no success.)
Is it feasible to improve BOOST_PYTHON_FUNCTION_OVERLOADS() to deal with 
different argument types in the future?


Thanks, Andreas


From dave at boost-consulting.com  Fri Dec 10 15:07:39 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Dec 2004 09:07:39 -0500
Subject: [C++-sig] Re: Overloading + different argument types
In-Reply-To: <41B984C1.5060305@imb-jena.de>
References: <41B984C1.5060305@imb-jena.de>
Message-ID: <41B9ADAB.3020605@boost-consulting.com>

Andreas Beyer wrote:
> Hi.
> 
> Hope I didn't miss something in the tutorial.
> 
> I would like to mix different numbers of arguments with different 
> argument types. Consider the following example:
> 
> 
> int f(int i, bool flag=true) { return i; }
> int f(string s, bool flag=true) { return atoi(s.c_str()); }
> 
> 
> The naive way to transfer this to python fails:
> 
> BOOST_PYTHON_FUNCTION_OVERLOADS(f_overloads, f, 1, 2);
> BOOST_PYTHON_MODULE(overload_test)
> {
>      def("f", &f, f_overloads());
> }
> 

BOOST_PYTHON_FUNCTION_OVERLOADS(f_overloads, f, 1, 2);
BOOST_PYTHON_MODULE(overload_test)
{
     def("f", static_cast<int (*)(int,bool)>(f), f_overloads1());
     def("f", static_cast<int (*)(string,bool)>(f), f_overloads2());
}

> This fails at compile time with:
> 
> gcc-C++-action bin\example\overload_test.pyd\mingw\runtime\overload_test.obj
> overload_test.cpp: In function `void init_module_overload_test()':
> overload_test.cpp:21: error: no matching function for call to `def(const 
> char[2], <unknown type>, f_overloads)'
	   ^^^^^^^^^^^^^^

Any time you want to pass the address of an overloaded function you have
to cast it to the type you mean.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From dave at boost-consulting.com  Fri Dec 10 15:07:39 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Dec 2004 09:07:39 -0500
Subject: [C++-sig] Re: Overloading + different argument types
In-Reply-To: <41B984C1.5060305@imb-jena.de>
References: <41B984C1.5060305@imb-jena.de>
Message-ID: <41B9ADAB.3020605@boost-consulting.com>

Andreas Beyer wrote:
> Hi.
> 
> Hope I didn't miss something in the tutorial.
> 
> I would like to mix different numbers of arguments with different 
> argument types. Consider the following example:
> 
> 
> int f(int i, bool flag=true) { return i; }
> int f(string s, bool flag=true) { return atoi(s.c_str()); }
> 
> 
> The naive way to transfer this to python fails:
> 
> BOOST_PYTHON_FUNCTION_OVERLOADS(f_overloads, f, 1, 2);
> BOOST_PYTHON_MODULE(overload_test)
> {
>      def("f", &f, f_overloads());
> }
> 

BOOST_PYTHON_FUNCTION_OVERLOADS(f_overloads, f, 1, 2);
BOOST_PYTHON_MODULE(overload_test)
{
     def("f", static_cast<int (*)(int,bool)>(f), f_overloads1());
     def("f", static_cast<int (*)(string,bool)>(f), f_overloads2());
}

> This fails at compile time with:
> 
> gcc-C++-action bin\example\overload_test.pyd\mingw\runtime\overload_test.obj
> overload_test.cpp: In function `void init_module_overload_test()':
> overload_test.cpp:21: error: no matching function for call to `def(const 
> char[2], <unknown type>, f_overloads)'
	   ^^^^^^^^^^^^^^

Any time you want to pass the address of an overloaded function you have
to cast it to the type you mean.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Paul_Kunz at slac.stanford.edu  Fri Dec 10 16:38:12 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Fri, 10 Dec 2004 07:38:12 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpaukt$k4j$1@sea.gmane.org> (message from David Abrahams on Thu, 
	09 Dec 2004 20:37:18 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>
	<200412092355.iB9NtCS30340@libra3.slac.stanford.edu>
	<cpaukt$k4j$1@sea.gmane.org>
Message-ID: <200412101538.iBAFcCf00606@libra3.slac.stanford.edu>

>>>>> On Thu, 09 Dec 2004 20:37:18 -0500, David Abrahams <dave at boost-consulting.com> said:


> Sorry, this should be:

>      class_<FunctionWrap, std::auto_ptr<FunctionWrap> >(
> "FunctionBase", init<FunctionBase const&>())

Ok, that compiles.   Obvious no that I see it.

But now at run time I get...

Traceback (most recent call last):
  File "fitting.py", line 62, in ?
    f = Linear ()
  File "fitting.py", line 21, in __init__
    FunctionBase.__init__(self)
Boost.Python.ArgumentError: Python argument types in
    FunctionBase.__init__(Linear)
did not match C++ signature:
    __init__(_object*, FunctionBase)
>>> 

from ...

from hippo import FunctionBase
class Linear ( FunctionBase ) :
    def __init__ ( self ) :
        FunctionBase.__init__(self)
        self.initialize ()
    
    def initialize ( self ) :
        self.setName ( 'linear' )
        self.setParmNames ( [ 'Intercept', 'Slope' ] )
        self.setParameters ( [ intercept, slope ] )

f = Linear ()

---





From Paul_Kunz at slac.stanford.edu  Fri Dec 10 20:20:06 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Fri, 10 Dec 2004 11:20:06 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <200412101538.iBAFcCf00606@libra3.slac.stanford.edu>
	(Paul_Kunz@slac.stanford.edu)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>
	<200412092355.iB9NtCS30340@libra3.slac.stanford.edu>
	<cpaukt$k4j$1@sea.gmane.org>
	<200412101538.iBAFcCf00606@libra3.slac.stanford.edu>
Message-ID: <200412101920.iBAJK6r01545@libra3.slac.stanford.edu>

>>>>> On Fri, 10 Dec 2004 07:38:12 -0800, "Paul F. Kunz" <Paul_Kunz at slac.stanford.edu> said:

>>>>> On Thu, 09 Dec 2004 20:37:18 -0500, David Abrahams <dave at boost-consulting.com> said:
>> Sorry, this should be:

>> class_<FunctionWrap, std::auto_ptr<FunctionWrap> >( "FunctionBase",
>> init<FunctionBase const&>())

> Ok, that compiles.  Obvious no that I see it.

> But now at run time I get...

   Replying to my own item, I got pass the runtime error by doing the
following instead of the above...

      class_ < FunctionBase, std::auto_ptr< FunctionWrap> >
		( "FunctionBase" )

with the constructor of the class as ...

FunctionWrap::
FunctionWrap ( PyObject * self )
  : FunctionBase (),
    m_self ( self )
{
}

`m_self' is data member to hold the PyObject.

   Now at runtime I crash in the suggested FunctionWrap::clone()
method when trying to call get_ower().   With gdb I see ...

  <boost::python::wrapper<FunctionBase>> = {
    <boost::python::detail::wrapper_base> = {
      m_self = 0x0
    }, <No data fields>}, 
  members of FunctionWrap: 
  m_self = 0x4060911c, 
  invert_ownership = {
    <boost::python::api::object_base> = {
      <boost::python::api::object_operators<boost::python::api::object>> = {
        <boost::python::def_visitor<boost::python::api::object>> = {<No data fields>}, <No data fields>}, 
      members of boost::python::api::object_base: 
      m_ptr = 0x8125d60
    }, <No data fields>}
}
(gdb) 

Note that the wrapper_base data member `m_self' is a null pointer.
So I guess my FunctionWrap class ...

class FunctionWrap : public FunctionBase,
		     public boost::python::wrapper < FunctionBase >
{

didn't get initialized properly.   Looking at the wrapper.hpp and
detail/wrapper_base.hpp files, I don't see how to initialize it.

Do I really need it?   If get_owner had worked, would it have returned
FunctionWrap::m_self?


From dave at boost-consulting.com  Fri Dec 10 20:45:02 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 10 Dec 2004 14:45:02 -0500
Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual
	function
In-Reply-To: <200412101920.iBAJK6r01545@libra3.slac.stanford.edu>
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412092355.iB9NtCS30340@libra3.slac.stanford.edu>	<cpaukt$k4j$1@sea.gmane.org>	<200412101538.iBAFcCf00606@libra3.slac.stanford.edu>
	<200412101920.iBAJK6r01545@libra3.slac.stanford.edu>
Message-ID: <cpcucc$rom$1@sea.gmane.org>

Paul F. Kunz wrote:
>>>>>> On Fri, 10 Dec 2004 07:38:12 -0800, "Paul F. Kunz" <Paul_Kunz at slac.stanford.edu> said:
> 
>>>>>> On Thu, 09 Dec 2004 20:37:18 -0500, David Abrahams <dave at boost-consulting.com> said:
>>> Sorry, this should be:
> 
>>> class_<FunctionWrap, std::auto_ptr<FunctionWrap> >( "FunctionBase",
>>> init<FunctionBase const&>())
> 
>> Ok, that compiles.  Obvious no that I see it.
> 
>> But now at run time I get...
> 
>    Replying to my own item, I got pass the runtime error by doing the
> following instead of the above...
> 
>       class_ < FunctionBase, std::auto_ptr< FunctionWrap> >
> 		( "FunctionBase" )

Don't do that; the code I suggested was there for a reason.  I think I
have a bug, but it will help a lot to have a test case.  Can you back up
a step to the previous version that compiled and make a reduced test
case for me to test my changes against?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From johan at carlstedt.net  Fri Dec 10 22:00:27 2004
From: johan at carlstedt.net (Johan Carlstedt)
Date: Fri, 10 Dec 2004 21:00:27 -0000 (GMT)
Subject: [C++-sig] Solaris 10x86 - Problem compiling libboost_python
Message-ID: <26183.147.114.226.181.1102712427.squirrel@www.flirble.org>

Hello,

I am having problems compiling Boost 1.32 on Solaris 10 X86 with gcc 3.4.1
and Python 2.23. The compilation fails for libboost_python with the error
message below. I have tried with and without "-fpermissive".

I would be grateful if anyone was able to advice.

With friendly regards,

Johan Carlstedt

bash-2.05b# bjam "-sTOOLS=gcc" "-sGXX=g++ -fpermissive" install
...found 11612 targets...
...updating 32 targets...
gcc-C++-action
bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-
true/inheritance.o
In file included
from /export/home/johan/boost_1_32_0/libs/python/build/../src/object/inherit
ance.cpp:11:
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441: error:
expected identifier before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441:
warning: ISO C++ forbids declaration of `parameter' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441: error:
expected `>' before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`VP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`EP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`GP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`EL' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
type/value mismatch at argument 3 in template parameter list for
`template<class OutEdgeListS, class VertexListS, class DirectedS, class
VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS>
class boost::adjacency_list'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444:
error:   expected a type, got `3'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
template argument 4 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
template argument 5 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
template argument 6 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
template argument 7 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`Tag' has not been declared
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445: error:
expected `,' or `...' before '&' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445:
warning: ISO C++ forbids declaration of `g' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445:
warning: ISO C++ forbids declaration of `parameter' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445:
warning: ISO C++ forbids declaration of `Value' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp: In function
`void boost::set_property(int&, int, int)':
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error:
`m_property' has not been declared
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error:
request for member of non-aggregate type before ',' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446:
warning: there are no arguments to `Tag' that depend on a template
parameter, so a declaration of `Tag' must be available
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error:
`value' undeclared (first use this function)
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error:
(Each undeclared identifier is reported only once for each function it
appears in.)
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp: At global
scope:
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449: error:
expected identifier before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449:
warning: ISO C++ forbids declaration of `parameter' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449: error:
expected `>' before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`VP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`EP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`GP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`EL' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
type/value mismatch at argument 3 in template parameter list for
`template<class OutEdgeListS, class VertexListS, class DirectedS, class
VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS>
class boost::adjacency_list'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452:
error:   expected a type, got `3'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 4 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 5 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 6 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 7 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`Tag' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 1 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 2 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
expected init-declarator before '&' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
expected `;' before '&' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457: error:
expected identifier before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457:
warning: ISO C++ forbids declaration of `parameter' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457: error:
expected `>' before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`VP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`EP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`GP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`EL' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
type/value mismatch at argument 3 in template parameter list for
`template<class OutEdgeListS, class VertexListS, class DirectedS, class
VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS>
class boost::adjacency_list'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461:
error:   expected a type, got `3'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 4 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 5 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 6 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 7 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`Tag' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 1 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 2 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
expected init-declarator before '&' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
expected `;' before '&' token





From Paul_Kunz at slac.stanford.edu  Fri Dec 10 23:01:04 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Fri, 10 Dec 2004 14:01:04 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpcucc$rom$1@sea.gmane.org> (message from David Abrahams on Fri, 
	10 Dec 2004 14:45:02 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412092355.iB9NtCS30340@libra3.slac.stanford.edu>	<cpaukt$k4j$1@sea.gmane.org>	<200412101538.iBAFcCf00606@libra3.slac.stanford.edu>
	<200412101920.iBAJK6r01545@libra3.slac.stanford.edu>
	<cpcucc$rom$1@sea.gmane.org>
Message-ID: <200412102201.iBAM14205141@libra3.slac.stanford.edu>

>>>>> On Fri, 10 Dec 2004 14:45:02 -0500, David Abrahams <dave at boost-consulting.com> said:

> Paul F. Kunz wrote:
>>>>>>> On Fri, 10 Dec 2004 07:38:12 -0800, "Paul F. Kunz"
>>>>>>> <Paul_Kunz at slac.stanford.edu> said:
>>
>>>>>>> On Thu, 09 Dec 2004 20:37:18 -0500, David Abrahams
>>>>>>> <dave at boost-consulting.com> said:
>>>> Sorry, this should be:
>>
>>>> class_<FunctionWrap, std::auto_ptr<FunctionWrap> >(
>>>> "FunctionBase", init<FunctionBase const&>())
>>
>>> Ok, that compiles.  Obvious no that I see it.
>>
>>> But now at run time I get...
>>  Replying to my own item, I got pass the runtime error by doing the
>> following instead of the above...
>> 
>> class_ < FunctionBase, std::auto_ptr< FunctionWrap> > (
>> "FunctionBase" )

> Don't do that; the code I suggested was there for a reason.

   Ok.

>  I think
> I have a bug, but it will help a lot to have a test case.  Can you
> back up a step to the previous version that compiled and make a
> reduced test case for me to test my changes against?

   I'll try.   Frequently, it is hard to pull something out because
large dependency on other parts of a large project.   In this case, I
think there's only one external class envolved.

   


From Paul_Kunz at slac.stanford.edu  Sat Dec 11 02:34:09 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Fri, 10 Dec 2004 17:34:09 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpcucc$rom$1@sea.gmane.org> (message from David Abrahams on Fri, 
	10 Dec 2004 14:45:02 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412092355.iB9NtCS30340@libra3.slac.stanford.edu>	<cpaukt$k4j$1@sea.gmane.org>	<200412101538.iBAFcCf00606@libra3.slac.stanford.edu>
	<200412101920.iBAJK6r01545@libra3.slac.stanford.edu>
	<cpcucc$rom$1@sea.gmane.org>
Message-ID: <200412110134.iBB1Y9006041@libra3.slac.stanford.edu>

>>>>> On Fri, 10 Dec 2004 14:45:02 -0500, David Abrahams <dave at boost-consulting.com> said:

> Don't do that; the code I suggested was there for a reason.  I think
> I have a bug, but it will help a lot to have a test case.  Can you
> back up a step to the previous version that compiled and make a
> reduced test case for me to test my changes against?

   Ok at ...

ftp://ftp.slac.stanford.edu/users/pfkeb/abrahams/HippoDraw-1.12.7.tar.gz

with the necasary files and the test script.   After building, just run
the ``fitting.py' test script.   There's a bit nore than needed in the
tar ball, but is is sufficiently small.




From dave at boost-consulting.com  Sat Dec 11 15:40:20 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 11 Dec 2004 09:40:20 -0500
Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual
	function
In-Reply-To: <200412110134.iBB1Y9006041@libra3.slac.stanford.edu>
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412092355.iB9NtCS30340@libra3.slac.stanford.edu>	<cpaukt$k4j$1@sea.gmane.org>	<200412101538.iBAFcCf00606@libra3.slac.stanford.edu>	<200412101920.iBAJK6r01545@libra3.slac.stanford.edu>	<cpcucc$rom$1@sea.gmane.org>
	<200412110134.iBB1Y9006041@libra3.slac.stanford.edu>
Message-ID: <cpf0t2$kg3$1@sea.gmane.org>

Paul F. Kunz wrote:
>>>>>> On Fri, 10 Dec 2004 14:45:02 -0500, David Abrahams
>>>>>> <dave at boost-consulting.com> said:
> 
>> Don't do that; the code I suggested was there for a reason.  I
>> think I have a bug, but it will help a lot to have a test case.
>> Can you back up a step to the previous version that compiled and
>> make a reduced test case for me to test my changes against?
> 
> Ok at ...
> 
> ftp://ftp.slac.stanford.edu/users/pfkeb/abrahams/HippoDraw-1.12.7.tar.gz
> 
> 
> with the necasary files and the test script.   After building, just
> run the ``fitting.py' test script.   There's a bit nore than needed
> in the tar ball, but is is sufficiently small.

Sufficiently for whom?  It took me 20 minutes of massaging just to get
it to build under vc7.1 (where I have good debugging tools).  Then when
I tested it against a Python debug build the vc7.1 runtime found a
problem with corrupted dynamic memory.

Please reduce your problem to a *simple* test case with as few classes
and functions as possible.  Take out any threading-related stuff.  There
should be one .cpp file and one .py file.  Ideally, you'd pass me a
Jamfile, but I can produce one myself if neccessary.

Thanks,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Paul_Kunz at slac.stanford.edu  Sat Dec 11 19:55:42 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Sat, 11 Dec 2004 10:55:42 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpf0t2$kg3$1@sea.gmane.org> (message from David Abrahams on Sat, 
	11 Dec 2004 09:40:20 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412092355.iB9NtCS30340@libra3.slac.stanford.edu>	<cpaukt$k4j$1@sea.gmane.org>	<200412101538.iBAFcCf00606@libra3.slac.stanford.edu>	<200412101920.iBAJK6r01545@libra3.slac.stanford.edu>	<cpcucc$rom$1@sea.gmane.org>
	<200412110134.iBB1Y9006041@libra3.slac.stanford.edu>
	<cpf0t2$kg3$1@sea.gmane.org>
Message-ID: <200412111855.iBBItgT10158@libra3.slac.stanford.edu>

>>>>> On Sat, 11 Dec 2004 09:40:20 -0500, David Abrahams <dave at boost-consulting.com> said:

> Sufficiently for whom?  It took me 20 minutes of massaging just to
> get it to build under vc7.1 (where I have good debugging tools).

   Sorry, I wasn't think about VC++

> Please reduce your problem to a *simple* test case with as few
> classes and functions as possible.  Take out any threading-related
> stuff.  There should be one .cpp file and one .py file.  Ideally,
> you'd pass me a Jamfile, but I can produce one myself if neccessary.

   Ok, one file, one Python script.   No includes other that C++
standard library.

ftp://ftp.slac.stanford.edu/users/pfkeb/abrahams/HippoDraw-1.12.7.tar.gz

   Thanks for your patience.


From dave at boost-consulting.com  Sat Dec 11 21:34:15 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 11 Dec 2004 15:34:15 -0500
Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual
	function
In-Reply-To: <200412111855.iBBItgT10158@libra3.slac.stanford.edu>
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412092355.iB9NtCS30340@libra3.slac.stanford.edu>	<cpaukt$k4j$1@sea.gmane.org>	<200412101538.iBAFcCf00606@libra3.slac.stanford.edu>	<200412101920.iBAJK6r01545@libra3.slac.stanford.edu>	<cpcucc$rom$1@sea.gmane.org>	<200412110134.iBB1Y9006041@libra3.slac.stanford.edu>	<cpf0t2$kg3$1@sea.gmane.org>
	<200412111855.iBBItgT10158@libra3.slac.stanford.edu>
Message-ID: <cpflkl$1oi$1@sea.gmane.org>

Paul F. Kunz wrote:
>>>>>> On Sat, 11 Dec 2004 09:40:20 -0500, David Abrahams
>>>>>> <dave at boost-consulting.com> said:
> 
>> Sufficiently for whom?  It took me 20 minutes of massaging just to 
>> get it to build under vc7.1 (where I have good debugging tools).
> 
> Sorry, I wasn't think about VC++
> 
>> Please reduce your problem to a *simple* test case with as few 
>> classes and functions as possible.  Take out any threading-related 
>> stuff.  There should be one .cpp file and one .py file.  Ideally, 
>> you'd pass me a Jamfile, but I can produce one myself if
>> neccessary.
> 
> Ok, one file, one Python script.   No includes other that C++ 
> standard library.
> 
> ftp://ftp.slac.stanford.edu/users/pfkeb/abrahams/HippoDraw-1.12.7.tar.gz

I'm not surprised by the behavior of this example.
You wrapped a class with a single constructor:

      class_ < FunctionWrap, std::auto_ptr < FunctionWrap > >
	( "FunctionBase",  init < const FunctionBase & > () )

	;

That constructor takes a single FunctionBase& parameter.  Leaving out
the irrelevant Python code, you derive a class:

  from hippo import FunctionBase
  class Linear ( FunctionBase ) :
      def __init__ ( self ) :
          FunctionBase.__init__(self)

But this is how you call a nullary (zero-argument) ctor on a base class!
Don't try

          FunctionBase.__init__(self, self)

it won't work.  There's no C++ FunctionBase object yet that can be
extracted from the 2nd argument.  You just need to add a Default ctor to
FunctionWrap and expose it.  You also need to get rid of
FunctionWrap(PyObject*) -- that's old-style polymorphism.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Paul_Kunz at slac.stanford.edu  Sat Dec 11 23:14:45 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Sat, 11 Dec 2004 14:14:45 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpflkl$1oi$1@sea.gmane.org> (message from David Abrahams on Sat, 
	11 Dec 2004 15:34:15 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412092355.iB9NtCS30340@libra3.slac.stanford.edu>	<cpaukt$k4j$1@sea.gmane.org>	<200412101538.iBAFcCf00606@libra3.slac.stanford.edu>	<200412101920.iBAJK6r01545@libra3.slac.stanford.edu>	<cpcucc$rom$1@sea.gmane.org>	<200412110134.iBB1Y9006041@libra3.slac.stanford.edu>	<cpf0t2$kg3$1@sea.gmane.org>
	<200412111855.iBBItgT10158@libra3.slac.stanford.edu>
	<cpflkl$1oi$1@sea.gmane.org>
Message-ID: <200412112214.iBBMEjm10774@libra3.slac.stanford.edu>

>>>>> On Sat, 11 Dec 2004 15:34:15 -0500, David Abrahams <dave at boost-consulting.com> said:

> it won't work.  There's no C++ FunctionBase object yet that can be
> extracted from the 2nd argument.  You just need to add a Default
> ctor to FunctionWrap and expose it.  You also need to get rid of
> FunctionWrap(PyObject*) -- that's old-style polymorphism.

   Yes, that works.   Thanks a million.   Now back to trying to clone
from C++.



From johan at carlstedt.net  Sat Dec 11 23:38:52 2004
From: johan at carlstedt.net (Johan Carlstedt)
Date: Sat, 11 Dec 2004 22:38:52 +0000
Subject: [C++-sig] Solaris 10 x86 - Compiling libboost_python
Message-ID: <41BB76FC.1020705@carlstedt.net>

Hello,

I am having problems compiling Boost 1.32 on Solaris 10 X86 with gcc 
3.4.1 and Python 2.23. The compilation fails for libboost_python with 
the error message below. I have tried with and without "-fpermissive".

I would be grateful if anyone was able to advice.

With friendly regards,

Johan Carlstedt

bash-2.05b# bjam "-sTOOLS=gcc" "-sGXX=g++ -fpermissive" install
....found 11612 targets...
....updating 32 targets...
gcc-C++-action
bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-
true/inheritance.o
In file included
from /export/home/johan/boost_1_32_0/libs/python/build/../src/object/inherit
ance.cpp:11:
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441: error:
expected identifier before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441:
warning: ISO C++ forbids declaration of `parameter' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441: error:
expected `>' before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`VP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`EP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`GP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`EL' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
type/value mismatch at argument 3 in template parameter list for
`template<class OutEdgeListS, class VertexListS, class DirectedS, class
VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS>
class boost::adjacency_list'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444:
error:   expected a type, got `3'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
template argument 4 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
template argument 5 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
template argument 6 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
template argument 7 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`Tag' has not been declared
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445: error:
expected `,' or `...' before '&' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445:
warning: ISO C++ forbids declaration of `g' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445:
warning: ISO C++ forbids declaration of `parameter' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445:
warning: ISO C++ forbids declaration of `Value' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp: In function
`void boost::set_property(int&, int, int)':
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error:
`m_property' has not been declared
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error:
request for member of non-aggregate type before ',' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446:
warning: there are no arguments to `Tag' that depend on a template
parameter, so a declaration of `Tag' must be available
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error:
`value' undeclared (first use this function)
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error:
(Each undeclared identifier is reported only once for each function it
appears in.)
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp: At global
scope:
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449: error:
expected identifier before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449:
warning: ISO C++ forbids declaration of `parameter' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449: error:
expected `>' before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`VP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`EP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`GP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`EL' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
type/value mismatch at argument 3 in template parameter list for
`template<class OutEdgeListS, class VertexListS, class DirectedS, class
VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS>
class boost::adjacency_list'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452:
error:   expected a type, got `3'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 4 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 5 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 6 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 7 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`Tag' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 1 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 2 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
expected init-declarator before '&' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
expected `;' before '&' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457: error:
expected identifier before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457:
warning: ISO C++ forbids declaration of `parameter' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457: error:
expected `>' before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`VP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`EP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`GP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`EL' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
type/value mismatch at argument 3 in template parameter list for
`template<class OutEdgeListS, class VertexListS, class DirectedS, class
VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS>
class boost::adjacency_list'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461:
error:   expected a type, got `3'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 4 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 5 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 6 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 7 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`Tag' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 1 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 2 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
expected init-declarator before '&' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
expected `;' before '&' token






From dave at boost-consulting.com  Sun Dec 12 00:25:42 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 11 Dec 2004 18:25:42 -0500
Subject: [C++-sig] Re: Solaris 10 x86 - Compiling libboost_python
In-Reply-To: <41BB76FC.1020705@carlstedt.net>
References: <41BB76FC.1020705@carlstedt.net>
Message-ID: <cpfvm6$ajb$1@sea.gmane.org>

Johan Carlstedt wrote:
> Hello,
> 
> I am having problems compiling Boost 1.32 on Solaris 10 X86 with gcc 
> 3.4.1 and Python 2.23. The compilation fails for libboost_python with 
> the error message below. I have tried with and without "-fpermissive".
> 
> I would be grateful if anyone was able to advice.
> 
> With friendly regards,
> 
> Johan Carlstedt
> 
> bash-2.05b# bjam "-sTOOLS=gcc" "-sGXX=g++ -fpermissive" install
> .....found 11612 targets...
> .....updating 32 targets...
> gcc-C++-action
> bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-
> true/inheritance.o

This appears to be a problem in the Boost.Graph library, which is used
by Boost.Python.  I suggest you post about it on the main Boost
developer's list.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Kingdom.Lin at yeah.net  Sun Dec 12 16:02:49 2004
From: Kingdom.Lin at yeah.net (Donnie Leen)
Date: Sun, 12 Dec 2004 23:02:49 +0800
Subject: [C++-sig] problem with embbed boost.python in multi-interpreter and
	multi-thread HELP please
Message-ID: <20041212150213.C717A1E4003@bag.python.org>

I wrote a program embbed boost.python, each thread running a sub-interpreter, i made a module implement by boost.python, and i wish this module imported in each sub-interpreter, i find that the module could initialize only once, otherwise the boost.python will throw a exception said that something already registered; second conversion method ignored.

So I try another way, initialize and import the module in one interpreter such as the main interpreter, and I hope to import the module in any sub-interpreter, because I found the python document said:
"Extension modules are shared between (sub-)interpreters as follows: the first time a particular extension is imported, it is initialized normally, and a (shallow) copy of its module's dictionary is squirreled away. When the same extension is imported by another (sub-)interpreter, a new module is initialized and filled with the contents of this copy; the extension's init function is not called. "
but when i try this way i found that the program throw an exception:ImportError: No module named mym, (mym is the module name). This happens even i wrote the module in Python/C API without boost.python.

Could somebody tell me why this happened or how to deal with it, thanks for any suggestion.

Donnie Leen




From Paul_Kunz at slac.stanford.edu  Sun Dec 12 22:33:58 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Sun, 12 Dec 2004 13:33:58 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cp8fgb$pi8$1@sea.gmane.org> (message from David Abrahams on Wed, 
	08 Dec 2004 22:06:37 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>
	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>
	<cp8fgb$pi8$1@sea.gmane.org>
Message-ID: <200412122133.iBCLXwB21886@libra3.slac.stanford.edu>

  This clone function doesn't quite work ...

      FunctionBase* clone()
      {
        PyGILState_STATE state = PyGILState_Ensure ();
          object py_result;

           if (override clone = this->get_override("clone"))
           {
                // The Python class author overrode clone; do
                // whatever she says
                py_result = clone();
           }
           else
           {
                object self = get_owner(this);

                // Find its most-derived Python class
                object my_class = self.attr("__class__");

                // call the copy ctor through Python.
                py_result = my_class(self);
           }
           FunctionWrap* result = extract<FunctionBase*>(py_result);

           // Make the C++ result control the destiny of the Python result.
           result->invert_ownership = py_result;
          PyGILState_Release ( state );
          return result;
      }

This is being called from different thread from the one that created
the Python object, thus the Ensure/Release methods are used.

If I implement clone in Python, the the function gets called, but
calling clone() leads to ...

terminate called after throwing an instance of
'boost::python::error_already_set'

If I do not implement clone in Python, the the other path of the if is
taken and get same result.   I can call other methods implemented in
Python without problem.

   With the debugger, I walked thru lots of Python code and get quite
deep before it decides to return a null pointer instead of a new
object.   I note that it called, static PyObject *
instancemethod_call(PyObject *func, PyObject *arg, PyObject *kw)
Is this correct?   In C++ an constructor wouldn't be called a instance
method. 

   Any suggestions on what to look for?


From dave at boost-consulting.com  Mon Dec 13 04:26:21 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 12 Dec 2004 22:26:21 -0500
Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual
	function
In-Reply-To: <200412122133.iBCLXwB21886@libra3.slac.stanford.edu>
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>
	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>
Message-ID: <cpj25k$o2e$1@sea.gmane.org>

Paul F. Kunz wrote:
>   This clone function doesn't quite work ...
> 
>       FunctionBase* clone()
>       {
>         PyGILState_STATE state = PyGILState_Ensure ();
>           object py_result;
> 
>            if (override clone = this->get_override("clone"))
>            {
>                 // The Python class author overrode clone; do
>                 // whatever she says
>                 py_result = clone();
>            }
>            else
>            {
>                 object self = get_owner(this);
> 
>                 // Find its most-derived Python class
>                 object my_class = self.attr("__class__");
> 
>                 // call the copy ctor through Python.
>                 py_result = my_class(self);
>            }
>            FunctionWrap* result = extract<FunctionBase*>(py_result);
> 
>            // Make the C++ result control the destiny of the Python result.
>            result->invert_ownership = py_result;
>           PyGILState_Release ( state );
>           return result;
>       }
> 
> This is being called from different thread from the one that created
> the Python object, thus the Ensure/Release methods are used.
> 
> If I implement clone in Python, the the function gets called, but
> calling clone() leads to ...
> 
> terminate called after throwing an instance of
> 'boost::python::error_already_set'

This means some Python exception is being thrown.  You might set a
breakpoint on boost::python::detail::throw_error_already_set (I think I
have the namespace right) and look just up the stack to see what the
actual error being reported is.

> If I do not implement clone in Python, the the other path of the if is
> taken and get same result.   I can call other methods implemented in
> Python without problem.
> 
>    With the debugger, I walked thru lots of Python code and get quite
> deep before it 

"it?"

> decides to return a null pointer instead of a new
> object.   I note that it called, static PyObject *
> instancemethod_call(PyObject *func, PyObject *arg, PyObject *kw)
> Is this correct?   

How should I know?  That function gets used to implement all sorts of
things in Python.

> In C++ an constructor wouldn't be called a instance
> method. 

you are being led astray by terminology

>    Any suggestions on what to look for?

Yes:  Get rid of all the threading stuff and *all* the superfluous
functions/methods (you still had several unused Python methods floating
around in what you posted the last time) and reduce this to a simple
test case that can be used as a proof-of-concept for what you're doing
with cloning.  Test all the cloning cases you want to handle (e.g.
override clone in some Python derived classes but not others).  You will
very quickly narrow the issue down and if you don't discover that you
had a bug in your code, post the result and I will look at it.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From haller at ableton.com  Mon Dec 13 10:27:54 2004
From: haller at ableton.com (Stefan Haller)
Date: Mon, 13 Dec 2004 10:27:54 +0100
Subject: [C++-sig] Disallow adding attributes to wrapped classes from Python
Message-ID: <1goq9rz.9x19wb1kxzc4fM%haller@ableton.com>

Is there a way to make the __dict__ of exposed classes read-only?  I
fear it will be a common error for Python programmers to make typos when
setting attributes, and I would like this to generate an error rather
than silently adding a new attribute.

class_<Foo>("Foo")
    .add_property("foobar", &Foo::getFooBar, &Foo::setFooBar)
;

>>> foo.foobaz = 7   # oops: typo!
>>> foo.foobaz
7


-- 
Stefan Haller
Ableton
http://www.ableton.com/


From beyer at imb-jena.de  Mon Dec 13 10:56:49 2004
From: beyer at imb-jena.de (Andreas Beyer)
Date: Mon, 13 Dec 2004 10:56:49 +0100
Subject: [C++-sig] Disallow adding attributes to wrapped classes from
	Python
In-Reply-To: <1goq9rz.9x19wb1kxzc4fM%haller@ableton.com>
References: <1goq9rz.9x19wb1kxzc4fM%haller@ableton.com>
Message-ID: <41BD6761.9030508@imb-jena.de>

I think it should be possible to catch the __setattr__() of __dict__ and 
to throw an exception. However, I think that misses out the philosophy 
of Python. Variables are not declared. It is up to the user to define 
appropriate test cases that check the correctness of the code.
You could also define a function that sets the value of foobar. If the 
user writes
   foo.set_foobaz(7)
he/she will get an exception.

	Andreas

Stefan Haller wrote:
> Is there a way to make the __dict__ of exposed classes read-only?  I
> fear it will be a common error for Python programmers to make typos when
> setting attributes, and I would like this to generate an error rather
> than silently adding a new attribute.
> 
> class_<Foo>("Foo")
>     .add_property("foobar", &Foo::getFooBar, &Foo::setFooBar)
> ;
> 
> 
>>>>foo.foobaz = 7   # oops: typo!
>>>>foo.foobaz
> 
> 7
> 
> 

-- 
--------------------------------------
   Dr. Andreas Beyer - beyer at imb-jena.de
   http://www.imb-jena.de/~beyer
--------------------------------------


From dave at boost-consulting.com  Mon Dec 13 10:56:50 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 13 Dec 2004 04:56:50 -0500
Subject: [C++-sig] Re: Disallow adding attributes to wrapped classes from
	Python
In-Reply-To: <1goq9rz.9x19wb1kxzc4fM%haller@ableton.com>
References: <1goq9rz.9x19wb1kxzc4fM%haller@ableton.com>
Message-ID: <cpjp1l$55d$1@sea.gmane.org>

Stefan Haller wrote:
> Is there a way to make the __dict__ of exposed classes read-only?  I
> fear it will be a common error for Python programmers to make typos when
> setting attributes, and I would like this to generate an error rather
> than silently adding a new attribute.
> 
> class_<Foo>("Foo")
>     .add_property("foobar", &Foo::getFooBar, &Foo::setFooBar)
> ;
> 
>>>> foo.foobaz = 7   # oops: typo!
>>>> foo.foobaz
> 7

Just the same way you do it in Python:

  $ python
  Python 2.3.2 (#1, Nov 14 2003, 18:13:01)
  [GCC 3.3.1 (cygming special)] on cygwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> class X(object):
  ...     __slots__ = ('a', 'b')
  ...     def foo(self):
  ...             pass
  ...
  >>> x = X()
  >>> x.a = 1
  >>> x.b = 2
  >>> x.c = 3
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
  AttributeError: 'X' object has no attribute 'c'

Thus:

  class_<Foo>("Foo")
      .add_property("foobar", &Foo::getFooBar, &Foo::setFooBar)
      .attr("__slots__") = tuple()
      ;


HTH,


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From haller at ableton.com  Mon Dec 13 12:09:31 2004
From: haller at ableton.com (Stefan Haller)
Date: Mon, 13 Dec 2004 12:09:31 +0100
Subject: [C++-sig] Re: Disallow adding attributes to wrapped classes from
	Python
In-Reply-To: <cpjp1l$55d$1@sea.gmane.org>
Message-ID: <1goqek8.szoijz1nq2dkiM%haller@ableton.com>

David Abrahams <dave at boost-consulting.com> wrote:

>   class_<Foo>("Foo")
>       .add_property("foobar", &Foo::getFooBar, &Foo::setFooBar)
>       .attr("__slots__") = tuple()
>       ;

Thanks for the quick help, but unfortunately it doesn't work.  I suspect
this may be for the same reason why the following doesn't work:

  $ python
  Python 2.2.3 (#1, Jan 21 2004, 06:55:19) 
  [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> class X(object):
  ...     pass
  ... 
  >>> X.__slots__ = ()
  >>> x = X()
  >>> x.foobar = 1
  >>> x.foobar    
  1


Or does it make a difference that I'm still using Python 2.2?



-- 
Stefan Haller
Ableton
http://www.ableton.com/


From dave at boost-consulting.com  Mon Dec 13 12:53:57 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 13 Dec 2004 06:53:57 -0500
Subject: [C++-sig] Re: Disallow adding attributes to wrapped classes from
	Python
In-Reply-To: <1goqek8.szoijz1nq2dkiM%haller@ableton.com>
References: <cpjp1l$55d$1@sea.gmane.org>
	<1goqek8.szoijz1nq2dkiM%haller@ableton.com>
Message-ID: <cpjvt7$nj3$1@sea.gmane.org>

Stefan Haller wrote:
> David Abrahams <dave at boost-consulting.com> wrote:
> 
>>   class_<Foo>("Foo")
>>       .add_property("foobar", &Foo::getFooBar, &Foo::setFooBar)
>>       .attr("__slots__") = tuple()
>>       ;
> 
> Thanks for the quick help, but unfortunately it doesn't work.  I suspect
> this may be for the same reason why the following doesn't work:
> 
>   $ python
>   Python 2.2.3 (#1, Jan 21 2004, 06:55:19) 
>   [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
>   Type "help", "copyright", "credits" or "license" for more information.
>   >>> class X(object):
>   ...     pass
>   ... 
>   >>> X.__slots__ = ()
>   >>> x = X()
>   >>> x.foobar = 1
>   >>> x.foobar    
>   1
> 
> 
> Or does it make a difference that I'm still using Python 2.2?

Naw, you're right.  Are you willing to use the Boost CVS?  I'd be happy
to add a patch to support this:

  dict d;
  d["__slots__"] = tuple();
  class_<Foo>(
	"Foo",   // name
	tuple(), // more bases
	d)
      ...

You could fake it, but it wouldn't work nearly as well:

   object proxy
	 = class<anything>("anything")
		.add_property("foobar", &Foo::getFooBar, &Foo::setFooBar);

   object metaclass = proxy.attr("__class__");

   dict d = proxy().attr("__dict__");
   d["__slots__"] = tuple();
   scope().attr("Foo")
      = metaclass("Foo", tuple(), d);

You'd lose the benefit of a conversion from C++ Foo to Python, for
example.  But you might try the above anyway just to make sure I'm not
wasting my time with the patch.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Mon Dec 13 13:03:53 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 13 Dec 2004 07:03:53 -0500
Subject: [C++-sig] Re: Wrapper for exception translation
In-Reply-To: <013401c357a6$db402e70$44a837c2@gieke>
References: <2040C0A1CA23D51181A30050BAAC990274AAC2@berexch.ber.haufemg.com>
	<u8yr3xfzf.fsf@boost-consulting.com>
	<001201c34936$303e0b60$44a837c2@gieke>
	<ubrvywcsu.fsf@boost-consulting.com>
	<uk79y4mgm.fsf@boost-consulting.com>
	<013401c357a6$db402e70$44a837c2@gieke>
Message-ID: <41BD8529.6040006@boost-consulting.com>

Gottfried Gan?auge wrote:
> Hi Dave,
> 
> I digged through the class_<> implementation and I think I know what I must
> do to implement it. Like you suggested I would add another argument to the
> class_base constructor which is used as another base class for the newly
> created class.

Hi Gottfried,

I don't know if you're still listening, but today I offered to implement
this patch on the C++-sig (see my other post).  Are you still interested?



-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From dave at boost-consulting.com  Mon Dec 13 13:03:53 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 13 Dec 2004 07:03:53 -0500
Subject: [C++-sig] Re: Wrapper for exception translation
In-Reply-To: <013401c357a6$db402e70$44a837c2@gieke>
References: <2040C0A1CA23D51181A30050BAAC990274AAC2@berexch.ber.haufemg.com>
	<u8yr3xfzf.fsf@boost-consulting.com>
	<001201c34936$303e0b60$44a837c2@gieke>
	<ubrvywcsu.fsf@boost-consulting.com>
	<uk79y4mgm.fsf@boost-consulting.com>
	<013401c357a6$db402e70$44a837c2@gieke>
Message-ID: <41BD8529.6040006@boost-consulting.com>

Gottfried Gan?auge wrote:
> Hi Dave,
> 
> I digged through the class_<> implementation and I think I know what I must
> do to implement it. Like you suggested I would add another argument to the
> class_base constructor which is used as another base class for the newly
> created class.

Hi Gottfried,

I don't know if you're still listening, but today I offered to implement
this patch on the C++-sig (see my other post).  Are you still interested?



-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Gottfried.Ganssauge at HAUFE.DE  Mon Dec 13 17:13:12 2004
From: Gottfried.Ganssauge at HAUFE.DE (Gottfried.Ganssauge at HAUFE.DE)
Date: Mon, 13 Dec 2004 17:13:12 +0100
Subject: [C++-sig] RE: Wrapper for exception translation
Message-ID: <2040C0A1CA23D51181A30050BAAC9902011046D8@berexch.ber.haufemg.com>

> -----Original Message-----
> From: David Abrahams [mailto:dave at boost-consulting.com]
> Sent: Monday, December 13, 2004 1:04 PM
> To: c++-sig at python.org; Gottfried Gan?auge
> Subject: Re: Wrapper for exception translation
> 
> 
> Gottfried Gan?auge wrote:
> > Hi Dave,
> > 
> > I digged through the class_<> implementation and I think I
> know what I
> > must do to implement it. Like you suggested I would add another 
> > argument to the class_base constructor which is used as
> another base
> > class for the newly created class.
> 
> Hi Gottfried,
Hi Dave,

> 
> I don't know if you're still listening, but today I offered to 
> implement this patch on the C++-sig (see my other post).
> Are you still interested?

I am still listening but was buried deeply with work so I even had to
abandon the work already invested into this. Nonetheless: Yes - I'm still
interested.

Cheers,

Gottfried 

P.S.:
What second Post?

I got 2 Copies of this one.
> 
> 
> 
> --
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041213/b0ae8564/attachment.htm>

From Paul_Kunz at slac.stanford.edu  Mon Dec 13 17:47:16 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Mon, 13 Dec 2004 08:47:16 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpj25k$o2e$1@sea.gmane.org> (message from David Abrahams on Sun, 
	12 Dec 2004 22:26:21 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>
	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>
	<cpj25k$o2e$1@sea.gmane.org>
Message-ID: <200412131647.iBDGlGO25543@libra3.slac.stanford.edu>

>>>>> On Sun, 12 Dec 2004 22:26:21 -0500, David Abrahams <dave at boost-consulting.com> said:

> This means some Python exception is being thrown.  You might set a
> breakpoint on boost::python::detail::throw_error_already_set (I
> think I have the namespace right) and look just up the stack to see
> what the actual error being reported is.

   Doing that, I find exception being thrown from here...

template <class T>
inline T* expect_non_null(T* x)
{
    if (x == 0)
        throw_error_already_set();
    return x;
}

x is 0.   This is result of calling...

	FunctionWrap * t = const_cast < FunctionWrap * > ( this );
	object self = get_owner ( t );

	// Find its most-derived Python class
	object my_class = self.attr("__class__");

	// call the copy ctor through Python.
	py_result = my_class(self);

This probably doesn't help, but thought I mentioned it in case it
rings a bell.


From Paul_Kunz at slac.stanford.edu  Mon Dec 13 18:56:11 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Mon, 13 Dec 2004 09:56:11 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpj25k$o2e$1@sea.gmane.org> (message from David Abrahams on Sun, 
	12 Dec 2004 22:26:21 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>
	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>
	<cpj25k$o2e$1@sea.gmane.org>
Message-ID: <200412131756.iBDHuBH25693@libra3.slac.stanford.edu>

>>>>> On Sun, 12 Dec 2004 22:26:21 -0500, David Abrahams <dave at boost-consulting.com> said:

> This means some Python exception is being thrown.  You might set a
> breakpoint on boost::python::detail::throw_error_already_set (I
> think I have the namespace right) and look just up the stack to see
> what the actual error being reported is.

   It appears that Python is creating the null pointer in type_call()
after these lines...

		type = obj->ob_type;
		if (PyType_HasFeature(type, Py_TPFLAGS_HAVE_CLASS) &&
		    type->tp_init != NULL &&
		    type->tp_init(obj, args, kwds) < 0) {
			Py_DECREF(obj);
			obj = NULL;



From Paul_Kunz at slac.stanford.edu  Mon Dec 13 19:22:29 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Mon, 13 Dec 2004 10:22:29 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpj25k$o2e$1@sea.gmane.org> (message from David Abrahams on Sun, 
	12 Dec 2004 22:26:21 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>
	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>
	<cpj25k$o2e$1@sea.gmane.org>
Message-ID: <200412131822.iBDIMT925758@libra3.slac.stanford.edu>

>>>>> On Sun, 12 Dec 2004 22:26:21 -0500, David Abrahams <dave at boost-consulting.com> said:

> This means some Python exception is being thrown.  You might set a
> breakpoint on boost::python::detail::throw_error_already_set (I
> think I have the namespace right) and look just up the stack to see
> what the actual error being reported is.

   Here's the what type contains in 

		type = obj->ob_type;
		if (PyType_HasFeature(type, Py_TPFLAGS_HAVE_CLASS) &&
		    type->tp_init != NULL &&
		    type->tp_init(obj, args, kwds) < 0) {
			Py_DECREF(obj);
			obj = NULL;

(gdb) p *obj->ob_type
$10 = {
  ob_refcnt = 5, 
  ob_type = 0x41ce55c0, 
  ob_size = 0, 
  tp_name = 0x401941b4 "Linear", 
  tp_basicsize = 24, 
  tp_itemsize = 1, 
  tp_dealloc = 0x808cab0 <subtype_dealloc>, 
  tp_print = 0, 
  tp_getattr = 0, 
  tp_setattr = 0, 
  tp_compare = 0, 
  tp_repr = 0x808d910 <object_repr>, 
  tp_as_number = 0x819e28c, 
  tp_as_sequence = 0x819e330, 
  tp_as_mapping = 0x819e324, 
  tp_hash = 0x808dbc0 <object_hash>, 
  tp_call = 0, 
  tp_str = 0x808db90 <object_str>, 
  tp_getattro = 0x8080940 <PyObject_GenericGetAttr>, 
  tp_setattro = 0x8080c00 <PyObject_GenericSetAttr>, 
  tp_as_buffer = 0x819e358, 
  tp_flags = 22523, 
  tp_doc = 0x0, 
  tp_traverse = 0x808c8c0 <subtype_traverse>, 
  tp_clear = 0x808ca00 <subtype_clear>, 
  tp_richcompare = 0, 
  tp_weaklistoffset = 16, 
  tp_iter = 0, 
  tp_iternext = 0, 
  tp_methods = 0x0, 
  tp_members = 0x819e370, 
  tp_getset = 0x0, 
  tp_base = 0x862f4e4, 
  tp_dict = 0x4060835c, 
  tp_descr_get = 0, 
  tp_descr_set = 0, 
  tp_dictoffset = 12, 
  tp_init = 0x80949a0 <slot_tp_init>, 
  tp_alloc = 0x808c7a0 <PyType_GenericAlloc>, 
  tp_new = 0x41cc9ca0 <boost::python::instance_holder::install(_object*)+32>, 
  tp_free = 0x80eb2c0 <PyObject_GC_Del>, 
  tp_is_gc = 0, 
  tp_bases = 0x401a3ecc, 
  tp_mro = 0x4019320c, 
  tp_cache = 0x0, 
  tp_subclasses = 0x0, 
  tp_weaklist = 0x40600edc, 
  tp_del = 0
}

   I don't know what is good or bad in the above.   Maybe someone
does.


From dave at boost-consulting.com  Mon Dec 13 20:06:26 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 13 Dec 2004 14:06:26 -0500
Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual
	function
In-Reply-To: <200412131647.iBDGlGO25543@libra3.slac.stanford.edu>
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>	<cpj25k$o2e$1@sea.gmane.org>
	<200412131647.iBDGlGO25543@libra3.slac.stanford.edu>
Message-ID: <cpkp7j$al6$4@sea.gmane.org>

Paul F. Kunz wrote:
>>>>>> On Sun, 12 Dec 2004 22:26:21 -0500, David Abrahams <dave at boost-consulting.com> said:
> 
>> This means some Python exception is being thrown.  You might set a
>> breakpoint on boost::python::detail::throw_error_already_set (I
>> think I have the namespace right) and look just up the stack to see
>> what the actual error being reported is.
> 
>    Doing that, I find exception being thrown from here...
> 
> template <class T>
> inline T* expect_non_null(T* x)
> {
>     if (x == 0)
>         throw_error_already_set();
>     return x;
> }
> 
> x is 0.   This is result of calling...
> 
> 	FunctionWrap * t = const_cast < FunctionWrap * > ( this );
> 	object self = get_owner ( t );
> 
> 	// Find its most-derived Python class
> 	object my_class = self.attr("__class__");
> 
> 	// call the copy ctor through Python.
> 	py_result = my_class(self);

Ahem.  Which line above and precisely which part of the expression on
that line is being evaluated?

> This probably doesn't help, but thought I mentioned it in case it
> rings a bell.

No bell-ringing.
The exception should be caught by Boost.Python and returned to Python as
a Python exception.  Python isn't issuing any error message?
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Paul_Kunz at slac.stanford.edu  Mon Dec 13 20:12:33 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Mon, 13 Dec 2004 11:12:33 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpkp7j$al6$4@sea.gmane.org> (message from David Abrahams on Mon, 
	13 Dec 2004 14:06:26 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>	<cpj25k$o2e$1@sea.gmane.org>
	<200412131647.iBDGlGO25543@libra3.slac.stanford.edu>
	<cpkp7j$al6$4@sea.gmane.org>
Message-ID: <200412131912.iBDJCXj25876@libra3.slac.stanford.edu>

>>>>> On Mon, 13 Dec 2004 14:06:26 -0500, David Abrahams <dave at boost-consulting.com> said:

>> FunctionWrap * t = const_cast < FunctionWrap * > ( this );
>>  object self = get_owner ( t );
>> 
>> // Find its most-derived Python class object my_class =
>> self.attr("__class__");
>> 
>> // call the copy ctor through Python.  
>> py_result = my_class(self);

> Ahem.  Which line above and precisely which part of the expression
> on that line is being evaluated?

   The last line, my_class(self)

>> This probably doesn't help, but thought I mentioned it in case it
>> rings a bell.

> No bell-ringing.  The exception should be caught by Boost.Python and
> returned to Python as a Python exception.  Python isn't issuing any
> error message?

   No error message from Python.   Just silently returns a NULL
result.

P.S.

   I am trying to find a way to isolate the problem.


From Paul_Kunz at slac.stanford.edu  Mon Dec 13 20:32:02 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Mon, 13 Dec 2004 11:32:02 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpj25k$o2e$1@sea.gmane.org> (message from David Abrahams on Sun, 
	12 Dec 2004 22:26:21 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>
	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>
	<cpj25k$o2e$1@sea.gmane.org>
Message-ID: <200412131932.iBDJW2R26035@libra3.slac.stanford.edu>

   I decided to try invoking this clone function from Python instead
of from C++ so as to try to isolate the problem (no threads, etc).
So I just added 

>>> foo = f.clone()

to the test script after exposing this method to Python and get ...

Traceback (most recent call last):
  File "fitting.py", line 66, in ?
    foo = f.clone ()
TypeError: __init__() takes exactly 1 argument (2 given)

This might be the error message that we're not getting when clone() is
called from C++.  Maybe we're not getting the message because
boost::python::throw_error_already_set () is calling std::terminate?




From dave at boost-consulting.com  Mon Dec 13 20:34:28 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 13 Dec 2004 14:34:28 -0500
Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual
	function
In-Reply-To: <200412131912.iBDJCXj25876@libra3.slac.stanford.edu>
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>	<cpj25k$o2e$1@sea.gmane.org>	<200412131647.iBDGlGO25543@libra3.slac.stanford.edu>	<cpkp7j$al6$4@sea.gmane.org>
	<200412131912.iBDJCXj25876@libra3.slac.stanford.edu>
Message-ID: <cpkqs5$hps$1@sea.gmane.org>

Paul F. Kunz wrote:
>>>>>> On Mon, 13 Dec 2004 14:06:26 -0500, David Abrahams <dave at boost-consulting.com> said:
> 
>>> FunctionWrap * t = const_cast < FunctionWrap * > ( this );
>>>  object self = get_owner ( t );
>>> 
>>> // Find its most-derived Python class object my_class =
>>> self.attr("__class__");
>>> 
>>> // call the copy ctor through Python.  
>>> py_result = my_class(self);
> 
>> Ahem.  Which line above and precisely which part of the expression
>> on that line is being evaluated?
> 
>    The last line, my_class(self)
> 
>>> This probably doesn't help, but thought I mentioned it in case it
>>> rings a bell.
> 
>> No bell-ringing.  The exception should be caught by Boost.Python and
>> returned to Python as a Python exception.  Python isn't issuing any
>> error message?
> 
>    No error message from Python.   Just silently returns a NULL
> result.

The error message only appears on your screen *after* the exception is
thrown by C++ in response to the NULL result, and caught.  Somewhere up
the call stack is boost::python::handle_exception, which catches the C++
exception and returns an error code to the Python interpreter, which
should eventually issue an error message (unless of course your Python
code is eating the resulting Python exception).

> P.S.
> 
>    I am trying to find a way to isolate the problem.

Good.
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From haller at ableton.com  Mon Dec 13 20:38:20 2004
From: haller at ableton.com (Stefan Haller)
Date: Mon, 13 Dec 2004 20:38:20 +0100
Subject: [C++-sig] Re: Disallow adding attributes to wrapped classes from
	Python
In-Reply-To: <cpjvt7$nj3$1@sea.gmane.org>
Message-ID: <1goqprt.1wv05mxq616r3M%haller@ableton.com>

David Abrahams <dave at boost-consulting.com> wrote:

> Naw, you're right.  Are you willing to use the Boost CVS?

Not easily, sorry.  And I'm not sure if the feature is important enough
for us to go to the trouble, and to waste your time on it.

(But I could easily use a patch if it can be applied against the 1.32.0
 release; I have no idea how realistic this is.)

> You could fake it, but it wouldn't work nearly as well:
> 
>    object proxy
>    = class<anything>("anything")
>       .add_property("foobar", &Foo::getFooBar, &Foo::setFooBar);
> 
>    object metaclass = proxy.attr("__class__");
> 
>    dict d = proxy().attr("__dict__");
>    d["__slots__"] = tuple();
>    scope().attr("Foo")
>       = metaclass("Foo", tuple(), d);
> 
> You'd lose the benefit of a conversion from C++ Foo to Python, for
> example.  But you might try the above anyway just to make sure I'm not
> wasting my time with the patch.

Phew.  I'm afraid I don't understand this code at all.  I tried to get
it to work for a simple test case, with the following adjustments to
make it compile (not really knowing what I was doing):

-    = class<anything>("anything")
+    = class_<Foo>("anything")

-    dict d = proxy().attr("__dict__");
+    dict d(proxy().attr("__dict__"));

But no, this doesn't work.  It *does* prevent me from adding new
attributes, but it also doesn't show the existing property (foobar),
which is not much progress.  :-)

>>> f = Foo()
>>> f.foobar
Traceback (most recent call last):
File "<string>", line 1, in ?
AttributeError: 'Foo' object has no attribute 'foobar'
>>> f.x = 1
Traceback (most recent call last):
File "<string>", line 1, in ?
AttributeError: 'Foo' object has no attribute 'x'
>>> dir(f)
['__class__', '__delattr__', '__doc__', '__getattribute__',
'__getstate__', '__hash__', '__init__', '__new__', '__reduce__',
'__repr__', '__setattr__', '__slots__', '__str__']


-- 
Stefan Haller
Ableton
http://www.ableton.com/


From nicolas.kowenski at softogo.com  Mon Dec 13 19:31:38 2004
From: nicolas.kowenski at softogo.com (Nicolas Kowenski)
Date: Mon, 13 Dec 2004 18:31:38 +0000
Subject: [C++-sig] Path problems! - 
Message-ID: <41BDE00A.7080108@softogo.com>

Hello, i am trying to extend c++ class to python..
there are *2 ways to build my module*.. :
1- Run the python bin from my sources folder.

*cd  /home/dev/WireLessStudio/PythonWsUsrlib/src/
/home/dev/Python/Python-2.4/./python WS.py build*

Thats work... at least ther are no compilation errors. but does not work..:
 >>> import WS
usage:  [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or:  --help [cmd1 cmd2 ...]
   or:  --help-commands
   or:  cmd --help

error: no commands supplied
bash-2.05b$                  

2- The problem here, is the WS.cpp  include other headers located in
/home/dev/WireLessStudio/PythonWsUsrlib/src/  when i try to run these:

*cd /home/dev/Python/Python-2.4/
./python /home/dev/WireLessStudio/PythonWsUsrlib/src/WS.py build*

the gcc returned some errors. it cant found the included files in WS.cpp
and if I specify the path in WS.cpp like these:
#include </home/dev/WireLessStudio/PythonWsUsrlib/src/ WSApp.h> thats 
dont work, because WSApp.h calls other headers located in .../src/

If i move all (a lot)  the files to /home/dev/Python/Python-2.4/ i 
supouse thats works. but its very derty :'(

WS.py :
from distutils.core import setup, Extension

module3 = Extension('testclases1',
                    sources = ['WS.cpp'])

setup (name = 'PackageName',
       version = '1.0',
       description = 'probando claes en piton, gross',
       ext_modules = [module3])
WS.cpp:
#include "WSApp.h"
#include </home/dev/Python/Python-2.4/Include/Python.h>

WSApp app;



static PyObject *WStest_BC_AddBarcode(PyObject *self, PyObject *args)
{
    int sts;
    int nBarcodeType;
    int bExpand;
    int nDecode;
    int nMin;
    int nMax;
   
     if (!PyArg_ParseTuple(args, 
"ibiii",&nBarcodeType,&bExpand,&nDecode,&nMin,&nMax))  return NULL;
    sts = 
app.m_RFBarcode.AddBarcode(nBarcodeType,bExpand,nDecode,nMin,nMax);
    return Py_BuildValue("b", sts);
}

static PyMethodDef WStestMeth[] = {
    {"BC_AddBarcode", WStest_BC_AddBarcode, METH_VARARGS,"BC_AddBarcode"},
    {NULL, NULL, 0, NULL}        /* Sentinel */
};

PyMODINIT_FUNC initWStest(void)
{
    (void) Py_InitModule("WStest", WStestMeth);
}

int main(int argc, char *argv[])
{
  
    /* Pass argv[0] to the Python interpreter */
    Py_SetProgramName(argv[0]);

    /* Initialize the Python interpreter.  Required. */
    Py_Initialize();

    /* Add a static module */
    initWStest();
}


i try to invert the include order.. its the same.


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

From Paul_Kunz at slac.stanford.edu  Tue Dec 14 01:05:54 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Mon, 13 Dec 2004 16:05:54 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpj25k$o2e$1@sea.gmane.org> (message from David Abrahams on Sun, 
	12 Dec 2004 22:26:21 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>
	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>
	<cpj25k$o2e$1@sea.gmane.org>
Message-ID: <200412140005.iBE05s230302@libra3.slac.stanford.edu>

  I replaced the file

ftp://ftp.slac.stanford.edu/users/pfkeb/abrahams/HippoDraw-1.12.7.tar.gz

With one that illustrates the clone() problem.   One file, one script,
no threads.   


From amp at singingwizard.org  Tue Dec 14 01:58:33 2004
From: amp at singingwizard.org (Arthur Peters)
Date: Mon, 13 Dec 2004 18:58:33 -0600
Subject: [C++-sig] problems with weak_ptr to python object
Message-ID: <E1Ce11N-0006ac-AT@lazarus.localnet.local>


Hello,

I am working on a project that uses shared_ptr for more or less
everything, so weak_ptrs are important. I discovered that the
shared_ptrs created by boost.python from python objects that use
shared_ptr as a holder are not shared_ptrs managing the same object as
the holder, but are shared_ptrs managing a reference to the python
object. This is fine until you make a weak_ptr to it. Then the weak_ptr
will become invalid way before the actually object is destroyed.

See the thread from a year ago called "keeping weak_ptrs upon python
objects smart_ptrholders"
(http://mail.python.org/pipermail/c++-sig/2003-November/006337.html).
There was talk of fixing this problem. Did it go anywhere?

I have had the following thoughts:

The problem is that a shared_ptr directly related (sharing a use_count)
to the holder is only passed to C++ if the type requested exactly
matches the holder (I think). And in other cases, a unrelated (seperate
use_count) shared_ptr to the same object is passed.

If a shared_ptr<void> was used in place of the void*s in the converter
code the shared_ptr-ness could be preserved. It would be silly to use
shared_ptr<void> when the target type was a plain pointer so maybe it
would be possible to make a duplicate of a part of the "conversion
path" that used shared_ptr<void>. This path could be used by
shared_ptr_from_python to return shared_ptrs that are related to the
shared_ptr that is the holder.

Does any of that make sense? I'm having trouble explaining my self.

Thanks,
-Arthur


From qhf at oce.nl  Tue Dec 14 10:13:24 2004
From: qhf at oce.nl (Fred Houben)
Date: Tue, 14 Dec 2004 10:13:24 +0100
Subject: [C++-sig] Re: problem with overloaded address operator
References: <002e01c4d3c8$d6a89970$6bf6bc86@oce.nl>	<upt20bnco.fsf@boost-consulting.com><005101c4dba2$f5d5c930$6bf6bc86@oce.nl>	<cp2029$j03$1@sea.gmane.org><016501c4ddbb$d2839c80$6bf6bc86@oce.nl>
	<cp9ka0$cbm$1@sea.gmane.org>
Message-ID: <003301c4e1bd$2aafcf50$6bf6bc86@oce.nl>


----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Thursday, December 09, 2004 2:34 PM
Subject: [C++-sig] Re: problem with overloaded address operator


> Fred Houben wrote:
>
> > From: "David Abrahams" <dave at boost-consulting.com>
> >>
> >> > I've downloaded the latest version of boost.python from the cvs
server.
> >> > It seems that the problem of overloaded address operators shifts from
> >> > pointer_holder.hpp( v1.30.2) to to_python_indirect.hpp (latest cvs).
> >> > Replacing U* const p = &const_cast<U&>(x) with U* const p =
> >> > const_cast<U*>(boost::addressof(x)) fixes the problem.
> >> > I'm really not that familiar with the boost.python library, but this
seems
> >> > the only change needed.
> >> > If someone can point out other possible problems with overloaded
address
> >> > operators in boost.python, let me know.
> >> >
> >> > I've included the patched to_python_indirect.hpp.
> >>
> >> ?? This appears to be pointer_holder.hpp ??
> >>
> >> Do you know how to create a patch file?  One easy way is to make
> >> changes in your CVS image and then do a "cvs diff -du" from the
> >> top directory.
> >
> > Okay I've created a patch to fix the problem.
>
> Thanks; are you sure that's all that's needed?  The pointer_holder.hpp
> you sent also was using addressof().
>
> Also, would you mind contributing a testcase for libs/python/test that
> fails to compile without your patch?
>
> Thanks again,
>
> -- 
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com

i guess the testcase should be nothing more than one simple source file?
Is my guess correct?



From dave at boost-consulting.com  Tue Dec 14 13:54:59 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 14 Dec 2004 07:54:59 -0500
Subject: [C++-sig] Re: Path problems! -
In-Reply-To: <41BDE00A.7080108@softogo.com>
References: <41BDE00A.7080108@softogo.com>
Message-ID: <cpmnr6$1hr$4@sea.gmane.org>

Nicolas Kowenski wrote:
> Hello, i am trying to extend c++ class to python..
> there are *2 ways to build my module*.. :

This question is not C++-specific, so I suggest you'll get better
answers from comp.lang.python

Cheers,

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Tue Dec 14 13:52:57 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 14 Dec 2004 07:52:57 -0500
Subject: [C++-sig] Re: problem with overloaded address operator
In-Reply-To: <003301c4e1bd$2aafcf50$6bf6bc86@oce.nl>
References: <002e01c4d3c8$d6a89970$6bf6bc86@oce.nl>	<upt20bnco.fsf@boost-consulting.com><005101c4dba2$f5d5c930$6bf6bc86@oce.nl>	<cp2029$j03$1@sea.gmane.org><016501c4ddbb$d2839c80$6bf6bc86@oce.nl>	<cp9ka0$cbm$1@sea.gmane.org>
	<003301c4e1bd$2aafcf50$6bf6bc86@oce.nl>
Message-ID: <cpmnnc$1hr$3@sea.gmane.org>

Fred Houben wrote:
> ----- Original Message ----- 

> i guess the testcase should be nothing more than one simple source file?
> Is my guess correct?

That would work, although I'm guessing it's possible to produce a case
with the existing codebase that compiles but fails at runtime.  So the
ideal would be a pair of C++/python files as found in libs/python/test/
that actually causes addressof() to be used and shows that it works.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Paul_Kunz at slac.stanford.edu  Tue Dec 14 18:36:27 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Tue, 14 Dec 2004 09:36:27 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpj25k$o2e$1@sea.gmane.org> (message from David Abrahams on Sun, 
	12 Dec 2004 22:26:21 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>
	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>
	<cpj25k$o2e$1@sea.gmane.org>
Message-ID: <200412141736.iBEHaRH01204@libra3.slac.stanford.edu>

>>>>> On Sun, 12 Dec 2004 22:26:21 -0500, David Abrahams <dave at boost-consulting.com> said:

> Paul F. Kunz wrote:
>> This clone function doesn't quite work ...
>> 
>> FunctionBase* clone() { PyGILState_STATE state = PyGILState_Ensure
>> (); object py_result;
>> 
>> if (override clone = this->get_override("clone")) { // The Python
>> class author overrode clone; do // whatever she says py_result =
>> clone(); } else { object self = get_owner(this);
>> 
>> // Find its most-derived Python class object my_class =
>> self.attr("__class__");
>> 
>> // call the copy ctor through Python.  
>> py_result = my_class(self);

   The line above was the problem   It should be

   py_result = my_class();

i.e., no arguments.

Thanks Dave for your help and patience with me.


From Paul_Kunz at slac.stanford.edu  Tue Dec 14 20:37:20 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Tue, 14 Dec 2004 11:37:20 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cp8fgb$pi8$1@sea.gmane.org> (message from David Abrahams on Wed, 
	08 Dec 2004 22:06:37 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>
	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>
	<cp8fgb$pi8$1@sea.gmane.org>
Message-ID: <200412141937.iBEJbKu01793@libra3.slac.stanford.edu>

   I'm having problem with destructor suggested by Dave

FunctionWrap::
~FunctionWrap ()
{
  cout << "FunctionWrap::destructor"
       << endl;

  extract<std::auto_ptr<FunctionWrap>&> x(get_owner(this));

  if ( x.check() ) x().release();
}

When I quit python, it appears to be called recursively before things
die on seg fault.




From dave at boost-consulting.com  Tue Dec 14 21:40:10 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 14 Dec 2004 15:40:10 -0500
Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual
	function
In-Reply-To: <200412140005.iBE05s230302@libra3.slac.stanford.edu>
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>	<cpj25k$o2e$1@sea.gmane.org>
	<200412140005.iBE05s230302@libra3.slac.stanford.edu>
Message-ID: <cpnj3f$pt8$1@sea.gmane.org>

Paul F. Kunz wrote:
>   I replaced the file
> 
> ftp://ftp.slac.stanford.edu/users/pfkeb/abrahams/HippoDraw-1.12.7.tar.gz
> 
> With one that illustrates the clone() problem.   One file, one script,
> no threads.   

Paul, I've take a look, but you really could make my life easier.  I
don't need makefiles or (worse) autoconf ".in" files.  I don't need
subdirectories.  I just want a .cpp (not .cxx, if we're going to pick
nits) and a .py file.  You could strip out all the extraneous macros too.

Traceback (most recent call last):
  File "c:\boost\libs\python\user\hippo/fitting.py", line 32, in ?
    f.test()
TypeError: __init__() takes exactly 1 argument (2 given)
[5611 refs]

So your problem is really simple.  In cloning the Linear object you've
created, its __init__ method is getting called with *another* Linear
object that should be the source of the clone operation.  But your
Linear's __init__ function only takes one argument, as the error message
says.

If you want to pass through both default construction and copy
construction, you have to write something like:

    def __init__ ( self, other = None ):
        if other:
            FunctionBase.__init__(self, other)
        else:
            FunctionBase.__init__(self)

But then, this is boring; why don't you leave off the __init__ function
altogether?  Then the one(s) supplied by FunctionBase will get called.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Paul_Kunz at slac.stanford.edu  Tue Dec 14 21:45:59 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Tue, 14 Dec 2004 12:45:59 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpnj3f$pt8$1@sea.gmane.org> (message from David Abrahams on Tue, 
	14 Dec 2004 15:40:10 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>	<cpj25k$o2e$1@sea.gmane.org>
	<200412140005.iBE05s230302@libra3.slac.stanford.edu>
	<cpnj3f$pt8$1@sea.gmane.org>
Message-ID: <200412142045.iBEKjxr09538@libra3.slac.stanford.edu>

>>>>> On Tue, 14 Dec 2004 15:40:10 -0500, David Abrahams <dave at boost-consulting.com> said:

> Paul F. Kunz wrote:
>> I replaced the file
>> 
>> ftp://ftp.slac.stanford.edu/users/pfkeb/abrahams/HippoDraw-1.12.7.tar.gz
>> 
>> With one that illustrates the clone() problem.  One file, one
>> script, no threads.

> Paul, I've take a look, but you really could make my life easier.  I
> don't need makefiles or (worse) autoconf ".in" files.  I don't need
> subdirectories.  I just want a .cpp (not .cxx, if we're going to
> pick nits) and a .py file.  You could strip out all the extraneous
> macros too.

   I think I solved that problem, see item I posted after this one.


From dave at boost-consulting.com  Tue Dec 14 21:41:02 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 14 Dec 2004 15:41:02 -0500
Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual
	function
In-Reply-To: <200412141736.iBEHaRH01204@libra3.slac.stanford.edu>
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>	<cpj25k$o2e$1@sea.gmane.org>
	<200412141736.iBEHaRH01204@libra3.slac.stanford.edu>
Message-ID: <cpnj52$pt8$2@sea.gmane.org>

Paul F. Kunz wrote:
>>>>>> On Sun, 12 Dec 2004 22:26:21 -0500, David Abrahams <dave at boost-consulting.com> said:
> 
>> Paul F. Kunz wrote:
>>> This clone function doesn't quite work ...
>>> 
>>> FunctionBase* clone() { PyGILState_STATE state = PyGILState_Ensure
>>> (); object py_result;
>>> 
>>> if (override clone = this->get_override("clone")) { // The Python
>>> class author overrode clone; do // whatever she says py_result =
>>> clone(); } else { object self = get_owner(this);
>>> 
>>> // Find its most-derived Python class object my_class =
>>> self.attr("__class__");
>>> 
>>> // call the copy ctor through Python.  
>>> py_result = my_class(self);
> 
>    The line above was the problem   It should be
> 
>    py_result = my_class();
> 
> i.e., no arguments.

No, that's wrong.  That line is supposed to call the exposed copy ctor.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Tue Dec 14 21:59:53 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 14 Dec 2004 15:59:53 -0500
Subject: [C++-sig] Re: Making copy of function derived from C++ pure virtual
	function
In-Reply-To: <200412142045.iBEKjxr09538@libra3.slac.stanford.edu>
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>	<cpj25k$o2e$1@sea.gmane.org>	<200412140005.iBE05s230302@libra3.slac.stanford.edu>	<cpnj3f$pt8$1@sea.gmane.org>
	<200412142045.iBEKjxr09538@libra3.slac.stanford.edu>
Message-ID: <cpnk8d$shd$2@sea.gmane.org>

Paul F. Kunz wrote:
>>>>>> On Tue, 14 Dec 2004 15:40:10 -0500, David Abrahams <dave at boost-consulting.com> said:
> 
>> Paul F. Kunz wrote:
>>> I replaced the file
>>> 
>>> ftp://ftp.slac.stanford.edu/users/pfkeb/abrahams/HippoDraw-1.12.7.tar.gz
>>> 
>>> With one that illustrates the clone() problem.  One file, one
>>> script, no threads.
> 
>> Paul, I've take a look, but you really could make my life easier.  I
>> don't need makefiles or (worse) autoconf ".in" files.  I don't need
>> subdirectories.  I just want a .cpp (not .cxx, if we're going to
>> pick nits) and a .py file.  You could strip out all the extraneous
>> macros too.
> 
>    I think I solved that problem, see item I posted after this one.

No, your "solution" was in error.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Tue Dec 14 21:55:34 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 14 Dec 2004 15:55:34 -0500
Subject: [C++-sig] Re: Disallow adding attributes to wrapped classes from
	Python
In-Reply-To: <1goqprt.1wv05mxq616r3M%haller@ableton.com>
References: <cpjvt7$nj3$1@sea.gmane.org>
	<1goqprt.1wv05mxq616r3M%haller@ableton.com>
Message-ID: <cpnk0b$shd$1@sea.gmane.org>

Stefan Haller wrote:
> David Abrahams <dave at boost-consulting.com> wrote:
> 
>> Naw, you're right.  Are you willing to use the Boost CVS?
> 
> Not easily, sorry.  And I'm not sure if the feature is important enough
> for us to go to the trouble, and to waste your time on it.
> 
> (But I could easily use a patch if it can be applied against the 1.32.0
>  release; I have no idea how realistic this is.)

Nearly as easy as making the change in CVS.  What I'd like from you
first is a test case along the lines of any one in libs/python/test (one
xxxx.cpp and one xxxx.py) that demonstrates the problem you're trying to
solve and fails unless it is solved.  Then I can make the changes to the
codebase and update the docs.

>> You could fake it, but it wouldn't work nearly as well:
>> 
>>    object proxy
>>    = class<anything>("anything")
>>       .add_property("foobar", &Foo::getFooBar, &Foo::setFooBar);
>> 
>>    object metaclass = proxy.attr("__class__");
>> 
>>    dict d = proxy().attr("__dict__");
>>    d["__slots__"] = tuple();
>>    scope().attr("Foo")
>>       = metaclass("Foo", tuple(), d);
>> 
>> You'd lose the benefit of a conversion from C++ Foo to Python, for
>> example.  But you might try the above anyway just to make sure I'm not
>> wasting my time with the patch.
> 
> Phew.  I'm afraid I don't understand this code at all.  I tried to get
> it to work for a simple test case, with the following adjustments to
> make it compile (not really knowing what I was doing):
> 
> -    = class<anything>("anything")
> +    = class_<Foo>("anything")

No, I really did mean for you to wrap some other class here.  Just
declare struct anything{};

> -    dict d = proxy().attr("__dict__");
> +    dict d(proxy().attr("__dict__"));
> 
> But no, this doesn't work.  It *does* prevent me from adding new
> attributes, but it also doesn't show the existing property (foobar),
> which is not much progress.  :-)

Oh, heck.  I know why.

>>>> f = Foo()
>>>> f.foobar
> Traceback (most recent call last):
> File "<string>", line 1, in ?
> AttributeError: 'Foo' object has no attribute 'foobar'
>>>> f.x = 1
> Traceback (most recent call last):
> File "<string>", line 1, in ?
> AttributeError: 'Foo' object has no attribute 'x'
>>>> dir(f)
> ['__class__', '__delattr__', '__doc__', '__getattribute__',
> '__getstate__', '__hash__', '__init__', '__new__', '__reduce__',
> '__repr__', '__setattr__', '__slots__', '__str__']
> 
> 


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Tue Dec 14 21:52:14 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 14 Dec 2004 15:52:14 -0500
Subject: [C++-sig] Re: problems with weak_ptr to python object
In-Reply-To: <E1Ce11N-0006ac-AT@lazarus.localnet.local>
References: <E1Ce11N-0006ac-AT@lazarus.localnet.local>
Message-ID: <cpnjq4$ruq$1@sea.gmane.org>

Arthur Peters wrote:
> Hello,
> 
> I am working on a project that uses shared_ptr for more or less
> everything, so weak_ptrs are important. I discovered that the
> shared_ptrs created by boost.python from python objects that use
> shared_ptr as a holder are not shared_ptrs managing the same object as
> the holder, but are shared_ptrs managing a reference to the python
> object. This is fine until you make a weak_ptr to it. Then the weak_ptr
> will become invalid way before the actually object is destroyed.

Interesting.

The way to get at the underlying shared_ptr is to convert the Python
object to a non-const shared_ptr&.  So you could do:

template <class T>
weak_ptr<T> get_weak_ptr(shared_ptr<T> const& x)
{
    object python_owner(x);
    shared_ptr<T>& inner_shared_ptr(
          extract<shared_ptr<T>&>(python_owner));
    return inner_shared_ptr; // convert to weak_ptr.
};

> See the thread from a year ago called "keeping weak_ptrs upon python
> objects smart_ptrholders"
> (http://mail.python.org/pipermail/c++-sig/2003-November/006337.html).
> There was talk of fixing this problem. Did it go anywhere?

Was a solution proposed?  Oh, I see:

----schnipp------
wouldn't it be possible, when converting the arguments provided to a
function, that if :

- a shared_ptr (weak_ptr) argument is the 'target' of a specified implicit
conversion whose source is the type of
  the provided value for the argument

- AND the provided value wrapper is held by shared_ptr

- THEN the shared_ptr " conjured up 'from thin air' " is contructed from the
shared_ptr holding the provided value
  thus having a valid reference count

I don't if/where/how all this could be done, and if it covers every aspect
of the problem !
-----schnapp------

The problem is that the existing conversion has great value even when
the inner objects are held by shared_ptr.  If you're going to pass the
shared_ptr back to Python you should see the same managing object.
Otherwise you can end up with two different Python objects managing the
same C++ base sub-object <shiver>.

> I have had the following thoughts:
> 
> The problem is that a shared_ptr directly related (sharing a use_count)
> to the holder 

You lost me.  Which holder?

> is only passed to C++ if the type requested exactly
> matches the holder (I think). 


Example?

> And in other cases, a unrelated (seperate
> use_count) shared_ptr to the same object is passed.


> If a shared_ptr<void> was used in place of the void*s in the converter
> code the shared_ptr-ness could be preserved. It would be silly to use
> shared_ptr<void> when the target type was a plain pointer so maybe it
> would be possible to make a duplicate of a part of the "conversion
> path" that used shared_ptr<void>. This path could be used by
> shared_ptr_from_python to return shared_ptrs that are related to the
> shared_ptr that is the holder.
> 
> Does any of that make sense? I'm having trouble explaining my self.

No and yes ;-)

Give some code examples to show what you mean.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Paul_Kunz at slac.stanford.edu  Tue Dec 14 22:18:07 2004
From: Paul_Kunz at slac.stanford.edu (Paul F. Kunz)
Date: Tue, 14 Dec 2004 13:18:07 -0800
Subject: [C++-sig] Re: Making copy of function derived from C++ pure
	virtual function
In-Reply-To: <cpnj52$pt8$2@sea.gmane.org> (message from David Abrahams on Tue, 
	14 Dec 2004 15:41:02 -0500)
References: <200412081858.iB8Iw3a12866@libra3.slac.stanford.edu>	<cp7ljt$p9p$1@sea.gmane.org>	<200412082014.iB8KELf13038@libra3.slac.stanford.edu>	<cp8fgb$pi8$1@sea.gmane.org>	<200412122133.iBCLXwB21886@libra3.slac.stanford.edu>	<cpj25k$o2e$1@sea.gmane.org>
	<200412141736.iBEHaRH01204@libra3.slac.stanford.edu>
	<cpnj52$pt8$2@sea.gmane.org>
Message-ID: <200412142118.iBELI7M15815@libra3.slac.stanford.edu>

>>>>> On Tue, 14 Dec 2004 15:41:02 -0500, David Abrahams <dave at boost-consulting.com> said:

>> 
>> py_result = my_class();
>> 
>> i.e., no arguments.

> No, that's wrong.  That line is supposed to call the exposed copy
> ctor.

   I restored 

py_result = my_class ( self )

and exposed the copy constructor as you suggested.   This works.

Thanks again, Dave.


From haller at ableton.com  Wed Dec 15 16:47:22 2004
From: haller at ableton.com (Stefan Haller)
Date: Wed, 15 Dec 2004 16:47:22 +0100
Subject: [C++-sig] Re: Disallow adding attributes to wrapped classes from
	Python
In-Reply-To: <cpnk0b$shd$1@sea.gmane.org>
Message-ID: <1gougx9.fpf7yro3j5t1M%haller@ableton.com>

David Abrahams <dave at boost-consulting.com> wrote:

> What I'd like from you first is a test case along the lines of any one in
> libs/python/test (one xxxx.cpp and one xxxx.py) that demonstrates the
> problem you're trying to solve and fails unless it is solved.

OK.  Will this do?  (Sorry for pasting directly into the mail, my mailer
doesn't support file attachments.)

Mind the "Todo" comment in the .cpp file.


>>>>>>>>>>>>>>>> immutable_instance_dict.cpp
#include <boost/python.hpp>

using namespace boost::python;

class Foo
{
public:
  Foo() { a = 42; }

  int get_a() const { return this->a; }
  void set_a(int a) { this->a = a; }

private:
  int a;
};


BOOST_PYTHON_MODULE(immutable_instance_dict_ext)
{
  // Todo: add a template parameter (or something) to request that
  // we want instance __dict__s to be immutable
  class_<Foo>("Foo")
    .add_property("a", &Foo::get_a, &Foo::set_a)
  ;
}


#include "module_tail.cpp"
<<<<<<<<<<<<<<<< immutable_instance_dict.cpp


>>>>>>>>>>>>>>>> immutable_instance_dict.py
"""
>>> from immutable_instance_dict_ext import *
>>> f = Foo()
>>> f.a
42
>>> f.a = 3
>>> f.a
3
>>> try:
...   f.b = 5
... except AttributeError:
...   pass
... else:
...   print "Expected AttributeError."
...
"""


def run(args = None):
    import sys
    import doctest

    if args is not None:
        sys.argv = args
    return doctest.testmod(sys.modules.get(__name__))

if __name__ == '__main__':
    print "running..."
    import sys
    status = run()[0]
    if (status == 0): print "Done."
    sys.exit(status)
<<<<<<<<<<<<<<<< immutable_instance_dict.py


-- 
Stefan Haller
Ableton
http://www.ableton.com/


From johan at carlstedt.net  Wed Dec 15 23:25:39 2004
From: johan at carlstedt.net (Johan Carlstedt)
Date: Wed, 15 Dec 2004 22:25:39 +0000
Subject: [C++-sig] [Boost] [Graph] Problem compiling  on Solaris 10
Message-ID: <41C0B9E3.1010308@carlstedt.net>

Hello,

I am having problems compiling Boost 1.32 on Solaris 10 X86 with gcc 
3.4.1 and Python 2.23. The compilation fails for libboost_python with 
the error message below. I have tried with and without "-fpermissive".

I would be grateful if anyone was able to advice.

With friendly regards,

Johan Carlstedt

bash-2.05b# bjam "-sTOOLS=gcc" "-sGXX=g++ -fpermissive" install
....found 11612 targets...
....updating 32 targets...
gcc-C++-action
bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-
true/inheritance.o
In file included
from /export/home/johan/boost_1_32_0/libs/python/build/../src/object/inherit
ance.cpp:11:
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441: error:
expected identifier before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441:
warning: ISO C++ forbids declaration of `parameter' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441: error:
expected `>' before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`VP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`EP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`GP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`EL' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
type/value mismatch at argument 3 in template parameter list for
`template<class OutEdgeListS, class VertexListS, class DirectedS, class
VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS>
class boost::adjacency_list'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444:
error:   expected a type, got `3'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
template argument 4 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
template argument 5 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
template argument 6 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
template argument 7 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error:
`Tag' has not been declared
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445: error:
expected `,' or `...' before '&' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445:
warning: ISO C++ forbids declaration of `g' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445:
warning: ISO C++ forbids declaration of `parameter' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445:
warning: ISO C++ forbids declaration of `Value' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp: In function
`void boost::set_property(int&, int, int)':
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error:
`m_property' has not been declared
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error:
request for member of non-aggregate type before ',' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446:
warning: there are no arguments to `Tag' that depend on a template
parameter, so a declaration of `Tag' must be available
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error:
`value' undeclared (first use this function)
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error:
(Each undeclared identifier is reported only once for each function it
appears in.)
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp: At global
scope:
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449: error:
expected identifier before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449:
warning: ISO C++ forbids declaration of `parameter' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449: error:
expected `>' before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`VP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`EP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`GP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`EL' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
type/value mismatch at argument 3 in template parameter list for
`template<class OutEdgeListS, class VertexListS, class DirectedS, class
VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS>
class boost::adjacency_list'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452:
error:   expected a type, got `3'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 4 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 5 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 6 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 7 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
`Tag' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 1 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
template argument 2 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
expected init-declarator before '&' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error:
expected `;' before '&' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457: error:
expected identifier before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457:
warning: ISO C++ forbids declaration of `parameter' with no type
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457: error:
expected `>' before numeric constant
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`VP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`EP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`GP' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`EL' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
type/value mismatch at argument 3 in template parameter list for
`template<class OutEdgeListS, class VertexListS, class DirectedS, class
VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS>
class boost::adjacency_list'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461:
error:   expected a type, got `3'
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 4 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 5 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 6 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 7 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
`Tag' was not declared in this scope
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 1 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
template argument 2 is invalid
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
expected init-declarator before '&' token
/export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error:
expected `;' before '&' token






From kvance at wam.umd.edu  Wed Dec 15 23:38:40 2004
From: kvance at wam.umd.edu (Kevin Vance)
Date: Wed, 15 Dec 2004 17:38:40 -0500 (EST)
Subject: [C++-sig] Wrapping C++ class with unnamed union
Message-ID: <Pine.LNX.4.58.0412151727420.26333@localhost>

Hi,

I am new to boost.python, so there may be a very simple answer to this.
I would like to access the OGRE graphics library from python.  But it has
several classes with data like this:

union {
  struct {
    Real r,g,b,a;
  };
  Real val[4];
};

And I cannot access e.g. 'r' with a statement like:

.def_readwrite("r", &Ogre::ColourValue::r)

I'm assuming this is because there is an unnamed union and unnamed struct
in between the class and the 'r'.  I could write a new C++ class to wrap
this one, and then use boost to wrap *that*.  But if there is a simpler
way, I would rather use it.

Thanks for your advice,
kvance


From dave at boost-consulting.com  Thu Dec 16 02:14:10 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 15 Dec 2004 20:14:10 -0500
Subject: [C++-sig] Re: Wrapping C++ class with unnamed union
In-Reply-To: <Pine.LNX.4.58.0412151727420.26333@localhost>
References: <Pine.LNX.4.58.0412151727420.26333@localhost>
Message-ID: <cpqnhg$p06$1@sea.gmane.org>

Kevin Vance wrote:
> Hi,
> 
> I am new to boost.python, so there may be a very simple answer to this.
> I would like to access the OGRE graphics library from python.  But it has
> several classes with data like this:
> 
> union {
>   struct {
>     Real r,g,b,a;
>   };
>   Real val[4];
> };
> 
> And I cannot access e.g. 'r' with a statement like:
> 
> ..def_readwrite("r", &Ogre::ColourValue::r)
> 
> I'm assuming this is because there is an unnamed union and unnamed struct
> in between the class and the 'r'.  I could write a new C++ class to wrap
> this one, and then use boost to wrap *that*.  But if there is a simpler
> way, I would rather use it.

write getter and setter functions and use add_property:

   Real get_r(Ogre::ColourValue& c)  {return c.r;}
   void set_r(Ogre::ColourValue& c, Real x)  { c.r = x;}

   class_<Ogre::ColourValue>(....)
       .add_property("r", get_r, set_r)

HTH,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Thu Dec 16 02:17:28 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 15 Dec 2004 20:17:28 -0500
Subject: [C++-sig] Re: [Boost] [Graph] Problem compiling  on Solaris 10
In-Reply-To: <41C0B9E3.1010308@carlstedt.net>
References: <41C0B9E3.1010308@carlstedt.net>
Message-ID: <41C0E228.8030003@boost-consulting.com>

Johan Carlstedt wrote:
> Hello,
> 
> I am having problems compiling Boost 1.32 on Solaris 10 X86 with gcc 
> 3.4.1 and Python 2.23. The compilation fails for libboost_python with 
> the error message below. I have tried with and without "-fpermissive".
> 
> I would be grateful if anyone was able to advice.

I'm very sorry that you haven't received a reply from the Boost Graph
Library maintainers by now.  I don't know why -- they're usually much
more responsive than this.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Kingdom.Lin at yeah.net  Thu Dec 16 08:21:21 2004
From: Kingdom.Lin at yeah.net (Donnie Leen)
Date: Thu, 16 Dec 2004 15:21:21 +0800
Subject: [C++-sig] what happened with this std::string parameter in
	boost.python
Message-ID: <20041216072015.4E0ED1E4008@bag.python.org>

I made a program embedding boost.python, writting a module as following:

void write( std::string s )
{
	// do nothing
}
BOOST_PYTHON_MODULE(mym)
{
	def( "write", &write );
}


I run the python code:
import mym
s = 'hello'
mym.write(s)

it runs ok, but if i run the python code as following:
import mym
s = int.__doc__
mym.write(s)

it crashed, and it seems to crashed while boost.python try to delete the parameter s.
Can someone tell me what happened to it? Thanks first.


Donnie Leen





From jmastro at rochester.rr.com  Thu Dec 16 09:18:30 2004
From: jmastro at rochester.rr.com (James Mastro)
Date: Thu, 16 Dec 2004 03:18:30 -0500
Subject: [C++-sig] code generation problems
Message-ID: <001c01c4e347$d4a25c90$2602a8c0@jimswindows>

I am having a big problem with BPL. When my extension module is compiled by
bjam I think it is giving me bad code. I have a couple of functions in a C++
object that have almost the same signature, just slightly different names. I
have a free function in the extension module for each of these that calls
into the C++ object:

MyObject*    gObject;
void DoSomethingToObject( int data )
{
    gObject->DoSomething( data );
}

void SomethingElseToObject( int data )
{
    gObject->SomethingElse( data );
}

gObject is a valid ptr.

When this code executes, the gObject->DoSomething call actually calls
gObject->SomethingElse and vise versa! So I went and changed names thinking
maybe it was confused by similar names, that didn't help. I went as far as
to add some bogus parameters to SomethingElse but even that did not work. It
still happily calls the wrong function even though it was called with a
different number of parameters. Now I don't trust the VS debugger at all,
but as I step through the code everything seems to make sense. It's
executing the code it's stepping through, it's not just displaying the wrong
lines of code as it has done before for me.
The 2 free functions that are called from Python get called fine. They're 
called by other C++ code not related to my module and it works fine. It's 
just
the call into gObject that is bad from the wrapped free functions. If you 
ignore the fact that it's calling
a function with different number of parameters and filling those in with
garbage, even after the bogus call everything is working OK until an
assertion of mine fails because the wrong function has been called at the
wrong time. The gObject class looks just fine to me. Calling some other 
gObject member functions instead works fine. It's just the DoSomething and 
SomethingElse ones that are problematic. Thinking I probably had
bad code elsewhere or something I moved the calls to these 2 free functions
up so they're basically the first things called by the Python script, but I
get the same result.

Are there any known problems with compiling modules that would lead to
something like this? I don't even know where to start. I guess I will have
to try to come up with a small example demonstrating the problem. This is 
using boost 1.32 with vc-7_1.

-jim



From GCopeland at efjohnson.com  Thu Dec 16 23:03:54 2004
From: GCopeland at efjohnson.com (Greg Copeland)
Date: Thu, 16 Dec 2004 16:03:54 -0600
Subject: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
Message-ID: <0392B3A5F875DB4295BD6A949A7839EF8C86B5@efjdfw.local>

I'm attempting to compile Boost (3.1.1) and especially Boost.Python
against Python 2.3.4 on VxWorks.  I have done so, without problem, via
cygwin (g++ 3.3.3).  So, I know the version of python isn't the problem.
The compiler provided by WRS, to use for VxWorks, is g++ 2.96 (ya, I
know).  I did a number of searches and found that some portions of Boost
are said not to compile with this compiler, however, I found a message
from Dave Abrahams, in August 2003, who said that this compiler is
supported with Boost.Python.  Is this still the case?  Should I
reasonably expect Boost & Boost.Python to compile using this compiler?

 

Is there anyone currently using this compiler with Boost.Python?

 

 

Best Regards,

 

Greg Copeland

 

 

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

From dave at boost-consulting.com  Fri Dec 17 00:00:22 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 16 Dec 2004 18:00:22 -0500
Subject: [C++-sig] Re: code generation problems
In-Reply-To: <001c01c4e347$d4a25c90$2602a8c0@jimswindows>
References: <001c01c4e347$d4a25c90$2602a8c0@jimswindows>
Message-ID: <41C21386.5020400@boost-consulting.com>

James Mastro wrote:
> I am having a big problem with BPL. When my extension module is compiled by
> bjam I think it is giving me bad code. I have a couple of functions in a C++
> object that have almost the same signature, just slightly different names. I
> have a free function in the extension module for each of these that calls
> into the C++ object:
> 
> MyObject*    gObject;
> void DoSomethingToObject( int data )
> {
>     gObject->DoSomething( data );
> }
> 
> void SomethingElseToObject( int data )
> {
>     gObject->SomethingElse( data );
> }
> 
> gObject is a valid ptr.
> 
> When this code executes, the gObject->DoSomething call actually calls
> gObject->SomethingElse and vise versa! 

If that is in fact the case you are not having a BPL problem at all:
it's simply a compiler bug.  You should reduce the problem to a minimal
case that doesn't involve BPL and post it to a microsoft support
newsgroup or other such resource at this point.

> So I went and changed names thinking
> maybe it was confused by similar names, that didn't help. I went as far as
> to add some bogus parameters to SomethingElse but even that did not work. It
> still happily calls the wrong function even though it was called with a
> different number of parameters. Now I don't trust the VS debugger at all,

I'm surprised; I find it to be very good.

> but as I step through the code everything seems to make sense. It's
> executing the code it's stepping through, it's not just displaying the wrong
> lines of code as it has done before for me.

I'm not sure exactly what you mean by "seems to make sense."  Do you
mean that when you step into the call to DoSomething the PC is shown
somewhere inside the source code to DoSomething?

> Are there any known problems with compiling modules that would lead to
> something like this? I don't even know where to start. I guess I will have
> to try to come up with a small example demonstrating the problem. This is 
> using boost 1.32 with vc-7_1.

Yes, but unless you have a good reason to think this is BPL-related, you
should take your problem elsewhere.  It's not that I'm unsympathetic,
but I don't think there's anything I can do to help you.

Sorry,

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Fri Dec 17 00:05:02 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 16 Dec 2004 18:05:02 -0500
Subject: [C++-sig] Re: what happened with this std::string parameter in
	boost.python
In-Reply-To: <20041216072015.4E0ED1E4008@bag.python.org>
References: <20041216072015.4E0ED1E4008@bag.python.org>
Message-ID: <cpt4b7$sn7$1@sea.gmane.org>

Donnie Leen wrote:
> I made a program embedding boost.python, writting a module as following:
> 
> void write( std::string s )
> {
> 	// do nothing
> }
> BOOST_PYTHON_MODULE(mym)
> {
> 	def( "write", &write );
> }
> 
> 
> I run the python code:
> import mym
> s = 'hello'
> mym.write(s)
> 
> it runs ok, but if i run the python code as following:
> import mym
> s = int.__doc__
> mym.write(s)
> 
> it crashed

What do you mean by "crashed?"  Are you sure it didn't throw an
exception that was never caught?

> , and it seems to crashed while boost.python try to delete the parameter s.
> Can someone tell me what happened to it? Thanks first.

I suggest you insert the contents of libs/python/test/module_tail.cpp
into your program, run it again, and see where the JIT debugger says the
"crash" occurs.

I also suggest you try putting the logic of your program inside a call
to python::handle_exception, per libs/python/test/embedding.cpp:

    if (python::handle_exception(something))
    {
        if (PyErr_Occurred())
            PyErr_Print();
        return 1;
    }


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Fri Dec 17 01:39:54 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 16 Dec 2004 19:39:54 -0500
Subject: [C++-sig] Re: code generation problems
In-Reply-To: <41C21386.5020400@boost-consulting.com>
References: <001c01c4e347$d4a25c90$2602a8c0@jimswindows>
	<41C21386.5020400@boost-consulting.com>
Message-ID: <cpt9t3$914$1@sea.gmane.org>

David Abrahams wrote:

> Yes, but unless you have a good reason to think this is BPL-related, you
> should take your problem elsewhere.  It's not that I'm unsympathetic,
> but I don't think there's anything I can do to help you.

Except, of course, to Cc: a microsoft compiler engineer, who came back with:

There is a linker optimization that we do that describes some of the
behavior he is describing.  He could try passing -opt:noref to the
link.exe and see if the problem goes away.

So add "-sBUILD=<linkflags>-opt:noref" to the beginning of your bjam
command-line and see what happens.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Fri Dec 17 01:58:40 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 16 Dec 2004 19:58:40 -0500
Subject: [C++-sig] Re: code generation problems
In-Reply-To: <cpt9t3$914$1@sea.gmane.org>
References: <001c01c4e347$d4a25c90$2602a8c0@jimswindows>	<41C21386.5020400@boost-consulting.com>
	<cpt9t3$914$1@sea.gmane.org>
Message-ID: <cptb0a$b57$1@sea.gmane.org>

David Abrahams wrote:
> David Abrahams wrote:
> 
>> Yes, but unless you have a good reason to think this is BPL-related, you
>> should take your problem elsewhere.  It's not that I'm unsympathetic,
>> but I don't think there's anything I can do to help you.
> 
> Except, of course, to Cc: a microsoft compiler engineer, who came back with:
> 
> There is a linker optimization that we do that describes some of the
> behavior he is describing.  He could try passing -opt:noref to the
> link.exe and see if the problem goes away.
> 
> So add "-sBUILD=<linkflags>-opt:noref" to the beginning of your bjam
> command-line and see what happens.

And then he said:

"Whoops, I told you the wrong option, it should have been -opt:noicf.
icf is short for identical comdat folding."

So add "-sBUILD=<linkflags>-opt:noicf"

HTH,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From rwgk at yahoo.com  Fri Dec 17 04:47:11 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 16 Dec 2004 19:47:11 -0800 (PST)
Subject: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
In-Reply-To: <0392B3A5F875DB4295BD6A949A7839EF8C86B5@efjdfw.local>
Message-ID: <20041217034711.18424.qmail@web20227.mail.yahoo.com>

--- Greg Copeland <GCopeland at efjohnson.com> wrote:

> Is there anyone currently using this compiler with Boost.Python?

I am using the gcc 2.96 that comes with Red Hat 7.3. I had to come up with a
few workarounds but I am not aware of major problems.

Ralf



		
__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page ? Try My Yahoo!
http://my.yahoo.com 


From jmastro at rochester.rr.com  Fri Dec 17 08:59:09 2004
From: jmastro at rochester.rr.com (James Mastro)
Date: Fri, 17 Dec 2004 02:59:09 -0500
Subject: [C++-sig] Re: code generation problems
References: <001c01c4e347$d4a25c90$2602a8c0@jimswindows>
	<41C21386.5020400@boost-consulting.com>
	<cpt9t3$914$1@sea.gmane.org>
Message-ID: <007b01c4e40e$4a6514b0$2602a8c0@jimswindows>

David Abrahams wrote:
>> Yes, but unless you have a good reason to think this is BPL-related, you
>> should take your problem elsewhere.  It's not that I'm unsympathetic,
>> but I don't think there's anything I can do to help you.
>
> Except, of course, to Cc: a microsoft compiler engineer, who came back 
> with:
> "-sBUILD=<linkflags>-opt:noicf"

Great. I'll give that a shot tomorrow. I knew it wasn't bjam or bpl causing 
the problem, I worded it poorly. That's not one of my finer posts now that I 
read it again. Thank you for taking the time to look into it despite that.

>I'm not sure exactly what you mean by "seems to make sense."  Do you
>mean that when you step into the call to DoSomething the PC is shown
> somewhere inside the source code to DoSomething?

Yes, but more than that. Files that were supposed to be created or read from 
were actually being done, etc. So when DoSomething was shown as being 
stepped into, it was actually doing that despite the caller displaying a 
different function name than what was actually being stepped into. I agree 
about the VS debugger being quite good, my comment was idiotic. I went 
through a period trying to learn a new system (and BPL, actually) with a 
totally useless debugger, showing me code not what it was really executing, 
variable info being totally wrong or showing nothing, debugger crashing 
frequently, but upon further review that wasn't even on Windows. All those 
problems have since been fixed and that previously nasty debugger works 
great now last time I checked so I can't complain about any of the debuggers 
anymore. I jump around to too many systems for my own good, though.

-jim 



From GCopeland at efjohnson.com  Fri Dec 17 16:28:42 2004
From: GCopeland at efjohnson.com (Greg Copeland)
Date: Fri, 17 Dec 2004 09:28:42 -0600
Subject: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
Message-ID: <0392B3A5F875DB4295BD6A949A7839EF8C8885@efjdfw.local>

What type of problems did you encounter?  Can you describe the types of
"workarounds" that you had to implement?  Did you encounter any problems
using boost/operators.hpp?  Did you get complaints about template
default arguments...etc...?


Cheers,
 
Greg Copeland
 
> -----Original Message-----
> From: c++-sig-bounces+gcopeland=efjohnson.com at python.org
[mailto:c++-sig-
> bounces+gcopeland=efjohnson.com at python.org] On Behalf Of Ralf W.
Grosse-
> Kunstleve
> Sent: Thursday, December 16, 2004 9:47 PM
> To: Development of Python/C++ integration
> Subject: Re: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
> 
> --- Greg Copeland <GCopeland at efjohnson.com> wrote:
> 
> > Is there anyone currently using this compiler with Boost.Python?
> 
> I am using the gcc 2.96 that comes with Red Hat 7.3. I had to come up
with
> a
> few workarounds but I am not aware of major problems.
> 
> Ralf
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> All your favorites on one personal page - Try My Yahoo!
> http://my.yahoo.com
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


From rwgk at yahoo.com  Fri Dec 17 20:23:54 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 17 Dec 2004 11:23:54 -0800 (PST)
Subject: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
In-Reply-To: <0392B3A5F875DB4295BD6A949A7839EF8C8885@efjdfw.local>
Message-ID: <20041217192355.24748.qmail@web20224.mail.yahoo.com>

--- Greg Copeland <GCopeland at efjohnson.com> wrote:

> What type of problems did you encounter?  Can you describe the types of
> "workarounds" that you had to implement?  Did you encounter any problems
> using boost/operators.hpp?  Did you get complaints about template
> default arguments...etc...?

No, this doesn't ring any bells. The problems I had were much more subtle.

I noticed that the gcc 2.96 that comes with Red Hat 7.1 behaves differently
than the gcc 2.96 that comes with Red Hat 7.3. Maybe you have yet another
variety that calls itself gcc 2.96?

Ralf



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250


From GCopeland at efjohnson.com  Fri Dec 17 20:40:41 2004
From: GCopeland at efjohnson.com (Greg Copeland)
Date: Fri, 17 Dec 2004 13:40:41 -0600
Subject: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
Message-ID: <0392B3A5F875DB4295BD6A949A7839EF8C8A2D@efjdfw.local>

Ya, that's what I feared.  I've heard (unconfirmed) that one vendor's
2.96 may very well be different from another vendor's 2.96 release.
Your comment seems to confirm it.  

Thanks for speaking up!


Cheers,
 
Greg Copeland
 

> -----Original Message-----
> From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org]
On
> Behalf Of Ralf W. Grosse-Kunstleve
> Sent: Friday, December 17, 2004 1:24 PM
> To: Development of Python/C++ integration
> Subject: RE: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
> 
> --- Greg Copeland <GCopeland at efjohnson.com> wrote:
> 
> > What type of problems did you encounter?  Can you describe the types
of
> > "workarounds" that you had to implement?  Did you encounter any
problems
> > using boost/operators.hpp?  Did you get complaints about template
> > default arguments...etc...?
> 
> No, this doesn't ring any bells. The problems I had were much more
subtle.
> 
> I noticed that the gcc 2.96 that comes with Red Hat 7.1 behaves
> differently
> than the gcc 2.96 that comes with Red Hat 7.3. Maybe you have yet
another
> variety that calls itself gcc 2.96?
> 
> Ralf
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - 250MB free storage. Do more. Manage less.
> http://info.mail.yahoo.com/mail_250
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


From darylew at hotmail.com  Mon Dec 20 11:18:03 2004
From: darylew at hotmail.com (Daryle Walker)
Date: Mon, 20 Dec 2004 05:18:03 -0500
Subject: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
In-Reply-To: <0392B3A5F875DB4295BD6A949A7839EF8C8A2D@efjdfw.local>
Message-ID: <BAY23-DAV2369CA8D13261CE916498BFA20@phx.gbl>

On 12/17/04 2:40 PM, "Greg Copeland" <GCopeland at efjohnson.com> wrote:

> Ya, that's what I feared.  I've heard (unconfirmed) that one vendor's
> 2.96 may very well be different from another vendor's 2.96 release.
> Your comment seems to confirm it.

[There may be some flaming in this post.]

As I understand it, there was _never_ an official GCC 2.96 release.  The GNU
group uses a system where all version numbers ending in an even digit are
exclusively non-final (i.e. alpha/beta) and all version numbers ending in an
odd digit are exclusively final.  After an odd-number release, the
intermediate version in CVS immediately gets renamed to an even number, then
further work is done, then a rename to an odd number precedes the next
release (and the cycle continues).

Certain vendors (e.g. Red Hat) plucked out the GCC code out of CVS at some
random point after 2.95 and stuck it on their CDs.  This suckered many
uninformed users into compiling with beta software.  For you, either
downgrade to 2.95 or upgrade to any of the 3.x releases.  And tell all of
your friends to do the same.  Sorry, but the definition of "GCC 2.96" is too
unstable for any developer to reliably help you.

Red Hat, and any others, should apologize to all of their users for being
inattentive and hoisting this problem on the users.  And apologize to all
the developers, like me, who have to "waste" time to educate everyone about
the mistake.  (Worse, Red Hat picked an intermediate version whose line died
without ever having a final release.  So users have to pick either an older
version without fixed bugs or do a major reorganization for jumping to a new
compiler line.)


>> -----Original Message-----
>> From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On
>>  Behalf Of Ralf W. Grosse-Kunstleve
>> Sent: Friday, December 17, 2004 1:24 PM
>> To: Development of Python/C++ integration
>> Subject: RE: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
>> 
>> --- Greg Copeland <GCopeland at efjohnson.com> wrote:
>> 
>>> What type of problems did you encounter?  Can you describe the types of
>>> "workarounds" that you had to implement?  Did you encounter any problems
>>> using boost/operators.hpp?  Did you get complaints about template default
>>> arguments...etc...?
>> 
>> No, this doesn't ring any bells. The problems I had were much more subtle.
>> 
>> I noticed that the gcc 2.96 that comes with Red Hat 7.1 behaves differently
>> than the gcc 2.96 that comes with Red Hat 7.3. Maybe you have yet another
>> variety that calls itself gcc 2.96?

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com



From GCopeland at efjohnson.com  Mon Dec 20 15:47:39 2004
From: GCopeland at efjohnson.com (Greg Copeland)
Date: Mon, 20 Dec 2004 08:47:39 -0600
Subject: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
Message-ID: <0392B3A5F875DB4295BD6A949A7839EF8C8D49@efjdfw.local>

Thanks for the follow up.  I'm aware of the Red Hat debacle, however,
the "2.96" compiler I'm using, isn't even from a Linux vendor.  As such,
downgrading or upgrading to the compiler is not an easy solution, so I'm
told.  I must admit that I'm regurgitating what I've been told and can't
vouch for validity of, however, I'm told that the vendor has some custom
patches being applied against "their" compiler and will not release
them.  Worse, I'm also told that key components of their software will
not compile with some of gnu's newer compiler releases.  End result,
we're fairly stuck.  I'm still exploring some other options (alternate
compiler [non-gnu] provided by vendor), so hopefully this won't prove to
be tar pit too.

Cheers,
 
Greg Copeland
 
> -----Original Message-----
> From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org]
On
> Behalf Of Daryle Walker
> Sent: Monday, December 20, 2004 4:18 AM
> To: Python/C++ Integration Development
> Subject: Re: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
> 
> On 12/17/04 2:40 PM, "Greg Copeland" <GCopeland at efjohnson.com> wrote:
> 
> > Ya, that's what I feared.  I've heard (unconfirmed) that one
vendor's
> > 2.96 may very well be different from another vendor's 2.96 release.
> > Your comment seems to confirm it.
> 
> [There may be some flaming in this post.]
> 
> As I understand it, there was _never_ an official GCC 2.96 release.
The
> GNU
> group uses a system where all version numbers ending in an even digit
are
> exclusively non-final (i.e. alpha/beta) and all version numbers ending
in
> an
> odd digit are exclusively final.  After an odd-number release, the
> intermediate version in CVS immediately gets renamed to an even
number,
> then
> further work is done, then a rename to an odd number precedes the next
> release (and the cycle continues).
> 
> Certain vendors (e.g. Red Hat) plucked out the GCC code out of CVS at
some
> random point after 2.95 and stuck it on their CDs.  This suckered many
> uninformed users into compiling with beta software.  For you, either
> downgrade to 2.95 or upgrade to any of the 3.x releases.  And tell all
of
> your friends to do the same.  Sorry, but the definition of "GCC 2.96"
is
> too
> unstable for any developer to reliably help you.
> 
> Red Hat, and any others, should apologize to all of their users for
being
> inattentive and hoisting this problem on the users.  And apologize to
all
> the developers, like me, who have to "waste" time to educate everyone
> about
> the mistake.  (Worse, Red Hat picked an intermediate version whose
line
> died
> without ever having a final release.  So users have to pick either an
> older
> version without fixed bugs or do a major reorganization for jumping to
a
> new
> compiler line.)
> 
> 
> >> -----Original Message-----
> >> From: c++-sig-bounces at python.org
[mailto:c++-sig-bounces at python.org] On
> >>  Behalf Of Ralf W. Grosse-Kunstleve
> >> Sent: Friday, December 17, 2004 1:24 PM
> >> To: Development of Python/C++ integration
> >> Subject: RE: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
> >>
> >> --- Greg Copeland <GCopeland at efjohnson.com> wrote:
> >>
> >>> What type of problems did you encounter?  Can you describe the
types
> of
> >>> "workarounds" that you had to implement?  Did you encounter any
> problems
> >>> using boost/operators.hpp?  Did you get complaints about template
> default
> >>> arguments...etc...?
> >>
> >> No, this doesn't ring any bells. The problems I had were much more
> subtle.
> >>
> >> I noticed that the gcc 2.96 that comes with Red Hat 7.1 behaves
> differently
> >> than the gcc 2.96 that comes with Red Hat 7.3. Maybe you have yet
> another
> >> variety that calls itself gcc 2.96?
> 
> --
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT hotmail DOT com
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


From Kingdom.Lin at yeah.net  Mon Dec 20 18:26:26 2004
From: Kingdom.Lin at yeah.net (Donnie Leen)
Date: Tue, 21 Dec 2004 01:26:26 +0800
Subject: [C++-sig] Re: what happened with this std::string parameter
	inboost.python
Message-ID: <20041220172520.847141E4011@bag.python.org>

Dave Abrahams wrote:
>What do you mean by "crashed?"  Are you sure it didn't throw an
>exception that was never caught?
yes, I try to catch the exception, but it crashed in the function PyRun_SimpleString I called to run python code,and it didn't throw exception to my try-catch.

>I suggest you insert the contents of libs/python/test/module_tail.cpp
>into your program, run it again, and see where the JIT debugger says the
>"crash" occurs.
>
>I also suggest you try putting the logic of your program inside a call
>to python::handle_exception, per libs/python/test/embedding.cpp:
>
>    if (python::handle_exception(something))
>    {
>        if (PyErr_Occurred())
>            PyErr_Print();
>        return 1;
>    }
Thanks your suggestion, I had followed you suggestion, but I didn't get any more information about the "crash", the result was the same as the first time I run it.
I made the c++ program in vc6, use stlport std library, my system is win2000+sp4.
and in the vc6 debugger, i found the exception was caught by the following function in src/object/function.cpp of boost.python:
    static PyObject *
    function_call(PyObject *func, PyObject *args, PyObject *kw)
    {
        PyObject* result = 0;
        handle_exception(bind_return(result, static_cast<function*>(func), args, kw));
        return result;
    }
I use PyRun_SimpleString to run python code, and the python code call my function through function_call of boost.python, the function_call had handled the exception, could I catch the exception any more?

I paste the call stack of vc6 debugger as following:
NTDLL! 77f813b1()
NTDLL! 77fb6972()
NTDLL! 77f8be26()
KERNEL32! 77e7f76e()
_CrtIsValidHeapPointer(const void * 0x005857b0) line 1697
_free_dbg_lk(void * 0x005857b0, int 1) line 1044 + 9 bytes
_free_dbg(void * 0x005857b0, int 1) line 1001 + 13 bytes
free(void * 0x005857b0) line 956 + 11 bytes
operator delete(void * 0x005857b0) line 7 + 9 bytes
_STL::__stl_delete(void * 0x005857b0) line 99 + 33 bytes
_STL::__node_alloc<1,0>::deallocate(void * 0x005857b0, unsigned int 414) line 253 + 42 bytes
_STL::allocator<char>::deallocate(char * 0x005857b0, unsigned int 414) line 360 + 19 bytes
_STL::_STLP_alloc_proxy<char *,char,_STL::allocator<char> >::deallocate(char * 0x005857b0, unsigned int 414) line 507
_STL::_String_base<char,_STL::allocator<char> >::_M_deallocate_block() line 124 + 58 bytes
_STL::_String_base<char,_STL::allocator<char> >::~_String_base<char,_STL::allocator<char> >() line 135 + 65 bytes
_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >::~basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >() line 302 + 96 bytes
boost::python::detail::value_destroyer<0>::execute(const _STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > * 0x0012f8c4) line 34
boost::python::detail::destroy_referent_impl(void * 0x0012f8c4, _STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > & (void)* 0x00000000) line 95 + 9 bytes
boost::python::detail::destroy_referent(void * 0x0012f8c4, _STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > & (void)* 0x00000000) line 101 + 11 bytes
boost::python::converter::rvalue_from_python_data<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > &>::~rvalue_from_python_data<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > &>() line 135 + 14 bytes
boost::python::converter::arg_rvalue_from_python<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >::~arg_rvalue_from_python<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >() + 37 bytes
boost::python::arg_from_python<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >::~arg_from_python<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >() + 37 bytes
boost::python::detail::caller_arity<1>::impl<void (__cdecl*)(_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >),boost::python::default_call_policies,boost::mpl::vector2<void,_STL::basic_string<char,_STL::char_traits<char>,_STbfdc5a11(_object * 0x00a81c90, _object * 0x00000000) line 201 + 42 bytes
boost::python::objects::caller_py_function_impl<boost::python::detail::caller<void (__cdecl*)(_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >),boost::python::default_call_policies,boost::mpl::vector2<void,_STL::basic_stringf77a00c5(_object * 0x00a81c90, _object * 0x00000000) line 39
boost::python::objects::py_function::operator()(_object * 0x00a81c90, _object * 0x00000000) line 139 + 32 bytes
boost::python::objects::function::call(_object * 0x00a81c90, _object * 0x00000000) line 212 + 36 bytes
boost::python::objects::`anonymous namespace'::bind_return::operator()() line 505 + 25 bytes
boost::detail::function::void_function_obj_invoker0<boost::python::objects::`anonymous namespace'::bind_return,void>::invoke(boost::detail::function::any_pointer {...}) line 129
boost::function0<void,int>::operator()() line 320 + 28 bytes
boost::python::handle_exception_impl(boost::function0<void,int> {...}) line 26
boost::python::handle_exception(boost::python::objects::`anonymous-namespace'::bind_return {...}) line 29 + 35 bytes
function_call(_object * 0x00564a80, _object * 0x00a81c90, _object * 0x00000000) line 537 + 56 bytes
PYTHON24! 1e01937c()

Thanks
Donnie Leen




From Kingdom.lin at yeah.net  Mon Dec 20 18:45:32 2004
From: Kingdom.lin at yeah.net (Donnie Leen)
Date: Tue, 21 Dec 2004 01:45:32 +0800
Subject: [C++-sig] Re: what happened with this std::string parameter
	inboost.python
Message-ID: <000601c4e6bb$c26fb4b0$0a00a8c0@lin>

Another problem(maybe) I found while boost.python deal with std::string:

// my function
void write1( std::string s )
{
    //   no nothing
}
// my class to deal with python error output
class Cout
{
public:
 std::string sbuf;
public:
 void write( std::string s )
 {
  sbuf += s;
  if ( sbuf.find_first_of( "\n" ) == std::string::npos )
   return;
  printf( "Cout::write\t%s", sbuf.c_str() );
  sbuf = "";
 }
};

I wrapped it by boost.python in my c++ program embedding boost.python,
BOOST_PYTHON_MODULE(mym)
{
 def( "write", &write1 );
    class_<Cout>( "Cout", init<std::string>() )
        .def_readwrite( "sbuf", &Cout::sbuf )
        .def( "write", &Cout::write )
    ;
}

 and then I call it as following:
 PyRun_SimpleString(
  "import mym\n"
  "import sys\n"
  "sys.stderr = mym.Cout('')\n"
  "mym.write('aa','bb')\n"
 );

it crashed, I can't caught any exception, even I insert the contents of libs/python/test/module_tail.cpp into my program.

Donnie Leen


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

From dave at boost-consulting.com  Mon Dec 20 21:42:46 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 20 Dec 2004 15:42:46 -0500
Subject: [C++-sig] Re: what happened with this std::string parameter
	inboost.python
In-Reply-To: <000601c4e6bb$c26fb4b0$0a00a8c0@lin>
References: <000601c4e6bb$c26fb4b0$0a00a8c0@lin>
Message-ID: <cq7dg8$i0o$1@sea.gmane.org>

Donnie Leen wrote:
> Another problem(maybe) I found while boost.python deal with std::string:

Please post a minimal but *complete* example (that means your program
should have a main()) and show the exact command lines used to build
your program and to invoke it.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Mon Dec 20 21:44:39 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 20 Dec 2004 15:44:39 -0500
Subject: [C++-sig] Re: what happened with this std::string parameter
	inboost.python
In-Reply-To: <20041220172520.847141E4011@bag.python.org>
References: <20041220172520.847141E4011@bag.python.org>
Message-ID: <cq7djp$i0o$2@sea.gmane.org>

Donnie Leen wrote:
> Dave Abrahams wrote:
>>What do you mean by "crashed?"  Are you sure it didn't throw an
>>exception that was never caught?
> yes, I try to catch the exception, but it crashed in the function PyRun_SimpleString I called to run python code,and it didn't throw exception to my try-catch.
> 
>>I suggest you insert the contents of libs/python/test/module_tail.cpp
>>into your program, run it again, and see where the JIT debugger says the
>>"crash" occurs.
>>
>>I also suggest you try putting the logic of your program inside a call
>>to python::handle_exception, per libs/python/test/embedding.cpp:
>>
>>    if (python::handle_exception(something))
>>    {
>>        if (PyErr_Occurred())
>>            PyErr_Print();
>>        return 1;
>>    }
> Thanks your suggestion, I had followed you suggestion, but I didn't get any more information about the "crash", the result was the same as the first time I run it.
> I made the c++ program in vc6, use stlport std library, my system is win2000+sp4.
> and in the vc6 debugger, i found the exception was caught by the following function in src/object/function.cpp of boost.python:
>     static PyObject *
>     function_call(PyObject *func, PyObject *args, PyObject *kw)
>     {
>         PyObject* result = 0;
>         handle_exception(bind_return(result, static_cast<function*>(func), args, kw));
>         return result;
>     }
> I use PyRun_SimpleString to run python code, and the python code call my function through function_call of boost.python, the function_call had handled the exception, could I catch the exception any more?

No you can't; it has been translated into a Python exception.  You can
see that exception by calling PyErr_Print.

> I paste the call stack of vc6 debugger as following:
> NTDLL! 77f813b1()
> NTDLL! 77fb6972()
> NTDLL! 77f8be26()
> KERNEL32! 77e7f76e()
> _CrtIsValidHeapPointer(const void * 0x005857b0) line 1697

This means you have heap corruption.  Something you have done is walking
over and modifying memory it shouldn't touch.

> _free_dbg_lk(void * 0x005857b0, int 1) line 1044 + 9 bytes
> _free_dbg(void * 0x005857b0, int 1) line 1001 + 13 bytes
> free(void * 0x005857b0) line 956 + 11 bytes
> operator delete(void * 0x005857b0) line 7 + 9 bytes
> _STL::__stl_delete(void * 0x005857b0) line 99 + 33 bytes


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Kingdom.lin at yeah.net  Tue Dec 21 09:02:04 2004
From: Kingdom.lin at yeah.net (Donnie Leen)
Date: Tue, 21 Dec 2004 16:02:04 +0800
Subject: [C++-sig] Re: what happened with this std::string
	parameterinboost.python
References: <000601c4e6bb$c26fb4b0$0a00a8c0@lin> <cq7dg8$i0o$1@sea.gmane.org>
Message-ID: <cq8l9d$9r$1@sea.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:cq7dg8$i0o$1 at sea.gmane.org...
> Please post a minimal but *complete* example (that means your program
> should have a main()) and show the exact command lines used to build
> your program and to invoke it.

The example:
I build it in win2000+sp4, vc6+sp, stand template library is stlport, link
with boost.python debug library, python2.4



#define BOOST_PYTHON_STATIC_MODULE

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


void write1( std::string s )
{
 printf( "Cout::write\t%s", s.c_str() );
}
class Cout
{
public:
 std::string sbuf;
public:
 Cout( std::string s )
 {
  sbuf = s;
 }
 void write( std::string s )
 {
  sbuf += s;
  if ( sbuf.find_first_of( "\n" ) == std::string::npos )
   return;
  printf( "Cout::write\t%s", sbuf.c_str() );
  sbuf = "";
 }
};
BOOST_PYTHON_MODULE(mym)
{
 def( "write", &write1 );
    class_<Cout>( "Cout", init<std::string>() )
        .def_readwrite( "sbuf", &Cout::sbuf )
        .def( "write", &Cout::write )
    ;
}

void test()
{
 // mym.write() expect one parameter, I give it two to test the error output
 PyRun_SimpleString(
  "import mym\n"
  "import sys\n"
  "sys.stderr = mym.Cout('')\n"
  "mym.write('aa','bb')\n"
  );
}
void main( int argc, char **argv )
{
    if (PyImport_AppendInittab("mym", initmym) == -1)
        throw std::runtime_error("Failed to add mym to the interpreter's
builtin modules");
    Py_Initialize(  );
    if (handle_exception(test))
    {
        if (PyErr_Occurred())
            PyErr_Print();
    }
 Py_Finalize();
}
#include "module_tail.cpp"






From dave at boost-consulting.com  Thu Dec 23 00:51:57 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 22 Dec 2004 18:51:57 -0500
Subject: [C++-sig] Re: what happened with this std::string
	parameterinboost.python
In-Reply-To: <cq8l9d$9r$1@sea.gmane.org>
References: <000601c4e6bb$c26fb4b0$0a00a8c0@lin> <cq7dg8$i0o$1@sea.gmane.org>
	<cq8l9d$9r$1@sea.gmane.org>
Message-ID: <41CA089D.8080200@boost-consulting.com>

Donnie Leen wrote:
> "David Abrahams" <dave at boost-consulting.com> wrote in message
> news:cq7dg8$i0o$1 at sea.gmane.org...
>> Please post a minimal but *complete* example (that means your program
>> should have a main()) and 

**********************************
>> show the exact command lines used to build
>> your program and to invoke it.
**********************************

Thanks, you're partway there.  Could you please supply the missing info?
Also, which version of STLPort are you using.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From dave at boost-consulting.com  Thu Dec 23 00:51:57 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 22 Dec 2004 18:51:57 -0500
Subject: [C++-sig] Re: what happened with this std::string
	parameterinboost.python
In-Reply-To: <cq8l9d$9r$1@sea.gmane.org>
References: <000601c4e6bb$c26fb4b0$0a00a8c0@lin> <cq7dg8$i0o$1@sea.gmane.org>
	<cq8l9d$9r$1@sea.gmane.org>
Message-ID: <41CA089D.8080200@boost-consulting.com>

Donnie Leen wrote:
> "David Abrahams" <dave at boost-consulting.com> wrote in message
> news:cq7dg8$i0o$1 at sea.gmane.org...
>> Please post a minimal but *complete* example (that means your program
>> should have a main()) and 

**********************************
>> show the exact command lines used to build
>> your program and to invoke it.
**********************************

Thanks, you're partway there.  Could you please supply the missing info?
Also, which version of STLPort are you using.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Kingdom.lin at yeah.net  Thu Dec 23 04:53:08 2004
From: Kingdom.lin at yeah.net (Donnie Leen)
Date: Thu, 23 Dec 2004 11:53:08 +0800
Subject: [C++-sig] Re: what happened with this
	std::stringparameterinboost.python
References: <000601c4e6bb$c26fb4b0$0a00a8c0@lin>
	<cq7dg8$i0o$1@sea.gmane.org><cq8l9d$9r$1@sea.gmane.org>
	<41CA089D.8080200@boost-consulting.com>
Message-ID: <cqdfe1$b3l$1@sea.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:41CA089D.8080200 at boost-consulting.com...
> Donnie Leen wrote:
> > "David Abrahams" <dave at boost-consulting.com> wrote in message
> > news:cq7dg8$i0o$1 at sea.gmane.org...
> >> Please post a minimal but *complete* example (that means your program
> >> should have a main()) and
>
> **********************************
> >> show the exact command lines used to build
> >> your program and to invoke it.
> **********************************
>
> Thanks, you're partway there.  Could you please supply the missing info?
> Also, which version of STLPort are you using.

I build it in win2000+sp4, vc6+sp5, stand template library is stlport
v4.5.3, link
with boost.python debug library(boost.python version 1.32.0), python2.4
I create a "Win32 console Application" (Empty project) in vc6 IDE, add the
source file and use the default vc6 project setting, compile& link both in
IDE, not commandline.





From dave at boost-consulting.com  Thu Dec 23 06:30:57 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 23 Dec 2004 00:30:57 -0500
Subject: [C++-sig] Re: what happened with this
	std::stringparameterinboost.python
In-Reply-To: <cqdfe1$b3l$1@sea.gmane.org>
References: <000601c4e6bb$c26fb4b0$0a00a8c0@lin>	<cq7dg8$i0o$1@sea.gmane.org><cq8l9d$9r$1@sea.gmane.org>	<41CA089D.8080200@boost-consulting.com>
	<cqdfe1$b3l$1@sea.gmane.org>
Message-ID: <41CA5811.6060907@boost-consulting.com>

Donnie Leen wrote:
> "David Abrahams" <dave at boost-consulting.com> wrote in message
> news:41CA089D.8080200 at boost-consulting.com...
>> Donnie Leen wrote:
>> > "David Abrahams" <dave at boost-consulting.com> wrote in message
>> > news:cq7dg8$i0o$1 at sea.gmane.org...
>> >> Please post a minimal but *complete* example (that means your program
>> >> should have a main()) and
>>
>> **********************************
>> >> show the exact command lines used to build
>> >> your program and to invoke it.
>> **********************************
>>
>> Thanks, you're partway there.  Could you please supply the missing info?
>> Also, which version of STLPort are you using.
> 
> I build it in win2000+sp4, vc6+sp5, stand template library is stlport
> v4.5.3, link
> with boost.python debug library(boost.python version 1.32.0), python2.4
> I create a "Win32 console Application" (Empty project) in vc6 IDE, add the
> source file and use the default vc6 project setting, compile& link both in
> IDE, not commandline.

Ah.  Well, then there's something wrong with your Visual Studio project
settings.  It works for me here when built with bjam.

====== BEGIN OUTPUT ======
Cout::write	Traceback (most recent call last):
Cout::write	  File "<string>", line 4, in ?
Cout::write	Boost.Python.ArgumentError: Python argument types in
    mym.write(str, str)
did not match C++ signature:
    write(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >)Cout::write	
'import site' failed; use -v for traceback
[3378 refs]

EXIT STATUS: 0
====== END OUTPUT ======

====== BEGIN JAMFILE ========
import python.jam ;
import testing.jam ;

run foo.cpp <dll>@boost/libs/python/build/boost_python
  : # program args
  : # input files
  : # requirements
  $(PYTHON_PROPERTIES)
    <library-path>$(PYTHON_LIB_PATH)
        <find-library>$(PYTHON_EMBEDDED_LIBRARY)
            ;
======== END JAMFILE ==========

You can discover the differences by observing the bjam output with "bjam
-n -a" and comparing that with the command lines generated by the IDE
when it invokes the compiler.

HTH,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com


From dave at boost-consulting.com  Thu Dec 23 06:30:57 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 23 Dec 2004 00:30:57 -0500
Subject: [C++-sig] Re: what happened with this
	std::stringparameterinboost.python
In-Reply-To: <cqdfe1$b3l$1@sea.gmane.org>
References: <000601c4e6bb$c26fb4b0$0a00a8c0@lin>	<cq7dg8$i0o$1@sea.gmane.org><cq8l9d$9r$1@sea.gmane.org>	<41CA089D.8080200@boost-consulting.com>
	<cqdfe1$b3l$1@sea.gmane.org>
Message-ID: <41CA5811.6060907@boost-consulting.com>

Donnie Leen wrote:
> "David Abrahams" <dave at boost-consulting.com> wrote in message
> news:41CA089D.8080200 at boost-consulting.com...
>> Donnie Leen wrote:
>> > "David Abrahams" <dave at boost-consulting.com> wrote in message
>> > news:cq7dg8$i0o$1 at sea.gmane.org...
>> >> Please post a minimal but *complete* example (that means your program
>> >> should have a main()) and
>>
>> **********************************
>> >> show the exact command lines used to build
>> >> your program and to invoke it.
>> **********************************
>>
>> Thanks, you're partway there.  Could you please supply the missing info?
>> Also, which version of STLPort are you using.
> 
> I build it in win2000+sp4, vc6+sp5, stand template library is stlport
> v4.5.3, link
> with boost.python debug library(boost.python version 1.32.0), python2.4
> I create a "Win32 console Application" (Empty project) in vc6 IDE, add the
> source file and use the default vc6 project setting, compile& link both in
> IDE, not commandline.

Ah.  Well, then there's something wrong with your Visual Studio project
settings.  It works for me here when built with bjam.

====== BEGIN OUTPUT ======
Cout::write	Traceback (most recent call last):
Cout::write	  File "<string>", line 4, in ?
Cout::write	Boost.Python.ArgumentError: Python argument types in
    mym.write(str, str)
did not match C++ signature:
    write(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >)Cout::write	
'import site' failed; use -v for traceback
[3378 refs]

EXIT STATUS: 0
====== END OUTPUT ======

====== BEGIN JAMFILE ========
import python.jam ;
import testing.jam ;

run foo.cpp <dll>@boost/libs/python/build/boost_python
  : # program args
  : # input files
  : # requirements
  $(PYTHON_PROPERTIES)
    <library-path>$(PYTHON_LIB_PATH)
        <find-library>$(PYTHON_EMBEDDED_LIBRARY)
            ;
======== END JAMFILE ==========

You can discover the differences by observing the bjam output with "bjam
-n -a" and comparing that with the command lines generated by the IDE
when it invokes the compiler.

HTH,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From itamar at itamarst.org  Fri Dec 24 00:32:47 2004
From: itamar at itamarst.org (Itamar Shtull-Trauring)
Date: Thu, 23 Dec 2004 18:32:47 -0500
Subject: [C++-sig] ANN: Fusion v0.2, C++ integration for Twisted
Message-ID: <1103844768.14088.138.camel@sheriffpony>

Fusion is a library that supports implementing protocols in C++ for use
with Twisted, allowing control over memory allocation strategies, fast
method calls internally, etc.. Fusion supports TCP, UDP and multicast,
and is implemented using the Boost.Python python bindings.

Fusion has only been tested on Linux - Debian GNU/Linux with gcc 3.3 on
PowerPC and Redhat 7.3 with gcc 2.96 on x86.

Fusion is licensed under the MIT license, and available for download
from http://itamarst.org/software/fusion-0.2.tar.gz

Features supported in v0.2:

1. Scheduling functions with the twisted event loop from C++ (callLater
and LoopingCall).

2. Support for implementing C++ UDP and multicast protocols.

3. Support for implementing C++ TCP protocols (client and server), with
a zero-copy buffering layer written in C++. Protocols implemented in
Python can also use this custom buffering layer. There are two write
APIs, one accepting a functor/function that writes to a buffer allocated
by Fusion, and the other accepting a shared_ptr that points at an
instance that owns a buffer.


** WARNING **
Writing networking code in C++ can lead to buffer overflows and other
unpleasant security problems. Stick to pure Python unless you have no
other choice and know what you're doing. Don't assume I know what I'm
doing, either - bug reports are more than welcome :)




From Kingdom.lin at yeah.net  Fri Dec 24 08:26:42 2004
From: Kingdom.lin at yeah.net (Donnie Leen)
Date: Fri, 24 Dec 2004 15:26:42 +0800
Subject: [C++-sig] Re: what happened with
	thisstd::stringparameterinboost.python
References: <000601c4e6bb$c26fb4b0$0a00a8c0@lin>	<cq7dg8$i0o$1@sea.gmane.org><cq8l9d$9r$1@sea.gmane.org>	<41CA089D.8080200@boost-consulting.com><cqdfe1$b3l$1@sea.gmane.org>
	<41CA5811.6060907@boost-consulting.com>
Message-ID: <cqgg8o$3t6$1@sea.gmane.org>


"David Abrahams" <dave at boost-consulting.com> wrote in message
news:41CA5811.6060907 at boost-consulting.com...
> You can discover the differences by observing the bjam output with "bjam
> -n -a" and comparing that with the command lines generated by the IDE
> when it invokes the compiler.


I build the program again in release version,  it runs ok  :)
Perhaps it did had something difference between debug and release version, I
had tried for many times.

Thanks.

Donnie Leen





From jpaulofarias at yahoo.com.br  Tue Dec 28 14:57:11 2004
From: jpaulofarias at yahoo.com.br (=?ISO-8859-1?Q?Jo=E3o_Paulo?=)
Date: Tue, 28 Dec 2004 10:57:11 -0300
Subject: [C++-sig] Adding properties with Pyste
Message-ID: <cqroq6$mop$1@sea.gmane.org>

Hi!

How do I add a property using Pyste?

It was possible with old class_code, but now it appears to be no more 
avaliable on pyste. I've take a look on pyste.py n Pyste package and it 
appears to have a add_method function, but not and add_property.

Is there a way to add a property with pyste?

Thanks,

JP



From jpaulofarias at yahoo.com.br  Wed Dec 29 19:33:31 2004
From: jpaulofarias at yahoo.com.br (=?ISO-8859-1?Q?Jo=E3o?= Paulo Fernandes Farias)
Date: Wed, 29 Dec 2004 15:33:31 -0300
Subject: [C++-sig] Reduce the resulting .so file size
Message-ID: <1104345212.15817.1.camel@jpfarias.no-ip.com>

Hi! 

Is there a way to reduce the final .so file size?

I've ported pyogre to linux and the final .so file is about 63Mb.

Thanks.

--
JP



From dave at boost-consulting.com  Wed Dec 29 20:32:46 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 29 Dec 2004 10:32:46 -0900
Subject: [C++-sig] Re: Reduce the resulting .so file size
In-Reply-To: <1104345212.15817.1.camel@jpfarias.no-ip.com>
References: <1104345212.15817.1.camel@jpfarias.no-ip.com>
Message-ID: <cqv0pj$l99$2@sea.gmane.org>

Jo?o Paulo Fernandes Farias wrote:
> Hi! 
> 
> Is there a way to reduce the final .so file size?
> 
> I've ported pyogre to linux and the final .so file is about 63Mb.

See http://www.nedprod.com/programs/gccvisibility.html.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From jbrandmeyer at earthlink.net  Wed Dec 29 20:36:57 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Wed, 29 Dec 2004 14:36:57 -0500
Subject: [C++-sig] Reduce the resulting .so file size
In-Reply-To: <1104345212.15817.1.camel@jpfarias.no-ip.com>
References: <1104345212.15817.1.camel@jpfarias.no-ip.com>
Message-ID: <1104349017.4104.73.camel@illuvatar>

On Wed, 2004-12-29 at 15:33 -0300, Jo?o Paulo Fernandes Farias wrote:
> Hi! 
> 
> Is there a way to reduce the final .so file size?
> 
> I've ported pyogre to linux and the final .so file is about 63Mb.

First off, see how much stripping the .so reduces the file size.
Building with optimization enabled tends to produce much smaller
extension module code than building without it.

If you want to try something experimental, use this patch to reduce the
default symbol visibility in your module:
http://www.nedprod.com/programs/gccvisibility.html

You might be able to get away with using a linker version script as
described in my post of April 2, 2004 in the thread "Loading
Boost.Python made bindings is horribly slow?".  The caveat to this is
that it is only really practical if no other module will be using
symbols from the one that uses this trick.  Otherwise, it's a
maintenance nightmare.

HTH,
Jonathan Brandmeyer



From dave at boost-consulting.com  Wed Dec 29 20:49:29 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 29 Dec 2004 10:49:29 -0900
Subject: [C++-sig] Re: Reduce the resulting .so file size
In-Reply-To: <1104349017.4104.73.camel@illuvatar>
References: <1104345212.15817.1.camel@jpfarias.no-ip.com>
	<1104349017.4104.73.camel@illuvatar>
Message-ID: <cqv1ov$o14$1@sea.gmane.org>

Jonathan Brandmeyer wrote:
> On Wed, 2004-12-29 at 15:33 -0300, Jo?o Paulo Fernandes Farias wrote:
>> Hi! 
>> 
>> Is there a way to reduce the final .so file size?
>> 
>> I've ported pyogre to linux and the final .so file is about 63Mb.
> 
> First off, see how much stripping the .so reduces the file size.
> Building with optimization enabled tends to produce much smaller
> extension module code than building without it.
> 
> If you want to try something experimental, use this patch to reduce the
> default symbol visibility in your module:
> http://www.nedprod.com/programs/gccvisibility.html
> 
> You might be able to get away with using a linker version script as
> described in my post of April 2, 2004 in the thread "Loading
> Boost.Python made bindings is horribly slow?".  The caveat to this is
> that it is only really practical if no other module will be using
> symbols from the one that uses this trick.  Otherwise, it's a
> maintenance nightmare.

?? I can't see why you'd say that.  This patch just makes GCC use the
Windows model, which causes no maintenance hassles in my opinion.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From jbrandmeyer at earthlink.net  Wed Dec 29 21:50:19 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Wed, 29 Dec 2004 15:50:19 -0500
Subject: [C++-sig] Re: Reduce the resulting .so file size
In-Reply-To: <cqv1ov$o14$1@sea.gmane.org>
References: <1104345212.15817.1.camel@jpfarias.no-ip.com>
	<1104349017.4104.73.camel@illuvatar>  <cqv1ov$o14$1@sea.gmane.org>
Message-ID: <1104353420.4104.77.camel@illuvatar>

On Wed, 2004-12-29 at 10:49 -0900, David Abrahams wrote:
> Jonathan Brandmeyer wrote:
> > On Wed, 2004-12-29 at 15:33 -0300, Jo?o Paulo Fernandes Farias wrote:
> >> Hi! 
> >> 
> >> Is there a way to reduce the final .so file size?
> >> 
> >> I've ported pyogre to linux and the final .so file is about 63Mb.
> > 
> > First off, see how much stripping the .so reduces the file size.
> > Building with optimization enabled tends to produce much smaller
> > extension module code than building without it.
> > 
> > If you want to try something experimental, use this patch to reduce the
> > default symbol visibility in your module:
> > http://www.nedprod.com/programs/gccvisibility.html
> > 
> > You might be able to get away with using a linker version script as
> > described in my post of April 2, 2004 in the thread "Loading
> > Boost.Python made bindings is horribly slow?".  The caveat to this is
> > that it is only really practical if no other module will be using
> > symbols from the one that uses this trick.  Otherwise, it's a
> > maintenance nightmare.
> 
> ?? I can't see why you'd say that.  This patch just makes GCC use the
> Windows model, which causes no maintenance hassles in my opinion.


I was referring to the linker version script trick.  I think Niall's
patch is a much better solution in the long run.

-Jonathan



From jpaulofarias at yahoo.com.br  Wed Dec 29 23:24:05 2004
From: jpaulofarias at yahoo.com.br (=?ISO-8859-1?Q?Jo=E3o?= Paulo Fernandes Farias)
Date: Wed, 29 Dec 2004 19:24:05 -0300
Subject: [C++-sig] Reduce the resulting .so file size
In-Reply-To: <1104349017.4104.73.camel@illuvatar>
References: <1104345212.15817.1.camel@jpfarias.no-ip.com>
	<1104349017.4104.73.camel@illuvatar>
Message-ID: <1104359045.10043.0.camel@jpfarias.no-ip.com>

Hi!

Thanks everyone for the answers.

So, how do I strip the file? Just a "strip file.so" does the job?

Thanks,

JP.

Em Qua, 2004-12-29 ?s 14:36 -0500, Jonathan Brandmeyer escreveu:
> On Wed, 2004-12-29 at 15:33 -0300, Jo?o Paulo Fernandes Farias wrote:
> > Hi! 
> > 
> > Is there a way to reduce the final .so file size?
> > 
> > I've ported pyogre to linux and the final .so file is about 63Mb.
> 
> First off, see how much stripping the .so reduces the file size.
> Building with optimization enabled tends to produce much smaller
> extension module code than building without it.
> 
> If you want to try something experimental, use this patch to reduce the
> default symbol visibility in your module:
> http://www.nedprod.com/programs/gccvisibility.html
> 
> You might be able to get away with using a linker version script as
> described in my post of April 2, 2004 in the thread "Loading
> Boost.Python made bindings is horribly slow?".  The caveat to this is
> that it is only really practical if no other module will be using
> symbols from the one that uses this trick.  Otherwise, it's a
> maintenance nightmare.
> 
> HTH,
> Jonathan Brandmeyer
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig



From s_sourceforge at nedprod.com  Wed Dec 29 22:56:47 2004
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 29 Dec 2004 21:56:47 -0000
Subject: [C++-sig] Reduce the resulting .so file size
Message-ID: <mailman.97.1223937154.18936.cplusplus-sig@python.org>

On 29 Dec 2004 at 14:36, Jonathan Brandmeyer wrote:

> On Wed, 2004-12-29 at 15:33 -0300, Jo?o Paulo Fernandes Farias wrote:
> > Hi! > > Is there a way to reduce the final .so file size? > > I've
> ported pyogre to linux and the final .so file is about 63Mb.
> 
> If you want to try something experimental, use this patch to reduce
> the default symbol visibility in your module:
> http://www.nedprod.com/programs/gccvisibility.html

No one mentioned that GCC v4 from CVS already contains the GCC 
visibility patch, so I will here. They've also changed the 
intermediate code description language so it may produce bigger or 
smaller final binaries after optimisation (one would think smaller).

Cheers,
Niall



From s_sourceforge at nedprod.com  Wed Dec 29 23:36:00 2004
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 29 Dec 2004 22:36:00 -0000
Subject: [C++-sig] Reduce the resulting .so file size
In-Reply-To: <1104359045.10043.0.camel@jpfarias.no-ip.com>
References: <1104349017.4104.73.camel@illuvatar>
Message-ID: <41D33150.16258.39D7C6@localhost>

On 29 Dec 2004 at 19:24, Jo?o Paulo Fernandes Farias wrote:

> Hi!
> 
> Thanks everyone for the answers.
> 
> So, how do I strip the file? Just a "strip file.so" does the job?

Personally I found that stripped so's won't function as loadable 
libraries properly.But then I'm not sure if that's important for a 
pure python extension module.

With the GCC visibility patch or GCC v4, simply call with -
fvisibility=hidden -fvisibility-inlines-hidden to minimise binary 
size.

Cheers,
Niall





From halbert at bbn.com  Thu Dec 30 18:42:23 2004
From: halbert at bbn.com (Dan Halbert)
Date: Thu, 30 Dec 2004 12:42:23 -0500
Subject: [C++-sig] Reduce the resulting .so file size
In-Reply-To: <41D33150.16258.39D7C6@localhost> (s_sourceforge@nedprod.com)
References: <1104349017.4104.73.camel@illuvatar>
	<41D33150.16258.39D7C6@localhost>
Message-ID: <200412301742.iBUHgNm26786@rolex.bbn.com>

  >From: "Niall Douglas" <s_sourceforge at nedprod.com>
  >
  >Personally I found that stripped so's won't function as loadable 
  >libraries properly.But then I'm not sure if that's important for a 
  >pure python extension module.

We strip our (non-python) .so's with "strip -g foo.so", and they still
link fine at run-time. The "-g" (aka "-S", "-d", "--strip-debug")
removes only debugging symbols. Would that help here?

Dan


From halbert at bbn.com  Thu Dec 30 18:46:40 2004
From: halbert at bbn.com (Dan Halbert)
Date: Thu, 30 Dec 2004 12:46:40 -0500
Subject: [C++-sig] Reduce the resulting .so file size
In-Reply-To: <200412301742.iBUHgNm26786@rolex.bbn.com> (message from Dan
	Halbert on Thu, 30 Dec 2004 12:42:23 -0500)
References: <1104349017.4104.73.camel@illuvatar>
	<41D33150.16258.39D7C6@localhost>
	<200412301742.iBUHgNm26786@rolex.bbn.com>
Message-ID: <200412301746.iBUHkei26801@rolex.bbn.com>

  >We strip our (non-python) .so's with "strip -g foo.so", and they still
  >link fine at run-time. The "-g" (aka "-S", "-d", "--strip-debug")
  >removes only debugging symbols. Would that help here?

I sent this suggestion in too much haste. There are other options as well 
to explore, given on the strip man page:
  --strip-unneeded
  --discard-all (remove non-global symbols)
  --discard-locals