From vinayashrestha at gmail.com  Wed Mar  4 07:07:22 2009
From: vinayashrestha at gmail.com (Vinaya Shrestha)
Date: Wed, 4 Mar 2009 11:52:22 +0545
Subject: [C++-sig] Exposing C++ class to Python
Message-ID: <5aa2e3810903032207n219c067ax3113fcd0ff77bb10@mail.gmail.com>

Hello,        I need to be able to expose a C++ class to Python, say pass a
C++ object reference to Python and make modifications on the object using
Python scripting. I tried to use boost.python library for the same but
without any success. Can anyone help me ? Thanks.

Regards.
Vinaya Lal Shrestha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090304/72587ff8/attachment.htm>

From seefeld at sympatico.ca  Wed Mar  4 14:26:41 2009
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 04 Mar 2009 08:26:41 -0500
Subject: [C++-sig] Exposing C++ class to Python
In-Reply-To: <5aa2e3810903032207n219c067ax3113fcd0ff77bb10@mail.gmail.com>
References: <5aa2e3810903032207n219c067ax3113fcd0ff77bb10@mail.gmail.com>
Message-ID: <49AE8191.8040308@sympatico.ca>

Vinaya Shrestha wrote:
> Hello,
>         I need to be able to expose a C++ class to Python, say pass a 
> C++ object reference to Python and make modifications on the object 
> using Python scripting. I tried to use boost.python library for the 
> same but without any success. Can anyone help me ?
Please send some code that doesn't work the way you expect (with details 
concerning what you want it to do, as opposed to what it actually does). 
Then we can try to work from there.

Thanks,
       Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...


From ikarpov at gmail.com  Thu Mar  5 19:47:14 2009
From: ikarpov at gmail.com (Igor Karpov)
Date: Thu, 5 Mar 2009 12:47:14 -0600
Subject: [C++-sig] boost::python embedding error - runtime - Mac OS X - 1.38
Message-ID: <88575950903051047p6fe2ec9bo178fbc40d18a1d72@mail.gmail.com>

Hi,

I am trying to run the following program:

#include <iostream>
#include <Python.h>

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

using namespace std;

int main(int argc, char** argv) {

    { // Using Python/C
        Py_Initialize();
        PyObject* main_module = PyImport_ImportModule("__main__");
        PyObject* globals = PyEval_GetGlobals();
        PyObject* locals = PyEval_GetLocals();
        PyRun_SimpleString("print 'Hello World, from Python/C!'\n");
        Py_Finalize();
    }

    { // Using boost::python
        Py_Initialize();
        object main_module = import("__main__");
        object main_namespace = main_module.attr("__dict__");
        try {
            object ignored = exec("print 'Hello World, from boost::python!'\n",
                                  main_namespace);
            Py_Finalize();
        } catch (error_already_set const& e) {
            PyErr_Print();
            return 1;
        }
    }

    return 0;
}

on Linux (both x86 and x86_64), with Ubuntu's default version of Boost
(1.34.1) installed, I am able to do so as expected:

$ ./embed
Hello World, from Python/C!
Hello World, from boost::python!

on Mac OS X, I get a runtime error:
$ ./embed
Hello World, from Python/C!
Bus Error

Running with gdb, this is the stack trace:

Hello World, from Python/C!

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
#1  0x00bb618f in PyEval_GetGlobals ()
#2  0x00bce0dd in PyImport_Import ()
#3  0x00bce2b0 in PyImport_ImportModule ()
#4  0x008127d4 in boost::python::import (name=@0xbffff4a8) at
libs/python/src/import.cpp:20
#5  0x00004446 in main (argc=1, argv=0xbffff510) at embed.cc:22

For this Mac, boost version is latest (1.38) and python version is:

Python 2.5.4 (r254:67917, Dec 23 2008, 14:57:27)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin

Is this a bug? I attached the source and the cmake file I am using to
build, for convenience.

Thanks,

--Igor.
-------------- next part --------------
# require at least cmake 2.6
IF(COMMAND cmake_minimum_required)
  CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
ENDIF(COMMAND cmake_minimum_required)

# the project is called OpenNERO
PROJECT(embed)

# find the Boost C++ libraries
SET(Boost_ADDITIONAL_VERSIONS 1.37 1.37.0 1.38 1.38.0)
FIND_PACKAGE (Boost COMPONENTS python filesystem serialization system date_time)
IF (${Boost_MINOR_VERSION} LESS 35)
  FIND_PACKAGE (Boost COMPONENTS python filesystem serialization date_time)
ENDIF (${Boost_MINOR_VERSION} LESS 35)
IF (Boost_FOUND)
  MESSAGE(STATUS "Found boost libraries in ${Boost_INCLUDE_DIR} as ${Boost_LIBRARIES}")
ELSE (Boost_FOUND)
  MESSAGE(FATAL_ERROR "Boost libraries were not found")
ENDIF (Boost_FOUND)

# Find the Python libraries
FIND_PACKAGE ( PythonLibs )
IF (NOT PYTHON_FOUND AND PYTHON_LIBRARIES)
  SET(PYTHON_FOUND "YES")
ELSE (NOT PYTHON_FOUND AND PYTHON_LIBRARIES)
  SET(PYTHON_FOUND "NO")
ENDIF(NOT PYTHON_FOUND AND PYTHON_LIBRARIES)
IF (PYTHON_FOUND)
  MESSAGE(STATUS "Found Python libraries in ${PYTHON_INCLUDE_PATH} as ${PYTHON_LIBRARIES}")
ELSE (PYTHON_FOUND)
  MESSAGE(FATAL_ERROR "Python libraries not found")
ENDIF (PYTHON_FOUND)

INCLUDE_DIRECTORIES ( ${Boost_INCLUDE_DIR} )
INCLUDE_DIRECTORIES ( ${PYTHON_INCLUDE_PATH} )
ADD_EXECUTABLE(embed embed.cc)
TARGET_LINK_LIBRARIES (embed ${PYTHON_LIBRARIES})
TARGET_LINK_LIBRARIES (embed ${Boost_LIBRARIES})
-------------- next part --------------
A non-text attachment was scrubbed...
Name: embed.cc
Type: application/octet-stream
Size: 934 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090305/b2abdeba/attachment.obj>

From ikarpov at gmail.com  Thu Mar  5 20:30:32 2009
From: ikarpov at gmail.com (Igor Karpov)
Date: Thu, 5 Mar 2009 13:30:32 -0600
Subject: [C++-sig] boost::python embedding error - runtime - Mac OS X -
	1.38
In-Reply-To: <88575950903051047p6fe2ec9bo178fbc40d18a1d72@mail.gmail.com>
References: <88575950903051047p6fe2ec9bo178fbc40d18a1d72@mail.gmail.com>
Message-ID: <88575950903051130m58a88aadgabffc7ef2a0e3066@mail.gmail.com>

BTW, this seems specific to 1.38.0 version of Boost - I just
downgraded to 1.34.1 on the same mac, and got the expected "Hello
World from boost::python!".

--Igor.

