From dave at boost-consulting.com  Fri Oct  1 01:27:40 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 30 Sep 2004 19:27:40 -0400
Subject: [C++-sig] Re: SIGSEGV on extract_pointer
References: <1096580176.25489.20.camel@sheriffpony>
Message-ID: <uzn372v83.fsf@boost-consulting.com>

Itamar Shtull-Trauring <itamar at itamarst.org> writes:

> Platform: Redhat 7.3 on x86, gcc 2.96 (yes, it's horrible and ancient),
> boost 1.31.
>
> I have some code that looks like this:
>
>     extract<Twisted::DatagramProtocol*> pchecker(self.attr("protocol"));
>     if (pchecker.check()) {
> 	this->protocol = pchecker();
>
> When running this it gets a SIGSEGV:
>
> 0x401eccb5 in boost::python::converter::get_lvalue_from_python () from
> /usr/local/lib/libboost_python-gcc-mt-1_31.so.1.31.0
> (gdb) up
> #1  0x4027bcf2 in
> boost::python::converter::extract_pointer<Twisted::DatagramProtocol
> *>::extract_pointer (this=0xbfffda68, obj=0x87666ac)
>     at /usr/local/include/boost-1_31/boost/python/extract.hpp:203
>
> The code in question being:
>
>   template <class Ptr>
>   inline extract_pointer<Ptr>::extract_pointer(PyObject* obj)
>       : m_source(obj)
>       , m_result(
>           obj == Py_None ? 0 : (get_lvalue_from_python)(obj,
> registered_pointee<Ptr>::converters)
>           )
>   {
>   }
>
> Here's the fun part - it does NOT crash when I compile with -fno-inline.
> My code is perfectly valid, AFAICT - there is a protocol attribute there
> and it is of the right type.
>
> This is part of my C++/Twisted integration project.

Okay... what is your goal in reporting this here?  It is a GCC 2.96
bug, right?  Can you come up with something that inhibits it?
Otherwise, I'm not sure what to do for you.

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



From akulakov at creative-assembly.com.au  Fri Oct  1 08:21:29 2004
From: akulakov at creative-assembly.com.au (Artem Kulakov)
Date: Fri, 01 Oct 2004 16:21:29 +1000
Subject: [C++-sig] shared_ptr and weak references
Message-ID: <cjit18$g68$1@sea.gmane.org>

I have a problem with returning objects from C++ to Python via shared_ptr and 
using weak references on those objects. Here's what I am trying to do:

- create a new object in C++
- hold a shared_ptr to it in C++
- return the shared pointer to Python
- setup a weak reference to the object

My problem is that the weak reference turns dead once all Python variables 
pointing to the object are gone.

Any ideas?

Here is the source code:


#define BOOST_PYTHON_STATIC_LIB
#include <boost/python.hpp>
#include <boost/smart_ptr.hpp>
#include <boost/test/minimal.hpp>

#include <list>

using namespace boost::python;


struct Actor
{
	Actor()	{ std::cout << "  Actor::Actor" << std::endl; }
	~Actor() { std::cout << "  Actor::~Actor" << std::endl; }
};
typedef boost::shared_ptr<Actor> ActorPtr;

static std::list<ActorPtr> s_Actors;

ActorPtr NewActor()
{
	ActorPtr p(new Actor);
	s_Actors.push_back(p);
	return p;
}


BOOST_PYTHON_MODULE(cpp_impl)
{
	class_<Actor>("Actor");
	register_ptr_to_python<ActorPtr>();
	def("NewActor", &NewActor);
}

int test_main( int, char *[] )
{
	Py_Initialize();

	BOOST_REQUIRE(PyImport_AppendInittab("cpp_impl", initcpp_impl) != -1);

	handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
	handle<> main_namespace(borrowed( PyModule_GetDict(main_module.get()) ));

	try
	{
		handle<>( PyRun_String(
			"print 'Hello world!'		\n"
			"from cpp_impl import *		\n"
			"a = NewActor()				\n"
			"print a					\n"
			"import weakref				\n"
			"r = weakref.ref(a)			\n"
			"print r					\n"
			"a1 = a						\n"
			"del a						\n"
			"print r					\n"
			"del a1						\n"
			"print r					\n"
			"", Py_file_input,
			main_namespace.get(), main_namespace.get()) );
	}
	catch (error_already_set)
	{
		PyErr_Print();
	}
	Py_Finalize();
	return 0;
}


-- 


Artem Kulakov
Senior Programmer
The Creative Assembly International
http://www.creative-assembly.com.au/



From itamar at itamarst.org  Fri Oct  1 17:09:15 2004
From: itamar at itamarst.org (Itamar Shtull-Trauring)
Date: Fri, 01 Oct 2004 11:09:15 -0400
Subject: [C++-sig] Re: SIGSEGV on extract_pointer
In-Reply-To: <uzn372v83.fsf@boost-consulting.com>
References: <1096580176.25489.20.camel@sheriffpony>
	<uzn372v83.fsf@boost-consulting.com>
Message-ID: <1096643355.25488.55.camel@sheriffpony>

On Thu, 2004-09-30 at 19:27, David Abrahams wrote:

> Okay... what is your goal in reporting this here?  It is a GCC 2.96
> bug, right?  

Presumably, I'm new enough to C++ that I can't be certain.

> Can you come up with something that inhibits it?
> Otherwise, I'm not sure what to do for you.

I was hoping someone here might have a workaround, or seen in this in
the past. Oh well, more fuel for upgrading to a decent compiler.



From ndbecker2 at verizon.net  Fri Oct  1 20:31:36 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Fri, 01 Oct 2004 14:31:36 -0400
Subject: [C++-sig] documenting boost::python - and now for something
	completely different
Message-ID: <cjk7q9$971$1@sea.gmane.org>

Here is a completely different approach to documenting boost::python code.

The intended user of this documentation is a python programmer.  Therefore,
they want Python-ish documentation.

Doxygen can produce nice documents.  It doesn't know Python.  But wait! 
There is a script pythfilter.py that does a nice job of converting python
code, and can be run by doxygen as a filter.

So here's the deal.  You write python code inside a c++ comment.  This code
is marked up per doxygen markup.  You put a marker at the start and end of
each such comment.  A tiny python script I wrote strips everything not
between those markers and feeds it to pythfilter.  So, all you have to do
is in Doxyfile set INPUT_FILTER = todoxy.py.

The best way to do this is use emacs/xemacs.  (require 'mmm).  Write doc
blocks like this:

/* {%python%}
class IIR_double():
    """ \brief IIR filter class with float input and coefficients
    """
    def __init__(self, numerator, denominator):
 """Construct an IIR filter
 \param numerator vector
 \param denominator vector
 """
    
{%/python%} */

This will switch emacs into python mode inside the block, which makes it
really easy to edit the blocks.

Anyone interested I will supply the todoxy.py + modified pythfilter.py.




From ndbecker2 at verizon.net  Wed Oct  6 16:54:51 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Wed, 06 Oct 2004 10:54:51 -0400
Subject: [C++-sig] boost::python segfault related to extract
Message-ID: <ck10vs$dc9$1@sea.gmane.org>

I ran into a problem with code that assigns a slice of a vector of double to
a vector of complex.  The code will cause the following (this code is
shamelessly stolen):

    std::vector<value_type> temp (si.m_sliceLength);
    for (int i = 0; i < si.m_sliceLength; i++)
      {
 extract<value_type const&> x(new_value[i]);
 //  try if elem is an exact Data type
 if (x.check())
   {
     temp[i] = x();
   }
 else
   {
     //  try to convert elem to Data type
     extract<value_type> x(new_value[i]);
     if (x.check())
       {
  temp[i] = x(); <<<<<=== here
       }
     else
       {
  PyErr_SetString(PyExc_TypeError, 
    "Invalid sequence element");
  throw_error_already_set();
       }
   }
      }          
   

The segfault occurs at the indicated line.  This calls:

  template <class T>
  inline typename extract_rvalue<T>::result_type
  extract_rvalue<T>::operator()() const
  {
      return *(T*)(
          // Only do the stage2 conversion once
          m_data.stage1.convertible ==  m_data.storage.bytes
             ? m_data.storage.bytes
             : (rvalue_from_python_stage2)(m_source, m_data.stage1,
registered<T>::converters)
          );
  }

which calls:

BOOST_PYTHON_DECL void* rvalue_from_python_stage2(
[...]
    // If a construct function was registered (i.e. we found an
    // rvalue conversion), call it now.
    if (data.construct != 0)
        data.construct(source, &data); <<<<<<<<<<< here

which calls:


  // Given a target type and a SlotPolicy describing how to perform a
  // given conversion, registers from_python converters which use the
  // SlotPolicy to extract the type.
  template <class T, class SlotPolicy>
  struct slot_rvalue_from_python
  {
[...]

          // record successful construction
          data->convertible = storage; <<< here


which calls:
template <class T>
inline handle<T>::~handle()
{
    python::xdecref(m_p);  <<< here
}

with  *m_p
$7 = {ob_refcnt = 0, ob_type = 0x9114474}

Any ideas?
 



From dave at boost-consulting.com  Wed Oct  6 23:32:15 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 06 Oct 2004 17:32:15 -0400
Subject: [C++-sig] Re: boost::python segfault related to extract
References: <ck10vs$dc9$1@sea.gmane.org>
Message-ID: <uk6u3ednk.fsf@boost-consulting.com>

"Neal D. Becker" <ndbecker2 at verizon.net> writes:

>   // Given a target type and a SlotPolicy describing how to perform a
>   // given conversion, registers from_python converters which use the
>   // SlotPolicy to extract the type.
>   template <class T, class SlotPolicy>
>   struct slot_rvalue_from_python
>   {
> [...]
>
>           // record successful construction
>           data->convertible = storage; <<< here
>
>
> which calls:
> template <class T>
> inline handle<T>::~handle()
> {
>     python::xdecref(m_p);  <<< here
> }

This makes no sense.  data->convertible is a raw pointer.  Assigning
into it doesn't call anything.

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



From beyer at imb-jena.de  Fri Oct  8 11:39:53 2004
From: beyer at imb-jena.de (Andreas Beyer)
Date: Fri, 08 Oct 2004 11:39:53 +0200
Subject: [C++-sig] Initializing long_
Message-ID: <41666069.3000903@imb-jena.de>

Hi:

I would like to create a python Long object via long_ with data that do 
not fit into a long int. How can I initialize long_ with binary data? Is 
that possible?
My data are stored in a boost.dynamic_bitset<>.

Any suggestions?

Thanks,
	Andreas



From dave at boost-consulting.com  Fri Oct  8 20:02:28 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 08 Oct 2004 14:02:28 -0400
Subject: [C++-sig] Re: Initializing long_
References: <41666069.3000903@imb-jena.de>
Message-ID: <ubrfd3x6z.fsf@boost-consulting.com>

Andreas Beyer <beyer at imb-jena.de> writes:

> Hi:
>
> I would like to create a python Long object via long_ with data that
> do not fit into a long int. How can I initialize long_ with binary
> data? Is that possible?
> My data are stored in a boost.dynamic_bitset<>.
>
> Any suggestions?

You can do it by extracting successive [unsigned] long ints and using
<< 32 and | on the python::long_ object.

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



From faheem at email.unc.edu  Sun Oct 10 22:43:55 2004
From: faheem at email.unc.edu (Faheem Mitha)
Date: Sun, 10 Oct 2004 16:43:55 -0400 (EDT)
Subject: [C++-sig] accessing functions at C++ level from one boost.python
 module in another
Message-ID: <Pine.LNX.4.61.0410101552500.8590@Chrestomanci>


Dear People,

I've had modest success using Boost.Python recently. I have however found 
I need to do something for which I am not sure of the best way.

Suppose I have Boost.Python module foo and another one bar. Note that
above code is merely intended as an example/illustration, and may have
errors and/or missing details.

*******************************************************
foo.cc
*******************************************************
#include <boost/python.hpp>

static int state = 0;

void changestate(boost::python::object num)
{
int a = extract<int>(num);
state += a;
}

BOOST_PYTHON_MODULE(foo)
{
def("changestate",changestate);
}
********************************************************

********************************************************
bar.cc
********************************************************
#include <boost/python.hpp>

void accessstate(boost::python::object incr)
{
int a = extract<int>(incr);

// Want to do something like

changestate(a);

// The question is, how do I get my hands on changestate?
}

BOOST_PYTHON_MODULE(bar)
{
def("accessstate", accessstate);
}
**********************************************************

Suppose I load foo into Python. It seems plausible that the function
changestate should be then somehow available for use (with the right
incantation) inside another module bar.

So I can then access the static int state using the function
changestate in bar's C++ code.

Is this possible? If so, how exactly? Actual code would be most helpful.

Please cc me. I'm not subscribed. Thanks.            Faheem.


From Vikram_Gupta at Satyam.com  Wed Oct 13 08:50:01 2004
From: Vikram_Gupta at Satyam.com (Vikram_Gupta)
Date: Wed, 13 Oct 2004 12:20:01 +0530
Subject: [C++-sig] Querry : PyFront
Message-ID: <97B59E16D2BED74E848659E41D0DE97C010083CA@PSINT002>

Hi,
 
I was looking for something that could expediate the process of converting
Python code to C++ code. I came across PyFront. How suitable is PyFront for
the purpose? What are the other options??
************************************************************************** 
This email (including any attachments) is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or
distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard
is appreciated.
**************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041013/5896e342/attachment.htm>

From brian.p.murphy at gmail.com  Wed Oct 13 23:21:42 2004
From: brian.p.murphy at gmail.com (Brian Murphy)
Date: Wed, 13 Oct 2004 14:21:42 -0700
Subject: [C++-sig] Embedding python and sigint
Message-ID: <b3f2034e041013142178d7d8fc@mail.gmail.com>

Hi,
I have embedded python sucessfully in my multithreaded application but
I have one problem. It seems that when I initialize the interpreter,
sigint(ctrl-c) gets swallowed. I am running Fedora Core 2 and Python
2.3 compiled to a shared library. Is there any way; apart from writing
my own signal handler and binding it to sigint, to allow normal
sigints ?
Thanks,
Brian


From tlovexyj at 21cn.com  Thu Oct 14 04:22:53 2004
From: tlovexyj at 21cn.com (=?gb2312?B?x6fA78LtuM4=?=)
Date: Thu, 14 Oct 2004 10:22:53 +0800
Subject: [C++-sig] How can I use boost::python and Python API at the same
	time
Message-ID: <vc958985897894.27896@send1.inner-21cn.com>

Hi,
	How can I use boost::python and Python API at the same time?
	So, Which lib is the right lib I must link? It's boost_python_debug.lib or boost_python_pydebug.lib?
	Thanks for reply~




From dave at boost-consulting.com  Thu Oct 14 16:09:19 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 14 Oct 2004 10:09:19 -0400
Subject: [C++-sig] Re: How can I use boost::python and Python API at the
	same time
References: <vc958985897894.27896@send1.inner-21cn.com>
Message-ID: <u1xg1v1bk.fsf@boost-consulting.com>

"????" <tlovexyj at 21cn.com> writes:

> Hi,
> 	How can I use boost::python and Python API at the same time?

Just use them (?)  There's nothing to it.  You can find numerous
examples in the libs/python/test subdirectory of your Boost CVS tree
or in http://www.boost.org/libs/python/test/.

> 	So, Which lib is the right lib I must link? It's
> 	boost_python_debug.lib or boost_python_pydebug.lib?  Thanks for
> 	reply~

http://www.boost.org/libs/python/doc/building.html#variants should
answer your question.  If not, please ask.

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



From dave at boost-consulting.com  Thu Oct 14 16:10:04 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 14 Oct 2004 10:10:04 -0400
Subject: [C++-sig] Re: Embedding python and sigint
References: <b3f2034e041013142178d7d8fc@mail.gmail.com>
Message-ID: <uvfddtmpv.fsf@boost-consulting.com>

Brian Murphy <brian.p.murphy at gmail.com> writes:

> Hi,
> I have embedded python sucessfully in my multithreaded application but
> I have one problem. It seems that when I initialize the interpreter,
> sigint(ctrl-c) gets swallowed. I am running Fedora Core 2 and Python
> 2.3 compiled to a shared library. Is there any way; apart from writing
> my own signal handler and binding it to sigint, to allow normal
> sigints ?

Brian, 

Sounds like this is not a C++-specific question.  You might get
better answers on comp.lang.python.

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



From tlovexyj at 21cn.com  Sat Oct 16 17:43:54 2004
From: tlovexyj at 21cn.com (=?gb2312?B?x6fA78LtuM4=?=)
Date: Sat, 16 Oct 2004 23:43:54 +0800
Subject: [C++-sig] Re: C++-sig Digest, Vol 15, Issue 9
Message-ID: <3j958983765845.08777@send2.inner-21cn.com>

c++-sig-request,???

	I have allready complied boost::python and I have four lib named boost_python_pydebug.lib, boost_python_debug.lib, boost_python.lib and libboost_python_debug.lib. If I use boost::python only and link boost_python_debug.lib, it's all fine. 
 And I checked up the application need boost_python_debug.dll and python22.dll. When I use python API in this same code, then the python.h will be include, so it link the python22_d.lib in the pyconfig.h automatic. It means the application will be need python22_d.dll, OMG!!! If my poor application running, it will crash when I get the __main__ dict, because boost::python use python22.dll but python API use python22_d.dll, python initialize twice... oops~
	Thanks for help , David Abrahams!


>Send C++-sig mailing list submissions to
>	c++-sig at python.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://mail.python.org/mailman/listinfo/c++-sig
>or, via email, send a message with subject or body 'help' to
>	c++-sig-request at python.org
>
>You can reach the person managing the list at
>	c++-sig-owner at python.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of C++-sig digest..."
>
>
>Today's Topics:
>
>   1. Re: How can I use boost::python and Python API at the	same
>      time (David Abrahams)
>   2. Re: Embedding python and sigint (David Abrahams)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Thu, 14 Oct 2004 10:09:19 -0400
>From: David Abrahams <dave at boost-consulting.com>
>Subject: [C++-sig] Re: How can I use boost::python and Python API at
>	the	same time
>To: c++-sig at python.org
>Message-ID: <u1xg1v1bk.fsf at boost-consulting.com>
>Content-Type: text/plain; charset=gb2312
>
>"????" <tlovexyj at 21cn.com> writes:
>
>> Hi,
>> 	How can I use boost::python and Python API at the same time?
>
>Just use them (?)  There's nothing to it.  You can find numerous
>examples in the libs/python/test subdirectory of your Boost CVS tree
>or in http://www.boost.org/libs/python/test/.
>
>> 	So, Which lib is the right lib I must link? It's
>> 	boost_python_debug.lib or boost_python_pydebug.lib?  Thanks for
>> 	reply~
>
>http://www.boost.org/libs/python/doc/building.html#variants should
>answer your question.  If not, please ask.
>
>-- 
>Dave Abrahams
>Boost Consulting
>http://www.boost-consulting.com
>
>
>
>------------------------------
>
>Message: 2
>Date: Thu, 14 Oct 2004 10:10:04 -0400
>From: David Abrahams <dave at boost-consulting.com>
>Subject: [C++-sig] Re: Embedding python and sigint
>To: c++-sig at python.org
>Message-ID: <uvfddtmpv.fsf at boost-consulting.com>
>Content-Type: text/plain; charset=us-ascii
>
>Brian Murphy <brian.p.murphy at gmail.com> writes:
>
>> Hi,
>> I have embedded python sucessfully in my multithreaded application but
>> I have one problem. It seems that when I initialize the interpreter,
>> sigint(ctrl-c) gets swallowed. I am running Fedora Core 2 and Python
>> 2.3 compiled to a shared library. Is there any way; apart from writing
>> my own signal handler and binding it to sigint, to allow normal
>> sigints ?
>
>Brian, 
>
>Sounds like this is not a C++-specific question.  You might get
>better answers on comp.lang.python.
>
>-- 
>Dave Abrahams
>Boost Consulting
>http://www.boost-consulting.com
>
>
>
>------------------------------
>
>_______________________________________________
>C++-sig mailing list
>C++-sig at python.org
>http://mail.python.org/mailman/listinfo/c++-sig
>
>
>End of C++-sig Digest, Vol 15, Issue 9
>**************************************
>
>.


From lists.python.org at bdash.net.nz  Sun Oct 17 11:44:08 2004
From: lists.python.org at bdash.net.nz (Mark Rowe)
Date: Sun, 17 Oct 2004 22:44:08 +1300
Subject: [C++-sig] Problem With Calling Methods on Python Subclasses from C++
Message-ID: <175B9E0B-2021-11D9-B9C4-000A95D05654@bdash.net.nz>

Hi,

I am working on wrapping a C++ library using Boost::Python but have run 
into a small problem with polymorphic behaviour.

Basically, I have four classes exposed to Python - MainClass, 
ErrorHandler, Error and AnError.  AnError derives from Error.  When 
ErrorHandler is subclassed from Python and the handleError method of an 
instance of the Python subclass is called from C++ with an AnError 
instance as an argument, the argument arrives as an Error type.  I 
realise that this description is relatively confusing, so I have 
attached the C++ code and a failing Python unittest that demonstrates 
the problem I am encountering.

I hope that someone can clear this issue up for me.

Regards,

Mark Rowe
<http://bdash.net.nz/>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041017/eec66a15/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.py
Type: application/octet-stream
Size: 599 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041017/eec66a15/attachment.obj>

From dave at boost-consulting.com  Sun Oct 17 17:33:07 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 17 Oct 2004 11:33:07 -0400
Subject: [C++-sig] Re: Problem With Calling Methods on Python Subclasses
	from C++
In-Reply-To: <175B9E0B-2021-11D9-B9C4-000A95D05654@bdash.net.nz> (Mark Rowe's
	message of "Sun, 17 Oct 2004 22:44:08 +1300")
References: <175B9E0B-2021-11D9-B9C4-000A95D05654@bdash.net.nz>
Message-ID: <u7jpptl58.fsf@boost-consulting.com>

Mark Rowe <lists.python.org at bdash.net.nz> writes:

> class _ErrorHandlerWrapper : public ErrorHandler, public wrapper<ErrorHandler>
> {
>     public:
>         virtual void handleError(const Error & err) const {
>             if (override f = this->get_override("handleError"))
>             {
>                 f(err);

If you want the type of err to be preserved, you have to pass it by
reference:

                  f(boost::ref(f));

>             }
>             else
>                 ErrorHandler::handleError(err);
>         }
> };

Boost.Python never passes anything by reference, by default, because
it's unsafe: it can lead to dangling pointers.  It would be very
interesting to consider copying and passing whole most-derived class
instances by value, but that's not implemented.

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



From lists.python.org at bdash.net.nz  Mon Oct 18 02:34:57 2004
From: lists.python.org at bdash.net.nz (Mark Rowe)
Date: Mon, 18 Oct 2004 13:34:57 +1300
Subject: [C++-sig] Re: Problem With Calling Methods on Python Subclasses
	from C++
In-Reply-To: <u7jpptl58.fsf@boost-consulting.com>
References: <175B9E0B-2021-11D9-B9C4-000A95D05654@bdash.net.nz>
	<u7jpptl58.fsf@boost-consulting.com>
Message-ID: <89EB7941-209D-11D9-99E6-000A95D05654@bdash.net.nz>


On Oct 18, 2004, at 4:33 AM, David Abrahams wrote:

> If you want the type of err to be preserved, you have to pass it by
> reference:
>
>                   f(boost::ref(f));

Thanks very much!  A nice simple solution is always promising :-)

Kind Regards,

Mark Rowe
<http://bdash.net.nz/>



From agurtovoy at meta-comm.com  Mon Oct 18 23:51:01 2004
From: agurtovoy at meta-comm.com (Aleksey Gurtovoy)
Date: Mon, 18 Oct 2004 16:51:01 -0500
Subject: [C++-sig] const_argument test failures
Message-ID: <058a01c4b55c$95e07370$f977d70c@metacomm.com>

The comment in the test says:

 * The purpose of this test is to determine if a function can be called from
 * Python with a const value type as an argument, and whether or not the 
 * presence of a prototype without the cv-qualifier will work around the
 * compiler's bug.

So, OK, the first part of it fails on MSVC < 7.1, naturally, due to the same 
bug that makes the following to fail:

    template< typename T > void f(void (*)(T));
    void g(int const);

    int main()
    {
        f(g);   // error C2664: 'f' : cannot convert parameter 1 from 
                // 'void (const int)' to 'void (__cdecl *)(int)'

        return 0;
    }

The second part of the test "passes", but of course we'll never see it in
the reports.

So, the question is: what exactly was the original plan for this in terms 
of its presence in the regression reports? 

Right now the failures represented by yellow cells, and I'd like to see 
them cleared up, whether it's done through "explicit-failures-markup.xml"
or through appropriate #ifdef-s in the file itself.

--
Aleksey Gurtovoy
MetaCommunications Engineering



From jbrandmeyer at earthlink.net  Tue Oct 19 04:49:02 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Mon, 18 Oct 2004 22:49:02 -0400
Subject: [C++-sig] const_argument test failures
In-Reply-To: <058a01c4b55c$95e07370$f977d70c@metacomm.com>
References: <058a01c4b55c$95e07370$f977d70c@metacomm.com>
Message-ID: <1098154142.20288.33.camel@illuvatar>

On Mon, 2004-10-18 at 17:51, Aleksey Gurtovoy wrote:
> The comment in the test says:
> 
>  * The purpose of this test is to determine if a function can be called from
>  * Python with a const value type as an argument, and whether or not the 
>  * presence of a prototype without the cv-qualifier will work around the
>  * compiler's bug.
> 
> So, OK, the first part of it fails on MSVC < 7.1, naturally, due to the same 
> bug that makes the following to fail:
> 
>     template< typename T > void f(void (*)(T));
>     void g(int const);
> 
>     int main()
>     {
>         f(g);   // error C2664: 'f' : cannot convert parameter 1 from 
>                 // 'void (const int)' to 'void (__cdecl *)(int)'
> 
>         return 0;
>     }
> 
> The second part of the test "passes", but of course we'll never see it in
> the reports.
> 
> So, the question is: what exactly was the original plan for this in terms 
> of its presence in the regression reports? 

The "plan" was to see which compilers were affected by this bug.  It was
motivated by the thread "Slice test fails on Intel 8.1 at runtime" which
ran from 9/25 to 9/27.  When this test was originally added all versions
of MSVC and some (all?) versions of intel-win32 were affected.  MSVC 7.0
and newer would fail at runtime in the same way that vc7 is failing now,
and < 7.0 would fail at compile time.  At least one platform (icc 8.1 on
win32) had no source-level workaround at all that I knew of.  Apparently
something has changed since then since these toolchains are passing now.

Are the older regression reports still available somewhere?  If so, I
can search through them to find out when these tests started passing.

> Right now the failures represented by yellow cells, and I'd like to see 
> them cleared up, whether it's done through "explicit-failures-markup.xml"
> or through appropriate #ifdef-s in the file itself.

I can add an #ifdef for MSVC < 7.0, since that is a known source-level
workaround.  After I figure out what changed to let the newer toolkits
pass, maybe that can be applied to the vc7 toolkit.  Otherwise, I think
the only option for vc7 is to add it to explicit-failures-markup.xml.

-Jonathan



From dave at boost-consulting.com  Tue Oct 19 19:50:54 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 19 Oct 2004 13:50:54 -0400
Subject: [C++-sig] Re: const_argument test failures
In-Reply-To: <1098154142.20288.33.camel@illuvatar>
References: <058a01c4b55c$95e07370$f977d70c@metacomm.com>
	<1098154142.20288.33.camel@illuvatar>
Message-ID: <417553FE.8070600@boost-consulting.com>

Jonathan Brandmeyer wrote:
> On Mon, 2004-10-18 at 17:51, Aleksey Gurtovoy wrote:
> 
>>The comment in the test says:
>>
>> * The purpose of this test is to determine if a function can be called from
>> * Python with a const value type as an argument, and whether or not the 
>> * presence of a prototype without the cv-qualifier will work around the
>> * compiler's bug.
>>
>>So, OK, the first part of it fails on MSVC < 7.1, naturally, due to the same 
>>bug that makes the following to fail:
>>
>>    template< typename T > void f(void (*)(T));
>>    void g(int const);
>>
>>    int main()
>>    {
>>        f(g);   // error C2664: 'f' : cannot convert parameter 1 from 
>>                // 'void (const int)' to 'void (__cdecl *)(int)'
>>
>>        return 0;
>>    }
>>
>>The second part of the test "passes", but of course we'll never see it in
>>the reports.
>>
>>So, the question is: what exactly was the original plan for this in terms 
>>of its presence in the regression reports? 
> 
> 
> The "plan" was to see which compilers were affected by this bug.  It was
> motivated by the thread "Slice test fails on Intel 8.1 at runtime" which
> ran from 9/25 to 9/27.  When this test was originally added all versions
> of MSVC and some (all?) versions of intel-win32 were affected.  MSVC 7.0
> and newer would fail at runtime in the same way that vc7 is failing now,
> and < 7.0 would fail at compile time.  At least one platform (icc 8.1 on
> win32) had no source-level workaround at all that I knew of.  Apparently
> something has changed since then since these toolchains are passing now.

This compiler bug should have been worked around on
every platform that has partial specialization (the test passes for me 
with vc7.1), and it can be made to work on VC6/7 with

	BOOST_TT_BROKEN_COMPILER_SPEC( object )

It's not entirely clear whether we should put that in to make the test 
pass on vc6/7, but I am surprised that this test is causing any issue at 
this point.
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Tue Oct 19 19:51:10 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 19 Oct 2004 13:51:10 -0400
Subject: [C++-sig] Re: const_argument test failures
In-Reply-To: <1098154142.20288.33.camel@illuvatar>
References: <058a01c4b55c$95e07370$f977d70c@metacomm.com>
	<1098154142.20288.33.camel@illuvatar>
Message-ID: <4175540E.9000905@boost-consulting.com>

Jonathan Brandmeyer wrote:
> On Mon, 2004-10-18 at 17:51, Aleksey Gurtovoy wrote:
> 
>>The comment in the test says:
>>
>> * The purpose of this test is to determine if a function can be called from
>> * Python with a const value type as an argument, and whether or not the 
>> * presence of a prototype without the cv-qualifier will work around the
>> * compiler's bug.
>>
>>So, OK, the first part of it fails on MSVC < 7.1, naturally, due to the same 
>>bug that makes the following to fail:
>>
>>    template< typename T > void f(void (*)(T));
>>    void g(int const);
>>
>>    int main()
>>    {
>>        f(g);   // error C2664: 'f' : cannot convert parameter 1 from 
>>                // 'void (const int)' to 'void (__cdecl *)(int)'
>>
>>        return 0;
>>    }
>>
>>The second part of the test "passes", but of course we'll never see it in
>>the reports.
>>
>>So, the question is: what exactly was the original plan for this in terms 
>>of its presence in the regression reports? 
> 
> 
> The "plan" was to see which compilers were affected by this bug.  It was
> motivated by the thread "Slice test fails on Intel 8.1 at runtime" which
> ran from 9/25 to 9/27.  When this test was originally added all versions
> of MSVC and some (all?) versions of intel-win32 were affected.  MSVC 7.0
> and newer would fail at runtime in the same way that vc7 is failing now,
> and < 7.0 would fail at compile time.  At least one platform (icc 8.1 on
> win32) had no source-level workaround at all that I knew of.  Apparently
> something has changed since then since these toolchains are passing now.

This compiler bug should have been worked around on
every platform that has partial specialization (the test passes for me 
with vc7.1), and it can be made to work on VC6/7 with

	BOOST_TT_BROKEN_COMPILER_SPEC( object )

It's not entirely clear whether we should put that in to make the test 
pass on vc6/7, but I am surprised that this test is causing any issue at 
this point.
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From agurtovoy at meta-comm.com  Wed Oct 20 01:01:15 2004
From: agurtovoy at meta-comm.com (Aleksey Gurtovoy)
Date: Tue, 19 Oct 2004 18:01:15 -0500
Subject: [C++-sig] Re: const_argument test failures
References: <058a01c4b55c$95e07370$f977d70c@metacomm.com><1098154142.20288.33.camel@illuvatar>
	<417553FE.8070600@boost-consulting.com>
Message-ID: <0d2c01c4b62f$8c14fb80$f977d70c@metacomm.com>

David Abrahams writes:
> Jonathan Brandmeyer wrote:
> > The "plan" was to see which compilers were affected by this bug.  It was
> > motivated by the thread "Slice test fails on Intel 8.1 at runtime" which
> > ran from 9/25 to 9/27.  When this test was originally added all versions
> > of MSVC and some (all?) versions of intel-win32 were affected.  MSVC 7.0
> > and newer would fail at runtime in the same way that vc7 is failing now,
> > and < 7.0 would fail at compile time.  At least one platform (icc 8.1 on
> > win32) had no source-level workaround at all that I knew of.  Apparently
> > something has changed since then since these toolchains are passing now.
> 
> This compiler bug should have been worked around on
> every platform that has partial specialization 

Definitely possible, but then all platforms that support partial 
specialization don't have a problem _compiling_ the code. I'm not sure how
run-time failures come into picture here.

> (the test passes for me with vc7.1), 

That's because the bug was fixed in the compiler.

> and it can be made to work on VC6/7 with
> 
> BOOST_TT_BROKEN_COMPILER_SPEC( object )

I don't see how this one would help, though.

--
Aleksey Gurtovoy
MetaCommunications Engineering



From agurtovoy at meta-comm.com  Wed Oct 20 01:01:34 2004
From: agurtovoy at meta-comm.com (Aleksey Gurtovoy)
Date: Tue, 19 Oct 2004 18:01:34 -0500
Subject: [C++-sig] const_argument test failures
References: <058a01c4b55c$95e07370$f977d70c@metacomm.com>
	<1098154142.20288.33.camel@illuvatar>
Message-ID: <0d2d01c4b62f$979ec760$f977d70c@metacomm.com>

Jonathan Brandmeyer writes:
> On Mon, 2004-10-18 at 17:51, Aleksey Gurtovoy wrote:
> > The comment in the test says:
> > 
> >  * The purpose of this test is to determine if a function can be called from
> >  * Python with a const value type as an argument, and whether or not the 
> >  * presence of a prototype without the cv-qualifier will work around the
> >  * compiler's bug.
> > 
> > So, OK, the first part of it fails on MSVC < 7.1, naturally, due to the same 
> > bug that makes the following to fail:
> > 
> >     template< typename T > void f(void (*)(T));
> >     void g(int const);
> > 
> >     int main()
> >     {
> >         f(g);   // error C2664: 'f' : cannot convert parameter 1 from 
> >                 // 'void (const int)' to 'void (__cdecl *)(int)'
> > 
> >         return 0;
> >     }
> > 
> > The second part of the test "passes", but of course we'll never see it in
> > the reports.
> > 
> > So, the question is: what exactly was the original plan for this in terms 
> > of its presence in the regression reports? 
> 
> The "plan" was to see which compilers were affected by this bug.  It was
> motivated by the thread "Slice test fails on Intel 8.1 at runtime" which
> ran from 9/25 to 9/27.  When this test was originally added all versions
> of MSVC and some (all?) versions of intel-win32 were affected.  MSVC 7.0
> and newer would fail at runtime in the same way that vc7 is failing now,

Could you explain how something like this turns into a run-time failure?

> and < 7.0 would fail at compile time.  

OK.

> At least one platform (icc 8.1 on
> win32) had no source-level workaround at all that I knew of.  Apparently
> something has changed since then since these toolchains are passing now.

May be some toolset options has been changed, but I doubt it.


> Are the older regression reports still available somewhere?  

Unfortunately, no. We used to keep reports history, but the setup was
never restored after a move to another machine. It's on our TODO list (not
that it helps right now).

> If so, I
> can search through them to find out when these tests started passing.
> 
> > Right now the failures represented by yellow cells, and I'd like to see 
> > them cleared up, whether it's done through "explicit-failures-markup.xml"
> > or through appropriate #ifdef-s in the file itself.
> 
> I can add an #ifdef for MSVC < 7.0, since that is a known source-level
> workaround.  After I figure out what changed to let the newer toolkits
> pass, maybe that can be applied to the vc7 toolkit.  Otherwise, I think
> the only option for vc7 is to add it to explicit-failures-markup.xml.

David, would you be OK with this?

--
Aleksey Gurtovoy
MetaCommunications Engineering



From dave at boost-consulting.com  Wed Oct 20 08:01:15 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 20 Oct 2004 02:01:15 -0400
Subject: [C++-sig] Re: const_argument test failures
References: <058a01c4b55c$95e07370$f977d70c@metacomm.com>
	<1098154142.20288.33.camel@illuvatar>
	<0d2d01c4b62f$979ec760$f977d70c@metacomm.com>
Message-ID: <umzyiudw4.fsf@boost-consulting.com>

"Aleksey Gurtovoy" <agurtovoy at meta-comm.com> writes:

>> At least one platform (icc 8.1 on
>> win32) had no source-level workaround at all that I knew of.  Apparently
>> something has changed since then since these toolchains are passing now.
>
> May be some toolset options has been changed, but I doubt it.

I implemented a workaround.

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



From agurtovoy at meta-comm.com  Wed Oct 20 14:14:58 2004
From: agurtovoy at meta-comm.com (Aleksey Gurtovoy)
Date: Wed, 20 Oct 2004 07:14:58 -0500
Subject: [C++-sig] Re: const_argument test failures
In-Reply-To: <uoeiyym0n.fsf@boost-consulting.com> (David Abrahams's message
	of "Wed, 20 Oct 2004 01:52:08 -0400")
References: <058a01c4b55c$95e07370$f977d70c@metacomm.com>
	<1098154142.20288.33.camel@illuvatar>
	<417553FE.8070600@boost-consulting.com>
	<0d2c01c4b62f$8c14fb80$f977d70c@metacomm.com>
	<uoeiyym0n.fsf@boost-consulting.com>
Message-ID: <m2u0sptwl9.fsf@meta-comm.com>

David Abrahams writes:
>>> This compiler bug should have been worked around on
>>> every platform that has partial specialization 
>>
>> Definitely possible, but then all platforms that support partial
>> specialization don't have a problem _compiling_ the code. I'm not
>> sure how run-time failures come into picture here.
>
> The type of the argument is translated into a typeid, and type
> converters are registered against a typeid.  If the type of the
> argument is wrong, it won't find the right registered converter.

Got it.

>
>>> (the test passes for me with vc7.1), 
>>
>> That's because the bug was fixed in the compiler.
>
> I don't think so.  It used to fail on vc7.1 IIUC.  I certainly ran
> the test, had it fail, applied a workaround, and had the test pass on
> some compiler.

We are talking about slightly different bugs here. On MSVC 6.5 the
following simply doesn't compile (bug #1):

    template< typename T > void f(void (*)(T));
    void g(int const);

    int main()
    {
        f(g);
    }

On VC 7 and higher it does, but T is deduced as 'int const' (bug #2).

>
>>> and it can be made to work on VC6/7 with
>>> 
>>> BOOST_TT_BROKEN_COMPILER_SPEC( object )
>>
>> I don't see how this one would help, though.
>
> It allows the workaround, which involves remove_cv, to work.

... taking care of the run-time failure. Got it. I was saying that it
won't help to get 'get_signature' compile on MSVC 6.5.

-- 
Aleksey Gurtovoy
MetaCommunications Engineering



From dimour at mail.ru  Wed Oct 20 14:22:51 2004
From: dimour at mail.ru (Dmitri Mouromtsev)
Date: Wed, 20 Oct 2004 16:22:51 +0400
Subject: [C++-sig] pickling new-style classes object
Message-ID: <14610281645.20041020162251@mail.ru>

Hello All,

Is it possible to customize pickling for class objects?
or these are pickled only by name using default implementation.

I need to save and restore custom class definition in different Python
sessions. For example:

  class Prototype(type):
    def __init__(cls, name, bases, dict):
      super(Prototype, cls).__init__(name, bases, dict)

  class C(object):
    __metaclass__ = Prototype

    def __init__(self, name):
      self.__name__ = name

If I define new class

  class New(C): pass
  New.a = 35
  New.b = 'string'

and new instance of 'New':

  x = New('New')

And trying to save 'New' and 'x':

  file = open('pickle_New.txt', 'w')
  dump(New, file)
  file = open('pickle_x.txt', 'w')
  dump(x, file)

I have only 'x' state saved.
__getstate__ and __setstate__ are not called for class instances(New).
What is the problem? Is there another way to resolve this problem?

Thanks.
Dmitri




From tlovexyj at 21cn.com  Fri Oct 22 04:08:40 2004
From: tlovexyj at 21cn.com (????)
Date: Fri, 22 Oct 2004 10:08:40 +0800
Subject: [C++-sig] re: How can I use boost::python and Python API at the
	same time
Message-ID: <sr958977899392.01648@send4.inner-21cn.com>

Hi,

  I have allready complied boost::python and I have four lib named boost_python_pydebug.lib, boost_python_debug.lib, boost_python.lib and libboost_python_debug.lib. If I use boost::python only and link boost_python_debug.lib, it's all fine. 

  And I checked up the application need boost_python_debug.dll and python22.dll. When I use python API in this same code, then the python.h will be include, so it link the python22_d.lib in the pyconfig.h automatic. It means the application will be need python22_d.dll, OMG!!! If my poor application running, it will crash when I get the __main__ dict, because boost::python use python22.dll but python API use python22_d.dll, python initialize twice... oops~
  
  sorry for my poor english!



From agurtovoy at meta-comm.com  Sun Oct 24 09:33:39 2004
From: agurtovoy at meta-comm.com (Aleksey Gurtovoy)
Date: Sun, 24 Oct 2004 02:33:39 -0500
Subject: [C++-sig] Re: const_argument test failures
References: <058a01c4b55c$95e07370$f977d70c@metacomm.com><1098154142.20288.33.camel@illuvatar><417553FE.8070600@boost-consulting.com><0d2c01c4b62f$8c14fb80$f977d70c@metacomm.com><uoeiyym0n.fsf@boost-consulting.com>
	<m2u0sptwl9.fsf@meta-comm.com>
Message-ID: <01b201c4b99b$c7b4a270$5b44a8c0@metacomm.com>

Aleksey Gurtovoy writes:
> David Abrahams writes:
> >>> This compiler bug should have been worked around on
> >>> every platform that has partial specialization 
> >>
> >> Definitely possible, but then all platforms that support partial
> >> specialization don't have a problem _compiling_ the code. I'm not
> >> sure how run-time failures come into picture here.
> >
> > The type of the argument is translated into a typeid, and type
> > converters are registered against a typeid.  If the type of the
> > argument is wrong, it won't find the right registered converter.
> 
> Got it.
> 
> >
> >>> (the test passes for me with vc7.1), 
> >>
> >> That's because the bug was fixed in the compiler.
> >
> > I don't think so.  It used to fail on vc7.1 IIUC.  I certainly ran
> > the test, had it fail, applied a workaround, and had the test pass on
> > some compiler.
> 
> We are talking about slightly different bugs here. On MSVC 6.5 the
> following simply doesn't compile (bug #1):
> 
>     template< typename T > void f(void (*)(T));
>     void g(int const);
> 
>     int main()
>     {
>         f(g);
>     }
> 
> On VC 7 and higher it does, but T is deduced as 'int const' (bug #2).
> 
> >
> >>> and it can be made to work on VC6/7 with
> >>> 
> >>> BOOST_TT_BROKEN_COMPILER_SPEC( object )
> >>
> >> I don't see how this one would help, though.
> >
> > It allows the workaround, which involves remove_cv, to work.
> 
> ... taking care of the run-time failure. Got it. I was saying that it
> won't help to get 'get_signature' compile on MSVC 6.5.

I took care of it (both in the main trunk and the release branch).

--
Aleksey Gurtovoy
MetaCommunications Engineering



From dave at boost-consulting.com  Sun Oct 24 18:31:45 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 24 Oct 2004 09:31:45 -0700
Subject: [C++-sig] Re: const_argument test failures
References: <058a01c4b55c$95e07370$f977d70c@metacomm.com>
	<1098154142.20288.33.camel@illuvatar>
	<417553FE.8070600@boost-consulting.com>
	<0d2c01c4b62f$8c14fb80$f977d70c@metacomm.com>
	<uoeiyym0n.fsf@boost-consulting.com> <m2u0sptwl9.fsf@meta-comm.com>
	<01b201c4b99b$c7b4a270$5b44a8c0@metacomm.com>
Message-ID: <u4qkkm61a.fsf@boost-consulting.com>

"Aleksey Gurtovoy" <agurtovoy at meta-comm.com> writes:

>> ... taking care of the run-time failure. Got it. I was saying that it
>> won't help to get 'get_signature' compile on MSVC 6.5.
>
> I took care of it (both in the main trunk and the release branch).

Thank you!!

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



From john at johnmeinel.com  Sun Oct 31 17:49:48 2004
From: john at johnmeinel.com (John Meinel)
Date: Sun, 31 Oct 2004 10:49:48 -0600
Subject: [C++-sig] shared_ptr<Object>
Message-ID: <418517AC.8090502@johnmeinel.com>

I found an old post on how to handle handing around shared_ptr<Object> 
instead of Object.
http://mail.python.org/pipermail/c++-sig/2004-August/007873.html

However, I don't know how to do it when you have a virtual object that 
you want to allow inheritance from in Python.

Attached is a sample version of what I'm doing. Basically, I have a base 
class which allows introspection into the type. This gets overridden my 
a virtual child, which provides some functionality. And then finally you 
have private grand-children which actually implement this functionality.

So what goes wrong with this situation:

1) If I pass no_init to a pure-virtual object with a wrapper, I cannot
    inherit from it in Python. because I cannot call __init__ to create
    the C++ object. And if I don't call __init__, then when a function
    wants my inherited class, it fails with "did not match C++ signature"

2) Without no_init, it will compile, but I can directly create an object
    of that type, which will cause "unidentifiable C++ exception" when
    you try to call the function. I assume this is because it is calling
    the wrapper function overload, which tries to access an invalid
    member function. I can live with this, but I would have really liked
    the safety of no_init

3) If I add shared_ptr<mine> to the class_<> definition, I get "too
    many template parameters" error. If I replace the mine_w with
    shared_ptr<mine> then it will allow me to return a shared_ptr, but
    not inherit the C++ object in python.
    If I try to do shared_ptr<mine_w>, then I still cannot create a
    shared_ptr<mine>.

4) In my base class, I have whoami() as virtual. I override it in mine
    which works fine. But I cannot override it again, without adding a
    re-definition of "whoami". This is probably un-avoidable, especially
    since I need to create a default-overload.

I also saw this post:
http://mail.python.org/pipermail/c++-sig/2004-October/008157.html

Which has stuff like "get_override" and "public wrapper<>". Is this a 
better way to do the python wrapping. It's not in the tutorial, and the 
documentation in general seems pretty weak. I also didn't find it in the 
documentation.
http://www.boost.org/libs/python/doc/v2/reference.html

Thanks for your help.
John
=:->
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: python_shared_ptr.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041031/b201f57c/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.py
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041031/b201f57c/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041031/b201f57c/attachment.pgp>

From dave at boost-consulting.com  Sun Oct 31 18:19:51 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 31 Oct 2004 12:19:51 -0500
Subject: [C++-sig] Re: shared_ptr<Object>
References: <418517AC.8090502@johnmeinel.com>
Message-ID: <usm7uls94.fsf@boost-consulting.com>

John Meinel <john at johnmeinel.com> writes:


I have lots of questions about your questions, but see ******** below
before answering.

> I found an old post on how to handle handing around shared_ptr<Object>
> instead of Object.
> http://mail.python.org/pipermail/c++-sig/2004-August/007873.html
>
> However, I don't know how to do it when you have a virtual object 

What's a virtual object?  An instance of a class with virtual
functions?


> that you want to allow inheritance from in Python.
>
> Attached is a sample version of what I'm doing. Basically, I have a
> base class which allows introspection into the type. This gets
> overridden my a virtual child, which provides some functionality. And
> then finally you have private grand-children which actually implement
> this functionality.
>
> So what goes wrong with this situation:
>
> 1) If I pass no_init to a pure-virtual object 

What is a pure-virtual object?

>     with a wrapper, I cannot
>     inherit from it in Python. because I cannot call __init__ to create
>     the C++ object. And if I don't call __init__, then when a function
>     wants my inherited class, it fails with "did not match C++ signature"
>
> 2) Without no_init, it will compile, but I can directly create an object
>     of that type, which will cause "unidentifiable C++ exception" when
>     you try to call the function. 

