From trigves at yahoo.com  Mon Aug  2 10:59:34 2010
From: trigves at yahoo.com (Trigve Siver)
Date: Mon, 2 Aug 2010 01:59:34 -0700 (PDT)
Subject: [C++-sig] division operator in 3.1
Message-ID: <878294.59758.qm@web110415.mail.gq1.yahoo.com>

Hi,
I've found bug in boost python with division operator. Division operator  with 
custom types doesn't work with python 3.1. It is because there were  some 
changes 

in this regard in python 3. I've created ticket with patch 
https://svn.boost.org/trac/boost/ticket/4497 . Can somebody look at  it?
 
Thanks

Trigve


      

From opadon at yahoo.com  Mon Aug  2 13:27:31 2010
From: opadon at yahoo.com (Oded Padon)
Date: Mon, 2 Aug 2010 04:27:31 -0700 (PDT)
Subject: [C++-sig] Calling a C++ function with arguments by reference
	(lvalues)
Message-ID: <331489.30841.qm@web55704.mail.re3.yahoo.com>

Hello everybody,

I'm very new to Boost.Python, and I just spent hours trying to do something trivial, and couldn't get it. The C++ code is:

void add(int const a, int const b, int const& c)
{
    c = a + b;
}

BOOST_PYTHON_MODULE(hello_ext)
{
    using namespace boost::python;
    def("add", add);
}

When I tried to call this function from python I got the following error:
>>> import hello_ext
>>> x = int()
>>> y = int()
>>> z = int()
>>> hello_ext.add(x,y,z)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
Boost.Python.ArgumentError: Python argument types in
    hello_ext.add(int, int, int)
did not match C++ signature:
    add(int, int, int {lvalue})

How can I get this to work?
I must emphasize that I wish to have functions that get arguments by reference and change them. Returning the values using the return mechanism isn't what I want to do (I have functions that get and set many many arguments, and I hardly wish to rewrite them).

Thanks,
Oded


      


From nat at lindenlab.com  Mon Aug  2 17:24:22 2010
From: nat at lindenlab.com (Nat Goodspeed)
Date: Mon, 02 Aug 2010 11:24:22 -0400
Subject: [C++-sig] Calling a C++ function with arguments by reference
 (lvalues)
In-Reply-To: <331489.30841.qm@web55704.mail.re3.yahoo.com>
References: <331489.30841.qm@web55704.mail.re3.yahoo.com>
Message-ID: <4C56E326.4090606@lindenlab.com>

Oded Padon wrote:

> The C++ code is:
> 
> void add(int const a, int const b, int const& c)
> {
>     c = a + b;
> }

This doesn't even compile under g++ 4.0.1 (Mac):
error: assignment of read-only reference 'c'

I hope you're not using a compiler that accepts such code as legal?

> I must emphasize that I wish to have functions that get arguments
 > by reference and change them. Returning the values using the return
 > mechanism isn't what I want to do (I have functions that get and set
 > many many arguments, and I hardly wish to rewrite them).

<boring anecdote>

Many moons ago I had the dubious pleasure of using a FORTRAN compiler 
that was old and dumb even for the time. With this compiler, all 
parameters were passed by non-const reference. One of my team was 
delegated to write a subroutine that accepted certain parameters. There 
was miscommunication about the expected parameter order, and the calling 
code ended up passing the integer literal '5' in the parameter slot to 
which the subroutine stored its result.

 From that point on, everywhere the literal '5' appeared in the source, 
the executable was instead referencing the result of some computation.

Merriment ensued as the program confounded all attempts to predict its 
behavior.

You are proposing to do the same to the Python interpreter. It's 
appropriate for Boost.Python to try to make that difficult.

</boring anecdote>

Suppose you were writing this code from scratch in pure Python. How 
would you approach the problem? This won't work:

def add(a, b, c):
     c = a + b

def caller():
     c = 0
     add(1, 2, c)
     assert c == 3   # FAIL

One way would be to keep some set of working variables in an object, and 
pass that object into the function that wants to modify them:

class Vars(object):
     def __init__(self):
         self.a = 0
         self.b = 0
         self.c = 0

def add(a, b, vars):
     vars.c = a + b

def caller():
     v = Vars()
     add(1, 2, v)
     assert v.c == 3

Or you could keep working values in a dict, if you prefer dict lookup to 
attribute references.

You can code your C++ add() function to accept its 'vars' parameter as a 
boost::python::object. If you pass a class object, you can reference 
vars.attr("c"). If you pass a dict, you can reference vars["c"].

See also: 
http://www.boost.org/doc/libs/1_43_0/libs/python/doc/tutorial/doc/html/python/embedding.html#python.using_the_interpreter 


From opadon at yahoo.com  Mon Aug  2 22:46:37 2010
From: opadon at yahoo.com (Oded Padon)
Date: Mon, 2 Aug 2010 13:46:37 -0700 (PDT)
Subject: [C++-sig] Calling a C++ function with arguments by reference
	(lvalues)
In-Reply-To: <4C56E326.4090606@lindenlab.com>
Message-ID: <653642.71834.qm@web55703.mail.re3.yahoo.com>

Thank you for your rapid response.
I had a typo in my code. It should have been:
void add(int const a, int const b, int & c)
{
    c = a + b;
}
i.e. the last argument is passed by non-const reference.

One solution is indeed to rewrite the function to accept either a
python object (class, dict, etc.) or a C++ defined struct by reference, but this means a change to the function's coding style, which I'd like to preserve.
I somehow feel that there should be a way to achieve this, as the python module does compile, and boost.python does understand the signature of the function that gives my desired behavior:
"
did not match C++ signature:
    add(int, int, int {lvalue})
"
This makes me think that boost.python does know how to handle functions of such signature, but I do not yet know how to invoke them from python.

There is another reason why I think this has to be possible. It is possible using ctypes. Using ctypes with the same C++ code written above (except for extern "C"), the following python code:

import ctypes;
lib_cpp = ctypes.CDLL('./test_cpp.so')
result = ctypes.c_int(0);
lib_cpp.add(1, 2, ctypes.byref(result));
print result;

prints: "c_long(3)"

I do prefer however to use boost.python, as I would at a later stage want to expose C++ classes to python, but exposing functions like the above is step one for me.

Thanks again,
Oded

--- On Mon, 8/2/10, Nat Goodspeed <nat at lindenlab.com> wrote:

> From: Nat Goodspeed <nat at lindenlab.com>
> Subject: Re: [C++-sig] Calling a C++ function with arguments by reference (lvalues)
> To: "Development of Python/C++ integration" <cplusplus-sig at python.org>
> Date: Monday, August 2, 2010, 6:24 PM
> Oded Padon wrote:
> 
> > The C++ code is:
> > 
> > void add(int const a, int const b, int const& c)
> > {
> >? ???c = a + b;
> > }
> 
> This doesn't even compile under g++ 4.0.1 (Mac):
> error: assignment of read-only reference 'c'
> 
> I hope you're not using a compiler that accepts such code
> as legal?
> 
> > I must emphasize that I wish to have functions that
> get arguments
> > by reference and change them. Returning the values
> using the return
> > mechanism isn't what I want to do (I have functions
> that get and set
> > many many arguments, and I hardly wish to rewrite
> them).
> 
> <boring anecdote>
> 
> Many moons ago I had the dubious pleasure of using a
> FORTRAN compiler that was old and dumb even for the time.
> With this compiler, all parameters were passed by non-const
> reference. One of my team was delegated to write a
> subroutine that accepted certain parameters. There was
> miscommunication about the expected parameter order, and the
> calling code ended up passing the integer literal '5' in the
> parameter slot to which the subroutine stored its result.
> 
> From that point on, everywhere the literal '5' appeared in
> the source, the executable was instead referencing the
> result of some computation.
> 
> Merriment ensued as the program confounded all attempts to
> predict its behavior.
> 
> You are proposing to do the same to the Python interpreter.
> It's appropriate for Boost.Python to try to make that
> difficult.
> 
> </boring anecdote>
> 
> Suppose you were writing this code from scratch in pure
> Python. How would you approach the problem? This won't
> work:
> 
> def add(a, b, c):
> ? ? c = a + b
> 
> def caller():
> ? ? c = 0
> ? ? add(1, 2, c)
> ? ? assert c == 3???# FAIL
> 
> One way would be to keep some set of working variables in
> an object, and pass that object into the function that wants
> to modify them:
> 
> class Vars(object):
> ? ? def __init__(self):
> ? ? ? ? self.a = 0
> ? ? ? ? self.b = 0
> ? ? ? ? self.c = 0
> 
> def add(a, b, vars):
> ? ? vars.c = a + b
> 
> def caller():
> ? ? v = Vars()
> ? ? add(1, 2, v)
> ? ? assert v.c == 3
> 
> Or you could keep working values in a dict, if you prefer
> dict lookup to attribute references.
> 
> You can code your C++ add() function to accept its 'vars'
> parameter as a boost::python::object. If you pass a class
> object, you can reference vars.attr("c"). If you pass a
> dict, you can reference vars["c"].
> 
> See also: http://www.boost.org/doc/libs/1_43_0/libs/python/doc/tutorial/doc/html/python/embedding.html#python.using_the_interpreter
> 
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
> 


      