On Thu, Mar 5, 2009 at 12:47 PM, Igor Karpov <ikarpov at gmail.com> wrote:
> Hi,
>
> I am trying to run the following program:
>
> #include <iostream>
> #include <Python.h>
>
> #include <boost/python.hpp>
> using namespace boost::python;
>
> using namespace std;
>
> int main(int argc, char** argv) {
>
> ? ?{ // Using Python/C
> ? ? ? ?Py_Initialize();
> ? ? ? ?PyObject* main_module = PyImport_ImportModule("__main__");
> ? ? ? ?PyObject* globals = PyEval_GetGlobals();
> ? ? ? ?PyObject* locals = PyEval_GetLocals();
> ? ? ? ?PyRun_SimpleString("print 'Hello World, from Python/C!'\n");
> ? ? ? ?Py_Finalize();
> ? ?}
>
> ? ?{ // Using boost::python
> ? ? ? ?Py_Initialize();
> ? ? ? ?object main_module = import("__main__");
> ? ? ? ?object main_namespace = main_module.attr("__dict__");
> ? ? ? ?try {
> ? ? ? ? ? ?object ignored = exec("print 'Hello World, from boost::python!'\n",
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?main_namespace);
> ? ? ? ? ? ?Py_Finalize();
> ? ? ? ?} catch (error_already_set const& e) {
> ? ? ? ? ? ?PyErr_Print();
> ? ? ? ? ? ?return 1;
> ? ? ? ?}
> ? ?}
>
> ? ?return 0;
> }
>
> on Linux (both x86 and x86_64), with Ubuntu's default version of Boost
> (1.34.1) installed, I am able to do so as expected:
>
> $ ./embed
> Hello World, from Python/C!
> Hello World, from boost::python!
>
> on Mac OS X, I get a runtime error:
> $ ./embed
> Hello World, from Python/C!
> Bus Error
>
> Running with gdb, this is the stack trace:
>
> Hello World, from Python/C!
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
> 0x00000000 in ?? ()
> (gdb) where
> #0 ?0x00000000 in ?? ()
> #1 ?0x00bb618f in PyEval_GetGlobals ()
> #2 ?0x00bce0dd in PyImport_Import ()
> #3 ?0x00bce2b0 in PyImport_ImportModule ()
> #4 ?0x008127d4 in boost::python::import (name=@0xbffff4a8) at
> libs/python/src/import.cpp:20
> #5 ?0x00004446 in main (argc=1, argv=0xbffff510) at embed.cc:22
>
> For this Mac, boost version is latest (1.38) and python version is:
>
> Python 2.5.4 (r254:67917, Dec 23 2008, 14:57:27)
> [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
>
> Is this a bug? I attached the source and the cmake file I am using to
> build, for convenience.
>
> Thanks,
>
> --Igor.
>

From rwgk at yahoo.com  Thu Mar  5 22:26:09 2009
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 5 Mar 2009 13:26:09 -0800 (PST)
Subject: [C++-sig] boost::python embedding error - runtime - Mac OS X -
	1.38
In-Reply-To: <88575950903051047p6fe2ec9bo178fbc40d18a1d72@mail.gmail.com>
References: <88575950903051047p6fe2ec9bo178fbc40d18a1d72@mail.gmail.com>
Message-ID: <194462.13299.qm@web111405.mail.gq1.yahoo.com>


>        Py_Finalize();


Boost.Python doesn't support Py_Finalize(). Could you try again without?
It is a long-standing known issue, e.g.
http://mail.python.org/pipermail/cplusplus-sig/2005-November/009543.html

From ikarpov at gmail.com  Thu Mar  5 22:46:26 2009
From: ikarpov at gmail.com (Igor Karpov)
Date: Thu, 5 Mar 2009 15:46:26 -0600
Subject: [C++-sig] boost::python embedding error - runtime - Mac OS X -
	1.38
In-Reply-To: <194462.13299.qm@web111405.mail.gq1.yahoo.com>
References: <88575950903051047p6fe2ec9bo178fbc40d18a1d72@mail.gmail.com>
	<194462.13299.qm@web111405.mail.gq1.yahoo.com>
Message-ID: <88575950903051346h49768a22m18a1b6401a3f48bc@mail.gmail.com>

Well, the version with Py_Finalize() runs on the same machine with
1.34.1, so I don't think that's the problem. However, paring down the
code to:

#include <Python.h>
#include <boost/python.hpp>
using namespace boost::python;

int main(int argc, char** argv) {

    { // Using boost::python
        Py_Initialize();
        object main_module = import("__main__");
        object main_namespace = main_module.attr("__dict__");
        try {
            object ignored = exec("print 'Hello World, from boost::python!'\n",
                                  main_namespace);
        } catch (error_already_set const& e) {
            PyErr_Print();
            return 1;
        }
    }

    return 0;
}

Will re-create the same Bus error at runtime...

--Igor.

On Thu, Mar 5, 2009 at 3:26 PM, Ralf W. Grosse-Kunstleve <rwgk at yahoo.com> wrote:
>
>> ? ? ? ?Py_Finalize();
>
>
> Boost.Python doesn't support Py_Finalize(). Could you try again without?
> It is a long-standing known issue, e.g.
> http://mail.python.org/pipermail/cplusplus-sig/2005-November/009543.html
>

From rwgk at yahoo.com  Fri Mar  6 01:19:05 2009
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 5 Mar 2009 16:19:05 -0800 (PST)
Subject: [C++-sig] boost::python embedding error - runtime - Mac OS X -
	1.38
In-Reply-To: <88575950903051346h49768a22m18a1b6401a3f48bc@mail.gmail.com>
References: <88575950903051047p6fe2ec9bo178fbc40d18a1d72@mail.gmail.com>
	<194462.13299.qm@web111405.mail.gq1.yahoo.com>
	<88575950903051346h49768a22m18a1b6401a3f48bc@mail.gmail.com>
Message-ID: <418200.5886.qm@web111405.mail.gq1.yahoo.com>


Sorry I cannot help any further; I've never used embedding myself. I hope someone
else will step in.

For the archives:

http://www.boost.org/doc/libs/1_38_0/libs/python/todo.html#pyfinalize-safety

I believe you're just getting lucky if Py_Finalize() doesn't crash the process.





----- Original Message ----
From: Igor Karpov <ikarpov at gmail.com>
To: Ralf W. Grosse-Kunstleve <rwgk at yahoo.com>
Cc: Development of Python/C++ integration <cplusplus-sig at python.org>
Sent: Thursday, March 5, 2009 1:46:26 PM
Subject: Re: [C++-sig] boost::python embedding error - runtime - Mac OS X -  1.38

Well, the version with Py_Finalize() runs on the same machine with
1.34.1, so I don't think that's the problem. However, paring down the
code to:

#include <Python.h>
#include <boost/python.hpp>
using namespace boost::python;

int main(int argc, char** argv) {

    { // Using boost::python
        Py_Initialize();
        object main_module = import("__main__");
        object main_namespace = main_module.attr("__dict__");
        try {
            object ignored = exec("print 'Hello World, from boost::python!'\n",
                                  main_namespace);
        } catch (error_already_set const& e) {
            PyErr_Print();
            return 1;
        }
    }

    return 0;
}

Will re-create the same Bus error at runtime...

--Igor.

On Thu, Mar 5, 2009 at 3:26 PM, Ralf W. Grosse-Kunstleve <rwgk at yahoo.com> wrote:
>
>>        Py_Finalize();
>
>
> Boost.Python doesn't support Py_Finalize(). Could you try again without?
> It is a long-standing known issue, e.g.
> http://mail.python.org/pipermail/cplusplus-sig/2005-November/009543.html
>


From merlin66b at gmail.com  Fri Mar  6 18:38:10 2009
From: merlin66b at gmail.com (Thomas Berg)
Date: Fri, 6 Mar 2009 18:38:10 +0100
Subject: [C++-sig] boost::python embedding error - runtime - Mac OS X -
	1.38
In-Reply-To: <88575950903051346h49768a22m18a1b6401a3f48bc@mail.gmail.com>
References: <88575950903051047p6fe2ec9bo178fbc40d18a1d72@mail.gmail.com>
	<194462.13299.qm@web111405.mail.gq1.yahoo.com>
	<88575950903051346h49768a22m18a1b6401a3f48bc@mail.gmail.com>
Message-ID: <c472dffc0903060938m3980d843m6071ee1ca2111ea4@mail.gmail.com>

Hi,

On Thu, Mar 5, 2009 at 10:46 PM, Igor Karpov <ikarpov at gmail.com> wrote:
> Well, the version with Py_Finalize() runs on the same machine with
> 1.34.1, so I don't think that's the problem. However, paring down the
> code to:
>
> #include <Python.h>
> #include <boost/python.hpp>
> using namespace boost::python;


Not sure it will make a difference in your case, but the boost.python
documentation does specify that you should never include Python.h
yourself. boost.python does it for you, taking care of several #define
issues:
http://www.boost.org/doc/libs/1_38_0/libs/python/doc/building.html#include-issues

- Thomas



> int main(int argc, char** argv) {
>
> ? ?{ // Using boost::python
> ? ? ? ?Py_Initialize();
> ? ? ? ?object main_module = import("__main__");
> ? ? ? ?object main_namespace = main_module.attr("__dict__");
> ? ? ? ?try {
> ? ? ? ? ? ?object ignored = exec("print 'Hello World, from boost::python!'\n",
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?main_namespace);
> ? ? ? ?} catch (error_already_set const& e) {
> ? ? ? ? ? ?PyErr_Print();
> ? ? ? ? ? ?return 1;
> ? ? ? ?}
> ? ?}
>
> ? ?return 0;
> }
>
> Will re-create the same Bus error at runtime...
>
> --Igor.
>
> On Thu, Mar 5, 2009 at 3:26 PM, Ralf W. Grosse-Kunstleve <rwgk at yahoo.com> wrote:
>>
>>> ? ? ? ?Py_Finalize();
>>
>>
>> Boost.Python doesn't support Py_Finalize(). Could you try again without?
>> It is a long-standing known issue, e.g.
>> http://mail.python.org/pipermail/cplusplus-sig/2005-November/009543.html
>>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>

From trigves at yahoo.com  Sun Mar  8 21:55:19 2009
From: trigves at yahoo.com (Trigve)
Date: Sun, 8 Mar 2009 20:55:19 +0000 (UTC)
Subject: [C++-sig] destructor not called
Message-ID: <loom.20090308T204643-822@post.gmane.org>

Hi,
I've got problem with embedded python. When using some classes inside embedded
python, the the number of constructor/destructor doesn't match. I don't have
code because it is a big project. But the class I have problem with looks like 
that:

class SessionImpl;
class Session
{
  boost::shared_ptr<SessionImpl> m_pImpl;

  ...
};

So as you can see when the destructor is not called appropriate times, the
shared_ptr isn't destroyed. I've tried searching but no working solution was
found.

thanks

Trigve


From trigves at yahoo.com  Mon Mar  9 09:29:04 2009
From: trigves at yahoo.com (Trigve)
Date: Mon, 9 Mar 2009 08:29:04 +0000 (UTC)
Subject: [C++-sig] destructor not called
References: <loom.20090308T204643-822@post.gmane.org>
Message-ID: <loom.20090309T082803-1@post.gmane.org>

Trigve <trigves <at> yahoo.com> writes:

> 
> Hi,
> I've got problem with embedded python. When using some classes inside embedded
> python...

Sorry,
It looks like it is not python fault.

Trigve





From murrayc at murrayc.com  Tue Mar 10 08:02:37 2009
From: murrayc at murrayc.com (Murray Cumming)
Date: Tue, 10 Mar 2009 08:02:37 +0100
Subject: [C++-sig] boost::python without exceptions?
Message-ID: <1236668557.8608.6.camel@murrayc-desktop>

Is there any version of the boost::python API that doesn't use
exceptions? I have an environment that disables exceptions in the C++
compiler, but I'd like to use boost::python there.

-- 
murrayc at murrayc.com
www.murrayc.com
www.openismus.com


From seefeld at sympatico.ca  Tue Mar 10 10:55:55 2009
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 10 Mar 2009 05:55:55 -0400
Subject: [C++-sig] boost::python without exceptions?
In-Reply-To: <1236668557.8608.6.camel@murrayc-desktop>
References: <1236668557.8608.6.camel@murrayc-desktop>
Message-ID: <49B6392B.4060500@sympatico.ca>

Murray Cumming wrote:
> Is there any version of the boost::python API that doesn't use
> exceptions? I have an environment that disables exceptions in the C++
> compiler, but I'd like to use boost::python there.
>   

You may compile boost with exceptions disabled, and see how far you get.

Regards,
       Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...


From zaexage at gmail.com  Wed Mar 11 07:05:18 2009
From: zaexage at gmail.com (ZaeX)
Date: Wed, 11 Mar 2009 14:05:18 +0800
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
	0xCCCCCCCC
Message-ID: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>

Hi, All:

I used a "shared_ptr<A> const&" to store a ref of A in B;
Well, the constructor of B seems ok, the share_ptr<A> seems to be well
initialized;
but after the constructor, I found the the pointer silently become
0xCCCCCCCC

///////////////////////////////////// below are the simplified class
definitions
class A{};

class B
{
private:
   shared_ptr<A> const& m_ptr;
public:
   B(shared_ptr<A> const& ptr):m_ptr(ptr) {cout<<m_ptr.get()<<endl;}
   void ShowPtr(cout<<m_ptr.get()<<endl;)
}
/////////////////////////////////// below are my exporting code

    class_<B, auto_ptr<B> >("B",  init<shared_ptr<A> const&>())
       .def("ShowPtr", &B::ShowPtr)
    ;
    class_<A, shared_ptr<A>, noncopyable >("A")
    ;
/////////////////////////////////// below are python code
 a = A()
 b = B(a)  #cout output the ptr of a
 b.ShowPtr()  #cout output 0xCCCCCCCC

============================================
I'm quite confused by the behaviors here. Could you tell me what goes wrong?

-- 
Time is mana, we must hurry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090311/0bc59282/attachment.htm>

From roman.yakovenko at gmail.com  Wed Mar 11 07:19:47 2009
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Wed, 11 Mar 2009 08:19:47 +0200
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
	0xCCCCCCCC
In-Reply-To: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
Message-ID: <7465b6170903102319s646e7df6t2a8755d49742b8a4@mail.gmail.com>

2009/3/11 ZaeX <zaexage at gmail.com>:
> Hi, All:
>
> I used a "shared_ptr<A> const&" to store a ref of A in B;
> Well, the constructor of B seems ok, the share_ptr<A> seems to be well
> initialized;
> but after the constructor, I found the the pointer silently become
> 0xCCCCCCCC
>
> ///////////////////////////////////// below are the simplified class
> definitions
> class A{};
>
> class B
> {
> private:
> ?? shared_ptr<A> const& m_ptr;
> public:
> ?? B(shared_ptr<A> const& ptr):m_ptr(ptr) {cout<<m_ptr.get()<<endl;}
> ?? void ShowPtr(cout<<m_ptr.get()<<endl;)
> }
> /////////////////////////////////// below are my exporting code
>
> ??? class_<B, auto_ptr<B> >("B",? init<shared_ptr<A> const&>())
> ??? ?? .def("ShowPtr", &B::ShowPtr)
> ??? ;
> ??? class_<A, shared_ptr<A>, noncopyable >("A")
> ??? ;
> /////////////////////////////////// below are python code
> ?a = A()
> ?b = B(a)? #cout output the ptr of a
> ?b.ShowPtr()? #cout output 0xCCCCCCCC
>
> ============================================
> I'm quite confused by the behaviors here. Could you tell me what goes wrong?

You have to bind lifetime argument to the lifetime of the created
object: http://www.boost.org/doc/libs/1_38_0/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies

Constructors also have call policies and you can use them.

Anyway, you will save to yourself a lot of time, if you will use
shared_ptr by value. I suggest you to change your code.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

From zaexage at gmail.com  Wed Mar 11 09:21:52 2009
From: zaexage at gmail.com (ZaeX)
Date: Wed, 11 Mar 2009 16:21:52 +0800
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
	0xCCCCCCCC
In-Reply-To: <7465b6170903102319s646e7df6t2a8755d49742b8a4@mail.gmail.com>
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
	<7465b6170903102319s646e7df6t2a8755d49742b8a4@mail.gmail.com>
Message-ID: <2c5080560903110121t1f08306bxb936617b72599b13@mail.gmail.com>

Hi,Roman:

I have tried adding call policy on my constructor, but I'm really no good at
this.
I have tried all the combinations below but none of them work:

   - init<shared_ptr<A> const& >()[with_custodian_and_ward_postcall<0, 2>
   >()]
   - init<shared_ptr<A> const& >()[with_custodian_and_ward_postcall<1, 2>
   >()]
   - init<shared_ptr<A> const& >()[return_internal_reference<1,
   with_custodian_and_ward<1, 2> >()]
   - init<shared_ptr<A> const& >()[return_internal_reference<1,
   with_custodian_and_ward<0, 2> >()]

Could you give some more advice on this?
P.S.:
I cannot modify the code back  to use shared_ptr by value here, I have to
break cyclic reference. And I think weak_ptr is no good idea, if I lock it
60 times per second for each object, I guess it would be an impact on
performance.

On Wed, Mar 11, 2009 at 2:19 PM, Roman Yakovenko
<roman.yakovenko at gmail.com>wrote:

> 2009/3/11 ZaeX <zaexage at gmail.com>:
> > Hi, All:
> >
> > I used a "shared_ptr<A> const&" to store a ref of A in B;
> > Well, the constructor of B seems ok, the share_ptr<A> seems to be well
> > initialized;
> > but after the constructor, I found the the pointer silently become
> > 0xCCCCCCCC
> >
> > ///////////////////////////////////// below are the simplified class
> > definitions
> > class A{};
> >
> > class B
> > {
> > private:
> >    shared_ptr<A> const& m_ptr;
> > public:
> >    B(shared_ptr<A> const& ptr):m_ptr(ptr) {cout<<m_ptr.get()<<endl;}
> >    void ShowPtr(cout<<m_ptr.get()<<endl;)
> > }
> > /////////////////////////////////// below are my exporting code
> >
> >     class_<B, auto_ptr<B> >("B",  init<shared_ptr<A> const&>())
> >        .def("ShowPtr", &B::ShowPtr)
> >     ;
> >     class_<A, shared_ptr<A>, noncopyable >("A")
> >     ;
> > /////////////////////////////////// below are python code
> >  a = A()
> >  b = B(a)  #cout output the ptr of a
> >  b.ShowPtr()  #cout output 0xCCCCCCCC
> >
> > ============================================
> > I'm quite confused by the behaviors here. Could you tell me what goes
> wrong?
>
> You have to bind lifetime argument to the lifetime of the created
> object:
> http://www.boost.org/doc/libs/1_38_0/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies
>
> Constructors also have call policies and you can use them.
>
> Anyway, you will save to yourself a lot of time, if you will use
> shared_ptr by value. I suggest you to change your code.
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>

-- 
Time is mana, we must hurry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090311/5553782c/attachment.htm>

From rancas at gmail.com  Wed Mar 11 17:06:00 2009
From: rancas at gmail.com (Luca Secchi)
Date: Wed, 11 Mar 2009 17:06:00 +0100
Subject: [C++-sig] [c++-sig] Making a Python tuple from a Boost.Fusion
	sequence
In-Reply-To: <9bea5ee0902270808t3c17744dn15c1d69c8b5fc0df@mail.gmail.com>
References: <9bea5ee0902270808t3c17744dn15c1d69c8b5fc0df@mail.gmail.com>
Message-ID: <4f52d9c70903110906p778e959esa7bfc8abfaff4844@mail.gmail.com>

It seems very useful to me.
By the way, is there a simple way to iterate through a fusion sequence or
transformation of it with a python iterator?

Luca.

2009/2/27 Bruno Lalande <bruno.lalande at gmail.com>

> Hello,
>
> The topic below was opened in the Boost development mailing list,
> where it's been pointed out to me that it fits better here.
>
> You can also read the thread archive:
> http://thread.gmane.org/gmane.comp.lib.boost.devel/186573
>
> Regards
> Bruno
>
>
> ---------- Forwarded message ----------
>
>
> Hello,
>
> I have written a little function that converts any Boost.Fusion
> sequence into a Python tuple (boost::python::tuple). If a sub-sequence
> is nested in the sequence, the result will also be a nested tuple (for
> instance, boost::make_tuple(0, std::make_pair(1, 2), 3) will give (0,
> (1, 2), 3) in Python).
>
> The source code is attached to this mail.
>
> The principle is that any sequence previously adapted to Boost.Fusion
> will become a tuple in Python. So, by including the right
> boost/fusion/adapted/xxx header, one can convert a pair, a tuple, a
> boost::array, and obviously any of the sequences provided by
> Boost.Fusion. For example:
>
> #include <boost/python.hpp>
> #include <boost/fusion/adapted/std_pair.hpp>
> #include <boost/fusion/adapted/boost_tuple.hpp>
> #include <boost/fusion/container/generation/make_vector.hpp>
> #include "make_tuple_from_fusion_sequence.hpp"
>
> using namespace boost::python;
>
> tuple from_sequence()
> {
>   return make_tuple_from_fusion(
>              boost::fusion::make_vector(
>                 1,
>                 std::make_pair("first", "second"),
>                 2,
>                 boost::make_tuple('a', 'b', 'c'),
>                 3
>              )
>          );
> }
>
> BOOST_PYTHON_MODULE(mymodule)
> {
>   def("from_sequence", &from_sequence);
> }
>
>
> In Python we get:
>
> >>> import mymodule
> >>> mymodule.from_sequence()
> (1, ('first', 'second'), 2, ('a', 'b', 'c'), 3)
>
>
> Is there any interest in adding this function into Boost.Python? If
> yes, I can write the doc and tests, clean the source and maybe improve
> the implementation (for example, I feel that I could avoid the use of
> m_iteration with a better use of Boost.Fusion...).
>
>
> Regards
> Bruno
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>



-- 
Ing. Luca Secchi
Ass.to Turismo, Artigianato e Commercio
Servizio amministrativo e legale, del bilancio e degli affari generali
tel. interno  4312
tel. esterno 070/606 4312
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090311/2db081d9/attachment.htm>

From divinekid at gmail.com  Wed Mar 11 17:56:46 2009
From: divinekid at gmail.com (Haoyu Bai)
Date: Thu, 12 Mar 2009 00:56:46 +0800
Subject: [C++-sig] GSoC and py3k support for Boost.Python
Message-ID: <1d7983e80903110956k60e23acdufff81677b19f8453@mail.gmail.com>

Hi,

I have posted this to Boost development mailling list before and many
people suggested me to repost here, so I did.

I'm a student who has finished SWIG's Python 3.0 support in GSoC 2008.
I'd like to contribute my knowledge of Python 3 migration to
Boost.Python, by implementing Python 3 support for it as a Google
Summer of Code 2009 project. Finally the users of Boost.Python would
get py3k support smoothly.

Also, you may suggest other useful features that Boost.Python
currently lack, for example thread safety and PyFinalize support. I
would like to take it as part of this project if possible.

Any comment is welcome. And it would be great if you are willing to
mentor this project.

Thanks!

-- Haoyu Bai

From lists_ravi at lavabit.com  Wed Mar 11 18:42:42 2009
From: lists_ravi at lavabit.com (Ravi)
Date: Wed, 11 Mar 2009 13:42:42 -0400
Subject: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
In-Reply-To: <1d7983e80903110938v2aef386t84f9c779a6398b70@mail.gmail.com>
References: <1d7983e80903091021h4e877034j497c89a3e6883819@mail.gmail.com>
	<200903091554.07149.lists_ravi@lavabit.com>
	<1d7983e80903110938v2aef386t84f9c779a6398b70@mail.gmail.com>
Message-ID: <200903111342.42995.lists_ravi@lavabit.com>

On Wednesday 11 March 2009 12:38:55 Haoyu Bai wrote:
> > 1. Thread safety
> > 2. PyFinalize support
> > 3. Easier methods to write to_python/from_python converters
> > 4. Python 3.0 support
> > 5. Ability to extend the fundamental PyTypeObject used by boost.python
>
> Thanks! Seems there's a lot of interesting. So would anyone willing to
> mentor this?

Sadly, I suspect that finding a mentor will be difficult (perhaps even more 
difficult than the actual project). Off the top of my head, the following 
folks come to mind:
  - Dave Abrahams
  - Stefan Seefeld
  - Ralf Grosse-Kunstleve
  - Roman Yakovenko
You might try contacting them off list or on c++-sig (cc'ed on this email).

> Also thanks Ravi for a list of features that may be candidates for
> this project. I will dive into Boost.Python source code to see more
> about these.

I did not mean to imply that the features I requested should be part of your 
GSoC. Thread safety & PyFinalize support would each be worth a GSoC project 
just by themselves, IMHO. If you will be tackling python 3.0 support, it might 
be possible to combine it with greater support for embedding python since much 
of the work in both aspects would be about wrapping python C API for C++ 
programmers.

Regards,
Ravi



From troy at resophonic.com  Wed Mar 11 19:30:12 2009
From: troy at resophonic.com (troy d. straszheim)
Date: Wed, 11 Mar 2009 14:30:12 -0400
Subject: [C++-sig] GSoC and py3k support for Boost.Python
In-Reply-To: <1d7983e80903110956k60e23acdufff81677b19f8453@mail.gmail.com>
References: <1d7983e80903110956k60e23acdufff81677b19f8453@mail.gmail.com>
Message-ID: <49B80334.9060009@resophonic.com>

Haoyu Bai wrote:
> Hi,
> 
> I have posted this to Boost development mailling list before and many
> people suggested me to repost here, so I did.
> 
> I'm a student who has finished SWIG's Python 3.0 support in GSoC 2008.
> I'd like to contribute my knowledge of Python 3 migration to
> Boost.Python, by implementing Python 3 support for it as a Google
> Summer of Code 2009 project. Finally the users of Boost.Python would
> get py3k support smoothly.
> 
> Also, you may suggest other useful features that Boost.Python
> currently lack, for example thread safety and PyFinalize support. I
> would like to take it as part of this project if possible.
> 
> Any comment is welcome. 

Everybody wins here.  Clearly this needs to get done, the sooner the 
better, a GSoC project sounds like a great way to get it done, and you 
sound like a great candidate for the job.

I'd set the goal to be py3k support for the current boost::python 
feature set, keeping the other feature requests in mind.   Maybe you'll 
get lucky and get some of these in along the way.  If you have time left 
over, you can tackle them directly.  Just my two cents.

> And it would be great if you are willing to
> mentor this project.

1.  What are the responsibilities of the mentor(s)?

2.  Do you need an individual mentor?  Would a small group do?  Would 
the general support of the mailing list work?

-t

From william.marie at gmail.com  Wed Mar 11 20:25:36 2009
From: william.marie at gmail.com (=?UTF-8?Q?William_Mari=C3=A9?=)
Date: Wed, 11 Mar 2009 12:25:36 -0700 (PDT)
Subject: [C++-sig]  del dict[key] equivalent ?
Message-ID: <22462620.post@talk.nabble.com>


Hi,

I'm looking for a function in boost python ( C++ side ) to do the equivalent
of del dict[key] but i can't find it .
Thank you very much

-- 
View this message in context: http://www.nabble.com/del-dict-key--equivalent---tp22462620p22462620.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.


From troy at resophonic.com  Wed Mar 11 20:38:50 2009
From: troy at resophonic.com (troy d. straszheim)
Date: Wed, 11 Mar 2009 15:38:50 -0400
Subject: [C++-sig] del dict[key] equivalent ?
In-Reply-To: <22462620.post@talk.nabble.com>
References: <22462620.post@talk.nabble.com>
Message-ID: <49B8134A.6090404@resophonic.com>

William Mari? wrote:
> Hi,
> 
> I'm looking for a function in boost python ( C++ side ) to do the equivalent
> of del dict[key] but i can't find it .
> Thank you very much
> 

I think you want:

   boost::python::object obj;
   obj["where"].del();

-t

From s_sourceforge at nedprod.com  Wed Mar 11 21:50:08 2009
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 11 Mar 2009 20:50:08 -0000
Subject: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
In-Reply-To: <200903111342.42995.lists_ravi@lavabit.com>
References: <1d7983e80903091021h4e877034j497c89a3e6883819@mail.gmail.com>,
	<1d7983e80903110938v2aef386t84f9c779a6398b70@mail.gmail.com>,
	<200903111342.42995.lists_ravi@lavabit.com>
Message-ID: <49B82400.25524.24AF2D1D@s_sourceforge.nedprod.com>

On 11 Mar 2009 at 13:42, Ravi wrote:

> On Wednesday 11 March 2009 12:38:55 Haoyu Bai wrote:
> > > 1. Thread safety
> > > 2. PyFinalize support
> > > 3. Easier methods to write to_python/from_python converters
> > > 4. Python 3.0 support
> > > 5. Ability to extend the fundamental PyTypeObject used by boost.python

My thread safety patch is still working to my knowledge. It sure 
would be lovely to have it officially integrated. I'd also like to 
see PyFinalize working though maybe not "complete" in the sense of a 
total cleanup (just "good enough").

I would say that any GSoC project should choose *one* of the above 
rather than try combining them. Better to do one thing well and in 
stages than many things at once (unless you have loads of spare 
time!).

I have been out of commission development-wise during the last few 
years as I have been undertaking some very time consuming academic 
study - hence I have been very quiet on here. However, I finally 
become free come this June and at long, long last I finally can 
return to my own self-directed study (but now I have a whole pile of 
bits of paper to officially say I can do what I was already capable 
of). I will certainly be updating my TnFOX library for sure anyway, 
and that means fresh Python bindings.

> > Thanks! Seems there's a lot of interesting. So would anyone willing to
> > mentor this?
> 
> Sadly, I suspect that finding a mentor will be difficult (perhaps even more 
> difficult than the actual project). Off the top of my head, the following 
> folks come to mind:
>   - Dave Abrahams
>   - Stefan Seefeld
>   - Ralf Grosse-Kunstleve
>   - Roman Yakovenko
> You might try contacting them off list or on c++-sig (cc'ed on this email).

It's not /quite/ as easy as that ... Google want a mentoring 
organisation rather than just a mentor and it has to be an approved 
one. I could volunteer as mentor but I wouldn't qualify as I don't 
come with an organisation attached. I'd need an approved organisation 
to adopt me.

> I did not mean to imply that the features I requested should be part of your 
> GSoC. Thread safety & PyFinalize support would each be worth a GSoC project 
> just by themselves, IMHO. If you will be tackling python 3.0 support, it might 
> be possible to combine it with greater support for embedding python since much 
> of the work in both aspects would be about wrapping python C API for C++ 
> programmers.

As mentioned before, thread safety is actually fairly trivial as all 
the required work is already done. There is certainly some work 
involved in writing a test suite and making my patch much more 
generic as my patch was specifically designed to be diff-friendly to 
any Boost alterations, and it doesn't make for good code. I would be 
happy to mentor this project if we can find an approved mentoring 
organisation to adopt me. It certainly would be a good GSoC for a 
student programmer.

PyFinalize() is likely just a hard slog in catching all the code 
paths you wouldn't expect. It's harder than thread safety, but doable 
as a GSoc.

Adding Python 3.0 support ... I am afraid I have no idea as I've been 
out of the coding scene for two years now, but it does sound big and 
complex. But it's something I'm interested in though I'd be not much 
use as a mentor except as in general Boost.Python programming.

So, I guess you got a bit of a mentor if you'd like. BTW, I couldn't 
start mentoring till the start of June as I have my final project due 
then. But that fits the GSoC timetable just perfect.

If you want to know more about my suitability, search this mailing 
list.

HTH,
Niall




From s_sourceforge at nedprod.com  Wed Mar 11 23:21:55 2009
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 11 Mar 2009 22:21:55 -0000
Subject: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
In-Reply-To: <49B82400.25524.24AF2D1D@s_sourceforge.nedprod.com>
References: <1d7983e80903091021h4e877034j497c89a3e6883819@mail.gmail.com>,
	<200903111342.42995.lists_ravi@lavabit.com>,
	<49B82400.25524.24AF2D1D@s_sourceforge.nedprod.com>
Message-ID: <49B83983.20941.2503336D@s_sourceforge.nedprod.com>

I should add that the deadline for this appears to be tomorrow (the 
12th).

Niall

On 11 Mar 2009 at 20:50, Niall Douglas wrote:

> On 11 Mar 2009 at 13:42, Ravi wrote:
> 
> > On Wednesday 11 March 2009 12:38:55 Haoyu Bai wrote:
> > > > 1. Thread safety
> > > > 2. PyFinalize support
> > > > 3. Easier methods to write to_python/from_python converters
> > > > 4. Python 3.0 support
> > > > 5. Ability to extend the fundamental PyTypeObject used by boost.python
> 
> My thread safety patch is still working to my knowledge. It sure 
> would be lovely to have it officially integrated. I'd also like to 
> see PyFinalize working though maybe not "complete" in the sense of a 
> total cleanup (just "good enough").
> 
> I would say that any GSoC project should choose *one* of the above 
> rather than try combining them. Better to do one thing well and in 
> stages than many things at once (unless you have loads of spare 
> time!).
> 
> I have been out of commission development-wise during the last few 
> years as I have been undertaking some very time consuming academic 
> study - hence I have been very quiet on here. However, I finally 
> become free come this June and at long, long last I finally can 
> return to my own self-directed study (but now I have a whole pile of 
> bits of paper to officially say I can do what I was already capable 
> of). I will certainly be updating my TnFOX library for sure anyway, 
> and that means fresh Python bindings.
> 
> > > Thanks! Seems there's a lot of interesting. So would anyone willing to
> > > mentor this?
> > 
> > Sadly, I suspect that finding a mentor will be difficult (perhaps even more 
> > difficult than the actual project). Off the top of my head, the following 
> > folks come to mind:
> >   - Dave Abrahams
> >   - Stefan Seefeld
> >   - Ralf Grosse-Kunstleve
> >   - Roman Yakovenko
> > You might try contacting them off list or on c++-sig (cc'ed on this email).
> 
> It's not /quite/ as easy as that ... Google want a mentoring 
> organisation rather than just a mentor and it has to be an approved 
> one. I could volunteer as mentor but I wouldn't qualify as I don't 
> come with an organisation attached. I'd need an approved organisation 
> to adopt me.
> 
> > I did not mean to imply that the features I requested should be part of your 
> > GSoC. Thread safety & PyFinalize support would each be worth a GSoC project 
> > just by themselves, IMHO. If you will be tackling python 3.0 support, it might 
> > be possible to combine it with greater support for embedding python since much 
> > of the work in both aspects would be about wrapping python C API for C++ 
> > programmers.
> 
> As mentioned before, thread safety is actually fairly trivial as all 
> the required work is already done. There is certainly some work 
> involved in writing a test suite and making my patch much more 
> generic as my patch was specifically designed to be diff-friendly to 
> any Boost alterations, and it doesn't make for good code. I would be 
> happy to mentor this project if we can find an approved mentoring 
> organisation to adopt me. It certainly would be a good GSoC for a 
> student programmer.
> 
> PyFinalize() is likely just a hard slog in catching all the code 
> paths you wouldn't expect. It's harder than thread safety, but doable 
> as a GSoc.
> 
> Adding Python 3.0 support ... I am afraid I have no idea as I've been 
> out of the coding scene for two years now, but it does sound big and 
> complex. But it's something I'm interested in though I'd be not much 
> use as a mentor except as in general Boost.Python programming.
> 
> So, I guess you got a bit of a mentor if you'd like. BTW, I couldn't 
> start mentoring till the start of June as I have my final project due 
> then. But that fits the GSoC timetable just perfect.
> 
> If you want to know more about my suitability, search this mailing 
> list.
> 
> HTH,
> Niall
> 
> 
> 
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig





From bruno.lalande at gmail.com  Thu Mar 12 00:04:19 2009
From: bruno.lalande at gmail.com (Bruno Lalande)
Date: Thu, 12 Mar 2009 08:04:19 +0900
Subject: [C++-sig] [c++-sig] Making a Python tuple from a Boost.Fusion
	sequence
In-Reply-To: <4f52d9c70903110906p778e959esa7bfc8abfaff4844@mail.gmail.com>
References: <9bea5ee0902270808t3c17744dn15c1d69c8b5fc0df@mail.gmail.com>
	<4f52d9c70903110906p778e959esa7bfc8abfaff4844@mail.gmail.com>
Message-ID: <9bea5ee0903111604g3aa1ecc7l6d5d8adfe3aebfa8@mail.gmail.com>

> By the way, is there a simple way to iterate through a fusion sequence or
> transformation of it with a python iterator?

Do you mean making it an indexing suite, like Boost.Python does for
vectors and maps? I guess it would be possible by using the
indexing_suite base class (never did that before though) but
__setitem__ and __delitem__ operations could obviously not be defined
since the structure of a fusion sequence is fixed.

Bruno

From roman.yakovenko at gmail.com  Thu Mar 12 06:17:48 2009
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Thu, 12 Mar 2009 07:17:48 +0200
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
	0xCCCCCCCC
In-Reply-To: <2c5080560903110121t1f08306bxb936617b72599b13@mail.gmail.com>
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
	<7465b6170903102319s646e7df6t2a8755d49742b8a4@mail.gmail.com>
	<2c5080560903110121t1f08306bxb936617b72599b13@mail.gmail.com>
Message-ID: <7465b6170903112217l9d8eaaey41cc6ae42b1cb26b@mail.gmail.com>

2009/3/11 ZaeX <zaexage at gmail.com>:
> Hi,Roman:
>
> I have tried adding call policy on my constructor, but I'm really no good at
> this.
> I have tried all the combinations below but none of them work:
>
> init<shared_ptr<A> const& >()[with_custodian_and_ward_postcall<0, 2> >()]
> init<shared_ptr<A> const& >()[with_custodian_and_ward_postcall<1, 2> >()]
> init<shared_ptr<A> const& >()[return_internal_reference<1,
> with_custodian_and_ward<1, 2> >()]
> init<shared_ptr<A> const& >()[return_internal_reference<1,
> with_custodian_and_ward<0, 2> >()]
>
> Could you give some more advice on this?
> P.S.:
> I cannot modify the code back? to use shared_ptr by value here, I have to
> break cyclic reference. And I think weak_ptr is no good idea, if I lock it
> 60 times per second for each object, I guess it would be an impact on
> performance.

I don't know for sure, how to solve this problem. I can propose
work-around, which may be will work for you.
In your case, you have to keep shared_ptr<A> somewhere, until instance
of B will die. So, you already do some kind of memory management.

I suggest you to change your code as following:
struct no_delete_a{
    void operator(A*){}
};

class A{};

class B
{
private:
   shared_ptr<A> const m_ptr;
public:
   B(shared_ptr<A> const& ptr):m_ptr(ptr.get(), no_delete_a() )
{cout<<m_ptr.get()<<endl;}
   void ShowPtr(cout<<m_ptr.get()<<endl;)
}

In short to use "shared_ptr" custom deleter functionality.

You don't hurt performance and can switch to use "shared_ptr by
value"( and not to hurt your self :-) )

HTH

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

From zaexage at gmail.com  Thu Mar 12 09:25:04 2009
From: zaexage at gmail.com (ZaeX)
Date: Thu, 12 Mar 2009 16:25:04 +0800
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
	0xCCCCCCCC
In-Reply-To: <7465b6170903112217l9d8eaaey41cc6ae42b1cb26b@mail.gmail.com>
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
	<7465b6170903102319s646e7df6t2a8755d49742b8a4@mail.gmail.com>
	<2c5080560903110121t1f08306bxb936617b72599b13@mail.gmail.com>
	<7465b6170903112217l9d8eaaey41cc6ae42b1cb26b@mail.gmail.com>
Message-ID: <2c5080560903120125y393a1a01u1df3cdb635087268@mail.gmail.com>

Thanks Roman,
I think I will take the advice to try working around this problem.

On Thu, Mar 12, 2009 at 1:17 PM, Roman Yakovenko
<roman.yakovenko at gmail.com>wrote:

> 2009/3/11 ZaeX <zaexage at gmail.com>:
> > Hi,Roman:
> >
> > I have tried adding call policy on my constructor, but I'm really no good
> at
> > this.
> > I have tried all the combinations below but none of them work:
> >
> > init<shared_ptr<A> const& >()[with_custodian_and_ward_postcall<0, 2> >()]
> > init<shared_ptr<A> const& >()[with_custodian_and_ward_postcall<1, 2> >()]
> > init<shared_ptr<A> const& >()[return_internal_reference<1,
> > with_custodian_and_ward<1, 2> >()]
> > init<shared_ptr<A> const& >()[return_internal_reference<1,
> > with_custodian_and_ward<0, 2> >()]
> >
> > Could you give some more advice on this?
> > P.S.:
> > I cannot modify the code back  to use shared_ptr by value here, I have to
> > break cyclic reference. And I think weak_ptr is no good idea, if I lock
> it
> > 60 times per second for each object, I guess it would be an impact on
> > performance.
>
> I don't know for sure, how to solve this problem. I can propose
> work-around, which may be will work for you.
> In your case, you have to keep shared_ptr<A> somewhere, until instance
> of B will die. So, you already do some kind of memory management.
>
> I suggest you to change your code as following:
> struct no_delete_a{
>    void operator(A*){}
> };
>
> class A{};
>
> class B
> {
> private:
>   shared_ptr<A> const m_ptr;
> public:
>    B(shared_ptr<A> const& ptr):m_ptr(ptr.get(), no_delete_a() )
> {cout<<m_ptr.get()<<endl;}
>   void ShowPtr(cout<<m_ptr.get()<<endl;)
> }
>
> In short to use "shared_ptr" custom deleter functionality.
>
> You don't hurt performance and can switch to use "shared_ptr by
> value"( and not to hurt your self :-) )
>
> HTH
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>



-- 
Time is mana, we must hurry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090312/89a43723/attachment-0001.htm>

From divinekid at gmail.com  Thu Mar 12 10:06:30 2009
From: divinekid at gmail.com (Haoyu Bai)
Date: Thu, 12 Mar 2009 17:06:30 +0800
Subject: [C++-sig] GSoC and py3k support for Boost.Python
In-Reply-To: <49B80334.9060009@resophonic.com>
References: <1d7983e80903110956k60e23acdufff81677b19f8453@mail.gmail.com>
	<49B80334.9060009@resophonic.com>
Message-ID: <1d7983e80903120206n2008cce2sffd77d1c9b4a7aed@mail.gmail.com>

On Thu, Mar 12, 2009 at 2:30 AM, troy d. straszheim <troy at resophonic.com> wrote:
> 1. ?What are the responsibilities of the mentor(s)?
>

I took a loot at GSoC FAQ [1] but indeed there's no specifically
requirement for mentor. I think a mentor is who in charge of to help
the student to find out solution for problems, supervise the project's
progress and (maybe most importantly) write GSoC mid-term and final
report for the project. Also, the mentor will be paid $500 for these
work.

> 2.  Do you need an individual mentor?  Would a small group do?  Would the
> general support of the mailing list work?
>

Boost maybe applied as a mentor organization in GSoC, and then mentors
attached to the organization. For every project a mentor is allocated
by Boost's administrator, (and maybe one more backup mentor is
allocated). So there should be an individual mentor to responsible for
this project.

[1] http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs

Thanks!

-- Haoyu Bai

From thorena at gmail.com  Thu Mar 12 10:50:55 2009
From: thorena at gmail.com (athor)
Date: Thu, 12 Mar 2009 02:50:55 -0700 (PDT)
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
 0xCCCCCCCC
In-Reply-To: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
Message-ID: <22471472.post@talk.nabble.com>


Hi, 
I just tried your example and could not reproduce the "feature". I made a
few minor modifications like fixing typos and adding a cout statement in the
constructor of A but nothing that should affect the result.

A few things that could cause you problems:
* Passing shared_ptr by reference and keeping refs to shared_ptrs is just as
bad as passing standard pointers. You never know when it's deallocated.
Passing by value could help (as already mentioned).

* auto_ptr is rather scary. It transfers the responsibility for deallocating
the memory whenever it is copied. I have no idea what the effects could be
in a python environment. I'd suggest using shared_ptr instead.

Here's my code if you want to look for any differences:
-----------------------------------------------------
struct A
{
	A()
	{
		cerr << "Creating A" << endl;
	}
};

class B
{
private:
	shared_ptr&lt;A> const& m_ptr;
public:
	B(shared_ptr&lt;A> const& ptr):m_ptr(ptr) 
	{
		cerr << "Creating B" << endl;
		cerr << m_ptr.get() << endl;	   
	}

	void ShowPtr() const
	{
		cout << m_ptr.get() << endl;
	}
};

BOOST_PYTHON_MODULE(pylib)
{

	class_<B, auto_ptr &lt;B> >("B",  init<shared_ptr&lt;A> const&>())
		.def("ShowPtr", &B::ShowPtr);

	class_<A, shared_ptr&lt;A>, noncopyable >("A");
}
----------------------------------------------------
from pylib import *
a = A() # Creating A
b = B(a) # Creating B, 0xABCDE
b.ShowPtr() # 0xABCDE





-- 
View this message in context: http://www.nabble.com/why-does-the-%22shared_ptr%3CX%3E-const-%22-silently-become-0xCCCCCCCC-tp22449314p22471472.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.


From divinekid at gmail.com  Thu Mar 12 11:19:58 2009
From: divinekid at gmail.com (Haoyu Bai)
Date: Thu, 12 Mar 2009 18:19:58 +0800
Subject: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
In-Reply-To: <49B82400.25524.24AF2D1D@s_sourceforge.nedprod.com>
References: <1d7983e80903091021h4e877034j497c89a3e6883819@mail.gmail.com>
	<1d7983e80903110938v2aef386t84f9c779a6398b70@mail.gmail.com>
	<200903111342.42995.lists_ravi@lavabit.com>
	<49B82400.25524.24AF2D1D@s_sourceforge.nedprod.com>
Message-ID: <1d7983e80903120319g43113890m4a08f8a1e87ca49c@mail.gmail.com>

On Thu, Mar 12, 2009 at 4:50 AM, Niall Douglas
<s_sourceforge at nedprod.com> wrote:
> On 11 Mar 2009 at 13:42, Ravi wrote:
>
>> On Wednesday 11 March 2009 12:38:55 Haoyu Bai wrote:
>> > > 1. Thread safety
>> > > 2. PyFinalize support
>> > > 3. Easier methods to write to_python/from_python converters
>> > > 4. Python 3.0 support
>> > > 5. Ability to extend the fundamental PyTypeObject used by boost.python
>
> My thread safety patch is still working to my knowledge. It sure
> would be lovely to have it officially integrated. I'd also like to
> see PyFinalize working though maybe not "complete" in the sense of a
> total cleanup (just "good enough").
>
> I would say that any GSoC project should choose *one* of the above
> rather than try combining them. Better to do one thing well and in
> stages than many things at once (unless you have loads of spare
> time!).
>
> I have been out of commission development-wise during the last few
> years as I have been undertaking some very time consuming academic
> study - hence I have been very quiet on here. However, I finally
> become free come this June and at long, long last I finally can
> return to my own self-directed study (but now I have a whole pile of
> bits of paper to officially say I can do what I was already capable
> of). I will certainly be updating my TnFOX library for sure anyway,
> and that means fresh Python bindings.
>
>> > Thanks! Seems there's a lot of interesting. So would anyone willing to
>> > mentor this?
>>
>> Sadly, I suspect that finding a mentor will be difficult (perhaps even more
>> difficult than the actual project). Off the top of my head, the following
>> folks come to mind:
>> ? - Dave Abrahams
>> ? - Stefan Seefeld
>> ? - Ralf Grosse-Kunstleve
>> ? - Roman Yakovenko
>> You might try contacting them off list or on c++-sig (cc'ed on this email).
>
> It's not /quite/ as easy as that ... Google want a mentoring
> organisation rather than just a mentor and it has to be an approved
> one. I could volunteer as mentor but I wouldn't qualify as I don't
> come with an organisation attached. I'd need an approved organisation
> to adopt me.
>
>> I did not mean to imply that the features I requested should be part of your
>> GSoC. Thread safety & PyFinalize support would each be worth a GSoC project
>> just by themselves, IMHO. If you will be tackling python 3.0 support, it might
>> be possible to combine it with greater support for embedding python since much
>> of the work in both aspects would be about wrapping python C API for C++
>> programmers.
>
> As mentioned before, thread safety is actually fairly trivial as all
> the required work is already done. There is certainly some work
> involved in writing a test suite and making my patch much more
> generic as my patch was specifically designed to be diff-friendly to
> any Boost alterations, and it doesn't make for good code. I would be
> happy to mentor this project if we can find an approved mentoring
> organisation to adopt me. It certainly would be a good GSoC for a
> student programmer.
>
> PyFinalize() is likely just a hard slog in catching all the code
> paths you wouldn't expect. It's harder than thread safety, but doable
> as a GSoc.
>
> Adding Python 3.0 support ... I am afraid I have no idea as I've been
> out of the coding scene for two years now, but it does sound big and
> complex. But it's something I'm interested in though I'd be not much
> use as a mentor except as in general Boost.Python programming.
>
> So, I guess you got a bit of a mentor if you'd like. BTW, I couldn't
> start mentoring till the start of June as I have my final project due
> then. But that fits the GSoC timetable just perfect.
>
> If you want to know more about my suitability, search this mailing
> list.
>
> HTH,
> Niall
>
>
>

Hi,

Thanks Niall, it is great that you are willing to mentor. Also you
don't need to worry about the Python 3.0 things, since I have worked
on it and have knowledge about the API change. On the other side, I
need guidance of Boost.Python internals, which you are familiar. Your
time table is OK, but should notice that there's some trival things
before the coding started, eg. sign up as mentor and evaluating
proposal, hope you have time to do so. Hopefully you will be a great
mentor! :-)

One issue is that seems Boost is not going to participant in this
year's GSoC as a mentor organization. (Anyone knows the real situation
please clarify this, thanks!) If so, the project may could be attached
to PSF, since it is Python related.

We may limit the scope of this project to py3k support and
thread-safety. I'll try to learn more about Boost.Python internals and
see if the scope is feasible.

Thanks you all! :-)

-- Haoyu Bai

From zaexage at gmail.com  Thu Mar 12 13:00:02 2009
From: zaexage at gmail.com (ZaeX)
Date: Thu, 12 Mar 2009 20:00:02 +0800
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
	0xCCCCCCCC
In-Reply-To: <22471472.post@talk.nabble.com>
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
	<22471472.post@talk.nabble.com>
Message-ID: <2c5080560903120500l20905da7uef40aff4338a4a9b@mail.gmail.com>

Hi,

I copied the code and  tried again, and find out that this 0xcccccccc
problem would still occur at debug build,
and when I switched to Release build, the 'b.ShowPtr()' gave a wrong
address.

But since this code is correct at your side, I think it's possibly because
the precompiled boost.python lib I linked to is not compatible with
something at my environment. [ vc2008 sp1 + python 2.5.4 +
boost_python-vc90-mt-1_36.dll ]
So I think I should compile the boost.python in my environment first then
try it again.

P.S.:
Maybe I went wrong with the shared_ptr in my design, please give me some
advice on my design:

I got a  'class Manager' which contains a std::set of shared_ptr<Entity>;
and  'class Entity'  has a auto_ptr<StateMachine> as member
and  'class StateMachine'  needs shared_ptr<Entity> as member variable to
access some functions outside.

So, in order to break cyclic reference, I make the StateMachine to own a
'shared_ptr<Entity> const&', I think it's kind of reasonable.


On Thu, Mar 12, 2009 at 5:50 PM, athor <thorena at gmail.com> wrote:

>
> Hi,
> I just tried your example and could not reproduce the "feature". I made a
> few minor modifications like fixing typos and adding a cout statement in
> the
> constructor of A but nothing that should affect the result.
>
> A few things that could cause you problems:
> * Passing shared_ptr by reference and keeping refs to shared_ptrs is just
> as
> bad as passing standard pointers. You never know when it's deallocated.
> Passing by value could help (as already mentioned).
>
> * auto_ptr is rather scary. It transfers the responsibility for
> deallocating
> the memory whenever it is copied. I have no idea what the effects could be
> in a python environment. I'd suggest using shared_ptr instead.
>
> Here's my code if you want to look for any differences:
> -----------------------------------------------------
> struct A
> {
>        A()
>        {
>                cerr << "Creating A" << endl;
>        }
> };
>
> class B
> {
> private:
>        shared_ptr&lt;A> const& m_ptr;
> public:
>        B(shared_ptr&lt;A> const& ptr):m_ptr(ptr)
>        {
>                cerr << "Creating B" << endl;
>                cerr << m_ptr.get() << endl;
>        }
>
>        void ShowPtr() const
>        {
>                 cout << m_ptr.get() << endl;
>        }
> };
>
> BOOST_PYTHON_MODULE(pylib)
> {
>
>        class_<B, auto_ptr &lt;B> >("B",  init<shared_ptr&lt;A> const&>())
>                .def("ShowPtr", &B::ShowPtr);
>
>        class_<A, shared_ptr&lt;A>, noncopyable >("A");
> }
> ----------------------------------------------------
> from pylib import *
> a = A() # Creating A
> b = B(a) # Creating B, 0xABCDE
> b.ShowPtr() # 0xABCDE
>
>
>
>
>
> --
> View this message in context:
> http://www.nabble.com/why-does-the-%22shared_ptr%3CX%3E-const-%22-silently-become-0xCCCCCCCC-tp22449314p22471472.html
> Sent from the Python - c++-sig mailing list archive at Nabble.com.
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>



-- 
Time is mana, we must hurry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090312/308d86ea/attachment.htm>

From thorena at gmail.com  Thu Mar 12 13:36:16 2009
From: thorena at gmail.com (athor)
Date: Thu, 12 Mar 2009 05:36:16 -0700 (PDT)
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
 0xCCCCCCCC
In-Reply-To: <2c5080560903120500l20905da7uef40aff4338a4a9b@mail.gmail.com>
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
	<22471472.post@talk.nabble.com>
	<2c5080560903120500l20905da7uef40aff4338a4a9b@mail.gmail.com>
Message-ID: <22475430.post@talk.nabble.com>



zaexage wrote:
> 
> I got a  'class Manager' which contains a std::set of shared_ptr<Entity>;
> and  'class Entity'  has a auto_ptr<StateMachine> as member
> and  'class StateMachine'  needs shared_ptr<Entity> as member variable to
> access some functions outside.
> 
> So, in order to break cyclic reference, I make the StateMachine to own a
> 'shared_ptr<Entity> const&', I think it's kind of reasonable.
> 

I also use VS2008 with Python 2.5 and the boost libraries using the boost
consulting installer so it seems identical (which is strange).

I'd guess there's a simple typo somewhere. By using a const& to the
shared_ptr, it may be deallocated once the program (Python/C++) thinks the
original shared_ptr is not in use anymore. For example, 
a = A()
a = B(a)
would be such a simple typo. A would immediately be deallocated but the
const ref in B wouldn't know.

A few comments:

* I assume each entity owns a unique StateMachine. Otherwise, the
auto_ptr<StateMachine> may be a problem. I've had many strange bugs from
using auto_ptr and thus I only use shared_ptr nowadays.

* You don't *need* a const& to break cyclic reference. Passing a shared_ptr
by value works too.
Example:
-------------------------------
// Forward Declare Entity
class Entity;

// Declare StateMachine
class StateMachine
{
StateMachine(shared_ptr<Entity> e) {...}
};

// Declare Entitity
class Entity
{
Entity(shared_ptr<StateMachine> s) {...}
};


-- 
View this message in context: http://www.nabble.com/why-does-the-%22shared_ptr%3CX%3E-const-%22-silently-become-0xCCCCCCCC-tp22449314p22475430.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.


From dave at boostpro.com  Thu Mar 12 15:11:02 2009
From: dave at boostpro.com (David Abrahams)
Date: Thu, 12 Mar 2009 07:11:02 -0700
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
	0xCCCCCCCC
In-Reply-To: <22475430.post@talk.nabble.com> (athor's message of "Thu, 12 Mar
	2009 05:36:16 -0700 (PDT)")
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
	<22471472.post@talk.nabble.com>
	<2c5080560903120500l20905da7uef40aff4338a4a9b@mail.gmail.com>
	<22475430.post@talk.nabble.com>
Message-ID: <m2mybqx24p.fsf@boostpro.com>


on Thu Mar 12 2009, athor <thorena-AT-gmail.com> wrote:

> * You don't *need* a const& to break cyclic reference. Passing a shared_ptr
> by value works too.

And that's almost always a better idea.  If you *do* have a reference
cycle, consider weak_ptr instead.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

From zaexage at gmail.com  Thu Mar 12 18:57:07 2009
From: zaexage at gmail.com (ZaeX)
Date: Fri, 13 Mar 2009 01:57:07 +0800
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
	0xCCCCCCCC
In-Reply-To: <22475430.post@talk.nabble.com>
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
	<22471472.post@talk.nabble.com>
	<2c5080560903120500l20905da7uef40aff4338a4a9b@mail.gmail.com>
	<22475430.post@talk.nabble.com>
Message-ID: <2c5080560903121057j2b90780cxb8340e0a57204b01@mail.gmail.com>

I just built the boost.python 1.36 with Python2.6.1 and tried again, and it
still turned out to be 0xcccccccc in debug build.
And I made sure this is not caused by 'a = B(a)'-like typo.

Maybe it's something concerning the project setting or something went wrong
with my compiler(?)
Whatever, I think taking a workaround would be a better choice, and maybe I
will figure out what really went wrong sometime later..

On Thu, Mar 12, 2009 at 8:36 PM, athor <thorena at gmail.com> wrote:

>
>
> zaexage wrote:
> >
> > I got a  'class Manager' which contains a std::set of shared_ptr<Entity>;
> > and  'class Entity'  has a auto_ptr<StateMachine> as member
> > and  'class StateMachine'  needs shared_ptr<Entity> as member variable to
> > access some functions outside.
> >
> > So, in order to break cyclic reference, I make the StateMachine to own a
> > 'shared_ptr<Entity> const&', I think it's kind of reasonable.
> >
>
> I also use VS2008 with Python 2.5 and the boost libraries using the boost
> consulting installer so it seems identical (which is strange).
>
> I'd guess there's a simple typo somewhere. By using a const& to the
> shared_ptr, it may be deallocated once the program (Python/C++) thinks the
> original shared_ptr is not in use anymore. For example,
> a = A()
> a = B(a)
> would be such a simple typo. A would immediately be deallocated but the
> const ref in B wouldn't know.
>
> A few comments:
>
> * I assume each entity owns a unique StateMachine. Otherwise, the
> auto_ptr<StateMachine> may be a problem. I've had many strange bugs from
> using auto_ptr and thus I only use shared_ptr nowadays.
>
> * You don't *need* a const& to break cyclic reference. Passing a shared_ptr
> by value works too.
> Example:
> -------------------------------
> // Forward Declare Entity
> class Entity;
>
> // Declare StateMachine
> class StateMachine
> {
> StateMachine(shared_ptr<Entity> e) {...}
> };
>
> // Declare Entitity
> class Entity
> {
> Entity(shared_ptr<StateMachine> s) {...}
> };
>
>
> --
> View this message in context:
> http://www.nabble.com/why-does-the-%22shared_ptr%3CX%3E-const-%22-silently-become-0xCCCCCCCC-tp22449314p22475430.html
> Sent from the Python - c++-sig mailing list archive at Nabble.com.
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>



-- 
Time is mana, we must hurry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090313/2a9a492e/attachment-0001.htm>

From dave at boostpro.com  Thu Mar 12 22:32:39 2009
From: dave at boostpro.com (David Abrahams)
Date: Thu, 12 Mar 2009 14:32:39 -0700
Subject: [C++-sig] GSoC and py3k support for Boost.Python
In-Reply-To: <1d7983e80903110956k60e23acdufff81677b19f8453@mail.gmail.com>
	(Haoyu Bai's message of "Thu, 12 Mar 2009 00:56:46 +0800")
References: <1d7983e80903110956k60e23acdufff81677b19f8453@mail.gmail.com>
Message-ID: <m2prgmv348.fsf@boostpro.com>


on Wed Mar 11 2009, Haoyu Bai <divinekid-AT-gmail.com> wrote:

> Hi,
>
> I have posted this to Boost development mailling list before and many
> people suggested me to repost here, so I did.
>
> I'm a student who has finished SWIG's Python 3.0 support in GSoC 2008.
> I'd like to contribute my knowledge of Python 3 migration to
> Boost.Python, by implementing Python 3 support for it as a Google
> Summer of Code 2009 project. Finally the users of Boost.Python would
> get py3k support smoothly.
>
> Also, you may suggest other useful features that Boost.Python
> currently lack, for example thread safety and PyFinalize support. I
> would like to take it as part of this project if possible.
>
> Any comment is welcome. And it would be great if you are willing to
> mentor this project.

At the risk of overcommitting myself (or worse, promising and not
delivering), I'd be willing to mentor this project.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

From dave at boostpro.com  Thu Mar 12 22:57:34 2009
From: dave at boostpro.com (David Abrahams)
Date: Thu, 12 Mar 2009 14:57:34 -0700
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
	0xCCCCCCCC
In-Reply-To: <2c5080560903121057j2b90780cxb8340e0a57204b01@mail.gmail.com>
	(ZaeX's message of "Fri, 13 Mar 2009 01:57:07 +0800")
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
	<22471472.post@talk.nabble.com>
	<2c5080560903120500l20905da7uef40aff4338a4a9b@mail.gmail.com>
	<22475430.post@talk.nabble.com>
	<2c5080560903121057j2b90780cxb8340e0a57204b01@mail.gmail.com>
Message-ID: <m2zlfqtne9.fsf@boostpro.com>


on Thu Mar 12 2009, ZaeX <zaexage-AT-gmail.com> wrote:

> I just built the boost.python 1.36 with Python2.6.1 and tried again, and it
> still turned out to be 0xcccccccc in debug build.

Have you read
http://www.boost.org/doc/libs/1_38_0/libs/python/doc/building.html#python-debugging-builds
?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

From zaexage at gmail.com  Fri Mar 13 04:21:13 2009
From: zaexage at gmail.com (ZaeX)
Date: Fri, 13 Mar 2009 11:21:13 +0800
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
	0xCCCCCCCC
In-Reply-To: <m2zlfqtne9.fsf@boostpro.com>
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
	<22471472.post@talk.nabble.com>
	<2c5080560903120500l20905da7uef40aff4338a4a9b@mail.gmail.com>
	<22475430.post@talk.nabble.com>
	<2c5080560903121057j2b90780cxb8340e0a57204b01@mail.gmail.com>
	<m2zlfqtne9.fsf@boostpro.com>
Message-ID: <2c5080560903122021v66d0d2b4m5d1ac6247f1f2af@mail.gmail.com>

No, I compiled boost.python with just ' --with-python '.

and I just made a last try to change the 'shared_ptr<A> const& ' to
'shared_ptr<A>&',
and things suddenly become right.  ^_^
well I don't quite understand what's going on inside though. maybe
'shared_ptr<A> const&' made temp copy (?)
----------------------------------------------------------------------------
struct A
{
       A()
       {
               cerr << "Creating A" << endl;
       }
};

class B
{
private:
    //   shared_ptr<A> const& m_ptr; //remove const
         shared_ptr<A> & m_ptr
public:
       //B(shared_ptr<A> const& ptr):m_ptr(ptr)
       B(shared_ptr<A> & ptr) : m_ptr(ptr)
       {
               cerr << "Creating B" << endl;
               cerr << m_ptr.get() << endl;
       }

       void ShowPtr() const
       {
                cout << m_ptr.get() << endl;
       }
};

BOOST_PYTHON_MODULE(TryIt)
{

    //   class_<B, auto_ptr<B> >("B",  init<shared_ptr<A> const&>())
         class_<B, auto_ptr<B> >("B", init<shared_ptr<A> &() )
               .def("ShowPtr", &B::ShowPtr);

       class_<A, shared_ptr&lt;A>, noncopyable >("A");
}
----------------------------------------------------
from TryIt import *
a = A() # Creating A
b = B(a) # Creating B, 0xABCDE
b.ShowPtr() # 0xABCDE


On Fri, Mar 13, 2009 at 5:57 AM, David Abrahams <dave at boostpro.com> wrote:

>
> on Thu Mar 12 2009, ZaeX <zaexage-AT-gmail.com> wrote:
>
> > I just built the boost.python 1.36 with Python2.6.1 and tried again, and
> it
> > still turned out to be 0xcccccccc in debug build.
>
> Have you read
>
> http://www.boost.org/doc/libs/1_38_0/libs/python/doc/building.html#python-debugging-builds
> ?
>
> --
> Dave Abrahams
> BoostPro Computing
> http://www.boostpro.com
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>



-- 
Time is mana, we must hurry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090313/e5ce8cc5/attachment.htm>

From thorena at gmail.com  Fri Mar 13 09:41:43 2009
From: thorena at gmail.com (athor)
Date: Fri, 13 Mar 2009 01:41:43 -0700 (PDT)
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
 0xCCCCCCCC
In-Reply-To: <2c5080560903122021v66d0d2b4m5d1ac6247f1f2af@mail.gmail.com>
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
	<22471472.post@talk.nabble.com>
	<2c5080560903120500l20905da7uef40aff4338a4a9b@mail.gmail.com>
	<22475430.post@talk.nabble.com>
	<2c5080560903121057j2b90780cxb8340e0a57204b01@mail.gmail.com>
	<m2zlfqtne9.fsf@boostpro.com>
	<2c5080560903122021v66d0d2b4m5d1ac6247f1f2af@mail.gmail.com>
Message-ID: <22492273.post@talk.nabble.com>


That is very very strange. Removing const should not change anything. If it
does... well... black magic?
The debugging link Dave provided is very important if you must compile debug
versions. I remember something about not mixing debug/release versions of
python but I just avoid the issue by never compiling pyd's in debug mode...

Removing the reference completely should do the trick though. I.e.
       shared_ptr  m_ptr
and
       B(shared_ptr  ptr) : m_ptr(ptr)

It's much safer than keeping the ref.
-- 
View this message in context: http://www.nabble.com/why-does-the-%22shared_ptr%3CX%3E-const-%22-silently-become-0xCCCCCCCC-tp22449314p22492273.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.


From thorena at gmail.com  Fri Mar 13 09:57:03 2009
From: thorena at gmail.com (athor)
Date: Fri, 13 Mar 2009 01:57:03 -0700 (PDT)
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
 0xCCCCCCCC
In-Reply-To: <22492273.post@talk.nabble.com>
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
	<22471472.post@talk.nabble.com>
	<2c5080560903120500l20905da7uef40aff4338a4a9b@mail.gmail.com>
	<22475430.post@talk.nabble.com>
	<2c5080560903121057j2b90780cxb8340e0a57204b01@mail.gmail.com>
	<m2zlfqtne9.fsf@boostpro.com>
	<2c5080560903122021v66d0d2b4m5d1ac6247f1f2af@mail.gmail.com>
	<22492273.post@talk.nabble.com>
Message-ID: <22492427.post@talk.nabble.com>


I just reproduced the behaviour. Out of habit, I compiled with release the
last time. Using a debug build, I get the same behaviour (using const&,
non-const& etc). 

I'm guessing this is a case of "undefined behaviour" resulting from mixing
Debug/Release dll's. Changing to Release (or reading Daves link) should
help. 

Passing shared_ptr by value and not by ref is still recommended though :)

-- 
View this message in context: http://www.nabble.com/why-does-the-%22shared_ptr%3CX%3E-const-%22-silently-become-0xCCCCCCCC-tp22449314p22492427.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.


From zaexage at gmail.com  Fri Mar 13 10:13:46 2009
From: zaexage at gmail.com (ZaeX)
Date: Fri, 13 Mar 2009 17:13:46 +0800
Subject: [C++-sig] why does the "shared_ptr<X> const&" silently become
	0xCCCCCCCC
In-Reply-To: <22492427.post@talk.nabble.com>
References: <2c5080560903102305v59b86abdj4e277c3179aef8d1@mail.gmail.com>
	<22471472.post@talk.nabble.com>
	<2c5080560903120500l20905da7uef40aff4338a4a9b@mail.gmail.com>
	<22475430.post@talk.nabble.com>
	<2c5080560903121057j2b90780cxb8340e0a57204b01@mail.gmail.com>
	<m2zlfqtne9.fsf@boostpro.com>
	<2c5080560903122021v66d0d2b4m5d1ac6247f1f2af@mail.gmail.com>
	<22492273.post@talk.nabble.com> <22492427.post@talk.nabble.com>
Message-ID: <2c5080560903130213q1c2a77deve435bad16689dda5@mail.gmail.com>

Oh, Thank god, so at least it is not only me. :)

I just double-check this, and this behavior not only happened in debug
build, it will happen in release build too,
But the pointer showing up would not be 0xcccccccc but something arbitrary.

P.S.: I have already changed to follow you guys'  advices to pass by value,
and I will try best to avoid this reference swamp.

On Fri, Mar 13, 2009 at 4:57 PM, athor <thorena at gmail.com> wrote:

>
> I just reproduced the behaviour. Out of habit, I compiled with release the
> last time. Using a debug build, I get the same behaviour (using const&,
> non-const& etc).
>
> I'm guessing this is a case of "undefined behaviour" resulting from mixing
> Debug/Release dll's. Changing to Release (or reading Daves link) should
> help.
>
> Passing shared_ptr by value and not by ref is still recommended though :)
>
> --
> View this message in context:
> http://www.nabble.com/why-does-the-%22shared_ptr%3CX%3E-const-%22-silently-become-0xCCCCCCCC-tp22449314p22492427.html
> Sent from the Python - c++-sig mailing list archive at Nabble.com.
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>



-- 
Time is mana, we must hurry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090313/c855ccfe/attachment-0001.htm>

From seefeld at sympatico.ca  Fri Mar 13 19:19:59 2009
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 13 Mar 2009 14:19:59 -0400
Subject: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
In-Reply-To: <49B82400.25524.24AF2D1D@s_sourceforge.nedprod.com>
References: <1d7983e80903091021h4e877034j497c89a3e6883819@mail.gmail.com>,
	<1d7983e80903110938v2aef386t84f9c779a6398b70@mail.gmail.com>,
	<200903111342.42995.lists_ravi@lavabit.com>
	<49B82400.25524.24AF2D1D@s_sourceforge.nedprod.com>
Message-ID: <49BAA3CF.3090905@sympatico.ca>

Niall Douglas wrote:
>
> I would say that any GSoC project should choose *one* of the above 
> rather than try combining them. Better to do one thing well and in 
> stages than many things at once (unless you have loads of spare 
> time!).
>   

I agree. (I wouldn't mind seeing projects for all of the above, but they 
definitely shouldn't be combined into one.)


>>> Thanks! Seems there's a lot of interesting. So would anyone willing to
>>> mentor this?
>>>       
>> Sadly, I suspect that finding a mentor will be difficult (perhaps even more 
>> difficult than the actual project). Off the top of my head, the following 
>> folks come to mind:
>>   - Dave Abrahams
>>   - Stefan Seefeld
>>   - Ralf Grosse-Kunstleve
>>   - Roman Yakovenko
>> You might try contacting them off list or on c++-sig (cc'ed on this email).
>>     

I'm willing to participate, in particular, if other folks such as David 
are part of such a team, too. (While I believe I understand enough of 
both C++ and Python, lots of boost.python is still very obscure, so 
having David being part would greatly help. May be we could take the 
opportunity and collectively work on the (internal) boost.python docs, too.

David, I notice you already indicated support. Could we team up for this ?
(I will be out on vacation for about two weeks during the summer. Other 
than that I should be available throughout the summer.)

Thanks,
       Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...


From dave at boostpro.com  Fri Mar 13 20:10:40 2009
From: dave at boostpro.com (David Abrahams)
Date: Fri, 13 Mar 2009 12:10:40 -0700
Subject: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
In-Reply-To: <49BAA3CF.3090905@sympatico.ca>
References: <1d7983e80903091021h4e877034j497c89a3e6883819@mail.gmail.com>,
	<1d7983e80903110938v2aef386t84f9c779a6398b70@mail.gmail.com>,
	<200903111342.42995.lists_ravi@lavabit.com>
	<49B82400.25524.24AF2D1D@s_sourceforge.nedprod.com>
	<49BAA3CF.3090905@sympatico.ca>
Message-ID: <25571D9E-0597-4353-B2D3-4E80EF5E7607@boostpro.com>



Sent from my iPhone

On Mar 13, 2009, at 11:19 AM, Stefan Seefeld <seefeld at sympatico.ca>  
wrote:


>
> I'm willing to participate, in particular, if other folks such as
>
> David, I notice you already indicated support. Could we team up for  
> this ?

Sure, I'd be glad to

From s_sourceforge at nedprod.com  Sat Mar 14 12:28:32 2009
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 14 Mar 2009 11:28:32 -0000
Subject: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
In-Reply-To: <25571D9E-0597-4353-B2D3-4E80EF5E7607@boostpro.com>
References: <1d7983e80903091021h4e877034j497c89a3e6883819@mail.gmail.com>,
	<49BAA3CF.3090905@sympatico.ca>,
	<25571D9E-0597-4353-B2D3-4E80EF5E7607@boostpro.com>
Message-ID: <49BB94E0.22183.2E3FD22@s_sourceforge.nedprod.com>

On 13 Mar 2009 at 12:10, David Abrahams wrote:

> On Mar 13, 2009, at 11:19 AM, Stefan Seefeld <seefeld at sympatico.ca>  
> wrote:
> 
> > I'm willing to participate, in particular, if other folks such as
> >
> > David, I notice you already indicated support. Could we team up for  
> > this ?
> 
> Sure, I'd be glad to

Would it make sense if Dave acted as second as in "person we fall 
back upon if the primaries can't figure it out?"

Mentoring would cost any of us at least five hours per week, and 
definitely more than that some weeks and less other weeks. I'm just 
very lucky that this summer I have that kind of time spare for the 
first time in years.

Cheers,
Niall




From dave at boostpro.com  Sat Mar 14 13:01:15 2009
From: dave at boostpro.com (David Abrahams)
Date: Sat, 14 Mar 2009 05:01:15 -0700
Subject: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
In-Reply-To: <49BB94E0.22183.2E3FD22@s_sourceforge.nedprod.com>
References: <1d7983e80903091021h4e877034j497c89a3e6883819@mail.gmail.com>,
	<49BAA3CF.3090905@sympatico.ca>,
	<25571D9E-0597-4353-B2D3-4E80EF5E7607@boostpro.com>
	<49BB94E0.22183.2E3FD22@s_sourceforge.nedprod.com>
Message-ID: <91FFE14B-226B-41E5-A28B-F5D3989599D0@boostpro.com>


On Mar 14, 2009, at 4:28 AM, Niall Douglas wrote:

> On 13 Mar 2009 at 12:10, David Abrahams wrote:
>
>> On Mar 13, 2009, at 11:19 AM, Stefan Seefeld <seefeld at sympatico.ca>
>> wrote:
>>
>>> I'm willing to participate, in particular, if other folks such as
>>>
>>> David, I notice you already indicated support. Could we team up for
>>> this ?
>>
>> Sure, I'd be glad to
>
> Would it make sense if Dave acted as second as in "person we fall
> back upon if the primaries can't figure it out?"

That would make plenty of sense to me.  I'd be very happy to have  
others leading the mentoring effort.   But we may have missed the GSoC  
application deadline by now.  I'm not sure whether anyone signed us up.

--
David Abrahams
BoostPro Computing
http://boostpro.com





From hartmut.kaiser at gmail.com  Sat Mar 14 13:31:24 2009
From: hartmut.kaiser at gmail.com (Hartmut Kaiser)
Date: Sat, 14 Mar 2009 07:31:24 -0500
Subject: [C++-sig] [boost]   [Python] GSoC and Python 3.0 Support
In-Reply-To: <91FFE14B-226B-41E5-A28B-F5D3989599D0@boostpro.com>
References: <1d7983e80903091021h4e877034j497c89a3e6883819@mail.gmail.com>,
	<49BAA3CF.3090905@sympatico.ca>,
	<25571D9E-0597-4353-B2D3-4E80EF5E7607@boostpro.com>	<49BB94E0.22183.2E3FD22@s_sourceforge.nedprod.com>
	<91FFE14B-226B-41E5-A28B-F5D3989599D0@boostpro.com>
Message-ID: <49bba3a3.c505be0a.37ff.2d78@mx.google.com>

> >> On Mar 13, 2009, at 11:19 AM, Stefan Seefeld <seefeld at sympatico.ca>
> >> wrote:
> >>
> >>> I'm willing to participate, in particular, if other folks such as
> >>>
> >>> David, I notice you already indicated support. Could we team up for
> >>> this ?
> >>
> >> Sure, I'd be glad to
> >
> > Would it make sense if Dave acted as second as in "person we fall
> > back upon if the primaries can't figure it out?"
> 
> That would make plenty of sense to me.  I'd be very happy to have
> others leading the mentoring effort.   But we may have missed the GSoC
> application deadline by now.  I'm not sure whether anyone signed us up.

Troy and me did. No response from Google yet, though.
Regards Hartmut


From seefeld at sympatico.ca  Sat Mar 14 14:29:32 2009
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sat, 14 Mar 2009 09:29:32 -0400
Subject: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
In-Reply-To: <91FFE14B-226B-41E5-A28B-F5D3989599D0@boostpro.com>
References: <1d7983e80903091021h4e877034j497c89a3e6883819@mail.gmail.com>,
	<49BAA3CF.3090905@sympatico.ca>,
	<25571D9E-0597-4353-B2D3-4E80EF5E7607@boostpro.com>	<49BB94E0.22183.2E3FD22@s_sourceforge.nedprod.com>
	<91FFE14B-226B-41E5-A28B-F5D3989599D0@boostpro.com>
Message-ID: <49BBB13C.9090306@sympatico.ca>

David Abrahams wrote:
>
> On Mar 14, 2009, at 4:28 AM, Niall Douglas wrote:
>
>>
>> Would it make sense if Dave acted as second as in "person we fall
>> back upon if the primaries can't figure it out?"
>
> That would make plenty of sense to me.  I'd be very happy to have 
> others leading the mentoring effort.   But we may have missed the GSoC 
> application deadline by now.  I'm not sure whether anyone signed us up.

I believe we are on track. And I agree, too: It might be wise if people 
like Niall and myself did the official mentoring, while being able to 
relay questions we can't answer on our own to David.

This could become a productive summer for boost.python !

Thanks,
       Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...


From dave at boostpro.com  Sun Mar 15 04:34:36 2009
From: dave at boostpro.com (David Abrahams)
Date: Sat, 14 Mar 2009 20:34:36 -0700
Subject: [C++-sig] Boost.Python app keeps crashing in debug
In-Reply-To: <5EBFFA2CDFF44CC79BD337584F34FFD9@cellardoor>
References: <F98C4B1A2DE74AF2A2259FE09AC71B9F@cellardoor><87ab8hucs2.fsf@mcbain.luannocracy.com>
	<8C15D922939048D390E2EB818DE86DCA@cellardoor>
	<5EBFFA2CDFF44CC79BD337584F34FFD9@cellardoor>
Message-ID: <E716F4A6-843C-4CFE-95E3-E78A073A9FD9@boostpro.com>


On Feb 22, 2009, at 7:23 AM, Martin Walser wrote:

>
> Okay... I found the problem.
>
> I used the opportunity to upgrade all my libs.
>
> Built Python 2.6.1 debug and release from sources...
> Downloaded Boost 1.38.0...
>
> And as I built Python myself this time, autodetection of python  
> failed when
> building the Boost.Python libs.
>
> So I needed a Jam File.
>
> And there was the problem.
>
>
> You REALLY seem to need a Jam file to build the real debug versions.

Doubtful, at least if the usual registry entries are set or you've  
installed in the standard locations.  Otherwise, e.g. if you installed  
in C:\Python-2.6.1 and moved it to C:\libs\Python-2.6.1, then yeah,  
you might need to tell the system where your Python is.

Properties like <python-debugging>off can be added on the command line  
with, e.g., "python-debugging=off"

define=BOOST_ALL_NO_LIB shouldn't be needed, but I'm totally willing  
to believe Boost.Python has bugs in that area.

> I put a "user-config.jam" in my home path (Windows: ECHO
> %HOMEDRIVE%%HOMEPATH%) and suddenly I got a working dll:
>
>
> #### user-config.jam ###########
>
> using python
> 	: 2.6 						# Version
> 	: C:\\libs\\Python-2.6.1\\python.exe	# Python Path
> 	: C:\\libs\\Python-2.6.1\\Include		# include path(s) -
> they may be not really needed here
>  	: C:\\libs\\Python-2.6.1\\libs		# lib path(s) - they may be
> not really needed here
>  	: <python-debugging>off ;
>
> using python
> 	: 2.6 						# Version
> 	: C:\\libs\\Python-2.6.1\\python_d.exe	# Python Path
> 	: C:\\libs\\Python-2.6.1\\Include		# include path(s) -
> they may be not really needed here
>  	: C:\\libs\\Python-2.6.1\\libs		# lib path(s) - they may be
> not really needed here
>  	: <python-debugging>on <define>BOOST_ALL_NO_LIB=1
> 	;
> ################################
>
>
>
>
> It seems to be absolutely necessary to define <python-debugging>on  
> in the
> jam file.
>
>
> Simply invoking...
>
> bjam toolset=msvc --verbose-test test python-debugging=on
> define=BOOST_ALL_NO_LIB
>
> ...won't do the trick.

Well, that's news to me.  If that's the case, I'd say it's a  
Boost.Build bug that you should take up on the boost-build list.


--
David Abrahams
BoostPro Computing
http://boostpro.com





From Matthew.Scouten at tradingtechnologies.com  Mon Mar 16 16:28:04 2009
From: Matthew.Scouten at tradingtechnologies.com (Matthew Scouten (TT))
Date: Mon, 16 Mar 2009 10:28:04 -0500
Subject: [C++-sig] strange behavior with respect to numeric and Boolean
	overloads
Message-ID: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01>

So here is some strange behavior I ran across with BP. A take a look at
this example code: 

 

busybox.cpp:

 

#include "stdafx.h"

 

std::string foo_int   (int    arg) { return std::string("foo(int)
Called"); }

std::string foo_double(double arg) { return std::string("foo(double)
Called"); }

std::string foo_bool  (bool   arg) { return std::string("foo(bool)
Called"); }

BOOST_PYTHON_MODULE(busybox)

{

    bp::def("foo", foo_double);

    bp::def("foo", foo_bool);

    bp::def("foo", foo_int);

    

}

 

python Interpreter:   

 

Python 2.6.1 (r261:67517, Dec  4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on win32

Type "help", "copyright", "credits" or "license" for more information.

>>> import busybox

>>> busybox.foo(5.0)

'foo(double) Called'

>>> busybox.foo(5)

'foo(int)    Called'

>>> busybox.foo(True)

'foo(int)    Called'

>>> 

 

Note that the int overload is called for a bool argument. If I change
the order of the defs in the cpp file I can effect this to some extent.
If I put the def for the bool overload last, IT gets called for both int
and bool parameters. If I put the double override last, that override
gets called for ALL 3 CALLS regardless of what is passed.

 

Now the order sensitivity is annoying, but I can figure out how to make
it work right, and then comment the dickens out of the code. The real
killer is that there does not seem to be any way to force BP to
differentiate between a bool and an int. The only thing that has worked
is to apply a name skew (ie: bp::def("foo_bool", foo_bool);). This
works, but the users carp at me for changing the interface from the
underlying library.

 

Is there a better work around?

Is this a bug?    

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

From roman.yakovenko at gmail.com  Mon Mar 16 17:59:41 2009
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Mon, 16 Mar 2009 18:59:41 +0200
Subject: [C++-sig] strange behavior with respect to numeric and Boolean
	overloads
In-Reply-To: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01>
References: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01>
Message-ID: <7465b6170903160959h33acfbd8m57f6a6eff7f25a4d@mail.gmail.com>

2009/3/16 Matthew Scouten (TT) <Matthew.Scouten at tradingtechnologies.com>:
> So here is some strange behavior I ran across with BP. A take a look at this
> example code:
>
>
>
> busybox.cpp:
>
>
>
> #include "stdafx.h"
>
>
>
> std::string foo_int?? (int??? arg) { return std::string("foo(int)
> Called"); }
>
> std::string foo_double(double arg) { return std::string("foo(double)
> Called"); }
>
> std::string foo_bool? (bool?? arg) { return std::string("foo(bool)
> Called"); }
>
> BOOST_PYTHON_MODULE(busybox)
>
> {
>
> ??? bp::def("foo", foo_double);
>
> ??? bp::def("foo", foo_bool);
>
> ??? bp::def("foo", foo_int);
>
>
>
> }
>
> ...
>
> Now the order sensitivity is annoying, but I can figure out how to make it
> work right, and then comment the dickens out of the code. The real killer is
> that there does not seem to be any way to force BP to differentiate between
> a bool and an int. The only thing that has worked is to apply a name skew
> (ie: bp::def("foo_bool", foo_bool);). This works, but the users carp at me
> for changing the interface from the underlying library.
>
>
>
> Is there a better work around?

Yes:

1. rename your functions

2. introduce a function in Python, which selects "the right" function,
based on argument type.

> Is this a bug?

Take a look on the following doc:
http://www.language-binding.net/pyplusplus/documentation/functions/registration_order.html

HTH


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

From Matthew.Scouten at tradingtechnologies.com  Mon Mar 16 19:30:35 2009
From: Matthew.Scouten at tradingtechnologies.com (Matthew Scouten (TT))
Date: Mon, 16 Mar 2009 13:30:35 -0500
Subject: [C++-sig] strange behavior with respect to numeric and Boolean
	overloads
In-Reply-To: <7465b6170903160959h33acfbd8m57f6a6eff7f25a4d@mail.gmail.com>
References: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01>
	<7465b6170903160959h33acfbd8m57f6a6eff7f25a4d@mail.gmail.com>
Message-ID: <32490DFF7774554A85D65D23A9F0F9380A4C913B@chiex01>

I read the linked page, but this still feels like a bug to me. Or at least a wart. Like I said, the order sensitivity I can live with, because that only effects me. But the int vs bool problem is really obnoxious. C++ can tell an int from a bool, Python can tell an int from a bool, but library between them is discarding this information. 

I agree that the best solution (from a purely technical view point) would be to rename the functions in the underlying c++ library, but I do not have control over that library and they have good reason to serve c++ users first and to resist interface breaking changes. From a UI viewpoint, the function is called foo. It foos the data that you pass to it. Having functions foo_int and foo_bool is not good style in either c++ or python.

The problem seems to be that a bool implicitly cast to an int AND an int implicitly cast to a bool. If one of these could be blocked, then there would be some order that would make things work.   

-----Original Message-----
From: cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at python.org [mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at python.org] On Behalf Of Roman Yakovenko
Sent: Monday, March 16, 2009 12:00 PM
To: Development of Python/C++ integration
Subject: Re: [C++-sig] strange behavior with respect to numeric and Booleanoverloads

2009/3/16 Matthew Scouten (TT) <Matthew.Scouten at tradingtechnologies.com>:
> So here is some strange behavior I ran across with BP. A take a look at this
> example code:
>
>
>
> busybox.cpp:
>
>
>
> #include "stdafx.h"
>
>
>
> std::string foo_int?? (int??? arg) { return std::string("foo(int)
> Called"); }
>
> std::string foo_double(double arg) { return std::string("foo(double)
> Called"); }
>
> std::string foo_bool? (bool?? arg) { return std::string("foo(bool)
> Called"); }
>
> BOOST_PYTHON_MODULE(busybox)
>
> {
>
> ??? bp::def("foo", foo_double);
>
> ??? bp::def("foo", foo_bool);
>
> ??? bp::def("foo", foo_int);
>
>
>
> }
>
> ...
>
> Now the order sensitivity is annoying, but I can figure out how to make it
> work right, and then comment the dickens out of the code. The real killer is
> that there does not seem to be any way to force BP to differentiate between
> a bool and an int. The only thing that has worked is to apply a name skew
> (ie: bp::def("foo_bool", foo_bool);). This works, but the users carp at me
> for changing the interface from the underlying library.
>
>
>
> Is there a better work around?

Yes:

1. rename your functions

2. introduce a function in Python, which selects "the right" function,
based on argument type.

> Is this a bug?

Take a look on the following doc:
http://www.language-binding.net/pyplusplus/documentation/functions/registration_order.html

HTH


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

From rwgk at yahoo.com  Mon Mar 16 22:52:16 2009
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 16 Mar 2009 14:52:16 -0700 (PDT)
Subject: [C++-sig] strange behavior with respect to numeric and Boolean
	overloads
In-Reply-To: <32490DFF7774554A85D65D23A9F0F9380A4C913B@chiex01>
References: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01>
	<7465b6170903160959h33acfbd8m57f6a6eff7f25a4d@mail.gmail.com>
	<32490DFF7774554A85D65D23A9F0F9380A4C913B@chiex01>
Message-ID: <490808.99798.qm@web111402.mail.gq1.yahoo.com>


> I read the linked page, but this still feels like a bug to me. Or at least a wart.

I agree. Boost.Python 2 was written when the Python bool type still really was an int (Python 2.2).
I'm not sure what it would take to retro-fit Boost.Python, but probably it is doable for
a motivated volunteer.
Ralf


From gabrieljoel at gmail.com  Tue Mar 17 00:13:38 2009
From: gabrieljoel at gmail.com (Gabriel Joel Perez)
Date: Mon, 16 Mar 2009 19:13:38 -0400
Subject: [C++-sig] Problem with bjam quickstart
Message-ID: <9a442d030903161613v2321d07coe26a590eee5fa876@mail.gmail.com>

Hi! I'm getting problems with running the basic demo that is described in
the bjam quickstart guide
http://www.boost.org/doc/libs/1_38_0/libs/python/doc/building.html

I have the following bjam version: boost-jam-3.1.17-1-linuxx86/ and I'm
running Ubuntu 8.04 Hardy Heron  and I have libboost-python1.34.1

Whenever I run the following: bjam --verbose-test --debug-configuration test

I get the following error

notice: found boost-build.jam at
/usr/share/doc/libboost-doc/examples/libs/python/example/boost-build.jam
notice: loading Boost.Build from /usr/share/boost-build
notice: loading site-config.jam from /etc/site-config.jam
notice: loading user-config.jam from /usr/share/boost-build/user-config.jam
Error: Illegal attempt to re-bootstrap the build system by invoking

   'boost-build ../../../../tools/build/v2 ;'

Please consult the documentation at 'http://www.boost.org'.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090316/28cacb6d/attachment.htm>

From grafikrobot at gmail.com  Tue Mar 17 03:40:00 2009
From: grafikrobot at gmail.com (Rene Rivera)
Date: Mon, 16 Mar 2009 21:40:00 -0500
Subject: [C++-sig] Problem with bjam quickstart
In-Reply-To: <9a442d030903161613v2321d07coe26a590eee5fa876@mail.gmail.com>
References: <9a442d030903161613v2321d07coe26a590eee5fa876@mail.gmail.com>
Message-ID: <49BF0D80.90202@gmail.com>

Gabriel Joel Perez wrote:
> Hi! I'm getting problems with running the basic demo that is described in
> the bjam quickstart guide
> http://www.boost.org/doc/libs/1_38_0/libs/python/doc/building.html
> 
> I have the following bjam version: boost-jam-3.1.17-1-linuxx86/ and I'm
> running Ubuntu 8.04 Hardy Heron  and I have libboost-python1.34.1
> 
> Whenever I run the following: bjam --verbose-test --debug-configuration test
> 
> I get the following error
> 
> notice: found boost-build.jam at
> /usr/share/doc/libboost-doc/examples/libs/python/example/boost-build.jam
> notice: loading Boost.Build from /usr/share/boost-build
> notice: loading site-config.jam from /etc/site-config.jam
> notice: loading user-config.jam from /usr/share/boost-build/user-config.jam
> Error: Illegal attempt to re-bootstrap the build system by invoking
> 
>    'boost-build ../../../../tools/build/v2 ;'
> 
> Please consult the documentation at 'http://www.boost.org'.

IIRC, that example assumes it's being run as part of the full Boost 
sources. But it does it as a standalone project to show what it could 
look like in your own project. Hence it causes problems when it's really 
separate :-( It means you should open up the "example/boost-build.jam" 
<https://svn.boost.org/trac/boost/browser/tags/release/Boost_1_34_1/boost/libs/python/example/boost-build.jam> 
file, the "example/Jamroot" file, and likely other Jam* files in there 
to follow the instructions that mention changing paths when those 
examples are moved outside of the Boost source tree.

HTH.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

From roman.yakovenko at gmail.com  Tue Mar 17 06:40:14 2009
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Tue, 17 Mar 2009 07:40:14 +0200
Subject: [C++-sig] strange behavior with respect to numeric and Boolean
	overloads
In-Reply-To: <32490DFF7774554A85D65D23A9F0F9380A4C913B@chiex01>
References: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01>
	<7465b6170903160959h33acfbd8m57f6a6eff7f25a4d@mail.gmail.com>
	<32490DFF7774554A85D65D23A9F0F9380A4C913B@chiex01>
Message-ID: <7465b6170903162240u29c034b2y8f7d1b95b68301fc@mail.gmail.com>

On Mon, Mar 16, 2009 at 8:30 PM, Matthew Scouten (TT)
<Matthew.Scouten at tradingtechnologies.com> wrote:
> I read the linked page, but this still feels like a bug to me. Or at least a wart. Like I said, the order sensitivity I can live with, because that only effects me. But the int vs bool problem is really obnoxious. C++ can tell an int from a bool, Python can tell an int from a bool, but library between them is discarding this information.
>
> I agree that the best solution (from a purely technical view point) would be to rename the functions in the underlying c++ library, but I do not have control over that library and they have good reason to serve c++ users first and to resist interface breaking changes. From a UI viewpoint, the function is called foo. It foos the data that you pass to it. Having functions foo_int and foo_bool is not good style in either c++ or python.

May be you've got me wrong. I suggest to expose the function under
different names( aliases ) and than to create small function in
Python, which calls the desired one:

void foo( bool );
void foo( int );

def( "_foo_bool", (void *(bool) )( foo ) );
def( "_foo_int", (void *(int) )( foo ) );

Python code:

def foo( arg ):
    if isinstance( arg, int ):
         _foo_int( arg )
    else:
         _foo_bool( arg )

HTH

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

From meine at informatik.uni-hamburg.de  Tue Mar 17 11:03:10 2009
From: meine at informatik.uni-hamburg.de (Hans Meine)
Date: Tue, 17 Mar 2009 11:03:10 +0100
Subject: [C++-sig] strange behavior with respect to numeric and Boolean
	overloads
In-Reply-To: <7465b6170903162240u29c034b2y8f7d1b95b68301fc@mail.gmail.com>
References: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01>
	<32490DFF7774554A85D65D23A9F0F9380A4C913B@chiex01>
	<7465b6170903162240u29c034b2y8f7d1b95b68301fc@mail.gmail.com>
Message-ID: <200903171103.11258.meine@informatik.uni-hamburg.de>

On Monday 16 March 2009 22:52:16 Ralf W. Grosse-Kunstleve wrote:
> [...] Boost.Python 2 was written when the Python bool type still really
> was an int (Python 2.2). [...]

On Tuesday 17 March 2009 06:40:14 Roman Yakovenko wrote:
> Python code:
>
> def foo( arg ):
>     if isinstance( arg, int ):
>          _foo_int( arg )
>     else:
>          _foo_bool( arg )

Now I am confused.  Both of the above read as if a boolean was no longer an 
int, but I interpret "is a" and "isinstance" as checking for types inherited 
from, too?!  While Ralf could have meant (True is 1) with his "really", the 
above code should first test whether isinstance( arg, bool ), no?

Or did this change with 2.6/3?

Greetings,
  Hans

From Matthew.Scouten at tradingtechnologies.com  Tue Mar 17 15:25:30 2009
From: Matthew.Scouten at tradingtechnologies.com (Matthew Scouten (TT))
Date: Tue, 17 Mar 2009 09:25:30 -0500
Subject: [C++-sig] strange behavior with respect to numeric and
	Booleanoverloads
In-Reply-To: <200903171103.11258.meine@informatik.uni-hamburg.de>
References: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01><32490DFF7774554A85D65D23A9F0F9380A4C913B@chiex01><7465b6170903162240u29c034b2y8f7d1b95b68301fc@mail.gmail.com>
	<200903171103.11258.meine@informatik.uni-hamburg.de>
Message-ID: <32490DFF7774554A85D65D23A9F0F9380A4C933C@chiex01>

isinstance( True, int ) returns True

However, the code 

 def foo( arg ):
     if isinstance( arg, bool ):
          _foo_bool( arg )
     else:
          _foo_other( arg )

Would work in theory. 

I could do this. I'm just annoyed that BP is not doing it for me. 

-----Original Message-----
From:
cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at python.org
[mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at py
thon.org] On Behalf Of Hans Meine
Sent: Tuesday, March 17, 2009 5:03 AM
To: Development of Python/C++ integration
Subject: Re: [C++-sig] strange behavior with respect to numeric and
Booleanoverloads

On Monday 16 March 2009 22:52:16 Ralf W. Grosse-Kunstleve wrote:
> [...] Boost.Python 2 was written when the Python bool type still
really
> was an int (Python 2.2). [...]

On Tuesday 17 March 2009 06:40:14 Roman Yakovenko wrote:
> Python code:
>
> def foo( arg ):
>     if isinstance( arg, int ):
>          _foo_int( arg )
>     else:
>          _foo_bool( arg )

Now I am confused.  Both of the above read as if a boolean was no longer
an 
int, but I interpret "is a" and "isinstance" as checking for types
inherited 
from, too?!  While Ralf could have meant (True is 1) with his "really",
the 
above code should first test whether isinstance( arg, bool ), no?

Or did this change with 2.6/3?

Greetings,
  Hans
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

From troy at resophonic.com  Tue Mar 17 19:06:06 2009
From: troy at resophonic.com (troy d. straszheim)
Date: Tue, 17 Mar 2009 11:06:06 -0700
Subject: [C++-sig] strange behavior with respect to numeric
	and	Booleanoverloads
In-Reply-To: <32490DFF7774554A85D65D23A9F0F9380A4C933C@chiex01>
References: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01><32490DFF7774554A85D65D23A9F0F9380A4C913B@chiex01><7465b6170903162240u29c034b2y8f7d1b95b68301fc@mail.gmail.com>	<200903171103.11258.meine@informatik.uni-hamburg.de>
	<32490DFF7774554A85D65D23A9F0F9380A4C933C@chiex01>
Message-ID: <49BFE68E.7090507@resophonic.com>

I have a quasi-fix for this to the library itself, (see diff below) 
buuut it breaks a certain case:  if you have a wrapped c++ function that 
takes a bool, and you try to pass it an int, you get a

     ArgumentError: Python argument types in
         builtin_converters_ext.rewrap_const_reference_bool(int)
     did not match C++ signature:
         rewrap_const_reference_bool(bool)

so you have to call the function with an explicit cast to bool:

c++:

   void takes_a_bool(bool b) { ... };

   def("py_takesbool", takes_a_bool);

py:

   py_takesbool(bool(33))

to get things to work.   This breaks a lot of tests, I'm digging further.


Index: converter/builtin_converters.cpp
===================================================================
--- converter/builtin_converters.cpp	(revision 51812)
+++ converter/builtin_converters.cpp	(working copy)
@@ -99,8 +99,13 @@
            if (number_methods == 0)
                return 0;

-          return (PyInt_Check(obj) || PyLong_Check(obj))
-              ? &number_methods->nb_int : 0;
+          return (
+#if PY_VERSION_HEX >= 0x02040000
+		  !PyBool_Check(obj) &&
+#endif
+		  (PyInt_Check(obj) || PyLong_Check(obj)))
+
+	    ? &number_methods->nb_int : 0;
        }
        static PyTypeObject const* get_pytype() { return &PyInt_Type;}
    };
@@ -135,7 +140,11 @@
            if (number_methods == 0)
                return 0;

-          return (PyInt_Check(obj) || PyLong_Check(obj))
+          return (
+#if PY_VERSION_HEX >= 0x02040000
+		  !PyBool_Check(obj) &&
+#endif
+		  (PyInt_Check(obj) || PyLong_Check(obj)))
                ? &py_object_identity : 0;
        }
        static PyTypeObject const* get_pytype() { return &PyInt_Type;}
@@ -226,7 +235,11 @@
    {
        static unaryfunc* get_slot(PyObject* obj)
        {
+#if PY_VERSION_HEX >= 0x02040000
+	return obj == Py_None || PyBool_Check(obj) ? &py_object_identity : 0;
+#else
            return obj == Py_None || PyInt_Check(obj) ? 
&py_object_identity : 0;
+#endif
        }

        static bool extract(PyObject* intermediate)

From divinekid at gmail.com  Tue Mar 17 19:07:56 2009
From: divinekid at gmail.com (Haoyu Bai)
Date: Wed, 18 Mar 2009 02:07:56 +0800
Subject: [C++-sig] Some thoughts on py3k support
Message-ID: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>

Hi,

Here is some thoughts on GSoC Boost.Python py3k support project.

First thing come into my mind is the build system. For Python 3, we
would have a separate build target, eg. having libboost_python.so
built for Python 2.x and libboost_python3.so for Python 3. This would
match the current situation that most Linux distro packaged Python 3
in a way that lives together with Python 2.x. There's two build system
for Boost now - cmake and bjam. Personally I want to start with cmake,
and finally both of the two will up to date for Python 3.

I have read some piece of Boost.Python code in these, it is
understandable for me. And I'd say the usage of template
metaprogramming is really smart! Thanks to the high level abstraction,
there would be just a little code interfaced to Python C-API directly.
So there would not be so much works.

However there are something we need to take care of. One of them is,
in Python 3, string is unicode (and the old string class is called
bytes in Python 3). So if we have a C function

char const* hello(); // returns a "Hello"

According to the current behavior of Boost.Python converters, the
wrapped function in Python 3 will return a b"Hello" (which is a bytes
object but not a string). So code like this will broken:

if "Hello" == hello(): ...

Because string object "Hello" is not equal to bytes object b"Hello"
returned by hello(). We may change the behavior of converter to return
a unicode string in Python 3, that would keep most of existing code
compatible. Anyway there will be code really need a single byte string
returned, a new converter can be explicitly specified for this.

There are more issues similar to this. I'll figure out more and write
a detailed proposal as soon as possible.


Best regards,

Haoyu Bai

From divinekid at gmail.com  Tue Mar 17 19:19:08 2009
From: divinekid at gmail.com (Haoyu Bai)
Date: Wed, 18 Mar 2009 02:19:08 +0800
Subject: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
In-Reply-To: <49BBB13C.9090306@sympatico.ca>
References: <1d7983e80903091021h4e877034j497c89a3e6883819@mail.gmail.com>
	<49BAA3CF.3090905@sympatico.ca>
	<25571D9E-0597-4353-B2D3-4E80EF5E7607@boostpro.com>
	<49BB94E0.22183.2E3FD22@s_sourceforge.nedprod.com>
	<91FFE14B-226B-41E5-A28B-F5D3989599D0@boostpro.com>
	<49BBB13C.9090306@sympatico.ca>
Message-ID: <1d7983e80903171119s29ff9573o1d6528605ec6745e@mail.gmail.com>

On Sat, Mar 14, 2009 at 9:29 PM, Stefan Seefeld <seefeld at sympatico.ca> wrote:
> David Abrahams wrote:
>>
>> On Mar 14, 2009, at 4:28 AM, Niall Douglas wrote:
>>
>>>
>>> Would it make sense if Dave acted as second as in "person we fall
>>> back upon if the primaries can't figure it out?"
>>
>> That would make plenty of sense to me. ?I'd be very happy to have others
>> leading the mentoring effort. ? But we may have missed the GSoC application
>> deadline by now. ?I'm not sure whether anyone signed us up.
>
> I believe we are on track. And I agree, too: It might be wise if people like
> Niall and myself did the official mentoring, while being able to relay
> questions we can't answer on our own to David.
>
> This could become a productive summer for boost.python !
>
> Thanks,
> ? ? ?Stefan
>

Hi,

I'm very happy to see so much interest in this project. You are all
experts on Boost.Python so I'd glad to see anyone of you to mentor
this. I'm looking forward for this summer!

I'll post more questions and proposals etc. to Python c++-sig mailling
list, since that is focused on Boost.Python.

Thanks!

-- Haoyu Bai

From Matthew.Scouten at tradingtechnologies.com  Tue Mar 17 21:23:03 2009
From: Matthew.Scouten at tradingtechnologies.com (Matthew Scouten (TT))
Date: Tue, 17 Mar 2009 15:23:03 -0500
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
Message-ID: <32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01>

A thought on this bytes vs. strings:

I am not sure if others do the same thing, but:

There are a number of places where the underlying library that we are
wrapping has a char* or a char[] that can be either a null terminated
string or an arbitrary bag of bytes depending on context.  The fact that
python uses strings for arbitrary bags of bytes has been convenient for
us in this regard. 

I can work with whatever you come up with, but it might convenient if a
char* or char[] was treated as a bytes object and a std::string was
treated as a string. Thoughts? 

-----Original Message-----
From:
cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at python.org
[mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at py
thon.org] On Behalf Of Haoyu Bai
Sent: Tuesday, March 17, 2009 1:08 PM
To: Development of Python/C++ integration
Subject: [C++-sig] Some thoughts on py3k support


However there are something we need to take care of. One of them is,
in Python 3, string is unicode (and the old string class is called
bytes in Python 3). So if we have a C function

char const* hello(); // returns a "Hello"

According to the current behavior of Boost.Python converters, the
wrapped function in Python 3 will return a b"Hello" (which is a bytes
object but not a string). So code like this will broken:

if "Hello" == hello(): ...

Because string object "Hello" is not equal to bytes object b"Hello"
returned by hello(). We may change the behavior of converter to return
a unicode string in Python 3, that would keep most of existing code
compatible. Anyway there will be code really need a single byte string
returned, a new converter can be explicitly specified for this.

There are more issues similar to this. I'll figure out more and write
a detailed proposal as soon as possible.


Best regards,

Haoyu Bai
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

From kranar at hotmail.com  Tue Mar 17 23:30:21 2009
From: kranar at hotmail.com (Kamal Mansouri)
Date: Tue, 17 Mar 2009 18:30:21 -0400
Subject: [C++-sig] Smart pointer, polymorphism issue
Message-ID: <SNT105-W6F53E2A7353CC1FC00039CA980@phx.gbl>


Hello,

I have created a Python wrapper using a custom smart pointer that 
is defined 
in the following manner:

class_<EventWrapper, 
noncopyable, Ptr<EventWrapper>>("Event", init<>())
    
.def("f", &Event::f, &EventWrapper::default_f).
  
implicitely_convertible<Ptr<EventWrapper>, Ptr<Event>>();
  
register_ptr_to_python<Ptr<Event>>();

Now... when I subclass 
this in Python like so:

class MyEvent(Event):
  def f(self):
    
return 42

I can use MyEvent as expected only within Python code... when I 
pass an 
instance of MyEvent to C++, and then C++ passes MyEvent back 
to
Python, I no longer am able to call the overridden method f in 
Python.
Calling f in Python invokes Event::f, as opposed to 
MyEvent.f

This only happens when I construct MyEvent in Python code, pass 
the instance 
to some C++ code, and have the C++ code pass back the 
MyEvent instance
back to Python.

Any ideas why this may 
be?

Thanks. 

_________________________________________________________________
Share photos with friends on Windows Live Messenger
http://go.microsoft.com/?linkid=9650734
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090317/b8193ff1/attachment-0001.htm>

From grafikrobot at gmail.com  Wed Mar 18 00:25:38 2009
From: grafikrobot at gmail.com (Rene Rivera)
Date: Tue, 17 Mar 2009 18:25:38 -0500
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
	<32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01>
Message-ID: <49C03172.108@gmail.com>

Matthew Scouten (TT) wrote:
> I can work with whatever you come up with, but it might convenient if a
> char* or char[] was treated as a bytes object and a std::string was
> treated as a string. Thoughts? 

A char* can never be fully treated as a bytes object. You must mean a 
char* plus a size_t (or two char* iterator pointers). At which point any 
convenience you think you are getting from treating char* as bytes is 
gone as you have to introduce an intermediate type anyway to put in the 
"buffer" semantics. Hence you are better off with real buffer objects, 
or equivalents thereof. Say a std::pair<char*,char*> iterator range, or 
std::vector<char>, etc.


-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

From divinekid at gmail.com  Wed Mar 18 15:53:25 2009
From: divinekid at gmail.com (Haoyu Bai)
Date: Wed, 18 Mar 2009 22:53:25 +0800
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <49C03172.108@gmail.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
	<32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01>
	<49C03172.108@gmail.com>
Message-ID: <1d7983e80903180753w79210c52gf1aaf7dba745da08@mail.gmail.com>

On Wed, Mar 18, 2009 at 7:25 AM, Rene Rivera <grafikrobot at gmail.com> wrote:
> Matthew Scouten (TT) wrote:
>>
>> I can work with whatever you come up with, but it might convenient if a
>> char* or char[] was treated as a bytes object and a std::string was
>> treated as a string. Thoughts?
>
> A char* can never be fully treated as a bytes object. You must mean a char*
> plus a size_t (or two char* iterator pointers). At which point any
> convenience you think you are getting from treating char* as bytes is gone
> as you have to introduce an intermediate type anyway to put in the "buffer"
> semantics. Hence you are better off with real buffer objects, or equivalents
> thereof. Say a std::pair<char*,char*> iterator range, or std::vector<char>,
> etc.
>

Indeed char* is usually represent a string. For raw buffer there's a
'buffer' type in Python may be suitable in this case. So we would like
to just provide a converter and just let user to specify it if a raw
buffer is required.

-- Haoyu Bai

From meine at informatik.uni-hamburg.de  Wed Mar 18 16:09:16 2009
From: meine at informatik.uni-hamburg.de (Hans Meine)
Date: Wed, 18 Mar 2009 16:09:16 +0100
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
	<32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01>
Message-ID: <200903181609.17445.meine@informatik.uni-hamburg.de>

On Tuesday 17 March 2009 21:23:03 Matthew Scouten (TT) wrote:
> I can work with whatever you come up with, but it might convenient if a
> char* or char[] was treated as a bytes object and a std::string was
> treated as a string. Thoughts?

I would say one cannot see from the type (i.e. std::string, char*, const 
char*, ...) whether it refers to binary data or a string (maybe unsigned char* 
is an exception, which is 'unlikely' to be used for strings).  And even if you 
know that it's a string, that does not help as long as you do not know the 
encoding.

Oh, did I mention "In the face of ambiguity, refuse the temptation to guess."? 
:-)

Thus, I think one must be able to declare (i.e. via policies, as already used 
in the BPL) whether to convert to a bytes object or a string (using a certain 
encoding).

The question whether there are sensible defaults (e.g. convert everything to 
bytes as long as no encoding is given, or use a default encoding for all 
std::strings, ...) is open to discussion.

Have a nice day,
  Hans


From troy at resophonic.com  Wed Mar 18 18:00:19 2009
From: troy at resophonic.com (troy d. straszheim)
Date: Wed, 18 Mar 2009 10:00:19 -0700
Subject: [C++-sig] strange behavior with respect to
	numeric	and	Booleanoverloads
In-Reply-To: <49BFE68E.7090507@resophonic.com>
References: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01><32490DFF7774554A85D65D23A9F0F9380A4C913B@chiex01><7465b6170903162240u29c034b2y8f7d1b95b68301fc@mail.gmail.com>	<200903171103.11258.meine@informatik.uni-hamburg.de>	<32490DFF7774554A85D65D23A9F0F9380A4C933C@chiex01>
	<49BFE68E.7090507@resophonic.com>
Message-ID: <49C128A3.3060108@resophonic.com>

So, this isn't just a bool-int issue, you can get the same thing with 
int and double:

std::string takes_bool(bool b) { return "bool"; } 

std::string takes_int(int b) { return "int"; } 

std::string takes_double(double b) { return "double"; } 

 

BOOST_PYTHON_MODULE(overload_resolution) 

{ 

   def("bid", takes_bool); 

   def("bid", takes_int); 

   def("bid", takes_double);
 

   def("bdi", takes_bool); 

   def("bdi", takes_double); 

   def("bdi", takes_int); 

} 

 

In [11]: its_an_int = 3

In [12]: bid(its_an_int)
Out[12]: 'double'

In [13]: bdi(its_an_int)
Out[13]: 'int'

In [14]: bid(True)
Out[14]: 'double'

The current rule for overload resolution are simply 'first match in 
reverse order of registration'.  You could relatively easily make this 
'first match in forward order of registration'.   The library currently 
has no notion of one function being a better match than another, for a 
given set of arguments.  It looks like it would be interesting enough to 
implement, but it isn't clear what those rules would be or if the 
runtime cost would be worth it.  For instance, this situation:

   void fn_di(double, int);
   void fn_id(int, double);

   def("f", fn_di);
   def("f", fn_id);

   >>> f(3,3)

In C++, of course, that's a compile-time error.  In python, would you 
check all overloads for equally-good matches, and if so, throw some kind 
of ambiguous_function_call exception?

Maybe somebody else has more ideas on this.  I think you could tighten 
up the automatic conversion rules (like the patch below does for int and 
bool), so that one would have to clarify at the call site which function 
you're calling:

   >> f(float(3), 3)

this seems the most practical to me at the moment.  It would break a 
bunch of python code , but by adding casts, the old python code could be 
made to work with boost.python bindings pre- and post- this change.

-t

troy d. straszheim wrote:
> I have a quasi-fix for this to the library itself, (see diff below) 
> buuut it breaks a certain case:  if you have a wrapped c++ function that 
> takes a bool, and you try to pass it an int, you get a
> 
>     ArgumentError: Python argument types in
>         builtin_converters_ext.rewrap_const_reference_bool(int)
>     did not match C++ signature:
>         rewrap_const_reference_bool(bool)
> 
> so you have to call the function with an explicit cast to bool:
> 
> c++:
> 
>   void takes_a_bool(bool b) { ... };
> 
>   def("py_takesbool", takes_a_bool);
> 
> py:
> 
>   py_takesbool(bool(33))
> 
> to get things to work.   This breaks a lot of tests, I'm digging further.
> 
> 
> Index: converter/builtin_converters.cpp
> ===================================================================
> --- converter/builtin_converters.cpp    (revision 51812)
> +++ converter/builtin_converters.cpp    (working copy)
> @@ -99,8 +99,13 @@
>            if (number_methods == 0)
>                return 0;
> 
> -          return (PyInt_Check(obj) || PyLong_Check(obj))
> -              ? &number_methods->nb_int : 0;
> +          return (
> +#if PY_VERSION_HEX >= 0x02040000
> +          !PyBool_Check(obj) &&
> +#endif
> +          (PyInt_Check(obj) || PyLong_Check(obj)))
> +
> +        ? &number_methods->nb_int : 0;
>        }
>        static PyTypeObject const* get_pytype() { return &PyInt_Type;}
>    };
> @@ -135,7 +140,11 @@
>            if (number_methods == 0)
>                return 0;
> 
> -          return (PyInt_Check(obj) || PyLong_Check(obj))
> +          return (
> +#if PY_VERSION_HEX >= 0x02040000
> +          !PyBool_Check(obj) &&
> +#endif
> +          (PyInt_Check(obj) || PyLong_Check(obj)))
>                ? &py_object_identity : 0;
>        }
>        static PyTypeObject const* get_pytype() { return &PyInt_Type;}
> @@ -226,7 +235,11 @@
>    {
>        static unaryfunc* get_slot(PyObject* obj)
>        {
> +#if PY_VERSION_HEX >= 0x02040000
> +    return obj == Py_None || PyBool_Check(obj) ? &py_object_identity : 0;
> +#else
>            return obj == Py_None || PyInt_Check(obj) ? 
> &py_object_identity : 0;
> +#endif
>        }
> 
>        static bool extract(PyObject* intermediate)
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig


From rwgk at yahoo.com  Wed Mar 18 18:30:12 2009
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 18 Mar 2009 10:30:12 -0700 (PDT)
Subject: [C++-sig] strange behavior with respect to numeric and
	Booleanoverloads
In-Reply-To: <49C128A3.3060108@resophonic.com>
References: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01><32490DFF7774554A85D65D23A9F0F9380A4C913B@chiex01><7465b6170903162240u29c034b2y8f7d1b95b68301fc@mail.gmail.com>
	<200903171103.11258.meine@informatik.uni-hamburg.de>
	<32490DFF7774554A85D65D23A9F0F9380A4C933C@chiex01>
	<49BFE68E.7090507@resophonic.com> <49C128A3.3060108@resophonic.com>
Message-ID: <958476.77262.qm@web111411.mail.gq1.yahoo.com>


Very nice analysis of the pros-and-cons!

> Maybe somebody else has more ideas on this.  I think you could tighten
> up the automatic conversion rules (like the > patch below does for
> int and bool), so that one would have to clarify at the call site
> which function you're calling:
> 
>   >> f(float(3), 3)
> 
> this seems the most practical to me at the moment.  It would break a
> bunch of python code , but by adding casts, the old python code could
> be made to work with boost.python bindings pre- and post- this change.

I'm very much in favor of this approach.

BTW:

> The current rule for overload resolution are simply 'first match
> in reverse order of registration'.

The rule is the other way around for constructors.

Ralf

From rwgk at yahoo.com  Wed Mar 18 18:44:46 2009
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 18 Mar 2009 10:44:46 -0700 (PDT)
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <1d7983e80903180753w79210c52gf1aaf7dba745da08@mail.gmail.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
	<32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01>
	<49C03172.108@gmail.com>
	<1d7983e80903180753w79210c52gf1aaf7dba745da08@mail.gmail.com>
Message-ID: <93127.54494.qm@web111408.mail.gq1.yahoo.com>


C++ has wchar_t and std::wstring. Could these be leveraged to avoid ambiguities?
E.g. char, std::string are mapped to py3 byte objects, wchar_t and std::wstring
to py3 str objects.

(Hope this suggestion isn't totally dumb; I have very little experience using
unicode strings.)



----- Original Message ----
From: Haoyu Bai <divinekid at gmail.com>
To: Development of Python/C++ integration <cplusplus-sig at python.org>
Sent: Wednesday, March 18, 2009 7:53:25 AM
Subject: Re: [C++-sig] Some thoughts on py3k support

On Wed, Mar 18, 2009 at 7:25 AM, Rene Rivera <grafikrobot at gmail.com> wrote:
> Matthew Scouten (TT) wrote:
>>
>> I can work with whatever you come up with, but it might convenient if a
>> char* or char[] was treated as a bytes object and a std::string was
>> treated as a string. Thoughts?
>
> A char* can never be fully treated as a bytes object. You must mean a char*
> plus a size_t (or two char* iterator pointers). At which point any
> convenience you think you are getting from treating char* as bytes is gone
> as you have to introduce an intermediate type anyway to put in the "buffer"
> semantics. Hence you are better off with real buffer objects, or equivalents
> thereof. Say a std::pair<char*,char*> iterator range, or std::vector<char>,
> etc.
>

Indeed char* is usually represent a string. For raw buffer there's a
'buffer' type in Python may be suitable in this case. So we would like
to just provide a converter and just let user to specify it if a raw
buffer is required.

-- Haoyu Bai
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig


From seefeld at sympatico.ca  Wed Mar 18 18:52:11 2009
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 18 Mar 2009 13:52:11 -0400
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <93127.54494.qm@web111408.mail.gq1.yahoo.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>	<32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01>	<49C03172.108@gmail.com>	<1d7983e80903180753w79210c52gf1aaf7dba745da08@mail.gmail.com>
	<93127.54494.qm@web111408.mail.gq1.yahoo.com>
Message-ID: <49C134CB.5010206@sympatico.ca>

Ralf W. Grosse-Kunstleve wrote:
> C++ has wchar_t and std::wstring. Could these be leveraged to avoid ambiguities?
> E.g. char, std::string are mapped to py3 byte objects, wchar_t and std::wstring
> to py3 str objects.
>   

I don't quite agree with that suggestion. First, wchar_t doesn't imply 
Unicode (and char doesn't exclude it !). Second, I do want my existing 
string functions (whether they use 'std::string' or 'char const *') to 
keep operating on strings, not byte buffers.
I believe the only way to avoid ambiguities is by allowing / requesting 
users to explicitly set a policy.

Thanks,
       Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...


From divinekid at gmail.com  Wed Mar 18 19:11:43 2009
From: divinekid at gmail.com (Haoyu Bai)
Date: Thu, 19 Mar 2009 02:11:43 +0800
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <49C134CB.5010206@sympatico.ca>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
	<32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01>
	<49C03172.108@gmail.com>
	<1d7983e80903180753w79210c52gf1aaf7dba745da08@mail.gmail.com>
	<93127.54494.qm@web111408.mail.gq1.yahoo.com>
	<49C134CB.5010206@sympatico.ca>
Message-ID: <1d7983e80903181111h7a7e21eeh6bd19931bb64532a@mail.gmail.com>

On Thu, Mar 19, 2009 at 1:52 AM, Stefan Seefeld <seefeld at sympatico.ca> wrote:
> Ralf W. Grosse-Kunstleve wrote:
>>
>> C++ has wchar_t and std::wstring. Could these be leveraged to avoid
>> ambiguities?
>> E.g. char, std::string are mapped to py3 byte objects, wchar_t and
>> std::wstring
>> to py3 str objects.
>>
>
> I don't quite agree with that suggestion. First, wchar_t doesn't imply
> Unicode (and char doesn't exclude it !). Second, I do want my existing
> string functions (whether they use 'std::string' or 'char const *') to keep
> operating on strings, not byte buffers.
> I believe the only way to avoid ambiguities is by allowing / requesting
> users to explicitly set a policy.
>
> Thanks,
> ? ? ?Stefan
>

Yes of course we should allow users to set policy. So the problem is
what the default behavior should be when there is no policy set by
user explicitly. The candidates are:

- raise an error
- convert char* and std::string to/from Python bytes
- convert char* and std::string to/from Python 3 unicode string.

I personally like the last one because it would keep most of the
existing code compatible.

Thanks!

-- Haoyu Bai

From Matthew.Scouten at tradingtechnologies.com  Wed Mar 18 19:15:38 2009
From: Matthew.Scouten at tradingtechnologies.com (Matthew Scouten (TT))
Date: Wed, 18 Mar 2009 13:15:38 -0500
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <1d7983e80903181111h7a7e21eeh6bd19931bb64532a@mail.gmail.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com><32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01><49C03172.108@gmail.com><1d7983e80903180753w79210c52gf1aaf7dba745da08@mail.gmail.com><93127.54494.qm@web111408.mail.gq1.yahoo.com><49C134CB.5010206@sympatico.ca>
	<1d7983e80903181111h7a7e21eeh6bd19931bb64532a@mail.gmail.com>
Message-ID: <32490DFF7774554A85D65D23A9F0F9380A4C98DE@chiex01>

I also like the last one best. I can always explicitly construct a bytes in my ambiguous situations.

-----Original Message-----
From: cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at python.org [mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at python.org] On Behalf Of Haoyu Bai
Sent: Wednesday, March 18, 2009 1:12 PM
To: Development of Python/C++ integration
Subject: Re: [C++-sig] Some thoughts on py3k support

On Thu, Mar 19, 2009 at 1:52 AM, Stefan Seefeld <seefeld at sympatico.ca> wrote:
> Ralf W. Grosse-Kunstleve wrote:
>>
>> C++ has wchar_t and std::wstring. Could these be leveraged to avoid
>> ambiguities?
>> E.g. char, std::string are mapped to py3 byte objects, wchar_t and
>> std::wstring
>> to py3 str objects.
>>
>
> I don't quite agree with that suggestion. First, wchar_t doesn't imply
> Unicode (and char doesn't exclude it !). Second, I do want my existing
> string functions (whether they use 'std::string' or 'char const *') to keep
> operating on strings, not byte buffers.
> I believe the only way to avoid ambiguities is by allowing / requesting
> users to explicitly set a policy.
>
> Thanks,
> ? ? ?Stefan
>

Yes of course we should allow users to set policy. So the problem is
what the default behavior should be when there is no policy set by
user explicitly. The candidates are:

- raise an error
- convert char* and std::string to/from Python bytes
- convert char* and std::string to/from Python 3 unicode string.

I personally like the last one because it would keep most of the
existing code compatible.

Thanks!

-- Haoyu Bai
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

From seefeld at sympatico.ca  Wed Mar 18 19:18:03 2009
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 18 Mar 2009 14:18:03 -0400
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <1d7983e80903181111h7a7e21eeh6bd19931bb64532a@mail.gmail.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>	<32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01>	<49C03172.108@gmail.com>	<1d7983e80903180753w79210c52gf1aaf7dba745da08@mail.gmail.com>	<93127.54494.qm@web111408.mail.gq1.yahoo.com>	<49C134CB.5010206@sympatico.ca>
	<1d7983e80903181111h7a7e21eeh6bd19931bb64532a@mail.gmail.com>
Message-ID: <49C13ADB.6030302@sympatico.ca>

Haoyu Bai wrote:
>
> Yes of course we should allow users to set policy. So the problem is
> what the default behavior should be when there is no policy set by
> user explicitly. The candidates are:
>
> - raise an error
> - convert char* and std::string to/from Python bytes
> - convert char* and std::string to/from Python 3 unicode string.
>
> I personally like the last one because it would keep most of the
> existing code compatible.
>   

I agree.

Thanks,
       Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...


From dave at boostpro.com  Wed Mar 18 20:15:15 2009
From: dave at boostpro.com (David Abrahams)
Date: Wed, 18 Mar 2009 15:15:15 -0400
Subject: [C++-sig] strange behavior with respect to
	numeric	and	Booleanoverloads
In-Reply-To: <49C128A3.3060108@resophonic.com> (troy d. straszheim's message
	of "Wed, 18 Mar 2009 10:00:19 -0700")
References: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01>
	<32490DFF7774554A85D65D23A9F0F9380A4C913B@chiex01>
	<7465b6170903162240u29c034b2y8f7d1b95b68301fc@mail.gmail.com>
	<200903171103.11258.meine@informatik.uni-hamburg.de>
	<32490DFF7774554A85D65D23A9F0F9380A4C933C@chiex01>
	<49BFE68E.7090507@resophonic.com> <49C128A3.3060108@resophonic.com>
Message-ID: <m2ljr2od6k.fsf@boostpro.com>


on Wed Mar 18 2009, "troy d. straszheim" <troy-AT-resophonic.com> wrote:

> The current rule for overload resolution are simply 'first match in reverse order of
> registration'.  You could relatively easily make this 'first match in forward order of
> registration'.   The library currently has no notion of one function being a better
> match than another, for a given set of arguments.  It looks like it would be
> interesting enough to implement, but it isn't clear what those rules would be or if
> the runtime cost would be worth it.  

I think we know what the rules should be; Daniel W. implmented something
like that for Luabind.

> For instance, this situation:
>
>   void fn_di(double, int);
>   void fn_id(int, double);
>
>   def("f", fn_di);
>   def("f", fn_id);
>
>   >>> f(3,3)
>
> In C++, of course, that's a compile-time error.  In python, would you check all
> overloads for equally-good matches, and if so, throw some kind of
> ambiguous_function_call exception?

Probably.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

From rwgk at yahoo.com  Wed Mar 18 23:40:34 2009
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 18 Mar 2009 15:40:34 -0700 (PDT)
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <49C13ADB.6030302@sympatico.ca>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
	<32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01>
	<49C03172.108@gmail.com>
	<1d7983e80903180753w79210c52gf1aaf7dba745da08@mail.gmail.com>
	<93127.54494.qm@web111408.mail.gq1.yahoo.com>
	<49C134CB.5010206@sympatico.ca>
	<1d7983e80903181111h7a7e21eeh6bd19931bb64532a@mail.gmail.com>
	<49C13ADB.6030302@sympatico.ca>
Message-ID: <851329.94932.qm@web111409.mail.gq1.yahoo.com>


I tried the code below with Python 2.x. For a given str or unicode object, it copies the
bytes in memory (char*) to a list of 1-character strings. I'm getting

"hello" =  ['h', 'e', 'l', 'l', 'o']
u"hello" =  ['h', '\x00', 'e', '\x00', 'l', '\x00', 'l', '\x00', 'o', '\x00']
U"hello" =  ['h', '\x00', 'e', '\x00', 'l', '\x00', 'l', '\x00', 'o', '\x00']

on platforms with sizeof(PY_UNICODE_TYPE) = 2 and

"hello" =  ['h', 'e', 'l', 'l', 'o']
u"hello" =  ['h', '\x00', '\x00', '\x00', 'e', '\x00', '\x00', '\x00', 'l', '\x00', '\x00', '\x00', 'l', '\x00', '\x00', '\x00', 'o', '\x00', '\x00', '\x00']
U"hello" =  ['h', '\x00', '\x00', '\x00', 'e', '\x00', '\x00', '\x00', 'l', '\x00', '\x00', '\x00', 'l', '\x00', '\x00', '\x00', 'o', '\x00', '\x00', '\x00']

on platforms with sizeof(PY_UNICODE_TYPE) = 4.

Will the results be different using Python 3?

I have quite a few C++ functions with const char* arguments, expecting one byte per character.

> - convert char* and std::string to/from Python 3 unicode string.

How would this work exactly?
Is the plan to copy the unicode data to a temporary one-byte-per-character buffer?




----- Original Message ----
From: Stefan Seefeld <seefeld at sympatico.ca>
To: Development of Python/C++ integration <cplusplus-sig at python.org>
Sent: Wednesday, March 18, 2009 11:18:03 AM
Subject: Re: [C++-sig] Some thoughts on py3k support

Haoyu Bai wrote:
>
> Yes of course we should allow users to set policy. So the problem is
> what the default behavior should be when there is no policy set by
> user explicitly. The candidates are:
>
> - raise an error
> - convert char* and std::string to/from Python bytes
> - convert char* and std::string to/from Python 3 unicode string.
>
> I personally like the last one because it would keep most of the
> existing code compatible.
>  

I agree.

Thanks,
       Stefan



  boost::python::list
  str_or_unicode_as_char_list(
    boost::python::object const& O)
  {
    PyObject* obj = O.ptr();
    boost::python::ssize_t n;
    const char* c;
    if (PyString_Check(obj)) {
      n = PyString_GET_SIZE(obj);
      c = PyString_AS_STRING(obj);
    }
    else if (PyUnicode_Check(obj)) {
      n = PyUnicode_GET_DATA_SIZE(obj);
      c = PyUnicode_AS_DATA(obj);
    }
    else {
      throw std::invalid_argument("str or unicode object expected.");
    }
    boost::python::list result;
    for(boost::python::ssize_t i=0;i<n;i++) {
      result.append(std::string(c+i, 1u));
    }
    return result;
  }

From s_sourceforge at nedprod.com  Thu Mar 19 01:05:24 2009
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 19 Mar 2009 00:05:24 -0000
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
Message-ID: <49C18C44.4069.1A32860E@s_sourceforge.nedprod.com>

On 18 Mar 2009 at 2:07, Haoyu Bai wrote:

> First thing come into my mind is the build system. For Python 3, we
> would have a separate build target, eg. having libboost_python.so
> built for Python 2.x and libboost_python3.so for Python 3. This would
> match the current situation that most Linux distro packaged Python 3
> in a way that lives together with Python 2.x. There's two build system
> for Boost now - cmake and bjam. Personally I want to start with cmake,
> and finally both of the two will up to date for Python 3.

I'd prefer a slightly different naming convention for the eventual 
case when Boost.Python itself bumps a version. How about this:

libboost_python_py2.so
libboost_python_py3.so

I'd also be happy with (remembering that current Boost.Python is v2):

libboost_python2_py2.so
libboost_python2_py3.so

> I have read some piece of Boost.Python code in these, it is
> understandable for me. And I'd say the usage of template
> metaprogramming is really smart! Thanks to the high level abstraction,
> there would be just a little code interfaced to Python C-API directly.
> So there would not be so much works.

Hmm, we'll see. It's much trickier than you might think.

> However there are something we need to take care of. One of them is,
> in Python 3, string is unicode (and the old string class is called
> bytes in Python 3). So if we have a C function
> 
> char const* hello(); // returns a "Hello"
> 
> According to the current behavior of Boost.Python converters, the
> wrapped function in Python 3 will return a b"Hello" (which is a bytes
> object but not a string). So code like this will broken:
> 
> if "Hello" == hello(): ...
> 
> Because string object "Hello" is not equal to bytes object b"Hello"
> returned by hello(). We may change the behavior of converter to return
> a unicode string in Python 3, that would keep most of existing code
> compatible. Anyway there will be code really need a single byte string
> returned, a new converter can be explicitly specified for this.

One shouldn't be doing such a comparison anyway IMHO, though the 
idiom of equivalence between C++ immutable strings and python 
immutable strings is long-standing. Also, we need to fix booleans not 
working quite properly in BPL.

> There are more issues similar to this. I'll figure out more and write
> a detailed proposal as soon as possible.

I have my own opinion on unicode and judging by the other posts, I'll 
be disagreeing with just about everyone else.

Firstly, I'd like to state that Python v3 has ditched the old string 
system for very good reasons and this change more than any other has 
created source incompatibilites in most code. One cannot expect much 
difference in Boost.Python - code *should* need to be explicitly 
ported.

Much like the open() function with text (and reusing its machinery), 
I propose you need to specify the *default* encoding for immutable 
const char * though it defaults from LC_LANG in most cases to UTF-8 - 
that's right, const char * will be UTF-8 by default though it's 
overridable. This default encoding should be a per-python interpreter 
setting (i.e. it uses whatever open() uses) though it can be 
temporarily overridden using a specifier template.

const unsigned char * looks better to me for immutable byte data - I 
agree that some compilers have the option for char * == unsigned char 
*, but these are rare and it's an unwise option in most cases.

std::vector<unsigned char> is definitely the fellow for mutable byte 
data. std::vector<char> smells too much like a mutable string.

I appreciate that const char * defaulting to UTF-8 might be 
controversial - after all, ISO C++ has remained very agnostic about 
the matter (see http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm for a proposed 
slight change). I have rationales though:

1. While unicode in C++ source anywhere other than in string literals 
is a very bad idea, both MSVC and GCC support having the entire 
source file in UTF-8 text and unicode characters in string literals 
being incorporated as-is. This method of incorporating non-European 
letters into string literals is too easy to avoid using ;). It's 
certainly very common in Asia and until the u8 literal specifier is 
added to C++ there isn't an easy workaround. It wouldn't be very open 
minded of us to assume the world can still easily make do with ASCII-
7.

2. A *lot* of library code e.g. GUI library code, most of Linux or 
indeed the GNU C library, has moved to UTF-8 for its string literals. 
Interfacing strings between BPL and this library code is made much 
easier and natural if it takes UTF-8 as default.

3. "char *" in C and C++ means "a string" in the minds of most 
programmers. Having it be a set of bytes might be standards correct 
but let's be clear, C style strings have always had escape sequences 
so they have never been entirely pure byte sequences. Making this 
immutable bytes instead will make BPL unnatural to use - expect 
questions here on c++-sig :)

4. Chances are that world + dog is going to move to UTF-8 eventually 
anyway and that means all C++ source code. Might as well make that 
the least typing required scenario.

Anyway, I expect few will agree with me, but that's my opinion.

Cheers,
Niall




From divinekid at gmail.com  Thu Mar 19 09:02:35 2009
From: divinekid at gmail.com (Haoyu Bai)
Date: Thu, 19 Mar 2009 16:02:35 +0800
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <851329.94932.qm@web111409.mail.gq1.yahoo.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
	<32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01>
	<49C03172.108@gmail.com>
	<1d7983e80903180753w79210c52gf1aaf7dba745da08@mail.gmail.com>
	<93127.54494.qm@web111408.mail.gq1.yahoo.com>
	<49C134CB.5010206@sympatico.ca>
	<1d7983e80903181111h7a7e21eeh6bd19931bb64532a@mail.gmail.com>
	<49C13ADB.6030302@sympatico.ca>
	<851329.94932.qm@web111409.mail.gq1.yahoo.com>
Message-ID: <1d7983e80903190102mb617ef2u349e8343793e58d6@mail.gmail.com>

On Thu, Mar 19, 2009 at 6:40 AM, Ralf W. Grosse-Kunstleve
<rwgk at yahoo.com> wrote:
>
> I tried the code below with Python 2.x. For a given str or unicode object, it copies the
> bytes in memory (char*) to a list of 1-character strings. I'm getting
>
> "hello" = ?['h', 'e', 'l', 'l', 'o']
> u"hello" = ?['h', '\x00', 'e', '\x00', 'l', '\x00', 'l', '\x00', 'o', '\x00']
> U"hello" = ?['h', '\x00', 'e', '\x00', 'l', '\x00', 'l', '\x00', 'o', '\x00']
>
> on platforms with sizeof(PY_UNICODE_TYPE) = 2 and
>
> "hello" = ?['h', 'e', 'l', 'l', 'o']
> u"hello" = ?['h', '\x00', '\x00', '\x00', 'e', '\x00', '\x00', '\x00', 'l', '\x00', '\x00', '\x00', 'l', '\x00', '\x00', '\x00', 'o', '\x00', '\x00', '\x00']
> U"hello" = ?['h', '\x00', '\x00', '\x00', 'e', '\x00', '\x00', '\x00', 'l', '\x00', '\x00', '\x00', 'l', '\x00', '\x00', '\x00', 'o', '\x00', '\x00', '\x00']
>
> on platforms with sizeof(PY_UNICODE_TYPE) = 4.
>
> Will the results be different using Python 3?

The result in Python 3 will be:

"hello" =  ['h', '\x00', 'e', '\x00', 'l', '\x00', 'l', '\x00', 'o', '\x00']
b"hello" =  ['h', 'e', 'l', 'l', 'o']

and u"hello" is invalid by then.

>
> I have quite a few C++ functions with const char* arguments, expecting one byte per character.
>
>> - convert char* and std::string to/from Python 3 unicode string.
>
> How would this work exactly?
> Is the plan to copy the unicode data to a temporary one-byte-per-character buffer?
>

Of course the default converter policy we planed is not to convert to
raw data buffer from unicode object via PyUnicode_AS_DATA(). The C-API
such as PyUnicode_AsUTF8String() and PyUnicode_AsEncodedString() will
be used to convert unicode to bytes and then convert to char* and
passed to your C++ function.

By default we would use PyUnicode_AsUTF8String(), and encoding could
be explicitly specified by a converter policy. That may keep most of
your code compatible.

Thanks!

-- Haoyu Bai

From divinekid at gmail.com  Thu Mar 19 14:53:35 2009
From: divinekid at gmail.com (Haoyu Bai)
Date: Thu, 19 Mar 2009 21:53:35 +0800
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <49C18C44.4069.1A32860E@s_sourceforge.nedprod.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
	<49C18C44.4069.1A32860E@s_sourceforge.nedprod.com>
Message-ID: <1d7983e80903190653j4340b4a0u6044e5015ab300c0@mail.gmail.com>

On Thu, Mar 19, 2009 at 8:05 AM, Niall Douglas
<s_sourceforge at nedprod.com> wrote:
> On 18 Mar 2009 at 2:07, Haoyu Bai wrote:
>
> I'd prefer a slightly different naming convention for the eventual
> case when Boost.Python itself bumps a version. How about this:
>
> libboost_python_py2.so
> libboost_python_py3.so
>
> I'd also be happy with (remembering that current Boost.Python is v2):
>
> libboost_python2_py2.so
> libboost_python2_py3.so
>

This naming style is a bit more clear but broken user's build scripts
- not a big problem though. But when all the Python community evolved
to py3k, and 2.x come into history, should we change the name back
from libboost_python_py3.so to libboost_python.so?

>
> I have my own opinion on unicode and judging by the other posts, I'll
> be disagreeing with just about everyone else.
>
> Firstly, I'd like to state that Python v3 has ditched the old string
> system for very good reasons and this change more than any other has
> created source incompatibilites in most code. One cannot expect much
> difference in Boost.Python - code *should* need to be explicitly
> ported.
>
> Much like the open() function with text (and reusing its machinery),
> I propose you need to specify the *default* encoding for immutable
> const char * though it defaults from LC_LANG in most cases to UTF-8 -
> that's right, const char * will be UTF-8 by default though it's
> overridable. This default encoding should be a per-python interpreter
> setting (i.e. it uses whatever open() uses) though it can be
> temporarily overridden using a specifier template.
>
> const unsigned char * looks better to me for immutable byte data - I
> agree that some compilers have the option for char * == unsigned char
> *, but these are rare and it's an unwise option in most cases.
>
> std::vector<unsigned char> is definitely the fellow for mutable byte
> data. std::vector<char> smells too much like a mutable string.
>
> I appreciate that const char * defaulting to UTF-8 might be
> controversial - after all, ISO C++ has remained very agnostic about
> the matter (see http://www.open-
> std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm for a proposed
> slight change). I have rationales though:
>
> 1. While unicode in C++ source anywhere other than in string literals
> is a very bad idea, both MSVC and GCC support having the entire
> source file in UTF-8 text and unicode characters in string literals
> being incorporated as-is. This method of incorporating non-European
> letters into string literals is too easy to avoid using ;). It's
> certainly very common in Asia and until the u8 literal specifier is
> added to C++ there isn't an easy workaround. It wouldn't be very open
> minded of us to assume the world can still easily make do with ASCII-
> 7.
>
> 2. A *lot* of library code e.g. GUI library code, most of Linux or
> indeed the GNU C library, has moved to UTF-8 for its string literals.
> Interfacing strings between BPL and this library code is made much
> easier and natural if it takes UTF-8 as default.
>
> 3. "char *" in C and C++ means "a string" in the minds of most
> programmers. Having it be a set of bytes might be standards correct
> but let's be clear, C style strings have always had escape sequences
> so they have never been entirely pure byte sequences. Making this
> immutable bytes instead will make BPL unnatural to use - expect
> questions here on c++-sig :)
>
> 4. Chances are that world + dog is going to move to UTF-8 eventually
> anyway and that means all C++ source code. Might as well make that
> the least typing required scenario.
>
> Anyway, I expect few will agree with me, but that's my opinion.
>
> Cheers,
> Niall
>

Would you mean for converting between char * and Python, we may use
the encoding as same as Python interpreter's default encoding, which
can be get by sys.getdefaultencoding() in Python? Or let user to
choose default encoding for their extension module via Boost.Python
API? I'd say either of these is very flexiable. Nice idea!

Also I think to use the same default encoding as Python's
sys.getdefaultencoding() it a bit better since it provides a
unification in the whole Python environment. And it is configurable as
Python's startup by sys.setdefaultencoding().

I'm felling the difference between char*, unsinged char* and the
constant version and std::vector version of them would be a bit
complicated and confusing. We may document it clearly, but things are
still complicated. Any thoughts?

Thanks!

-- Haoyu Bai

From seefeld at sympatico.ca  Thu Mar 19 14:57:27 2009
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 19 Mar 2009 09:57:27 -0400
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <1d7983e80903190653j4340b4a0u6044e5015ab300c0@mail.gmail.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>	<49C18C44.4069.1A32860E@s_sourceforge.nedprod.com>
	<1d7983e80903190653j4340b4a0u6044e5015ab300c0@mail.gmail.com>
Message-ID: <49C24F47.7060708@sympatico.ca>

Haoyu Bai wrote:
>
> This naming style is a bit more clear but broken user's build scripts
> - not a big problem though. But when all the Python community evolved
> to py3k, and 2.x come into history, should we change the name back
> from libboost_python_py3.so to libboost_python.so?
>   

Can we postpone this question for another ten or so years ? :-)

Regards,
       Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...


From renatox at gmail.com  Thu Mar 19 15:34:54 2009
From: renatox at gmail.com (Renato Araujo)
Date: Thu, 19 Mar 2009 11:34:54 -0300
Subject: [C++-sig] Protected virtual Functions with default implementation
Message-ID: <95291a80903190734y6b678d24j23319dd01614e186@mail.gmail.com>

Hi guys, I'm working again in my bindings generation and I get a new
question about virtual functions.

I would like to know how export protected virtual functions with
default implementation, because I didn't find any documentation about
this and the code generated by Py++ not work in all cases.

I have attached the test case on this e-mail, if someone would like to
try my implementation.

BR

-- 
Renato Araujo Oliveira Filho
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boosttest.tar
Type: application/x-tar
Size: 20480 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090319/67a24c33/attachment-0001.tar>

From chrandr at binf.ku.dk  Thu Mar 19 16:17:07 2009
From: chrandr at binf.ku.dk (Christian Andreetta)
Date: Thu, 19 Mar 2009 16:17:07 +0100
Subject: [C++-sig] pyplusplus (pygccxml) bug: enumeration class
Message-ID: <300f68560903190817k346bb76cr5fe88e32e24c44d3@mail.gmail.com>

Hi all!

Noob question: I'm not familiar with neither boost.python nor with the
python c-api, so I tried pyplusplus on a stl library I need to
interface from python (this library is quite a good example of
templating, casting and overloading, and I would rather avoid doing it
manually ;) )
Issue: running pyplusplus_gui, the button "generate code" returns the
error " 'enumeration_t' object has no attribute 'clone' ", which I
guess is a pygccxml issue in the enumeration_t(declaration_t) class.

The other gui actions ("generate py++ code" and "create xml") are
working seamlessly, so I guess that includes and dependencies are
satisfied and happy :)
boost.python should be correctly installed and built as well: no
problems with small class interfaces.

in case a test is needed:

1) check out the svn mocapy library from sourceforge: # svn co
https://mocapy.svn.sourceforge.net/svnroot/mocapy .
2) run pyplusplus_gui on the top-level header "Mocapy/src/mocapy.h"

Thanks!
--
Christian

From rwgk at yahoo.com  Thu Mar 19 17:07:22 2009
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 19 Mar 2009 09:07:22 -0700 (PDT)
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <1d7983e80903190102mb617ef2u349e8343793e58d6@mail.gmail.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
	<32490DFF7774554A85D65D23A9F0F9380A4C95C9@chiex01>
	<49C03172.108@gmail.com>
	<1d7983e80903180753w79210c52gf1aaf7dba745da08@mail.gmail.com>
	<93127.54494.qm@web111408.mail.gq1.yahoo.com>
	<49C134CB.5010206@sympatico.ca>
	<1d7983e80903181111h7a7e21eeh6bd19931bb64532a@mail.gmail.com>
	<49C13ADB.6030302@sympatico.ca>
	<851329.94932.qm@web111409.mail.gq1.yahoo.com>
	<1d7983e80903190102mb617ef2u349e8343793e58d6@mail.gmail.com>
Message-ID: <316619.56135.qm@web111403.mail.gq1.yahoo.com>


> Of course the default converter policy we planed is not to convert to

> raw data buffer from unicode object via PyUnicode_AS_DATA(). The C-API
> such as PyUnicode_AsUTF8String() and PyUnicode_AsEncodedString() will
> be used to convert unicode to bytes and then convert to char* and
> passed to your C++ function.
>
> By default we would use PyUnicode_AsUTF8String(), and encoding could
> be explicitly specified by a converter policy. That may keep most of
> your code compatible.

Thanks!
It means though that one has to think more about runtime overhead. Sigh.
Ralf

From rwgk at yahoo.com  Thu Mar 19 17:10:39 2009
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 19 Mar 2009 09:10:39 -0700 (PDT)
Subject: [C++-sig] strange behavior with respect to numeric and
	Booleanoverloads
In-Reply-To: <m2ljr2od6k.fsf@boostpro.com>
References: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01>
	<32490DFF7774554A85D65D23A9F0F9380A4C913B@chiex01>
	<7465b6170903162240u29c034b2y8f7d1b95b68301fc@mail.gmail.com>
	<200903171103.11258.meine@informatik.uni-hamburg.de>
	<32490DFF7774554A85D65D23A9F0F9380A4C933C@chiex01>
	<49BFE68E.7090507@resophonic.com>
	<49C128A3.3060108@resophonic.com> <m2ljr2od6k.fsf@boostpro.com>
Message-ID: <191399.71254.qm@web111407.mail.gq1.yahoo.com>


The comprehensive solution sounds like a project. Do we have someone to work on this?

I'm asking because I think Troy's proposed simple solution is better than the status quo.



----- Original Message ----
From: David Abrahams <dave at boostpro.com>
To: Development of Python/C++ integration <cplusplus-sig at python.org>
Sent: Wednesday, March 18, 2009 12:15:15 PM
Subject: Re: [C++-sig] strange behavior with respect to numeric and Booleanoverloads


on Wed Mar 18 2009, "troy d. straszheim" <troy-AT-resophonic.com> wrote:

> The current rule for overload resolution are simply 'first match in reverse order of
> registration'.  You could relatively easily make this 'first match in forward order of
> registration'.   The library currently has no notion of one function being a better
> match than another, for a given set of arguments.  It looks like it would be
> interesting enough to implement, but it isn't clear what those rules would be or if
> the runtime cost would be worth it.  

I think we know what the rules should be; Daniel W. implmented something
like that for Luabind.

> For instance, this situation:
>
>   void fn_di(double, int);
>   void fn_id(int, double);
>
>   def("f", fn_di);
>   def("f", fn_id);
>
>   >>> f(3,3)
>
> In C++, of course, that's a compile-time error.  In python, would you check all
> overloads for equally-good matches, and if so, throw some kind of
> ambiguous_function_call exception?

Probably.

From divinekid at gmail.com  Thu Mar 19 17:20:47 2009
From: divinekid at gmail.com (Haoyu Bai)
Date: Fri, 20 Mar 2009 00:20:47 +0800
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <316619.56135.qm@web111403.mail.gq1.yahoo.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
	<49C03172.108@gmail.com>
	<1d7983e80903180753w79210c52gf1aaf7dba745da08@mail.gmail.com>
	<93127.54494.qm@web111408.mail.gq1.yahoo.com>
	<49C134CB.5010206@sympatico.ca>
	<1d7983e80903181111h7a7e21eeh6bd19931bb64532a@mail.gmail.com>
	<49C13ADB.6030302@sympatico.ca>
	<851329.94932.qm@web111409.mail.gq1.yahoo.com>
	<1d7983e80903190102mb617ef2u349e8343793e58d6@mail.gmail.com>
	<316619.56135.qm@web111403.mail.gq1.yahoo.com>
Message-ID: <1d7983e80903190920q56c34723o7cddbab3d4a70e56@mail.gmail.com>

On Fri, Mar 20, 2009 at 12:07 AM, Ralf W. Grosse-Kunstleve
<rwgk at yahoo.com> wrote:
>
>> Of course the default converter policy we planed is not to convert to
>
>> raw data buffer from unicode object via PyUnicode_AS_DATA(). The C-API
>> such as PyUnicode_AsUTF8String() and PyUnicode_AsEncodedString() will
>> be used to convert unicode to bytes and then convert to char* and
>> passed to your C++ function.
>>
>> By default we would use PyUnicode_AsUTF8String(), and encoding could
>> be explicitly specified by a converter policy. That may keep most of
>> your code compatible.
>
> Thanks!
> It means though that one has to think more about runtime overhead. Sigh.
> Ralf

Yes unicode string can't faster than raw string. However one can use
the bytes object while regarding to performance.

-- Haoyu Bai

From meine at informatik.uni-hamburg.de  Thu Mar 19 17:36:20 2009
From: meine at informatik.uni-hamburg.de (Hans Meine)
Date: Thu, 19 Mar 2009 17:36:20 +0100
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <1d7983e80903190102mb617ef2u349e8343793e58d6@mail.gmail.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
	<851329.94932.qm@web111409.mail.gq1.yahoo.com>
	<1d7983e80903190102mb617ef2u349e8343793e58d6@mail.gmail.com>
Message-ID: <200903191736.21560.meine@informatik.uni-hamburg.de>

On Thursday 19 March 2009 09:02:35 Haoyu Bai wrote:
> By default we would use PyUnicode_AsUTF8String(), and encoding could
> be explicitly specified by a converter policy. That may keep most of
> your code compatible.

Please do *not* hard-code UTF-8.  At least, if you need to guess a default, 
use some system (locale) setting, similar to sys.stdout.encoding or 
sys.getfilesystemencoding().  Personally, I would prefer to have to specify 
the encoding somewhere in the BPL exporting code.

Thinking about it, it might even be necessary to determine the encoding at 
*runtime*, depending on the wrapped code/library. :-(

Have a nice day,
  Hans

From Matthew.Scouten at tradingtechnologies.com  Thu Mar 19 17:41:49 2009
From: Matthew.Scouten at tradingtechnologies.com (Matthew Scouten (TT))
Date: Thu, 19 Mar 2009 11:41:49 -0500
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <200903191736.21560.meine@informatik.uni-hamburg.de>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com><851329.94932.qm@web111409.mail.gq1.yahoo.com><1d7983e80903190102mb617ef2u349e8343793e58d6@mail.gmail.com>
	<200903191736.21560.meine@informatik.uni-hamburg.de>
Message-ID: <32490DFF7774554A85D65D23A9F0F9380A4C9D36@chiex01>

Ok, Fine. But I want the ability to specify an encoding ONCE and have 
use that unless I change it or override a specific conversion. I also 
want there to be a reasonable default so that if I forget to specify 
anything, it will work for the majority of cases.

-----Original Message-----
From:
cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at python.org
[mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at py
thon.org] On Behalf Of Hans Meine
Sent: Thursday, March 19, 2009 11:36 AM
To: cplusplus-sig at python.org
Subject: Re: [C++-sig] Some thoughts on py3k support

On Thursday 19 March 2009 09:02:35 Haoyu Bai wrote:
> By default we would use PyUnicode_AsUTF8String(), and encoding could
> be explicitly specified by a converter policy. That may keep most of
> your code compatible.

Please do *not* hard-code UTF-8.  At least, if you need to guess a
default, 
use some system (locale) setting, similar to sys.stdout.encoding or 
sys.getfilesystemencoding().  Personally, I would prefer to have to
specify 
the encoding somewhere in the BPL exporting code.

Thinking about it, it might even be necessary to determine the encoding
at 
*runtime*, depending on the wrapped code/library. :-(

Have a nice day,
  Hans
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

From s_sourceforge at nedprod.com  Thu Mar 19 17:51:21 2009
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 19 Mar 2009 16:51:21 -0000
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <1d7983e80903190920q56c34723o7cddbab3d4a70e56@mail.gmail.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>,
	<316619.56135.qm@web111403.mail.gq1.yahoo.com>,
	<1d7983e80903190920q56c34723o7cddbab3d4a70e56@mail.gmail.com>
Message-ID: <49C27809.9126.1DCB7D15@s_sourceforge.nedprod.com>

On 20 Mar 2009 at 0:20, Haoyu Bai wrote:

> Yes unicode string can't faster than raw string. However one can use
> the bytes object while regarding to performance.

I took from reading the py3k docs that strings are now always held 
internally as utf-8?

On that assumption I proposed the treating of C++ string literals as 
utf-8 as in there would be no parsing or translation required in the 
usual case.

Cheers,
Niall




From s_sourceforge at nedprod.com  Thu Mar 19 17:51:21 2009
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 19 Mar 2009 16:51:21 -0000
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <1d7983e80903190653j4340b4a0u6044e5015ab300c0@mail.gmail.com>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>,
	<49C18C44.4069.1A32860E@s_sourceforge.nedprod.com>,
	<1d7983e80903190653j4340b4a0u6044e5015ab300c0@mail.gmail.com>
Message-ID: <49C27809.3055.1DCB7DA2@s_sourceforge.nedprod.com>

On 19 Mar 2009 at 21:53, Haoyu Bai wrote:

> This naming style is a bit more clear but broken user's build scripts
> - not a big problem though. But when all the Python community evolved
> to py3k, and 2.x come into history, should we change the name back
> from libboost_python_py3.so to libboost_python.so?

Well in my own opinion every single library revision should have its 
own unique filename - makes it much harder to have unintentional 
problems due to ABI changes you see. It's not like anyone usually 
needs to type out any library filename by hand (or if they do, 
hitting Tab fixes it). And I personally don't mind breaking people's 
build scripts when it's for their own good! :)

> Would you mean for converting between char * and Python, we may use
> the encoding as same as Python interpreter's default encoding, which
> can be get by sys.getdefaultencoding() in Python? Or let user to
> choose default encoding for their extension module via Boost.Python
> API? I'd say either of these is very flexiable. Nice idea!

I didn't make myself clear with that post - thanks to a fourteen hour 
day yesterday during which I taught for two hours, created and gave a 
presentation on business process modelling and sat a two hour exam. 
But yes, I did mean that const char * is treated as whatever 
sys.getdefaultencoding() is unless specifically overridden by a 
template parameter specifier.

> Also I think to use the same default encoding as Python's
> sys.getdefaultencoding() it a bit better since it provides a
> unification in the whole Python environment. And it is configurable as
> Python's startup by sys.setdefaultencoding().

Indeed - I was trying to convey the notion that as Python changes we 
must change too.

> I'm felling the difference between char*, unsinged char* and the
> constant version and std::vector version of them would be a bit
> complicated and confusing. We may document it clearly, but things are
> still complicated. Any thoughts?

Well, the whole concept of BPL is that it is extensible via overload 
and partial specialisation. One might provide these as default out-of-
the-box but any client code is more than free to add their own type 
specialisations. The only actual concern is whether my proposed 
overloads are a bit too generic and might interfere with client code, 
but then that's why we have namespaces with Koenig lookup.

I should add that this philosophical difference is why I am not a 
Booster - I strongly feel that utility and power lies within flexible 
structure rather than simple abstraction. This is why I went off and 
wrote my own integrated metaprogramming library in TnFOX rather than 
use Boost's - I was more than happy to sacrifice support for non-
compliant C++ compilers in return for vastly cleaner and more 
powerful code. That said, as we are contributing towards BPL, I will 
be sticking my philosophical hat into a drawer for the duration :)

Cheers,
Niall




From meine at informatik.uni-hamburg.de  Thu Mar 19 20:25:36 2009
From: meine at informatik.uni-hamburg.de (Hans Meine)
Date: Thu, 19 Mar 2009 20:25:36 +0100
Subject: [C++-sig] Some thoughts on py3k support
In-Reply-To: <32490DFF7774554A85D65D23A9F0F9380A4C9D36@chiex01>
References: <1d7983e80903171107m490ed2b2vd26cfae8e3bae853@mail.gmail.com>
	<200903191736.21560.meine@informatik.uni-hamburg.de>
	<32490DFF7774554A85D65D23A9F0F9380A4C9D36@chiex01>
Message-ID: <200903192025.38618.meine@informatik.uni-hamburg.de>

On Donnerstag 19 M?rz 2009, Matthew Scouten (TT) wrote:
> Ok, Fine. But I want the ability to specify an encoding ONCE and have
> use that unless I change it or override a specific conversion.

I would want such a thing, too.  (Assuming that all 8-bit strings *do* use the 
same encoding, which will be true in most, but not all cases - just as an 
example, ID3v2 tags come to my mind.)

> I also 
> want there to be a reasonable default so that if I forget to specify
> anything, it will work for the majority of cases.

I don't think this can be done.  "The majority" has used ASCII in the past, 
then latin-1, then (maybe) latin-15, now *maybe* UTF-8 (probably not yet, 
e.g. I am still using latin1).

Whatever.  My worries are probably not very constructive; I just wanted to 
prevent the same mistake made all those decades (assuming a specific, single, 
non-unicode encoding) be made again, several years into the third millenium.

OTOH, it will necessarily still be up to each and every programmer to care 
about the *correct* conversions in his/her program (/BPL extension module).

Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090319/4993afe3/attachment.pgp>

From troy at resophonic.com  Thu Mar 19 20:27:56 2009
From: troy at resophonic.com (troy d. straszheim)
Date: Thu, 19 Mar 2009 12:27:56 -0700
Subject: [C++-sig] strange behavior with respect to numeric
	and	Booleanoverloads
In-Reply-To: <191399.71254.qm@web111407.mail.gq1.yahoo.com>
References: <32490DFF7774554A85D65D23A9F0F9380A42B084@chiex01>	<32490DFF7774554A85D65D23A9F0F9380A4C913B@chiex01>	<7465b6170903162240u29c034b2y8f7d1b95b68301fc@mail.gmail.com>	<200903171103.11258.meine@informatik.uni-hamburg.de>	<32490DFF7774554A85D65D23A9F0F9380A4C933C@chiex01>	<49BFE68E.7090507@resophonic.com>	<49C128A3.3060108@resophonic.com>
	<m2ljr2od6k.fsf@boostpro.com>
	<191399.71254.qm@web111407.mail.gq1.yahoo.com>
Message-ID: <49C29CBC.4010006@resophonic.com>

Ralf W. Grosse-Kunstleve wrote:
> The comprehensive solution sounds like a project. Do we have someone to work on this?
> 
> I'm asking because I think Troy's proposed simple solution is better than the status quo.
> 

I'm willing to work on it.  I'd have to look at Daniel W's code to see 
if I want to push back on the simple solution or not... haven't done 
that yet.  Maybe we want to get Haoyu thinking about this in the 
background, as well, he might be done with py3k support before the end 
of the gsoc summer.

-t



From renatox at gmail.com  Fri Mar 20 17:46:57 2009
From: renatox at gmail.com (Renato Araujo)
Date: Fri, 20 Mar 2009 13:46:57 -0300
Subject: [C++-sig] gcc flag -fvisibility=hidden not working with
	boost::python
Message-ID: <95291a80903200946q5ce4b22co5e7a8b403cc5eb41@mail.gmail.com>

Hi,

I have worked with some gcc flags to reduce my binding size. After
some time using this -fvisibility=hidden with my library, I discovered
a strange behavior on boost::python more specific in object call
function like this:

python::call_method<void>(py_obj.ptr(), "myVirtualFunction");

The problem is: When I use this flag boost always call my "virtual
default" implementation and without this flag boost always call the
correct virtual method, I don't know what this is happening. I would
like to know if someone has any idea why this is happening?

I create this small test to show the problem. This flags is very
important for me because I got size reduction about 50% with this.

Thanks

-- 
Renato Araujo Oliveira Filho
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boosttest_visibility.tar
Type: application/x-tar
Size: 20480 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090320/0a83205f/attachment-0001.tar>

From s_sourceforge at nedprod.com  Sat Mar 21 21:38:59 2009
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 21 Mar 2009 20:38:59 -0000
Subject: [C++-sig] gcc flag -fvisibility=hidden not working with
	boost::python
In-Reply-To: <95291a80903200946q5ce4b22co5e7a8b403cc5eb41@mail.gmail.com>
References: <95291a80903200946q5ce4b22co5e7a8b403cc5eb41@mail.gmail.com>
Message-ID: <49C55063.9361.28E89E2C@s_sourceforge.nedprod.com>

On 20 Mar 2009 at 13:46, Renato Araujo wrote:

> I have worked with some gcc flags to reduce my binding size. After
> some time using this -fvisibility=hidden with my library, I discovered
> a strange behavior on boost::python more specific in object call
> function like this:
> 
> python::call_method<void>(py_obj.ptr(), "myVirtualFunction");
> 
> The problem is: When I use this flag boost always call my "virtual
> default" implementation and without this flag boost always call the
> correct virtual method, I don't know what this is happening. I would
> like to know if someone has any idea why this is happening?
> 
> I create this small test to show the problem. This flags is very
> important for me because I got size reduction about 50% with this.

You're not annotating your wrapper class correctly.

See http://www.nedprod.com/programs/gccvisibility.html.

Cheers,
Niall




From renatox at gmail.com  Sun Mar 22 16:36:17 2009
From: renatox at gmail.com (Renato Araujo)
Date: Sun, 22 Mar 2009 12:36:17 -0300
Subject: [C++-sig] gcc flag -fvisibility=hidden not working with
	boost::python
In-Reply-To: <49C55063.9361.28E89E2C@s_sourceforge.nedprod.com>
References: <95291a80903200946q5ce4b22co5e7a8b403cc5eb41@mail.gmail.com>
	<49C55063.9361.28E89E2C@s_sourceforge.nedprod.com>
Message-ID: <95291a80903220836p3ef0b1a8w320d3adf2a329fc0@mail.gmail.com>

Thanks for the link, I tried a lot of combinations but nothing works
Then I started looking in boost for the header where I got the error,
then I found the header but I don't know why this happen. I fix the
problem with:

#pragma GCC visibility push(default)
#include <boost/python/call.hpp>
#pragma GCC visibility pop
#include <boost/python.hpp>


You can try this only changing the "foo/python_headers.h" file in my
previous example.

I don't know if this is the correct way to fix this. Someone can talk about?


BR


On Sat, Mar 21, 2009 at 5:38 PM, Niall Douglas
<s_sourceforge at nedprod.com> wrote:
> On 20 Mar 2009 at 13:46, Renato Araujo wrote:
>
>> I have worked with some gcc flags to reduce my binding size. After
>> some time using this -fvisibility=hidden with my library, I discovered
>> a strange behavior on boost::python more specific in object call
>> function like this:
>>
>> python::call_method<void>(py_obj.ptr(), "myVirtualFunction");
>>
>> The problem is: When I use this flag boost always call my "virtual
>> default" implementation and without this flag boost always call the
>> correct virtual method, I don't know what this is happening. I would
>> like to know if someone has any idea why this is happening?
>>
>> I create this small test to show the problem. This flags is very
>> important for me because I got size reduction about 50% with this.
>
> You're not annotating your wrapper class correctly.
>
> See http://www.nedprod.com/programs/gccvisibility.html.
>
> Cheers,
> Niall
>
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>



-- 
Renato Araujo Oliveira Filho

From roman.yakovenko at gmail.com  Mon Mar 23 09:57:11 2009
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Mon, 23 Mar 2009 10:57:11 +0200
Subject: [C++-sig] Protected virtual Functions with default
	implementation
In-Reply-To: <95291a80903190734y6b678d24j23319dd01614e186@mail.gmail.com>
References: <95291a80903190734y6b678d24j23319dd01614e186@mail.gmail.com>
Message-ID: <7465b6170903230157o5808c83dqe87b37cd361d9226@mail.gmail.com>

2009/3/19 Renato Araujo <renatox at gmail.com>:
> Hi guys, I'm working again in my bindings generation and I get a new
> question about virtual functions.
>
> I would like to know how export protected virtual functions with
> default implementation, because I didn't find any documentation about
> this and the code generated by Py++ not work in all cases.
>
> I have attached the test case on this e-mail, if someone would like to
> try my implementation.

Do you mind to be more specific?

Can you show the original source code, the generated one and the
"right\desired" one?

Thanks

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

From renatox at gmail.com  Mon Mar 23 15:42:20 2009
From: renatox at gmail.com (Renato Araujo)
Date: Mon, 23 Mar 2009 11:42:20 -0300
Subject: [C++-sig] gcc flag -fvisibility=hidden not working with
	boost::python
In-Reply-To: <95291a80903220836p3ef0b1a8w320d3adf2a329fc0@mail.gmail.com>
References: <95291a80903200946q5ce4b22co5e7a8b403cc5eb41@mail.gmail.com>
	<49C55063.9361.28E89E2C@s_sourceforge.nedprod.com>
	<95291a80903220836p3ef0b1a8w320d3adf2a329fc0@mail.gmail.com>
Message-ID: <95291a80903230742u4c2f0169k57d351174c44e233@mail.gmail.com>

For more details about the problem, I found the correct header witch
give me this problem, and isolate that with this:

#include <boost/python/detail/prefix.hpp>
# include <boost/type_traits/is_polymorphic.hpp>
# include <boost/mpl/bool.hpp>

#pragma GCC visibility push(default)
#include <boost/python/detail/wrapper_base.hpp>
#pragma GCC visibility pop

#include <boost/python.hpp>

BR
Renato


On Sun, Mar 22, 2009 at 12:36 PM, Renato Araujo <renatox at gmail.com> wrote:
> Thanks for the link, I tried a lot of combinations but nothing works
> Then I started looking in boost for the header where I got the error,
> then I found the header but I don't know why this happen. I fix the
> problem with:
>
> #pragma GCC visibility push(default)
> #include <boost/python/call.hpp>
> #pragma GCC visibility pop
> #include <boost/python.hpp>
>
>
> You can try this only changing the "foo/python_headers.h" file in my
> previous example.
>
> I don't know if this is the correct way to fix this. Someone can talk about?
>
>
> BR
>
>
> On Sat, Mar 21, 2009 at 5:38 PM, Niall Douglas
> <s_sourceforge at nedprod.com> wrote:
>> On 20 Mar 2009 at 13:46, Renato Araujo wrote:
>>
>>> I have worked with some gcc flags to reduce my binding size. After
>>> some time using this -fvisibility=hidden with my library, I discovered
>>> a strange behavior on boost::python more specific in object call
>>> function like this:
>>>
>>> python::call_method<void>(py_obj.ptr(), "myVirtualFunction");
>>>
>>> The problem is: When I use this flag boost always call my "virtual
>>> default" implementation and without this flag boost always call the
>>> correct virtual method, I don't know what this is happening. I would
>>> like to know if someone has any idea why this is happening?
>>>
>>> I create this small test to show the problem. This flags is very
>>> important for me because I got size reduction about 50% with this.
>>
>> You're not annotating your wrapper class correctly.
>>
>> See http://www.nedprod.com/programs/gccvisibility.html.
>>
>> Cheers,
>> Niall
>>
>>
>>
>> _______________________________________________
>> Cplusplus-sig mailing list
>> Cplusplus-sig at python.org
>> http://mail.python.org/mailman/listinfo/cplusplus-sig
>>
>
>
>
> --
> Renato Araujo Oliveira Filho
>



-- 
Renato Araujo Oliveira Filho

From renatox at gmail.com  Mon Mar 23 18:50:35 2009
From: renatox at gmail.com (Renato Araujo)
Date: Mon, 23 Mar 2009 14:50:35 -0300
Subject: [C++-sig] Protected virtual Functions with default
	implementation
In-Reply-To: <7465b6170903230157o5808c83dqe87b37cd361d9226@mail.gmail.com>
References: <95291a80903190734y6b678d24j23319dd01614e186@mail.gmail.com>
	<7465b6170903230157o5808c83dqe87b37cd361d9226@mail.gmail.com>
Message-ID: <95291a80903231050o5f11e13ia93ebc38b6bf7f67@mail.gmail.com>

Hi Roman

The problem is that: How export this class?

namespace geometry{

class point_t
{
public:
    point_t() {};

protected:
    virtual bool ret_bool() { return false; }
};

class point_2 : public point_t
{
public:
    point_2() {};
};
}

I put attached the Py++ genereted code and a small test.
My  question is, how export this protected virtual function? the way
used in Py++ not work in this case.

Thanks

On Mon, Mar 23, 2009 at 5:57 AM, Roman Yakovenko
<roman.yakovenko at gmail.com> wrote:
> 2009/3/19 Renato Araujo <renatox at gmail.com>:
>> Hi guys, I'm working again in my bindings generation and I get a new
>> question about virtual functions.
>>
>> I would like to know how export protected virtual functions with
>> default implementation, because I didn't find any documentation about
>> this and the code generated by Py++ not work in all cases.
>>
>> I have attached the test case on this e-mail, if someone would like to
>> try my implementation.
>
> Do you mind to be more specific?
>
> Can you show the original source code, the generated one and the
> "right\desired" one?
>
> Thanks
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>



-- 
Renato Araujo Oliveira Filho
-------------- next part --------------
A non-text attachment was scrubbed...
Name: properties.py.cpp
Type: text/x-c++src
Size: 1637 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090323/83bde052/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.py
Type: text/x-python
Size: 260 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20090323/83bde052/attachment.py>

From roman.yakovenko at gmail.com  Mon Mar 23 20:48:02 2009
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Mon, 23 Mar 2009 21:48:02 +0200
Subject: [C++-sig] Protected virtual Functions with default
	implementation
In-Reply-To: <95291a80903231050o5f11e13ia93ebc38b6bf7f67@mail.gmail.com>
References: <95291a80903190734y6b678d24j23319dd01614e186@mail.gmail.com>
	<7465b6170903230157o5808c83dqe87b37cd361d9226@mail.gmail.com>
	<95291a80903231050o5f11e13ia93ebc38b6bf7f67@mail.gmail.com>
Message-ID: <7465b6170903231248m31759696g68fc4dea28044206@mail.gmail.com>

2009/3/23 Renato Araujo <renatox at gmail.com>:
> Hi Roman

Good evening.

> The problem is that: How export this class?
>
> namespace geometry{
>
> class point_t
> {
> public:
> ? ?point_t() {};
>
> protected:
> ? ?virtual bool ret_bool() { return false; }
> };
>
> }
>
> I put attached the Py++ genereted code and a small test.
> My ?question is, how export this protected virtual function? the way
> used in Py++ not work in this case.

Now I understand.

It is not possible to export protected virtual function and to be able
to call it from Python. If I am wrong, let me know and I'll update
Py++.
Previous version of Py++ allowed to do this, but than I ported it to
GCC 4.3 and MSVC 8.0 and found out that the used trick was illegal in
C++.

In many cases, protected virtual function are used in "template
method" design pattern. Py++ supports this usage and allows users to
(re)define those functions in Python.

If you need to access such functions directly, you will have to create
new class in hierarchy, which provides access to the desired
functionality.

HTH

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

From mmmnow at gmail.com  Wed Mar 25 13:48:08 2009
From: mmmnow at gmail.com (=?ISO-8859-2?Q?Micha=B3_Nowotka?=)
Date: Wed, 25 Mar 2009 13:48:08 +0100
Subject: [C++-sig]  [Py++] free operators
Message-ID: <3acfd39a0903250548v147e18c5x23db5a98a8a668d9@mail.gmail.com>

Hello,
I want to expose to python following code:

typedef std::map<const Haplotype*,double> ProbHaplotype;

typedef std::map<const Fenotype*,double> ProbFenotype;

typedef std::map<const Genotype*,double> ProbGenotype;

(...)

std::ostream& operator<<(std::ostream& os, const ProbHaplotype& hapl);

std::ostream& operator<<(std::ostream& os, const ProbFenotype& fen);

std::ostream& operator<<(std::ostream& os, const ProbGenotype& gen);

but I get some warnings:

WARNING: extern std::ostream & hapl::operator<<(std::ostream & os,
hapl::ProbGenotype const & gen) [free operator]
> warning W1052: Py++ will not expose free operator "extern std::ostream & hapl::operator<<(std::ostream & os, hapl::ProbGenotype const & gen) [free
> operator]" - all classes, this operator works on, are excluded.

WARNING: extern std::ostream & hapl::operator<<(std::ostream & os,
hapl::ProbFenotype const & fen) [free operator]
> warning W1052: Py++ will not expose free operator "extern std::ostream & hapl::operator<<(std::ostream & os, hapl::ProbFenotype const & fen) [free
> operator]" - all classes, this operator works on, are excluded.

WARNING: extern std::ostream & hapl::operator<<(std::ostream & os,
hapl::ProbHaplotype const & hapl) [free operator]
> warning W1052: Py++ will not expose free operator "extern std::ostream & hapl::operator<<(std::ostream & os, hapl::ProbHaplotype const & hapl) [free
> operator]" - all classes, this operator works on, are excluded.

How can I get rid of it?


-- 
Regards,

Micha? Nowotka

From roman.yakovenko at gmail.com  Wed Mar 25 13:59:12 2009
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Wed, 25 Mar 2009 14:59:12 +0200
Subject: [C++-sig] [Py++] free operators
In-Reply-To: <3acfd39a0903250548v147e18c5x23db5a98a8a668d9@mail.gmail.com>
References: <3acfd39a0903250548v147e18c5x23db5a98a8a668d9@mail.gmail.com>
Message-ID: <7465b6170903250559jb7f43efn3a6cc6018bb90049@mail.gmail.com>

2009/3/25 Micha? Nowotka <mmmnow at gmail.com>:
> Hello,
> I want to expose to python following code:
>
> typedef std::map<const Haplotype*,double> ProbHaplotype;
>
> typedef std::map<const Fenotype*,double> ProbFenotype;
>
> typedef std::map<const Genotype*,double> ProbGenotype;
>
> (...)
>
> std::ostream& operator<<(std::ostream& os, const ProbHaplotype& hapl);
>
> std::ostream& operator<<(std::ostream& os, const ProbFenotype& fen);
>
> std::ostream& operator<<(std::ostream& os, const ProbGenotype& gen);
>
> but I get some warnings:
>
> WARNING: extern std::ostream & hapl::operator<<(std::ostream & os,
> hapl::ProbGenotype const & gen) [free operator]
>> warning W1052: Py++ will not expose free operator "extern std::ostream & hapl::operator<<(std::ostream & os, hapl::ProbGenotype const & gen) [free
>> operator]" - all classes, this operator works on, are excluded.
>
> WARNING: extern std::ostream & hapl::operator<<(std::ostream & os,
> hapl::ProbFenotype const & fen) [free operator]
>> warning W1052: Py++ will not expose free operator "extern std::ostream & hapl::operator<<(std::ostream & os, hapl::ProbFenotype const & fen) [free
>> operator]" - all classes, this operator works on, are excluded.
>
> WARNING: extern std::ostream & hapl::operator<<(std::ostream & os,
> hapl::ProbHaplotype const & hapl) [free operator]
>> warning W1052: Py++ will not expose free operator "extern std::ostream & hapl::operator<<(std::ostream & os, hapl::ProbHaplotype const & hapl) [free
>> operator]" - all classes, this operator works on, are excluded.
>
> How can I get rid of it?

If you use SVN version, than you can "include" the classes.

HTH

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

From troy at resophonic.com  Wed Mar 25 14:51:07 2009
From: troy at resophonic.com (troy d. straszheim)
Date: Wed, 25 Mar 2009 09:51:07 -0400
Subject: [C++-sig] map_indexing_suite interface
Message-ID: <49CA36CB.9080209@resophonic.com>

I'm wondering why the current map_indexing_suite is the way it is.  Is 
there any reason not to enhance it to support now standard methods like 
keys(), values(), popitem() and the like?

-t

From mmmnow at gmail.com  Wed Mar 25 15:01:58 2009
From: mmmnow at gmail.com (=?ISO-8859-2?Q?Micha=B3_Nowotka?=)
Date: Wed, 25 Mar 2009 15:01:58 +0100
Subject: [C++-sig]  [Py++] call polices newbie questions
Message-ID: <3acfd39a0903250701t2435348dy9a9f15b91c461fcc@mail.gmail.com>

Hello,

First of all I found that set of return value polices mention in
boost.python documentation
(http://www.boost.org/doc/libs/1_38_0/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies):

    * reference_existing_object
    * copy_const_reference
    * copy_non_const_reference
    * manage_new_object

is different from those described in Py++ docs():

    * return_opaque_pointer.
    * copy_const_reference
    * return_by_value
    * copy_non_const_reference
    * return_internal_reference

Secondly, I really don't have any idea which call policy should i
choose with following method:

class Allel {

	public:

		(...)
		const Locus* getLocus() const { return locus_; }
 // <--- This generates warning W1050
	private:

		(...)
		const Locus* locus_;

	};

or generally which policy should be choosen for method with no
arguments returning pointer-type member of it's class.

-- 
Regards

Micha? Nowotka

From roman.yakovenko at gmail.com  Wed Mar 25 15:07:23 2009
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Wed, 25 Mar 2009 16:07:23 +0200
Subject: [C++-sig] [Py++] call polices newbie questions
In-Reply-To: <3acfd39a0903250701t2435348dy9a9f15b91c461fcc@mail.gmail.com>
References: <3acfd39a0903250701t2435348dy9a9f15b91c461fcc@mail.gmail.com>
Message-ID: <7465b6170903250707o3683445by59841f8a27109d32@mail.gmail.com>

2009/3/25 Micha? Nowotka <mmmnow at gmail.com>:
> Hello,
>
> First of all I found that set of return value polices mention in
> boost.python documentation
> (http://www.boost.org/doc/libs/1_38_0/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies):
>
> ? ?* reference_existing_object
> ? ?* copy_const_reference
> ? ?* copy_non_const_reference
> ? ?* manage_new_object
>
> is different from those described in Py++ docs():
>
> ? ?* return_opaque_pointer.
> ? ?* copy_const_reference
> ? ?* return_by_value
> ? ?* copy_non_const_reference
> ? ?* return_internal_reference

http://language-binding.net/pyplusplus/documentation/functions/call_policies/call_policies.html#syntax

Py++ introduces additional call policies for your convenience.

> Secondly, I really don't have any idea which call policy should i
> choose with following method:
>
> class Allel {
>
> ? ? ? ?public:
>
> ? ? ? ? ? ? ? ?(...)
> ? ? ? ? ? ? ? ?const Locus* getLocus() const { return locus_; }
> ?// <--- This generates warning W1050
> ? ? ? ?private:
>
> ? ? ? ? ? ? ? ?(...)
> ? ? ? ? ? ? ? ?const Locus* locus_;
>
> ? ? ? ?};
>
> or generally which policy should be choosen for method with no
> arguments returning pointer-type member of it's class.

Based on information you provided, I would use "return_internal_reference".

I suggest you to read Boost.Python tutorials. It is critical to
understand call policies for successful Boost.Python usage.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

From mmmnow at gmail.com  Wed Mar 25 17:27:54 2009
From: mmmnow at gmail.com (=?ISO-8859-2?Q?Micha=B3_Nowotka?=)
Date: Wed, 25 Mar 2009 17:27:54 +0100
Subject: [C++-sig]  [Py++] user-defined exceptions
Message-ID: <3acfd39a0903250927r3aa27869g1837d948d13b8a01@mail.gmail.com>

And one more question - what about user-defined exceptions?
Suppose I have following code from library which I cannot modify:

namespace faif

{


   class FaifException : public std::exception {

	public:

		FaifException(){}

		virtual ~FaifException() throw() {}

		virtual const char *what() const throw() { return "FaifException"; }

		
		virtual std::ostream& print(std::ostream& os) const throw();

	};

   class UserBreakException : public FaifException {

    public:

        UserBreakException(){}

        virtual ~UserBreakException() throw() {}

        virtual const char *what() const throw(){ return "UserBreak
exception"; }


        virtual std::ostream& print(std::ostream& os) const throw();

    };

(...)

}

This causes following warnings:

WARNING: char const * faif::UserBreakException::what() const [member function]
> warning W1046: The virtual function was declared with empty throw. Adding the ability to override the function from Python breaks the exception
> specification. The function wrapper can throw any exception. In case of exception in run-time, the behaviour of the program is undefined!

WARNING: std::ostream & faif::UserBreakException::print(std::ostream &
os) const [member function]
> warning W1049: This method could not be overriden in Python - method returns reference to local variable!

WARNING: std::ostream & faif::UserBreakException::print(std::ostream &
os) const [member function]
> warning W1046: The virtual function was declared with empty throw. Adding the ability to override the function from Python breaks the exception
> specification. The function wrapper can throw any exception. In case of exception in run-time, the behaviour of the program is undefined!

Should I exclude this declarations or there is another solution? (I am
not sure excluding it may be called 'solution'...)

BTW - Why warnings doesn't provide information form what header file
particular warning was generated?
BTW2 - How to exclude the whole class from generation?

-- 
Regards

Micha? Nowotka

From roman.yakovenko at gmail.com  Wed Mar 25 19:11:49 2009
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Wed, 25 Mar 2009 20:11:49 +0200
Subject: [C++-sig] [Py++] user-defined exceptions
In-Reply-To: <3acfd39a0903250927r3aa27869g1837d948d13b8a01@mail.gmail.com>
References: <3acfd39a0903250927r3aa27869g1837d948d13b8a01@mail.gmail.com>
Message-ID: <7465b6170903251111k7543fe2fib9ad0146f32073d4@mail.gmail.com>

2009/3/25 Micha? Nowotka <mmmnow at gmail.com>:
> And one more question - what about user-defined exceptions?
> Suppose I have following code from library which I cannot modify:
>
> namespace faif
>
> {
>
>
> ? class FaifException : public std::exception {
>
> ? ? ? ?public:
>
> ? ? ? ? ? ? ? ?FaifException(){}
>
> ? ? ? ? ? ? ? ?virtual ~FaifException() throw() {}
>
> ? ? ? ? ? ? ? ?virtual const char *what() const throw() { return "FaifException"; }
>
>
> ? ? ? ? ? ? ? ?virtual std::ostream& print(std::ostream& os) const throw();
>
> ? ? ? ?};
>
> ? class UserBreakException : public FaifException {
>
> ? ?public:
>
> ? ? ? ?UserBreakException(){}
>
> ? ? ? ?virtual ~UserBreakException() throw() {}
>
> ? ? ? ?virtual const char *what() const throw(){ return "UserBreak
> exception"; }
>
>
> ? ? ? ?virtual std::ostream& print(std::ostream& os) const throw();
>
> ? ?};
>
> (...)
>
> }
>
> This causes following warnings:
>
> WARNING: char const * faif::UserBreakException::what() const [member function]
>> warning W1046: The virtual function was declared with empty throw. Adding the ability to override the function from Python breaks the exception
>> specification. The function wrapper can throw any exception. In case of exception in run-time, the behaviour of the program is undefined!

I think this one is self-explained.

> WARNING: std::ostream & faif::UserBreakException::print(std::ostream &
> os) const [member function]
>> warning W1049: This method could not be overriden in Python - method returns reference to local variable!

The text should be different:
This method could not be overriden in Python - method returns *non
const* reference. In such cases, Boost.Python doesn't have place to
store the temporal variables.

> WARNING: std::ostream & faif::UserBreakException::print(std::ostream &
> os) const [member function]
>> warning W1046: The virtual function was declared with empty throw. Adding the ability to override the function from Python breaks the exception
>> specification. The function wrapper can throw any exception. In case of exception in run-time, the behaviour of the program is undefined!


> Should I exclude this declarations or there is another solution? (I am
> not sure excluding it may be called 'solution'...)

You may ignore them.

> BTW - Why warnings doesn't provide information form what header file
> particular warning was generated?

Because there was not demand to such functionality. A patch is welcome.

> BTW2 - How to exclude the whole class from generation?

c = mb.class_( <...> )
c.exclude()

I suggest you to take a look on the following document:
http://www.language-binding.net/pyplusplus/troubleshooting_guide/exceptions/exceptions.html

HTH

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

From s_sourceforge at nedprod.com  Wed Mar 25 23:17:44 2009
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 25 Mar 2009 22:17:44 -0000
Subject: [C++-sig] gcc flag -fvisibility=hidden not working with
	boost::python
In-Reply-To: <95291a80903230742u4c2f0169k57d351174c44e233@mail.gmail.com>
References: <95291a80903200946q5ce4b22co5e7a8b403cc5eb41@mail.gmail.com>,
	<95291a80903220836p3ef0b1a8w320d3adf2a329fc0@mail.gmail.com>,
	<95291a80903230742u4c2f0169k57d351174c44e233@mail.gmail.com>
Message-ID: <49CAAD88.31241.3DDC9538@s_sourceforge.nedprod.com>

On 23 Mar 2009 at 11:42, Renato Araujo wrote:

> For more details about the problem, I found the correct header witch
> give me this problem, and isolate that with this:
> 
> #include <boost/python/detail/prefix.hpp>
> # include <boost/type_traits/is_polymorphic.hpp>
> # include <boost/mpl/bool.hpp>
> 
> #pragma GCC visibility push(default)
> #include <boost/python/detail/wrapper_base.hpp>
> #pragma GCC visibility pop
> 
> #include <boost/python.hpp>

This is a fix which "just happens to work" but it won't do so 
reliably. I would strongly recommend finding exactly which part of 
either Boost or your code is missing its proper visibility 
declarations and fix it.

I'll be running a test build of TnFOX this summer (hopefully as part 
of GSoC), so if Boost.Python has introduced a regression I'll find it 
and fix it then.

Cheers,
Niall




From mmmnow at gmail.com  Thu Mar 26 07:37:35 2009
From: mmmnow at gmail.com (=?ISO-8859-2?Q?Micha=B3_Nowotka?=)
Date: Thu, 26 Mar 2009 07:37:35 +0100
Subject: [C++-sig] [Py++] free operators
In-Reply-To: <7465b6170903250559jb7f43efn3a6cc6018bb90049@mail.gmail.com>
References: <3acfd39a0903250548v147e18c5x23db5a98a8a668d9@mail.gmail.com>
	<7465b6170903250559jb7f43efn3a6cc6018bb90049@mail.gmail.com>
Message-ID: <3acfd39a0903252337oedb8294o48ea41473113ca7f@mail.gmail.com>

> If you use SVN version, than you can "include" the classes.

Ok, so I've checked out svn repository and reinstalled pygccxmm and
py++ from pygccxml_dev and pyplusplus_dev but I still get same
warnings. Should I do something else to include these classes?


-- 
Regards

Micha? Nowotka

From tjr303 at inbox.ru  Thu Mar 26 14:35:52 2009
From: tjr303 at inbox.ru (Tim J. Ranger)
Date: Thu, 26 Mar 2009 06:35:52 -0700 (PDT)
Subject: [C++-sig] Bug and patch for boost.python with
 enable_shared_from_this
In-Reply-To: <369001ee0802101714p5d234f2n1eaef7845bfa9c61@mail.gmail.com>
References: <369001ee0802101714p5d234f2n1eaef7845bfa9c61@mail.gmail.com>
Message-ID: <22722146.post@talk.nabble.com>


It's quite early to claim problem (completely) solved.

Niether of described mechanismes would help you if class Test is wrapped and
derived from and require PyObject alive along with. As well as Peter's
shared_ptr patches to date.

Because boost::python::object::ob_refcnt does not increases/decreases on
creation/deletion of an shared_ptr constructed from shared_from_this().

Any ideas?..
-- 
View this message in context: http://www.nabble.com/Bug-and-patch-for-boost.python-with-enable_shared_from_this-tp15403999p22722146.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.


From mmmnow at gmail.com  Fri Mar 27 19:04:07 2009
From: mmmnow at gmail.com (=?ISO-8859-2?Q?Micha=B3_Nowotka?=)
Date: Fri, 27 Mar 2009 19:04:07 +0100
Subject: [C++-sig] [Py++] free operators
In-Reply-To: <3acfd39a0903252337oedb8294o48ea41473113ca7f@mail.gmail.com>
References: <3acfd39a0903250548v147e18c5x23db5a98a8a668d9@mail.gmail.com>
	<7465b6170903250559jb7f43efn3a6cc6018bb90049@mail.gmail.com>
	<3acfd39a0903252337oedb8294o48ea41473113ca7f@mail.gmail.com>
Message-ID: <3acfd39a0903271104x2f63ed55m653919e56d139f65@mail.gmail.com>

I've checked out svn repository (from
https://pygccxml.svn.sourceforge.net/svnroot/pygccxml) and then:

- installed pygccxml and pypluspluss eggs from pygccxml_dev and
pyplusplus_dev eggs
- installed it once again from tags/pygccxml_dev_1.0.0 and
tags/pyplusplus_dev_1.0.0 directories
- I also tried to instal it form tags/pygccxml_dev_0.9.5 and
tags/pyplusplus_dev_0.9.5 directories
- then i copied directories pygccxml_dev/build/lib/pygccxml and
pyplusplus_dev/build/lib/pyplusplus to my working directory and tried
to use it as modules
- eventually I changed gccxml_path to gccxml_bin/v09/linux2/bin/gccxml

but in all cases I still get same warnings:

WARNING: extern std::ostream & hapl::operator<<(std::ostream & os,
hapl::ProbGenotype const & gen) [free operator]
> warning W1052: Py++ will not expose free operator "extern std::ostream & hapl::operator<<(std::ostream & os, hapl::ProbGenotype const & gen) [free
> operator]" - all classes, this operator works on, are excluded.

WARNING: extern std::ostream & hapl::operator<<(std::ostream & os,
hapl::ProbFenotype const & fen) [free operator]
> warning W1052: Py++ will not expose free operator "extern std::ostream & hapl::operator<<(std::ostream & os, hapl::ProbFenotype const & fen) [free
> operator]" - all classes, this operator works on, are excluded.

WARNING: extern std::ostream & hapl::operator<<(std::ostream & os,
hapl::ProbHaplotype const & hapl) [free operator]
> warning W1052: Py++ will not expose free operator "extern std::ostream & hapl::operator<<(std::ostream & os, hapl::ProbHaplotype const & hapl) [free
> operator]" - all classes, this operator works on, are excluded.

so please, help me.

-- 
Regards

Micha? Nowotka

From roman.yakovenko at gmail.com  Sun Mar 29 08:00:51 2009
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Sun, 29 Mar 2009 09:00:51 +0300
Subject: [C++-sig] [Py++] free operators
In-Reply-To: <3acfd39a0903252337oedb8294o48ea41473113ca7f@mail.gmail.com>
References: <3acfd39a0903250548v147e18c5x23db5a98a8a668d9@mail.gmail.com>
	<7465b6170903250559jb7f43efn3a6cc6018bb90049@mail.gmail.com>
	<3acfd39a0903252337oedb8294o48ea41473113ca7f@mail.gmail.com>
Message-ID: <7465b6170903282300p6e7c905bu2f798086d6edea0b@mail.gmail.com>

2009/3/26 Micha? Nowotka <mmmnow at gmail.com>
>
> > If you use SVN version, than you can "include" the classes.
>
> Ok, so I've checked out svn repository and reinstalled pygccxmm and
> py++ from pygccxml_dev and pyplusplus_dev but I still get same
> warnings. Should I do something else to include these classes?

Hmm, I will check this.

P.S. I am pretty busy these days, so it will take some time, sorry.


--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

From mmmnow at gmail.com  Sun Mar 29 14:34:03 2009
From: mmmnow at gmail.com (=?ISO-8859-2?Q?Micha=B3_Nowotka?=)
Date: Sun, 29 Mar 2009 14:34:03 +0200
Subject: [C++-sig]  [Py++] compilation errors
Message-ID: <3acfd39a0903290534y461d8eaeu831a3288a894e92d@mail.gmail.com>

Hello,
when generating binding code using Py++ i got following warnings:

   WARNING: hapl::Fenotype const *
hapl::Fenotypes::find_equal(hapl::Fenotype const & pattern) const
[member function]
   > compilation error W1050: The function returns "hapl::Fenotype
const *" type. You have to specify a call policies.Be sure to take a
look on Py++ defined
   > call policies:
http://language-binding.net/pyplusplus/documentation/functions/call_policies.html#py-defined-call-policies

   WARNING: hapl::Fenotype *
hapl::Fenotypes::find_equal(hapl::Fenotype const & pattern) [member
function]
   > compilation error W1050: The function returns "hapl::Fenotype *"
type. You have to specify a call policies.Be sure to take a look on
Py++ defined call
   > policies: http://language-binding.net/pyplusplus/documentation/functions/call_policies.html#py-defined-call-policies

   WARNING: hapl::Haplotype const *
hapl::Haplotypes::find_equal(hapl::Haplotype const & pattern) const
[member function]
   > compilation error W1050: The function returns "hapl::Haplotype
const *" type. You have to specify a call policies.Be sure to take a
look on Py++ defined
   > call policies:
http://language-binding.net/pyplusplus/documentation/functions/call_policies.html#py-defined-call-policies

   WARNING: hapl::Haplotype const * hapl::Genotype::getUp() const
[member function]
   > compilation error W1050: The function returns "hapl::Haplotype
const *" type. You have to specify a call policies.Be sure to take a
look on Py++ defined
   > call policies:
http://language-binding.net/pyplusplus/documentation/functions/call_policies.html#py-defined-call-policies

   WARNING: hapl::Haplotype const * hapl::Genotype::getDown() const
[member function]
   > compilation error W1050: The function returns "hapl::Haplotype
const *" type. You have to specify a call policies.Be sure to take a
look on Py++ defined
   > call policies:
http://language-binding.net/pyplusplus/documentation/functions/call_policies.html#py-defined-call-policies

   WARNING: hapl::Fenotype const * hapl::Genotype::getFenotype() const
[member function]
   > compilation error W1050: The function returns "hapl::Fenotype
const *" type. You have to specify a call policies.Be sure to take a
look on Py++ defined
   > call policies:
http://language-binding.net/pyplusplus/documentation/functions/call_policies.html#py-defined-call-policies


so I found all function declarations returning 'hapl::Fenotype const
*' and  ' hapl::Haplotype const *' in my header files and assigned
call policies:

mb.member_function( 'getLocus' ).call_policies =
module_builder.call_policies.return_internal_reference()
mb.member_functions( 'findVariant' ).call_policies =
module_builder.call_policies.return_internal_reference()
mb.member_functions( 'find_equal' ).call_policies =
module_builder.call_policies.return_internal_reference()
mb.member_function( 'getUp' ).call_policies =
module_builder.call_policies.return_internal_reference()
mb.member_function( 'getDown' ).call_policies =
module_builder.call_policies.return_internal_reference()
mb.member_function( 'getFenotype' ).call_policies =
module_builder.call_policies.return_internal_reference()

now all warnings disappeared. But when compiling output file i got some errors:

/usr/include/boost/python/detail/invoke.hpp: In function 'PyObject*
boost::python::detail::invoke(boost::python::detail::invoke_tag_<false,
false>, const RC&, F&, AC0&) [with RC =
boost::python::detail::caller_arity<1u>::impl<F, Policies,
Sig>::operator()(PyObject*, PyObject*) [with F = const hapl::Fenotype*
(*)(std::pair<const hapl::Fenotype* const, double>&), Policies =
boost::python::default_call_policies, Sig = boost::mpl::vector2<const
hapl::Fenotype*, std::pair<const hapl::Fenotype* const,
double>&>]::result_converter, F = const hapl::Fenotype*
(*)(std::pair<const hapl::Fenotype* const, double>&), AC0 =
boost::python::detail::caller_arity<1u>::impl<F, Policies,
Sig>::operator()(PyObject*, PyObject*) [with F = const hapl::Fenotype*
(*)(std::pair<const hapl::Fenotype* const, double>&), Policies =
boost::python::default_call_policies, Sig = boost::mpl::vector2<const
hapl::Fenotype*, std::pair<const hapl::Fenotype* const,
double>&>]::c_t0]':
/usr/include/boost/python/detail/caller.hpp:199:   instantiated from
'PyObject* boost::python::detail::caller_arity<1u>::impl<F, Policies,
Sig>::operator()(PyObject*, PyObject*) [with F = const hapl::Fenotype*
(*)(std::pair<const hapl::Fenotype* const, double>&), Policies =
boost::python::default_call_policies, Sig = boost::mpl::vector2<const
hapl::Fenotype*, std::pair<const hapl::Fenotype* const, double>&>]'
/usr/include/boost/python/object/py_function.hpp:38:   instantiated
from 'PyObject*
boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*,
PyObject*) [with Caller = boost::python::detail::caller<const
hapl::Fenotype* (*)(std::pair<const hapl::Fenotype* const, double>&),
boost::python::default_call_policies, boost::mpl::vector2<const
hapl::Fenotype*, std::pair<const hapl::Fenotype* const, double>&> >]'
bindings.cpp:780:   instantiated from here
/usr/include/boost/python/detail/invoke.hpp:75: error: no match for
call to '(const
boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<const
hapl::Fenotype*>) (const hapl::Fenotype*)'

/usr/include/boost/python/detail/invoke.hpp: In function 'PyObject*
boost::python::detail::invoke(boost::python::detail::invoke_tag_<false,
false>, const RC&, F&, AC0&) [with RC =
boost::python::detail::caller_arity<1u>::impl<F, Policies,
Sig>::operator()(PyObject*, PyObject*) [with F = const hapl::Genotype*
(*)(std::pair<const hapl::Genotype* const, double>&), Policies =
boost::python::default_call_policies, Sig = boost::mpl::vector2<const
hapl::Genotype*, std::pair<const hapl::Genotype* const,
double>&>]::result_converter, F = const hapl::Genotype*
(*)(std::pair<const hapl::Genotype* const, double>&), AC0 =
boost::python::detail::caller_arity<1u>::impl<F, Policies,
Sig>::operator()(PyObject*, PyObject*) [with F = const hapl::Genotype*
(*)(std::pair<const hapl::Genotype* const, double>&), Policies =
boost::python::default_call_policies, Sig = boost::mpl::vector2<const
hapl::Genotype*, std::pair<const hapl::Genotype* const,
double>&>]::c_t0]':
/usr/include/boost/python/detail/caller.hpp:199:   instantiated from
'PyObject* boost::python::detail::caller_arity<1u>::impl<F, Policies,
Sig>::operator()(PyObject*, PyObject*) [with F = const hapl::Genotype*
(*)(std::pair<const hapl::Genotype* const, double>&), Policies =
boost::python::default_call_policies, Sig = boost::mpl::vector2<const
hapl::Genotype*, std::pair<const hapl::Genotype* const, double>&>]'
/usr/include/boost/python/object/py_function.hpp:38:   instantiated
from 'PyObject*
boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*,
PyObject*) [with Caller = boost::python::detail::caller<const
hapl::Genotype* (*)(std::pair<const hapl::Genotype* const, double>&),
boost::python::default_call_policies, boost::mpl::vector2<const
hapl::Genotype*, std::pair<const hapl::Genotype* const, double>&> >]'
bindings.cpp:780:   instantiated from here
/usr/include/boost/python/detail/invoke.hpp:75: error: no match for
call to '(const
boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<const
hapl::Genotype*>) (const hapl::Genotype*)'

/usr/include/boost/python/detail/invoke.hpp: In function 'PyObject*
boost::python::detail::invoke(boost::python::detail::invoke_tag_<false,
false>, const RC&, F&, AC0&) [with RC =
boost::python::detail::caller_arity<1u>::impl<F, Policies,
Sig>::operator()(PyObject*, PyObject*) [with F = const
hapl::Haplotype* (*)(std::pair<const hapl::Haplotype* const,
double>&), Policies = boost::python::default_call_policies, Sig =
boost::mpl::vector2<const hapl::Haplotype*, std::pair<const
hapl::Haplotype* const, double>&>]::result_converter, F = const
hapl::Haplotype* (*)(std::pair<const hapl::Haplotype* const,
double>&), AC0 = boost::python::detail::caller_arity<1u>::impl<F,
Policies, Sig>::operator()(PyObject*, PyObject*) [with F = const
hapl::Haplotype* (*)(std::pair<const hapl::Haplotype* const,
double>&), Policies = boost::python::default_call_policies, Sig =
boost::mpl::vector2<const hapl::Haplotype*, std::pair<const
hapl::Haplotype* const, double>&>]::c_t0]':
/usr/include/boost/python/detail/caller.hpp:199:   instantiated from
'PyObject* boost::python::detail::caller_arity<1u>::impl<F, Policies,
Sig>::operator()(PyObject*, PyObject*) [with F = const
hapl::Haplotype* (*)(std::pair<const hapl::Haplotype* const,
double>&), Policies = boost::python::default_call_policies, Sig =
boost::mpl::vector2<const hapl::Haplotype*, std::pair<const
hapl::Haplotype* const, double>&>]'
/usr/include/boost/python/object/py_function.hpp:38:   instantiated
from 'PyObject*
boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*,
PyObject*) [with Caller = boost::python::detail::caller<const
hapl::Haplotype* (*)(std::pair<const hapl::Haplotype* const,
double>&), boost::python::default_call_policies,
boost::mpl::vector2<const hapl::Haplotype*, std::pair<const
hapl::Haplotype* const, double>&> >]'
bindings.cpp:780:   instantiated from here
/usr/include/boost/python/detail/invoke.hpp:75: error: no match for
call to '(const
boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<const
hapl::Haplotype*>) (const hapl::Haplotype*)'

this is strange for me bacause I'm sure I listed all methods returning
mentioned types. There is also one more type that doesn't cause
warning: '(const hapl::Genotype*'
So I guess this problem may be caused by typedef declaration in my header files:

typedef std::map<const Haplotype*,double> ProbHaplotype;

typedef std::map<const Fenotype*,double> ProbFenotype;

typedef std::map<const Genotype*,double> ProbGenotype;

and:

typedef std::set<const Fenotype*> ObsFenotypes;

typedef std::set<const Genotype*> ObsGenotypes;

typedef std::set<const Haplotype*> ObsHaplotypes;

STL generic containers can generate methods returning problematic
types so i cannot see it in my headers.
To solve this problem I replaced lines with call polices mentioned above by:

mb.member_functions(return_type='hapl::Fenotype const
*').call_policies =
module_builder.call_policies.return_internal_reference()
mb.member_functions(return_type='hapl::Haplotype const
*').call_policies =
module_builder.call_policies.return_internal_reference()
mb.member_functions(return_type='hapl::Genotype const
*').call_policies =
module_builder.call_policies.return_internal_reference()

but this causes run time error:

Traceback (most recent call last):
  File "makewindow.py", line 27, in <module>
    mb.member_functions(return_type='hapl::Fenotype const
*').call_policies =
module_builder.call_policies.return_internal_reference()
  File "/usr/lib/python2.5/site-packages/pyplusplus/module_builder/builder.py",
line 564, in member_functions
    , recursive=recursive)
  File "/usr/lib/python2.5/site-packages/pygccxml/declarations/scopedef.py",
line 518, in member_functions
    , allow_empty=allow_empty)
  File "/usr/lib/python2.5/site-packages/pygccxml/declarations/scopedef.py",
line 374, in _find_multiple
    raise RuntimeError( "Multi declaration query returned 0 declarations." )
RuntimeError: Multi declaration query returned 0 declarations.

So what shuld I do to get clean complation without errors?
-- 
Regards

Micha? Nowotka

From Gregor.Burger at uibk.ac.at  Mon Mar 30 17:55:34 2009
From: Gregor.Burger at uibk.ac.at (Gregor Burger)
Date: Mon, 30 Mar 2009 17:55:34 +0200
Subject: [C++-sig] instantiate python classes in c++
Message-ID: <1238428534.49d0eb768108f@web-mail1.uibk.ac.at>

hi all,

is it possible to use boost.python to define classes
in a script (like in the one below), register the defined
classes and later on create instances of the class?

from cd3 import *

class MyNode(Node):
	def init(self, start, stop, dt):
		in_flow = Flow()
		self.addInPort(in_flow)

	def f(self, time, dt):
		return dt


register_node(MyNode)

registering of the class is working also instantiating
the class. but it seems that when i call init(...) and f(...)
afterwards the namespace and all imports are lost. so
in_flow = Flow() raises an global name Flow undefined. The wrapping
of Flow works on first execution.

Is it possible to provide the same globals and locals to call_method
so that Flow and other classes are defined?

thanks in advance.

gregor burger
university of innsbruck

the wrapped Node looks like this:

struct NodeCallback : Node {
	NodeCallback(PyObject *p) : self(p) {
		Py_INCREF(self);
	}

	virtual ~NodeCallback() {
		Py_DECREF(self);
	}

	void init(int start, int stop, int dt) {
			call_method<void, int, int, int>(self, "init", start, stop, dt);
	}

	int f(int time, int dt) {
		return call_method<int, int, int>(self, "f", time, dt);
	}

	void addInPort(object o) {
		std::string name = extract<std::string>(o.attr("__name__"));
		std::cout << "adding in port " << name << std::endl;
	}

	PyObject *self;
};