That probably means your application is actually crashing, which is
usually not an error on the part of the library.  I assume you're on
Windows.  If so, #include this file in one of your source files:

http://www.boost.org/libs/python/test/module_tail.cpp

and when your application crashes you'll be able to see where it is
in the debugger.

>     I assume this is because it is calling the wrapper function
>     overload, 

I don't know what overload you're speaking of.  Do you mean
"override?"

>     which tries to access an invalid member function. 

What invalid member function do you think it's trying to access?  I
suggest you look at this in the debugger.  I'm fairly certain your
assumption is wrong.

>     I can live with this, but I would have really liked the safety
>     of no_init
>
> 3) If I add shared_ptr<mine> to the class_<> definition, I get "too
>     many template parameters" error. 

Please show code that produces the error... otherwise I will assume
you just added it 

>     If I replace the mine_w with shared_ptr<mine> then it will allow
>     me to return a shared_ptr, but not inherit the C++ object in
>     python.

What happens that indicates to you that it will "not allow you to
inherit the C++ object" in python?  BTW, you can't "inherit a C++
object."  I think I know what you mean, but using clear and correct
terminology will help me to help you.

>     If I try to do shared_ptr<mine_w>, then I still cannot create a
>     shared_ptr<mine>.

What happens that indicates to you that "still cannot create a
shared_ptr<mine>."