From talljimbo at gmail.com  Mon Aug  2 23:23:32 2010
From: talljimbo at gmail.com (Jim Bosch)
Date: Mon, 02 Aug 2010 14:23:32 -0700
Subject: [C++-sig] Calling a C++ function with arguments by reference
 (lvalues)
In-Reply-To: <653642.71834.qm@web55703.mail.re3.yahoo.com>
References: <653642.71834.qm@web55703.mail.re3.yahoo.com>
Message-ID: <4C573754.7000602@gmail.com>

On 08/02/2010 01:46 PM, Oded Padon wrote:
> import ctypes;
> lib_cpp = ctypes.CDLL('./test_cpp.so')
> result = ctypes.c_int(0);
> lib_cpp.add(1, 2, ctypes.byref(result));
> print result;
>
> prints: "c_long(3)"
>
> I do prefer however to use boost.python, as I would at a later stage want to expose C++ classes to python, but exposing functions like the above is step one for me.
>

This works because ctypes provides integer types ("c_int", etc.) which 
are mutable in Python; in other words, you can change the value of a 
ctypes.c_int object.

That isn't true for regular Python int objects (or str objects, or tuple 
objects, for instance).  Whenever it *looks* like you've changed one, as in:

a = 3
a += 2

... you actually haven't.  The second line won't add 2 to the integer 
object that previously had the value 3.  It might construct a new int 
object with a value of 5.  And in some Python implementations, it might 
just increment the reference count of a pre-existing global integer 
object that already has the value 5 and set "a" to be a reference to 
that object.  The point is that immutable types in Python simply cannot 
be modified in place, and Python plays tricks to make it *seem* like 
they're being modified while it ensures that they never really are.

If you really want to go down this route, you can create a C++ object 
that behaves like an int and wrap it with Boost.Python; that object 
won't be immutable, and you can give it the necessary operators to 
interact properly with regular ints.  And you'll be able to pass it 
by-value to functions.  But my guess is that it's probably much easier 
just to pass a dictionary to all of your functions.

Hope that helps!

Jim Bosch

From nat at lindenlab.com  Mon Aug  2 23:35:24 2010
From: nat at lindenlab.com (Nat Goodspeed)
Date: Mon, 02 Aug 2010 17:35:24 -0400
Subject: [C++-sig] Calling a C++ function with arguments by reference
 (lvalues)
In-Reply-To: <653642.71834.qm@web55703.mail.re3.yahoo.com>
References: <653642.71834.qm@web55703.mail.re3.yahoo.com>
Message-ID: <4C573A1C.3080501@lindenlab.com>

Oded Padon wrote:

> There is another reason why I think this has to be possible.
 > It is possible using ctypes. Using ctypes with the same C++
 > code written above (except for extern "C"), the following python code:
> 
> import ctypes;
> lib_cpp = ctypes.CDLL('./test_cpp.so')
> result = ctypes.c_int(0);
> lib_cpp.add(1, 2, ctypes.byref(result));
> print result;
> 
> prints: "c_long(3)"

Yes. In this case, you allocated and passed a specific ctypes object 
guaranteed to be compatible with a C++ int.

I still stand by my earlier point. Python doesn't recognize the concept 
of 'const'. All int values are equally immutable. If Boost.Python were 
to allow usage like this:

result = int()
cppmodule.add(1, 2, result)
assert result == 3

then what should happen in this innocent-looking case?

result = int()
cppmodule.add(result, 1, 2)

Or consider this. In recent versions of the Python interpreter, if you 
assign (say) 5 to a variable and then double it enough times, you will 
eventually produce a value larger than a C++ int. Unlike C++, Python 
will grow the storage associated with that variable to be able to 
represent the value exactly.

What should happen when you try to pass *that* value to a C++ int& 
parameter?

If you're happy with the ctypes approach, you could easily introduce a 
convention like this:

class RefInt(object):
     def __init__(self, value=int()):
         self.value = value

     def __int__(self):
         return self.value

     # ...other operations as desired for convenience...

Now, assuming you've coded your C++ add() function to accept a RefInt, 
you can write:

result = RefInt(0)
cppmodule.add(1, 2, result)
assert int(result) == 3

which is just as facile as the ctypes code you cited.

From marek at octogan.net  Wed Aug  4 15:09:35 2010
From: marek at octogan.net (Marek Denis)
Date: Wed, 04 Aug 2010 15:09:35 +0200
Subject: [C++-sig] Strange boost::python::object behaviour
Message-ID: <4C59668F.3090109@octogan.net>

Hello everybody,

This is my first post on this mailing group so I wanted to say hello to 
all ml users ;)

I am encounetring a strange problem with boost::python::object in my module.

What I want to achieve is a module written in C++ with use of the 
boost::python, that can be imported to normal python application.
Python classes would do some additional parsing and put everything into 
the database.  However, in my C++ code I would like to launch a few 
methods from the instances of the classes that were defined in the 
Python code (different module).

 From the python point of view it should look like this:

#v+
m=cppmodule.cppclass()()
t=pythonmodule.pythonclass()

m.register_callback(t)
m.start()
#v-

and the 'm' instance should start it's work however invoking some 
methods of the 't' instance.

What I did was writing a method in my C++ code, something like:

#v+
void Manager::register_callback(boost::python::object&  obj)
{

    this->callback = obj;
    for(int i=0;i<5;++i)
    {
        std::cout << "Callback P()" << endl;
        callback.attr("p")();
    }
    return;

}
#v-

This is supposed to save an object to my C++ class so that I can use it 
later ( this->callback = obj; )
I did some tests, by  invoking some 'test' method of the Python object 
(method called 'p'), that just prints some string. It does work when I 
invoke register_callback method. However, later in code, when I invoke 
other method, say (for tests now):

#v+
void Manager::test()
{

     callback.attr("p")();

     return;
}
#v-

I get the "segmentation fault".
I should admit, that the callback variable is inside the global instance 
of the Manager object, none of the objects are deleted.
Where should I look for a solution, what do I wrong?

Thanks in advance!

-- 
pozdrawiam

Marek Denis


From erlend.cleveland at gmail.com  Sun Aug 15 23:33:39 2010
From: erlend.cleveland at gmail.com (Erlend Cleveland)
Date: Mon, 16 Aug 2010 09:33:39 +1200
Subject: [C++-sig] shared_ptr object identity
Message-ID: <AANLkTi=+fxN7hFd9kMTT5jvf9RSuxxkoJ6mNKkVaM9NC@mail.gmail.com>

Hi all,

I've been bashing my head against a wall for the past couple of days
trying to figure this out. It's frustrating because it seems like it
should be such a simple thing. I've also read through every archived
message I can find relating to this topic, but just can't seem to pull
it all together.

Here is a minimal example showing what I'm trying to do:

---------------------------------------------------------------
C++:

#include <boost/shared_ptr.hpp>

class Bar
{};

typedef boost::shared_ptr<Bar> BarPtr;

BarPtr mFooInstance = BarPtr(new Bar());

BarPtr getBar()
{
?? ?return mBarInstance;
}

--------------------------------------------------------------
C++ / Python binding:

#include <boost/python.hpp>