*************

Did you try using 

  implicitly_convertible<shared_ptr<mine_w>, shared_ptr<mine> >()

??

Did you try using 

  register_ptr_to_python<shared_ptr<mine> >()

??

> 4) In my base class, I have whoami() as virtual. I override it in mine
>     which works fine. But I cannot override it again, without adding a
>     re-definition of "whoami". This is probably un-avoidable, especially
>     since I need to create a default-overload.
>
> I also saw this post:
> http://mail.python.org/pipermail/c++-sig/2004-October/008157.html
>
> Which has stuff like "get_override" and "public wrapper<>". Is this a
> better way to do the python wrapping. 

Yes, if you have the latest Boost CVS state.  If not, you can't use
it.

> It's not in the tutorial

It will be, in the upcoming release.

> and the documentation in general seems pretty weak. 

What's weak about it?

> I also didn't
> find it in the documentation.
> http://www.boost.org/libs/python/doc/v2/reference.html

That's because it's not released yet.

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



From john at johnmeinel.com  Sun Oct 31 19:18:48 2004
From: john at johnmeinel.com (John Meinel)
Date: Sun, 31 Oct 2004 12:18:48 -0600
Subject: [C++-sig] Re: shared_ptr<Object>
In-Reply-To: <usm7uls94.fsf@boost-consulting.com>
References: <418517AC.8090502@johnmeinel.com>
	<usm7uls94.fsf@boost-consulting.com>
Message-ID: <41852C88.9050700@johnmeinel.com>

David Abrahams wrote:
> John Meinel <john at johnmeinel.com> writes:
> 
> 
> I have lots of questions about your questions, but see ******** below
> before answering.
> 

I recognized I use the wrong terms in several places. Using "object" 
instead of "class", etc. However, your ***** was what I needed, as:
http://www.boost.org/libs/python/doc/v2/register_ptr_to_python.html#register_ptr_to_python-spec

Is pretty much exactly what I am doing, just with a little more hierarchy.


[...]

> 
> Please show code that produces the error... otherwise I will assume
> you just added it 
> 
If you change the line:
	class_<mine, mine_w, bases<parent>, boost::noncopyable>("mine")
To:
	class_<mine, boost::shared_ptr<mine>, mine_w
		, bases<parent>, boost::noncopyable>("mine")

It will not compile.

> 
> What happens that indicates to you that it will "not allow you to
> inherit the C++ object" in python?  BTW, you can't "inherit a C++
> object."  I think I know what you mean, but using clear and correct
> terminology will help me to help you.
> 

Sorry, again here I meant I cannot create a Python class that inherits 
properly from the C++ class. From my limited understanding, I could 
either use:

class_<mine, shared_ptr<mine>, ...>
or
class_<mine, mine_w, ...>