using namespace boost::python;

BOOST_PYTHON_MODULE(Foo)
{
    class_<Bar, boost::noncopyable>("Bar", no_init);

    def("getBar", &getBar);

    register_ptr_to_python<BarPtr>();
}

--------------------------------------------------------------
Python:

import Foo

bar1 = Foo.getBar()
bar2 = Foo.getBar()

assert bar1 == bar2    # Assert fails due to bar1 and bar2 having
separate python objects

All I would like to achieve is for bar1 and bar2 to point to the same
python object, in the case where the object was created on the C++
side, such that I can add python attributes to such instances and have
this state preserved. Note that I am using a global mFooInstance for
simplicity, but in reality such object will be held as members or in
containers.

Thanks in advance for any help!

From rwgk at yahoo.com  Mon Aug 16 00:45:34 2010
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 15 Aug 2010 15:45:34 -0700 (PDT)
Subject: [C++-sig] shared_ptr object identity
In-Reply-To: <AANLkTi=+fxN7hFd9kMTT5jvf9RSuxxkoJ6mNKkVaM9NC@mail.gmail.com>
References: <AANLkTi=+fxN7hFd9kMTT5jvf9RSuxxkoJ6mNKkVaM9NC@mail.gmail.com>
Message-ID: <297686.71582.qm@web111408.mail.gq1.yahoo.com>

Hi Erland,

> I've been bashing my head against a wall for the past couple of days

> trying to figure this out. It's frustrating because it seems like it
> should be such a simple thing.

I cannot be so simple if you think of the C++ side as being unaware of
the Python layer. Each time the C++ function is called Boost.Python has
to create a new Python object. I believe it is very difficult or maybe
even impossible to reliably return the same Python object like you expect.

> BarPtr getBar()
> {
>     return mBarInstance;
> }

I think your example can be made to work like this (untested):

In the file with the Python bindings:

boost::python::object getBar_wrapper()
{
  static boost::python::object result = getBar();
  return result;
}

With:

  def("getBar", getBar_wrapper);

But I've not tested it.

> Note that I am using a global mFooInstance for
> simplicity, but in reality such object will be held as members

That still seems doable, via a wrapper object.

> or in containers.

If you have pure C++ containers in mind I think it is possible only
via virtual functions that you override in a wrapper object.

But maybe the best solution is something else, without requiring object 
identity:

- Add all data attributes to the C++ object (and use .def_readonly() or 
.def_readwrite()).
  Then the state of the object is preserved naturally.

- Inject additional Python methods as described in the Boost.Python tutorial:

http://www.boost.org/doc/libs/1_43_0/libs/python/doc/tutorial/doc/html/python/techniques.html#python.extending_wrapped_objects_in_python


Ralf

From erlend.cleveland at gmail.com  Mon Aug 16 04:04:58 2010
From: erlend.cleveland at gmail.com (Erlend Cleveland)
Date: Mon, 16 Aug 2010 14:04:58 +1200
Subject: [C++-sig] shared_ptr object identity
In-Reply-To: <297686.71582.qm@web111408.mail.gq1.yahoo.com>
References: <AANLkTi=+fxN7hFd9kMTT5jvf9RSuxxkoJ6mNKkVaM9NC@mail.gmail.com>
	<297686.71582.qm@web111408.mail.gq1.yahoo.com>
Message-ID: <AANLkTimaqseAq9ry-eC1K_FtboyRTVxTFUB_ZJmL8yH=@mail.gmail.com>

>> I've been bashing my head against a wall for the past couple of days
>
>> trying to figure this out. It's frustrating because it seems like it
>> should be such a simple thing.
>
> I cannot be so simple if you think of the C++ side as being unaware of
> the Python layer. Each time the C++ function is called Boost.Python has
> to create a new Python object. I believe it is very difficult or maybe
> even impossible to reliably return the same Python object like you expect.

Well that's somewhat comforting to know :)

>> Note that I am using a global mFooInstance for
>> simplicity, but in reality such object will be held as members
>
> That still seems doable, via a wrapper object.
>

So I would wrap member functions returning the shared_ptr, and store a
persistent reference to the python object, returning its shared_ptr
instead?

> - Add all data attributes to the C++ object (and use .def_readonly() or
> .def_readwrite()).
> ?Then the state of the object is preserved naturally.
>
> - Inject additional Python methods as described in the Boost.Python tutorial:
>
> http://www.boost.org/doc/libs/1_43_0/libs/python/doc/tutorial/doc/html/python/techniques.html#python.extending_wrapped_objects_in_python

None of these methods would allow me to extend the individual
instances dynamically with attributes in python, correct? I suppose I
could create some python code to wrap attributes and map to them from
an ID on the object, but I can't imagine that would be terribly
generic or concise.

I stumbled upon this post in my search -
http://mail.python.org/pipermail/cplusplus-sig/2006-March/010169.html.
It talks about swapping out the shared_ptr with one that manages the
Python object instead, so that presumably, subsequent usage of the
shared_ptr will allow Python to know about the object. Unfortunately
it doesn't seem to fit with my scenario, and is possibly more relevant
to embedded python, but isn't there some way to write a custom
to_python_converter to allow me to inject that code whenever a
shared_ptr is to be converted to python?

Earl

From rwgk at yahoo.com  Mon Aug 16 06:11:48 2010
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 15 Aug 2010 21:11:48 -0700 (PDT)
Subject: [C++-sig] shared_ptr object identity
In-Reply-To: <AANLkTimaqseAq9ry-eC1K_FtboyRTVxTFUB_ZJmL8yH=@mail.gmail.com>
References: <AANLkTi=+fxN7hFd9kMTT5jvf9RSuxxkoJ6mNKkVaM9NC@mail.gmail.com>
	<297686.71582.qm@web111408.mail.gq1.yahoo.com>
	<AANLkTimaqseAq9ry-eC1K_FtboyRTVxTFUB_ZJmL8yH=@mail.gmail.com>
Message-ID: <634949.19831.qm@web111412.mail.gq1.yahoo.com>

Hi Earl,

> So I would wrap member functions returning the shared_ptr, and store a

> persistent reference to the python object, returning its shared_ptr
> instead?

Yes.

> > - Add all data attributes to the C++ object (and use .def_readonly() or
> > .def_readwrite()).
> >  Then the state of the object is preserved naturally.
> >
> > - Inject additional Python methods as described in the Boost.Python 
tutorial:
> >
> > 
>http://www.boost.org/doc/libs/1_43_0/libs/python/doc/tutorial/doc/html/python> 
>/techniques.html#python.extending_wrapped_objects_in_python
> 
> None of these methods would allow me to extend the individual
> instances dynamically with attributes in python, correct?

Yes.
Do I understand correctly that you want to use the object essentially like
a dictionary, just with obj.key instead of obj["key"]?
I consider this bad practice, since it isn't obvious to readers of your
code.
Did you consider adding a boost::python::object member to your C++
object? That would solve all your problems I think and it would be
obvious.
If you need to keep your C++ code independent of Python, you could
work with boost::any.
 
> but isn't there some way to write a custom
> to_python_converter to allow me to inject that code whenever a
> shared_ptr is to be converted to python?

I think you could make this work, but you'd have to maintain a registry.
I'd look for a more conventional solution first.

Ralf

From erlend.cleveland at gmail.com  Mon Aug 16 10:17:50 2010
From: erlend.cleveland at gmail.com (Erlend Cleveland)
Date: Mon, 16 Aug 2010 20:17:50 +1200
Subject: [C++-sig] shared_ptr object identity
In-Reply-To: <634949.19831.qm@web111412.mail.gq1.yahoo.com>
References: <AANLkTi=+fxN7hFd9kMTT5jvf9RSuxxkoJ6mNKkVaM9NC@mail.gmail.com>
	<297686.71582.qm@web111408.mail.gq1.yahoo.com>
	<AANLkTimaqseAq9ry-eC1K_FtboyRTVxTFUB_ZJmL8yH=@mail.gmail.com>
	<634949.19831.qm@web111412.mail.gq1.yahoo.com>
Message-ID: <AANLkTimtnBHurG0E_77cB5iD9J-5KuFMxt-S9SrUYKFf@mail.gmail.com>