The second would let me inherit in Python, the first would let me return 
shared_ptr<mine> objects.

> 
>>    If I try to do shared_ptr<mine_w>, then I still cannot create a
>>    shared_ptr<mine>.
> 
> 
> What happens that indicates to you that "still cannot create a
> shared_ptr<mine>."
> 

If I used:
class_<mine, shared_ptr<mine_w>, ...>
then if I called a function with:

shared_ptr<mine> create() { return shared_ptr<mine>(new child); }
I would get "no to-python converter registered for type ...".


> *************
> 
> Did you try using 
> 
>   implicitly_convertible<shared_ptr<mine_w>, shared_ptr<mine> >()
> 
> ??
> 
> Did you try using 
> 
>   register_ptr_to_python<shared_ptr<mine> >()
> 
> ??
> 

Just to clarify, should I use both? I think if I use:
class_<mine, mine_w, bases<...>, boost::noncopyable> ...
register_ptr_to_python<shared_ptr<mine> >();

Then the above function "create" would work. But do I need the 
"implicitly_convertible" in the case where I have create a Python class, 
and then I want to pass that into a C++ function that wants a 
shared_ptr? Or do I need to define my base class as:
class_<mine, shared_ptr<mine_w>, ...
to make both cases work?

> 
[...]

>>
>>Which has stuff like "get_override" and "public wrapper<>". Is this a
>>better way to do the python wrapping. 
> 
> 
> Yes, if you have the latest Boost CVS state.  If not, you can't use
> it.
> 
> 
>>It's not in the tutorial
> 
> 
> It will be, in the upcoming release.
> 
> 
>>and the documentation in general seems pretty weak. 
> 
> 
> What's weak about it?
> 

The documentation seems decent if you already know what to look for. 
Like once you told me about "register_ptr_to_python" it has a good 
example, and it fits what I need.

But there isn't a very good overview. The tutorial is very good for 
starting out, but doesn't cover the more advanced topics. I suppose one 
possibility is to just read *all* of the documentation, but when I first 
started out, it got so technical in places that it stopped making sense. 
It seemed like it was more for people who were trying to understand the 
implementation, rather than how to use it.

> 
>>I also didn't
>>find it in the documentation.
>>http://www.boost.org/libs/python/doc/v2/reference.html
> 
> 
> That's because it's not released yet.
> 

Thank you for your time. I'm interested in what 1.32 is going to look 
like. In general I'm very happy with boost, and boost::python. A lot of 
times the documentation feels like reading commented source code, rather 
than a document describing how things should be used. I suppose that's 
what tutorials and possibly wikis are for.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20041031/61df3b4e/attachment.pgp>

From dave at boost-consulting.com  Sun Oct 31 21:57:33 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 31 Oct 2004 15:57:33 -0500
Subject: [C++-sig] Re: shared_ptr<Object>
References: <418517AC.8090502@johnmeinel.com>
	<usm7uls94.fsf@boost-consulting.com> <41852C88.9050700@johnmeinel.com>