> Do I understand correctly that you want to use the object essentially like
> a dictionary, just with obj.key instead of obj["key"]?
> I consider this bad practice, since it isn't obvious to readers of your
> code.

Yes, you make a good point here, and it has made me question the use
cases that I was considering. That said, this type of usage can
provide some elegant solutions to otherwise cumbersome ones, and I
admit, I can sometimes be a very lazy programmer.

This raises the question of how, if object identity is not preserved,
one can explicitly associate data with objects in order to look up
said data later. Do I have to expose an ID manually on each class I
wrap?

Earl

From rwgk at yahoo.com  Mon Aug 16 22:38:44 2010
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 16 Aug 2010 13:38:44 -0700 (PDT)
Subject: [C++-sig] shared_ptr object identity
In-Reply-To: <AANLkTimtnBHurG0E_77cB5iD9J-5KuFMxt-S9SrUYKFf@mail.gmail.com>
References: <AANLkTi=+fxN7hFd9kMTT5jvf9RSuxxkoJ6mNKkVaM9NC@mail.gmail.com>
	<297686.71582.qm@web111408.mail.gq1.yahoo.com>
	<AANLkTimaqseAq9ry-eC1K_FtboyRTVxTFUB_ZJmL8yH=@mail.gmail.com>
	<634949.19831.qm@web111412.mail.gq1.yahoo.com>
	<AANLkTimtnBHurG0E_77cB5iD9J-5KuFMxt-S9SrUYKFf@mail.gmail.com>
Message-ID: <249470.1985.qm@web111410.mail.gq1.yahoo.com>

Hi Earl,

> > Do I understand correctly that you want to use the object essentially like

> > a dictionary, just with obj.key instead of obj["key"]?
> > I consider this bad practice, since it isn't obvious to readers of your
> > code.
>
> Yes, you make a good point here, and it has made me question the use
> cases that I was considering. That said, this type of usage can
> provide some elegant solutions to otherwise cumbersome ones, and I
> admit, I can sometimes be a very lazy programmer.
>
> This raises the question of how, if object identity is not preserved,
> one can explicitly associate data with objects in order to look up
> said data later. Do I have to expose an ID manually on each class I
> wrap?

Yes, you will need some type of ID. In one situation I've used the memory
address of the object, the pointee of the shared pointer cast to size_t.
But this was just used to determine object identity, not to look up associated
data. For that you'd have to worry about re-use of the old address for a new
object. So to be safe I believe you'd have to go to UUIDs. Another tricky
question is how you clean up your lookup table. I imagine you need some type of
garbage collection...
If you like to be lazy, just add a placeholder (boost::python::object or
boost::any) for the associated data to the C++ object!

Ralf

From branan at gmail.com  Mon Aug 16 23:33:04 2010
From: branan at gmail.com (Branan Purvine-Riley)
Date: Mon, 16 Aug 2010 14:33:04 -0700
Subject: [C++-sig] Python __init__ that copies internal reference,
	boost.python
Message-ID: <201008161433.04661.branan@gmail.com>

I'm working on replacing hand-rolled python bindings with boost.python. 
Unfortunately, I've hit a bit of a snag at a particular construct:

  a = someFunction(...) # returns an instance of myClass
  b = myClass(a)

In the current bindings, this creates a new python object that references the 
same internal C++ object. It's effectively no-op, and I have no idea why it was 
written that way in the first place, but I have to maintain API compatibility.

That being the case, how do I implement this in boost.python? I considered 
replacing __init__, but it seems if I implement that as a standalone function 
rather than a constructor, boost has already created a new C++ instance for 
me, so that's too late. I'm not really sure what else to try.

From talljimbo at gmail.com  Mon Aug 16 23:49:04 2010
From: talljimbo at gmail.com (Jim Bosch)
Date: Mon, 16 Aug 2010 14:49:04 -0700
Subject: [C++-sig] Python __init__ that copies internal reference,
	boost.python
In-Reply-To: <201008161433.04661.branan@gmail.com>
References: <201008161433.04661.branan@gmail.com>
Message-ID: <4C69B250.8010401@gmail.com>

On 08/16/2010 02:33 PM, Branan Purvine-Riley wrote:
> I'm working on replacing hand-rolled python bindings with boost.python.
> Unfortunately, I've hit a bit of a snag at a particular construct:
>
>    a = someFunction(...) # returns an instance of myClass
>    b = myClass(a)
>
> In the current bindings, this creates a new python object that references the
> same internal C++ object. It's effectively no-op, and I have no idea why it was
> written that way in the first place, but I have to maintain API compatibility.
>
> That being the case, how do I implement this in boost.python? I considered
> replacing __init__, but it seems if I implement that as a standalone function
> rather than a constructor, boost has already created a new C++ instance for
> me, so that's too late. I'm not really sure what else to try.

You'll want to use the make_constructor function; this takes a C++ 
function returning a C++ smart pointer and creates a Python __init__ 
overload.