Message-ID: <uhdoali6a.fsf@boost-consulting.com>

John Meinel <john at johnmeinel.com> writes:

> David Abrahams wrote:
>> John Meinel <john at johnmeinel.com> writes:
>> I have lots of questions about your questions, but see ********
>> below
>> before answering.
>> 
>
> I recognized I use the wrong terms in several places. Using "object"
> instead of "class", etc. However, your ***** was what I needed, as:
> http://www.boost.org/libs/python/doc/v2/register_ptr_to_python.html#register_ptr_to_python-spec
>
> Is pretty much exactly what I am doing, just with a little more hierarchy.
>
>
> [...]
>
>> Please show code that produces the error... otherwise I will assume
>> you just added it 
> If you change the line:
> 	class_<mine, mine_w, bases<parent>, boost::noncopyable>("mine")
> To:
> 	class_<mine, boost::shared_ptr<mine>, mine_w
> 		, bases<parent>, boost::noncopyable>("mine")
>
> It will not compile.

That's expected.  Does the documentation give you any reason to
believe that it should work?

>> What happens that indicates to you that it will "not allow you to
>> inherit the C++ object" in python?  BTW, you can't "inherit a C++
>> object."  I think I know what you mean, but using clear and correct
>> terminology will help me to help you.
>
> Sorry, again here I meant I cannot create a Python class that inherits
> properly from the C++ class. From my limited understanding, I could
> either use:
>
> class_<mine, shared_ptr<mine>, ...>
> or
> class_<mine, mine_w, ...>
>
> The second would let me inherit in Python, the first would let me
> return shared_ptr<mine> objects.

  class_<mine, shared_ptr<mine_w>, ...>

is supposed to work.

>> 
>>>    If I try to do shared_ptr<mine_w>, then I still cannot create a
>>>    shared_ptr<mine>.
>> What happens that indicates to you that "still cannot create a
>> shared_ptr<mine>."
>> 
>
> If I used:
> class_<mine, shared_ptr<mine_w>, ...>
> then if I called a function with:
>
> shared_ptr<mine> create() { return shared_ptr<mine>(new child); }
> I would get "no to-python converter registered for type ...".

Right.  Using shared_ptr<mine_w> as a template parameter here only
registers a to-python conversion for shared_ptr<mine_w>.  If you want
to convert a shared_ptr<mine> to python you need to explicitly
register the converter.

>> *************
>> Did you try using   implicitly_convertible<shared_ptr<mine_w>,
>> shared_ptr<mine> >()
>> ??
>> Did you try using   register_ptr_to_python<shared_ptr<mine> >()
>> ??
>> 
>
> Just to clarify, should I use both? 

No, actually the first one is totally unneeded.

> I think if I use:
> class_<mine, mine_w, bases<...>, boost::noncopyable> ...
> register_ptr_to_python<shared_ptr<mine> >();
>
> Then the above function "create" would work. But do I need the
> "implicitly_convertible" in the case where I have create a Python
> class, and then I want to pass that into a C++ function that wants a
> shared_ptr? Or do I need to define my base class as:
> class_<mine, shared_ptr<mine_w>, ...
> to make both cases work?

The latter.

> [...]
>
>>>
>>>Which has stuff like "get_override" and "public wrapper<>". Is this a
>>> better way to do the python wrapping. 
>> Yes, if you have the latest Boost CVS state.  If not, you can't use
>> it.
>> 
>>>It's not in the tutorial
>> It will be, in the upcoming release.
>> 
>>> and the documentation in general seems pretty weak. 
>> What's weak about it?
>> 
>
> The documentation seems decent if you already know what to look
> for. Like once you told me about "register_ptr_to_python" it has a
> good example, and it fits what I need.
>
> But there isn't a very good overview. The tutorial is very good for
> starting out, but doesn't cover the more advanced topics. I suppose
> one possibility is to just read *all* of the documentation, but when I
> first started out, it got so technical in places that it stopped
> making sense. It seemed like it was more for people who were trying to
> understand the implementation, rather than how to use it.

I think you're right.  The library needs an overview of how
conversions to and from python work.

>>>I also didn't
>>>find it in the documentation.
>>>http://www.boost.org/libs/python/doc/v2/reference.html
>> That's because it's not released yet.
>
> Thank you for your time. I'm interested in what 1.32 is going to
> look like. In general I'm very happy with boost, and
> boost::python. A lot of times the documentation feels like reading
> commented source code, rather than a document describing how things
> should be used.  I suppose that's what tutorials and possibly wikis
> are for.

Right; that's what the tutorial is for.  But some essays on select
topics (like conversions) would be very useful in addition to the
tutorial.  Unfortunately there are few resources available for
Boost.Python development (including further documentation) right now.
It would be nice if things were otherwise, but the project is quite
useful and stable, so I guess it's not too bad that it isn't moving
fast.

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