I *think* this should work (I haven't tested it):

----------------------------------------------

boost::shared_ptr<MyClass> construct(boost::python::object const & arg) {
     return boost::python::extract< boost::shared_ptr<MyClass> >(arg);
}

BOOST_PYTHON_MODULE(example) {
     boost::python::class_<MyClass>("MyClass")
         .def("__init__", boost::python::make_constructor(&construct))
         ;
     boost::python::register_ptr_to_python<
         boost::shared_ptr<MyClass>
     >();
}

----------------------------------------------

Hope that helps.

Jim Bosch


From branan at gmail.com  Tue Aug 17 01:21:17 2010
From: branan at gmail.com (Branan Purvine-Riley)
Date: Mon, 16 Aug 2010 16:21:17 -0700
Subject: [C++-sig] Python __init__ that copies internal reference,
	boost.python
In-Reply-To: <4C69B250.8010401@gmail.com>
References: <201008161433.04661.branan@gmail.com> <4C69B250.8010401@gmail.com>
Message-ID: <201008161621.17698.branan@gmail.com>

On Monday 16 August 2010 14:49:04 Jim Bosch wrote:
> On 08/16/2010 02:33 PM, Branan Purvine-Riley wrote:
> > I'm working on replacing hand-rolled python bindings with boost.python.
> > 
> > Unfortunately, I've hit a bit of a snag at a particular construct:
> >    a = someFunction(...) # returns an instance of myClass
> >    b = myClass(a)
> > 
> > In the current bindings, this creates a new python object that references
> > the same internal C++ object. It's effectively no-op, and I have no idea
> > why it was written that way in the first place, but I have to maintain
> > API compatibility.
> > 
> > That being the case, how do I implement this in boost.python? I
> > considered replacing __init__, but it seems if I implement that as a
> > standalone function rather than a constructor, boost has already created
> > a new C++ instance for me, so that's too late. I'm not really sure what
> > else to try.
> 
> You'll want to use the make_constructor function; this takes a C++
> function returning a C++ smart pointer and creates a Python __init__
> overload.
> 
> I *think* this should work (I haven't tested it):
> 
> ----------------------------------------------
> 
> boost::shared_ptr<MyClass> construct(boost::python::object const & arg) {
>      return boost::python::extract< boost::shared_ptr<MyClass> >(arg);
> }
> 
> BOOST_PYTHON_MODULE(example) {
>      boost::python::class_<MyClass>("MyClass")
>          .def("__init__", boost::python::make_constructor(&construct))
>          ;
>      boost::python::register_ptr_to_python<
>          boost::shared_ptr<MyClass>
> 
>      >();
> 
> }
> 

That's definitely on the right track. Not quite right because of some of the 
oddities of what I'm working with here. It's a game engine, and none of the 
pointers are stored in a smart pointer container of any kind. Unfortunately 
make_constructor will convert a raw ptr to an std::auto_ptr, which deletes the 
object somewhere in boost code.

What I ended up with is the following:

  template<typename T>
  struct dummy_ptr {
    dummy_ptr(T* p) : ptr(p) {}
    T* operator->() { return ptr; }
    T* ptr;
    typedef T element_type;
  };

  template<typename T>
  T* get_pointer(const dummy_ptr<T>& dummy) {
    return dummy.ptr;
  }

  template<typename T>
  dummy_ptr<T> noop_constructor(T* arg) {
    return dummy_ptr<T>(arg);
  }

 BOOST_PYTHON_MODULE(example) {
      boost::python::class_<MyClass>("MyClass")
          .def("__init__",boost::python::make_constructor(&noop_constructor<MyClass>));
      boost::python::register_ptr_to_python<dummy_ptr<MyClass> >();
 }

From talljimbo at gmail.com  Tue Aug 17 02:08:33 2010
From: talljimbo at gmail.com (Jim Bosch)
Date: Mon, 16 Aug 2010 17:08:33 -0700
Subject: [C++-sig] Python __init__ that copies internal reference,
	boost.python
In-Reply-To: <201008161621.17698.branan@gmail.com>
References: <201008161433.04661.branan@gmail.com> <4C69B250.8010401@gmail.com>
	<201008161621.17698.branan@gmail.com>
Message-ID: <4C69D301.80509@gmail.com>

On 08/16/2010 04:21 PM, Branan Purvine-Riley wrote:
>
> That's definitely on the right track. Not quite right because of some of the
> oddities of what I'm working with here. It's a game engine, and none of the
> pointers are stored in a smart pointer container of any kind. Unfortunately
> make_constructor will convert a raw ptr to an std::auto_ptr, which deletes the
> object somewhere in boost code.
>

Glad to see you've got something that works.  Don't dismiss the 
shared_ptr version automatically, though; Boost.Python can construct a 
shared_ptr for a wrapped C++ object held inside a Python object even if 
it wasn't wrapped using shared_ptr - it uses a shared_ptr deleter that 
owns a Python reference.

Of course, if there's no concern about whether the C++ object will get 
destroyed while the second Python object that refers to it is still 
alive, then your solution is just fine.


Jim

From David.Aldrich at EU.NEC.COM  Tue Aug 17 15:20:22 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Tue, 17 Aug 2010 14:20:22 +0100
Subject: [C++-sig] Linking issues with Boost.Python
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D1630@EUEXCLU01.EU.NEC.COM>

Hi

I would be grateful for some help with setting up some makefiles for my C++ application, compiled with gcc under Linux, that uses Boost.Python.

The application consists of a static library that contains main() and various shared libraries that are dynamically linked at runtime as required. 

One of the shared libraries invokes the Python interpreter to act on some Python objects.

Initially,  I called Py_Initialize() from the shared library and linked that library to the Python and Boost libraries within the shared library's makefile. Then the Python calls worked as expected.

Now I want to move Py_Initialize() to my main() function, and invoke the Python interpreter from the shared library as before. So I linked the application to the Python and Boost libraries in my top level makefile, and deleted mention of the Python and Boost libraries from the shared library's makefile.  The result all links without errors but the Python calls do nothing.

If I use Boost.Python in a shared library, do I have to link Boost.Python to it when I build it, or would linking Boost.Python to the main application be sufficient?

(I hope this makes some sense).

Best regards

David

From s_sourceforge at nedprod.com  Wed Aug 18 15:31:16 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 18 Aug 2010 14:31:16 +0100
Subject: [C++-sig] Linking issues with Boost.Python
In-Reply-To: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D1630@EUEXCLU01.EU.NEC.COM>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D1630@EUEXCLU01.EU.NEC.COM>
Message-ID: <4C6BE0A4.15331.6768096E@s_sourceforge.nedprod.com>

On 17 Aug 2010 at 14:20, David Aldrich wrote:

> I would be grateful for some help with setting up some makefiles for my
> C++ application, compiled with gcc under Linux, that uses Boost.Python. 

I would strongly recommend that you use something more modern than 
GNU make. Boost's build system is much better. The one I use is scons 
(http://www.scons.org/) whose only main fault is O(N^2) scaling to 
source file number, a problem they are in the process of fixing.

Scons has the *major* advantage of its build config being python 
source. So its SConstruct and SConscript files are literally straight 
python.

> Now I want to move Py_Initialize() to my main() function, and invoke the
> Python interpreter from the shared library as before. So I linked the
> application to the Python and Boost libraries in my top level makefile,
> and deleted mention of the Python and Boost libraries from the shared
> library's makefile.  The result all links without errors but the Python
> calls do nothing. 

Each thing which uses python ought to separately link to python and 
Boost.Python if necessary. You then leave the runtime linker figure 
it all out. If you were using scons or make, have a separate build 
config per DLL i.e. each DLL/shared object is a separate project.

If you're using dlopen() to load these libraries at runtime make SURE 
you use RTLD_GLOBAL, otherwise you'll get multiple copies of BPL and 
python and it won't work.

> If I use Boost.Python in a shared library, do I have to link
> Boost.Python to it when I build it, or would linking Boost.Python to the
> main application be sufficient? 

I think the command on Linux for checking what libraries link to what 
is 'ldd'. Use on each shared library to ensure its individual 
dependencies are satisfied.

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From David.Aldrich at EU.NEC.COM  Wed Aug 18 16:32:01 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Wed, 18 Aug 2010 15:32:01 +0100
Subject: [C++-sig] Linking issues with Boost.Python
In-Reply-To: <4C6BE0A4.15331.6768096E@s_sourceforge.nedprod.com>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D1630@EUEXCLU01.EU.NEC.COM>
	<4C6BE0A4.15331.6768096E@s_sourceforge.nedprod.com>
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D16C9@EUEXCLU01.EU.NEC.COM>

Hi Niall

> I would strongly recommend that you use something more modern than
> GNU make. Boost's build system is much better. The one I use is scons
> (http://www.scons.org/) whose only main fault is O(N^2) scaling to
> source file number, a problem they are in the process of fixing.

I take your point. Personally, I find makefiles very hard to maintain. In particular, our #include dependency management is indecipherable! I guess the obvious replacements are SCons and CMake. I will take a look at these.

Should one consider bjam?

Thanks very much for answering my other questions.

Best regards

David

From nat at lindenlab.com  Wed Aug 18 17:18:18 2010
From: nat at lindenlab.com (Nat Goodspeed)
Date: Wed, 18 Aug 2010 11:18:18 -0400
Subject: [C++-sig] Linking issues with Boost.Python
In-Reply-To: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D16C9@EUEXCLU01.EU.NEC.COM>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D1630@EUEXCLU01.EU.NEC.COM>	<4C6BE0A4.15331.6768096E@s_sourceforge.nedprod.com>
	<0CCCA5445D7FCB4298BBF0739D4FDD520260A85D16C9@EUEXCLU01.EU.NEC.COM>
Message-ID: <4C6BF9BA.6040707@lindenlab.com>

David Aldrich wrote:

>> I would strongly recommend that you use something more modern than
>> GNU make. Boost's build system is much better. The one I use is scons
>> (http://www.scons.org/) whose only main fault is O(N^2) scaling to
>> source file number, a problem they are in the process of fixing.
> 
> Should one consider bjam?

That's what Niall meant by "Boost's build system." Boost.Build uses bjam 
as its engine, with substantial work around that.

I've always found bjam syntax a bit off-putting, and I've never read the 
available Boost.Build documentation, which is probably superb. So in 
fairness to the work of many others, I'll only note that many of the 
questions on the boost-users mailing list seem to be from people 
confused by proper use of '--' on the bjam command line, proper 
placement of spaces and commas in the configuration files, etc.

I really want to like scons: I see no need to invent a whole new 
language for a build engine.

That said, our organization presently uses CMake.

From s_sourceforge at nedprod.com  Wed Aug 18 19:02:32 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 18 Aug 2010 18:02:32 +0100
Subject: [C++-sig] Linking issues with Boost.Python
In-Reply-To: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D16C9@EUEXCLU01.EU.NEC.COM>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D1630@EUEXCLU01.EU.NEC.COM>,
	<4C6BE0A4.15331.6768096E@s_sourceforge.nedprod.com>,
	<0CCCA5445D7FCB4298BBF0739D4FDD520260A85D16C9@EUEXCLU01.EU.NEC.COM>
Message-ID: <4C6C1228.15627.6829755C@s_sourceforge.nedprod.com>

On 18 Aug 2010 at 15:32, David Aldrich wrote:

> > I would strongly recommend that you use something more modern than
> > GNU make. Boost's build system is much better. The one I use is scons
> > (http://www.scons.org/) whose only main fault is O(N^2) scaling to
> > source file number, a problem they are in the process of fixing.
> 
> I take your point. Personally, I find makefiles very hard to maintain.
> In particular, our #include dependency management is indecipherable! I
> guess the obvious replacements are SCons and CMake. I will take a look
> at these. 

Yeah scons is particularly outstanding with handling dependencies, 
though it's exactly that which is introducing the O(N^2) complexity. 
It goes off and works out what they are for you as a default and then 
you can programatically override if you need to. Unlike other build 
systems, you really can program the build system down to a fine 
detail. Want some crazy build and dependency system which calls a 
series of munge scripts to auto-generate C++ and/or GLSL shader 
programs in a recursive descent? Want to build eight different 
versions of the same DLL each with slightly different configuration 
and slightly different name, and then get parent projects to choose 
the right binary to link against according to a set of heuristics? 
Want to have the build system fire up a copy of VirtualBox running 
some arbitrary operating system, compile some sources there checked 
out from the local GIT repo and push them into the local build? None 
of these are a problem with scons, mainly because scons IS python and 
anything python can do your build can do.

> Should one consider bjam?

As Nat said, bjam is the core of Boost Build but Boost adds a lot to 
it. I've always found it lacking in configurability personally, and 
like Nat I'm also not fond of its syntax either - much like CMake 
too. I will say though that bjam scales very well and has no issue 
with truly huge projects.

But as you might guess from my examples above, I program my build 
environment much as I program applications. Anything which saves time 
in the long run really, and for me almost all build systems which are 
100% OS portable don't cut it here. If it weren't for the O(N^2) 
scaling problem, I'd actually say it's the perfect build system 
unless you hate python. And certainly given we're in the C++ SIG for 
python it's hard not to naturally recommend it!

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From gjcarneiro at gmail.com  Thu Aug 19 15:10:02 2010
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Thu, 19 Aug 2010 14:10:02 +0100
Subject: [C++-sig] Linking issues with Boost.Python
In-Reply-To: <4C6C1228.15627.6829755C@s_sourceforge.nedprod.com>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D1630@EUEXCLU01.EU.NEC.COM>
	<4C6BE0A4.15331.6768096E@s_sourceforge.nedprod.com>
	<0CCCA5445D7FCB4298BBF0739D4FDD520260A85D16C9@EUEXCLU01.EU.NEC.COM>
	<4C6C1228.15627.6829755C@s_sourceforge.nedprod.com>
Message-ID: <AANLkTi=JfYBC6SkoC_909qwnwtMGS6aE2OaB5rSAwrdS@mail.gmail.com>

On Wed, Aug 18, 2010 at 18:02, Niall Douglas <s_sourceforge at nedprod.com>wrote:
[...]

>
> As Nat said, bjam is the core of Boost Build but Boost adds a lot to
> it. I've always found it lacking in configurability personally, and
> like Nat I'm also not fond of its syntax either - much like CMake
> too. I will say though that bjam scales very well and has no issue
> with truly huge projects.
>
> But as you might guess from my examples above, I program my build
> environment much as I program applications. Anything which saves time
> in the long run really, and for me almost all build systems which are
> 100% OS portable don't cut it here. If it weren't for the O(N^2)
> scaling problem, I'd actually say it's the perfect build system
> unless you hate python. And certainly given we're in the C++ SIG for
> python it's hard not to naturally recommend it!
>

See also: WAF http://code.google.com/p/waf/

It is also in Python, but is a lot faster than scons.  It has some usability
problems (but scons does have them too), but it's a pretty useful tool to
know...

-- 
Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20100819/422d9a42/attachment.html>

From s_sourceforge at nedprod.com  Thu Aug 19 16:09:30 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 19 Aug 2010 15:09:30 +0100
Subject: [C++-sig] Linking issues with Boost.Python
In-Reply-To: <AANLkTi=JfYBC6SkoC_909qwnwtMGS6aE2OaB5rSAwrdS@mail.gmail.com>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D1630@EUEXCLU01.EU.NEC.COM>,
	<4C6C1228.15627.6829755C@s_sourceforge.nedprod.com>,
	<AANLkTi=JfYBC6SkoC_909qwnwtMGS6aE2OaB5rSAwrdS@mail.gmail.com>
Message-ID: <4C6D3B1A.24153.6CB16583@s_sourceforge.nedprod.com>

On 19 Aug 2010 at 14:10, Gustavo Carneiro wrote:

> See also: WAF http://code.google.com/p/waf/
> 
> It is also in Python, but is a lot faster than scons.  It has some usability
> problems (but scons does have them too), but it's a pretty useful tool to
> know...

That is a very useful link indeed - thank you very much for posting 
it.

Waf does solve two of my most pressing problems with scons 
(scalability and needing to separately install scons after python) 
but it does introduce a number of other failings, such as a very 
Unixy approach which doesn't gel well with Windows or MSVC at all and 
a clone of the autotools UI and philosophy which I have always 
detested as being braindead. It makes sense of course coming from the 
KDE developers where they were trying to get scons to work, but it 
was infeasible so they came up with Waf.

Waf's documentation does make the very valid point that build systems 
ought not to be based around files but rather processes which receive 
input and generate output. That way things like distcc become easy as 
well as a load of other stuff because they now work with streams of 
data rather than files.

Oh for a python based build system which does tick all the boxes at 
once!

Thanks once again for the link,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From David.Aldrich at EU.NEC.COM  Thu Aug 19 17:27:48 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Thu, 19 Aug 2010 16:27:48 +0100
Subject: [C++-sig] Linking issues with Boost.Python
In-Reply-To: <4C6D3B1A.24153.6CB16583@s_sourceforge.nedprod.com>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D1630@EUEXCLU01.EU.NEC.COM>,
	<4C6C1228.15627.6829755C@s_sourceforge.nedprod.com>,
	<AANLkTi=JfYBC6SkoC_909qwnwtMGS6aE2OaB5rSAwrdS@mail.gmail.com>
	<4C6D3B1A.24153.6CB16583@s_sourceforge.nedprod.com>
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D1750@EUEXCLU01.EU.NEC.COM>

Hi

Thanks for the replies. It seems that some people do have concerns about SCons. 

I think that CMake may be a better choice for us. We don't need the cross-platform capability but if CMake has more comprehensible configuration files and solves the #include dependency checking problem, that would be a real improvement over gnu make.

Best regards

David


From David.Aldrich at EU.NEC.COM  Wed Aug 25 12:52:42 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Wed, 25 Aug 2010 11:52:42 +0100
Subject: [C++-sig] Does Py_Initialize change CTRL-C behaviour?
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D196F@EUEXCLU01.EU.NEC.COM>

Hi

We have just added Py_Initialize() and Py_Finalize() calls to our C++ application, in order to support embedded Python.

Our's is a console application.  We have noticed the side effect that CTRL-C no longer terminates the application. This is true for both Linux and Windows builds.

Is this a known behaviour of Py_Initialize() ?

Is there any way to reinstate normal CTRL-C handling?

Best regards

David

From David.Aldrich at EU.NEC.COM  Wed Aug 25 17:42:07 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Wed, 25 Aug 2010 16:42:07 +0100
Subject: [C++-sig] Does Py_Initialize change CTRL-C behaviour?
In-Reply-To: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D196F@EUEXCLU01.EU.NEC.COM>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D196F@EUEXCLU01.EU.NEC.COM>
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520260A85D19C7@EUEXCLU01.EU.NEC.COM>

Hi

I fixed this by replacing Py_Initialize() with Py_InitializeEx(0).

BR

David

From tuerke at cbs.mpg.de  Fri Aug 27 10:35:20 2010
From: tuerke at cbs.mpg.de (Erik Tuerke)
Date: Fri, 27 Aug 2010 10:35:20 +0200
Subject: [C++-sig] converting a PyObject into its C-Type
Message-ID: <4C7778C8.2030104@cbs.mpg.de>

Hi!

I am trying to convert a PyObject into its C-Type. The thing is, i have 
a function which takes a PyObject but i need to convert the PyObject 
into its respective C-Type.

For example i have a python class:

class_<isis::util::fvector4, _Vector4<float> >("py_fvector4", 
init<float, float, float, float>())
        .def( init<>())
        .def("__setitem__", &_Vector4<float>::setItem)
        .def("__getitem__", &_Vector4<float>::getItem)
        ;

How can i convert the PyObject "py_fvector4" back into its C-Type 
_Vector4 (or isis::util::fvector4) ?

Thanks for your help and best regards!

-- 
Erik Tuerke
Department of Neurophysics 
Max-Planck-Institute for Human Cognitive and Brain Sciences
Stephanstrasse 1A
04103 Leipzig
Germany 
Tel: +49 341 99 40-2440
Email: tuerke at cbs.mpg.de
www.cbs.mpg.de



From talljimbo at gmail.com  Fri Aug 27 19:16:22 2010
From: talljimbo at gmail.com (Jim Bosch)
Date: Fri, 27 Aug 2010 10:16:22 -0700
Subject: [C++-sig] converting a PyObject into its C-Type
In-Reply-To: <4C7778C8.2030104@cbs.mpg.de>
References: <4C7778C8.2030104@cbs.mpg.de>
Message-ID: <4C77F2E6.9000807@gmail.com>

On 08/27/2010 01:35 AM, Erik Tuerke wrote:
> Hi!
>
> I am trying to convert a PyObject into its C-Type. The thing is, i have
> a function which takes a PyObject but i need to convert the PyObject
> into its respective C-Type.
>
> For example i have a python class:
>
> class_<isis::util::fvector4, _Vector4<float> >("py_fvector4",
> init<float, float, float, float>())
> .def( init<>())
> .def("__setitem__", &_Vector4<float>::setItem)
> .def("__getitem__", &_Vector4<float>::getItem)
> ;
>
> How can i convert the PyObject "py_fvector4" back into its C-Type
> _Vector4 (or isis::util::fvector4) ?
>
> Thanks for your help and best regards!
>

Construct a boost::python::object from your PyObject*, and use extract():

namespace bp = boost::python;

void func(PyObject * arg);
     bp::object p(bp::handle<>(bp::borrowed(arg)));
     _Vector4<float> & v = bp::extract< _Vector4<float> >(arg);
}

This should also raise a TypeError if arg doesn't contain the 
appropriate C++ type.

By the way, Boost.Python can also wrap functions taking bp::object 
arguments, and that might be cleaner than a raw PyObject *.

HTH!

Jim Bosch

From talljimbo at gmail.com  Fri Aug 27 19:22:16 2010
From: talljimbo at gmail.com (Jim Bosch)
Date: Fri, 27 Aug 2010 10:22:16 -0700
Subject: [C++-sig] Strange boost::python::object behaviour
In-Reply-To: <4C59668F.3090109@octogan.net>
References: <4C59668F.3090109@octogan.net>
Message-ID: <4C77F448.70405@gmail.com>

On 08/04/2010 06:09 AM, Marek Denis wrote:
> Hello everybody,
>
> This is my first post on this mailing group so I wanted to say hello to
> all ml users ;)
>
> I am encounetring a strange problem with boost::python::object in my
> module.
>
<snip>

Could you please post a self-contained example that reproduces the problem?

I don't have any ideas on what's going wrong based on what you've posted 
so far.

Thanks!

Jim Bosch


From jiangzuoyan at gmail.com  Mon Aug 30 08:31:58 2010
From: jiangzuoyan at gmail.com (Changsheng Jiang)
Date: Mon, 30 Aug 2010 14:31:58 +0800
Subject: [C++-sig] registering the same type converter in different modules
	with Boost.Python
Message-ID: <AANLkTinJMxAY2+i2FH_MTSE0Wqn-8VkQ1GzgcS-OnD0H@mail.gmail.com>

Hi, list

I have to convert std::pair to python tuple in different modules
independently. And these modules may be used concurrently, importing the
second module will report an warning like "std::pair has been already
registered".

How to fixed the warning and registered the same type in different modules
correctly?

thanks.

                                                      Changsheng Jiang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20100830/5a9d8a55/attachment.html>

From rwgk at yahoo.com  Mon Aug 30 08:57:02 2010
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 29 Aug 2010 23:57:02 -0700 (PDT)
Subject: [C++-sig] registering the same type converter in different
	modules with Boost.Python
In-Reply-To: <AANLkTinJMxAY2+i2FH_MTSE0Wqn-8VkQ1GzgcS-OnD0H@mail.gmail.com>
References: <AANLkTinJMxAY2+i2FH_MTSE0Wqn-8VkQ1GzgcS-OnD0H@mail.gmail.com>
Message-ID: <695730.33471.qm@web111406.mail.gq1.yahoo.com>

> I have to convert std::pair to python tuple in different modules  
>independently.
> And these modules may be used concurrently, importing the  second module
> will report an warning like "std::pair has been already  registered".

A simple and clean approach is to have another basic module that defines the 
std::pair conversions,
and import that from the two modules you have already.
I never import extensions directly, but wrap each in a (possibly trivial) Python 
module; this has
many advantages unrelated to your original question. Then you can simply write:

module1.py
  import basic # e.g. with std::pair converters
  from module1_ext import *

similar for module2.py.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20100829/89c123b9/attachment.html>

From diepen at astron.nl  Mon Aug 30 09:15:56 2010
From: diepen at astron.nl (Ger van Diepen)
Date: Mon, 30 Aug 2010 09:15:56 +0200
Subject: [C++-sig] registering the same type converter in different	
	modules with Boost.Python
In-Reply-To: <695730.33471.qm@web111406.mail.gq1.yahoo.com>
References: <AANLkTinJMxAY2+i2FH_MTSE0Wqn-8VkQ1GzgcS-OnD0H@mail.gmail.com>
	<695730.33471.qm@web111406.mail.gq1.yahoo.com>
Message-ID: <4C7B76CC020000A90000E788@smtp.nfra.nl>


We had the same problem where one module registered converters for type
A and B and another module for type B and C. I do not know if Ralf's
solution caters for such situations with mixed types. 

We ended up having a private map (part of the shared library containing
our converters), so a converter gets only registered in Boost-Python if
not contained in the map.  

Cheers, 
Ger

>>> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> 8/30/2010 8:57 AM >>>

> I have to convert std::pair to python tuple in different modules
independently.
> And these modules may be used concurrently, importing the second
module
> will report an warning like "std::pair has been already registered".

A simple and clean approach is to have another basic module that
defines the std::pair conversions,
and import that from the two modules you have already.
I never import extensions directly, but wrap each in a (possibly
trivial) Python module; this has
many advantages unrelated to your original question. Then you can
simply write:

module1.py
  import basic # e.g. with std::pair converters
  from module1_ext import *

similar for module2.py.

Ralf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20100830/8010bfcf/attachment.html>

From rwgk at yahoo.com  Mon Aug 30 18:40:04 2010
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 30 Aug 2010 09:40:04 -0700 (PDT)
Subject: [C++-sig] registering the same type converter in different
	modules with Boost.Python
In-Reply-To: <4C7B76CC020000A90000E788@smtp.nfra.nl>
References: <AANLkTinJMxAY2+i2FH_MTSE0Wqn-8VkQ1GzgcS-OnD0H@mail.gmail.com>
	<695730.33471.qm@web111406.mail.gq1.yahoo.com>
	<4C7B76CC020000A90000E788@smtp.nfra.nl>
Message-ID: <324919.31492.qm@web111416.mail.gq1.yahoo.com>

> We had the same problem where one module registered converters for type A and B 
>
> and another module for type B and C. I do not know if Ralf's solution caters 
>for 
>
> such situations with mixed types.

Yes, you just have to put B in its own module.

> We ended up having a private map (part of the shared library containing our 
> converters), so a converter gets only registered in Boost-Python if not 
> contained in the map.  

Python's import mechanism does this for free if you organize your modules in
a natural way.

Ralf

From junweizhang2006 at gmail.com  Mon Aug 30 19:19:28 2010
From: junweizhang2006 at gmail.com (Junwei Zhang)
Date: Mon, 30 Aug 2010 12:19:28 -0500
Subject: [C++-sig] boost.python import problem
In-Reply-To: <AANLkTi=AiUd8nAwS5G4tp45X+jEvO=1s6woWp1EcYk8g@mail.gmail.com>
References: <AANLkTi=AiUd8nAwS5G4tp45X+jEvO=1s6woWp1EcYk8g@mail.gmail.com>
Message-ID: <AANLkTimUDWm1J-2KP6goc6UdYVQfs1OwJtYrWjCfBLtZ@mail.gmail.com>

Hi, everyone,

I just started study boost.python. and have following problem

/boostpy.cc
#include <boost/python.hpp>

char const* greet()
{
? return "hello, world";
}


BOOST_PYTHON_MODULE(boostpy)
{
? ?using namespace boost::python;
? ?def("greet", greet);
}


g++ boostpy.cc ?-lpython2.5 -I /usr/include/python2.5 -o boostpy.so -shared

It complies ,but when import it in python, I have following error,

<<<import boostpy
Traceback (most recent call last):
?File "<stdin>", line 1, in <module>
ImportError: ./boostpy.so: undefined symbol: _ZN5boost6python6detail11init_
moduleEPKcPFvvE

any suggestion?

Thanks

--
Junwei Zhang
Office Phone:402-472-1968
junweizhang2006 at gmail.com
www.junweizhang.com
Department of Electrical Engineering
University of Nebraska-Lincoln
209N Walter Scott Engineering Center
P.O. Box 880511
Lincoln, NE 68588-0511



-- 
Junwei Zhang
Office Phone:402-472-1968
junweizhang2006 at gmail.com
www.junweizhang.com
Department of Electrical Engineering
University of Nebraska-Lincoln
209N Walter Scott Engineering Center
P.O. Box 880511
Lincoln, NE 68588-0511

From charlessolar at gmail.com  Mon Aug 30 19:22:36 2010
From: charlessolar at gmail.com (Charles Solar)
Date: Mon, 30 Aug 2010 12:22:36 -0500
Subject: [C++-sig] boost.python import problem
In-Reply-To: <AANLkTimUDWm1J-2KP6goc6UdYVQfs1OwJtYrWjCfBLtZ@mail.gmail.com>
References: <AANLkTi=AiUd8nAwS5G4tp45X+jEvO=1s6woWp1EcYk8g@mail.gmail.com>
	<AANLkTimUDWm1J-2KP6goc6UdYVQfs1OwJtYrWjCfBLtZ@mail.gmail.com>
Message-ID: <AANLkTi=jGECvLXxdjmnt-ehGBK6DPbnMiA7eVLBZw=TG@mail.gmail.com>

You need to link with boost python as well.

g++ boostpy.cc  -lpython2.5 -lboost_python -I /usr/include/python2.5
-o boostpy.so -shared

should probably do the trick

On Mon, Aug 30, 2010 at 12:19 PM, Junwei Zhang
<junweizhang2006 at gmail.com> wrote:
> Hi, everyone,
>
> I just started study boost.python. and have following problem
>
> /boostpy.cc
> #include <boost/python.hpp>
>
> char const* greet()
> {
> ? return "hello, world";
> }
>
>
> BOOST_PYTHON_MODULE(boostpy)
> {
> ? ?using namespace boost::python;
> ? ?def("greet", greet);
> }
>
>
> g++ boostpy.cc ?-lpython2.5 -I /usr/include/python2.5 -o boostpy.so -shared
>
> It complies ,but when import it in python, I have following error,
>
> <<<import boostpy
> Traceback (most recent call last):
> ?File "<stdin>", line 1, in <module>
> ImportError: ./boostpy.so: undefined symbol: _ZN5boost6python6detail11init_
> moduleEPKcPFvvE
>
> any suggestion?
>
> Thanks
>
> --
> Junwei Zhang
> Office Phone:402-472-1968
> junweizhang2006 at gmail.com
> www.junweizhang.com
> Department of Electrical Engineering
> University of Nebraska-Lincoln
> 209N Walter Scott Engineering Center
> P.O. Box 880511
> Lincoln, NE 68588-0511
>
>
>
> --
> Junwei Zhang
> Office Phone:402-472-1968
> junweizhang2006 at gmail.com
> www.junweizhang.com
> Department of Electrical Engineering
> University of Nebraska-Lincoln
> 209N Walter Scott Engineering Center
> P.O. Box 880511
> Lincoln, NE 68588-0511
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>

From talljimbo at gmail.com  Mon Aug 30 19:23:39 2010
From: talljimbo at gmail.com (Jim Bosch)
Date: Mon, 30 Aug 2010 10:23:39 -0700
Subject: [C++-sig] boost.python import problem
In-Reply-To: <AANLkTimUDWm1J-2KP6goc6UdYVQfs1OwJtYrWjCfBLtZ@mail.gmail.com>
References: <AANLkTi=AiUd8nAwS5G4tp45X+jEvO=1s6woWp1EcYk8g@mail.gmail.com>
	<AANLkTimUDWm1J-2KP6goc6UdYVQfs1OwJtYrWjCfBLtZ@mail.gmail.com>
Message-ID: <4C7BE91B.4090702@gmail.com>

On 08/30/2010 10:19 AM, Junwei Zhang wrote:
> Hi, everyone,
>
> I just started study boost.python. and have following problem
<snip>
>
> g++ boostpy.cc  -lpython2.5 -I /usr/include/python2.5 -o boostpy.so -shared
>
<snip>
>
> any suggestion?
>

Two compiler/linker flags: -fPIC and -lboost_python

You may have to append a suffix to get the appropriate boost_python 
shared library in some cases.

Jim Bosch

From junweizhang2006 at gmail.com  Mon Aug 30 20:03:02 2010
From: junweizhang2006 at gmail.com (Junwei Zhang)
Date: Mon, 30 Aug 2010 13:03:02 -0500
Subject: [C++-sig] boost.python import problem
In-Reply-To: <4C7BE91B.4090702@gmail.com>
References: <AANLkTi=AiUd8nAwS5G4tp45X+jEvO=1s6woWp1EcYk8g@mail.gmail.com>
	<AANLkTimUDWm1J-2KP6goc6UdYVQfs1OwJtYrWjCfBLtZ@mail.gmail.com>
	<4C7BE91B.4090702@gmail.com>
Message-ID: <AANLkTikABWAyA3d2H9=12oLhzVcG3AUvZVD8Rt8QidXD@mail.gmail.com>

Thanks you all

it works

On Mon, Aug 30, 2010 at 12:23 PM, Jim Bosch <talljimbo at gmail.com> wrote:
> On 08/30/2010 10:19 AM, Junwei Zhang wrote:
>>
>> Hi, everyone,
>>
>> I just started study boost.python. and have following problem
>
> <snip>
>>
>> g++ boostpy.cc ?-lpython2.5 -I /usr/include/python2.5 -o boostpy.so
>> -shared
>>
> <snip>
>>
>> any suggestion?
>>
>
> Two compiler/linker flags: -fPIC and -lboost_python
>
> You may have to append a suffix to get the appropriate boost_python shared
> library in some cases.
>
> Jim Bosch
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>



-- 
Junwei Zhang
Office Phone:402-472-1968
junweizhang2006 at gmail.com
www.junweizhang.com
Department of Electrical Engineering
University of Nebraska-Lincoln
209N Walter Scott Engineering Center
P.O. Box 880511
Lincoln, NE 68588-0511

From junweizhang2006 at gmail.com  Tue Aug 31 23:46:54 2010
From: junweizhang2006 at gmail.com (Junwei Zhang)
Date: Tue, 31 Aug 2010 16:46:54 -0500
Subject: [C++-sig] question about object
Message-ID: <AANLkTi=nZUfeCikj+urtU-Hi4jiMOdHQZp0ZuUOUS8w1@mail.gmail.com>

Hi all,

who can tell me what c++ semantics of following  statement.
I do not understand it, it do not like usual c++ codes

object msg="%s is bigger than %s" %make_tuple(NAME,name);

-- 
Junwei Zhang
Office Phone:402-472-1968
junweizhang2006 at gmail.com
www.junweizhang.com
Department of Electrical Engineering
University of Nebraska-Lincoln
209N Walter Scott Engineering Center
P.O. Box 880511
Lincoln, NE 68588-0511