From k.dejong at geog.uu.nl  Mon Dec  1 09:38:49 2003
From: k.dejong at geog.uu.nl (Kor de Jong)
Date: Mon, 01 Dec 2003 09:38:49 +0100
Subject: [C++-sig] Problem using wrapped void* in Python
In-Reply-To: <20031129165252.53194.qmail@web20208.mail.yahoo.com>
References: <20031129165252.53194.qmail@web20208.mail.yahoo.com>
Message-ID: <3FCAFE19.5020208@geog.uu.nl>

Hi Ralf,

Thank you for your reply.

Ralf W. Grosse-Kunstleve wrote:
>>So, what I am looking for is a way to tell Boost.Python how to convert 
>>from void* to Python and back. I have tried various things, like the 
>>opaque_pointer_converter and the to_python_converter, but I end up with 
>>code which I don't understand anymore and/or which doesn't compile. I 
>>would be very grateful if one of you could provide me with a bit of code 
>>to get me going again.
> 
> 
> Recently Niall Douglas added this to the Boost.Python FAQ:
> 
> http://cci.lbl.gov/~rwgk/shortcuts/boost/libs/python/doc/v2/faq.html#voidptr
> 
> Does this help in your case?

I see how this works in the case of converting void* function arguments. 
This will be useful for me too. But in my current case I am wrapping a 
struct which has a void* datamember. Accessing the enum/int/string 
datamembers of the struct from Python goes fine, but accessing the void* 
datamember is a problem and gives:

TypeError: No to_python (by-value) converter found for C++ type: Pv

Again, I don't want to access the actual data pointed to by the pointer, 
I just want to pass it along to wrapped functions.

I might be missing something obvious, but the docs and mailinglist 
archives didn't help me further.

Does anyone have something to say about converting void* to Python and back?

Thanks,
Kor




From wl at flexis.de  Mon Dec  1 10:14:39 2003
From: wl at flexis.de (Wolfgang Langner)
Date: Mon, 01 Dec 2003 10:14:39 +0100
Subject: [C++-sig] Re: Boost.Python Deployment Dependencies
In-Reply-To: <200311271214.hARCEBq21406@ns.cricketthosting.co.uk>
References: <200311271214.hARCEBq21406@ns.cricketthosting.co.uk>
Message-ID: <bqf0pv$of8$1@sea.gmane.org>

Hi,

> I?m in the process of trying to deploy an application that uses 
> boost.python. I started off by just including the python23.dll (as well 
> as the boost.python dll), but when our python code is executed via 
> boost.python, we get an error suggesting that site.py cannot be found.
> 
> I then tried installing the python interpreter and libraries as well as 
> our new application, this worked. I then renamed the python23 
> directory, expecting our application to now fail. It didn?t. I am now 
> somewhat confused about what boost.python actually depends on????
> 
> I don?t want to have to install python on every machine where we want 
> to install our application, I want to be able to include the necessary 
> boost.python dependencies in our install script.
> 
> Any ideas?

Try to start your python programm with  "python -v prog.py"
then you get more info about what happens.

Now you can see what libs are needed.

If you start "python -v" without your prog name you can see what
files for a minimal python installation are needed.

bye by Wolfgang





From jacek.generowicz at cern.ch  Mon Dec  1 10:39:48 2003
From: jacek.generowicz at cern.ch (Jacek Generowicz)
Date: 01 Dec 2003 10:39:48 +0100
Subject: [C++-sig] Re: vector<foo*> -> list, preserving identity
References: <tyfbrqw39vg.fsf@pcepsft001.cern.ch> <u3cc8se8i.fsf@yahoo.co.uk>
Message-ID: <tyf1xro3mhn.fsf@pcepsft001.cern.ch>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> Jacek Generowicz <jacek.generowicz at cern.ch> writes:

[snip]

> > How should I write a converter for the std::vector<foo*>, in order to
> > preserve the identity of the foos ?
> >
> > (In the library I am wrapping, the return type of makefoos is actually
> > const std::vector<const foo*>&)
> 
> I'm not sure how you would handle this, except by switching to
> boost::shared_ptr instead of plain pointers. You would end up with
> something like this:
> 
> std::vector<boost::shared_ptr<const foo> > makefoos(int n) {
>   // ...
> }

Unfortunately "makefoos" is part of a library over which I have no
control, so I cannot make it return shared pointers.

> BOOST_PYTHON_MODULE( nocopy ) {
>   class_<foo, boost::shared_ptr<foo> >("foo", no_init)
>     .def("pointer", &foo::pointer);
> 
>   class_<std::vector<boost::shared_ptr<foo const> > > ("foo_vector")
>     .def (SOMETHING<std::vector<boost::shared_ptr<foo const> >());
> 
>   def ("makefoos", makefoos);
> }
> 
> Where SOMETHING would use either the current indexing suite (available
> from CVS)

Once again, I am obliged to use the local offical Boost version
(1.30.2, at the moment), as that is what my users have. The Boost
version I use is beyond my control.



How does reference_existing_object work?  Using it as the return value
policy for functions returning foo* preserves identity just fine.
It's just when I get a whole vector of them and try to put them in a
Python list that I don't seem to manage to avoid copying the objects
themselves.




From dave at boost-consulting.com  Mon Dec  1 12:01:09 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 01 Dec 2003 06:01:09 -0500
Subject: [C++-sig] Re: Problem using wrapped void* in Python
References: <20031129165252.53194.qmail@web20208.mail.yahoo.com>
	<3FCAFE19.5020208@geog.uu.nl>
Message-ID: <uk75gkdje.fsf@boost-consulting.com>

Kor de Jong <k.dejong at geog.uu.nl> writes:

> Hi Ralf,
>
> Thank you for your reply.
>
> Ralf W. Grosse-Kunstleve wrote:
>>> So, what I am looking for is a way to tell Boost.Python how to
>>> convert from void* to Python and back. I have tried various
>>> things, like the opaque_pointer_converter and the
>>> to_python_converter, but I end up with code which I don't
>>> understand anymore and/or which doesn't compile. I would be very
>>> grateful if one of you could provide me with a bit of code to
>>> get me going again.
>> Recently Niall Douglas added this to the Boost.Python FAQ:
>> http://cci.lbl.gov/~rwgk/shortcuts/boost/libs/python/doc/v2/faq.html#voidptr
>> Does this help in your case?
>
> I see how this works in the case of converting void* function
> arguments. This will be useful for me too. But in my current case I
> am wrapping a struct which has a void* datamember. Accessing the
> enum/int/string datamembers of the struct from Python goes fine,
> but accessing the void* datamember is a problem and gives:
>
> TypeError: No to_python (by-value) converter found for C++ type: Pv
>
> Again, I don't want to access the actual data pointed to by the
> pointer, I just want to pass it along to wrapped functions.
>
> I might be missing something obvious, but the docs and mailinglist
> archives didn't help me further.
>
> Does anyone have something to say about converting void* to Python and back?

If you want it to appear to be an attribute in Python, just write a
getter (and optional setter) function using the "opaque void_*"
technique, and use class_<...>.add_property("name", getter, setter) to
expose it.

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




From collar at gamic.com  Mon Dec  1 13:33:48 2003
From: collar at gamic.com (Benjamin Collar)
Date: Mon, 1 Dec 2003 13:33:48 +0100
Subject: [C++-sig] boost/python 2.3 + Qt -- Just a tip
Message-ID: <200312011333.49018.collar@gamic.com>

Greetings

I thought I'd offer a small tip to developers who use a combination of Qt and 
Python and boost. The word 'slots' is used by Qt (3.2.2) and is #defined to 
be empty when a certain macro is not defined.

====== (qt3/include/qobjectdefs.h:74)
...
#ifdef QT_MOC_CPP
#define slots                       slots
#define signals             signals
...
#else
#define slots                                   // slots: in class // line 88
#define signals protected                       // signals: in class
#ifndef QT_NO_EMIT
#define emit                                    // emit signal
#endif
======

The problem occurs when the developer includes headers from Qt before headers 
from boost or Python. In Python's object.h, there's this:

====== (python2.3/include/object.h:331)
typedef struct _heaptypeobject {
        /* Note: there's a dependency on the order of these members
           in slotptr() in typeobject.c . */
        PyTypeObject type;
        PyNumberMethods as_number;
        PyMappingMethods as_mapping;
        PySequenceMethods as_sequence; /* as_sequence comes after as_mapping,
                                          so that the mapping wins when both
                                          the mapping and the sequence define
                                          a given operator (e.g. __getitem__).
                                          see add_operators() in 
typeobject.c . 
*/
        PyBufferProcs as_buffer;
        PyObject *name, *slots;
        /* here are optional user slots, followed by the members. */
} PyHeapTypeObject;
======

If you include Qt files before anything from Python then you're the lucky 
winner of a syntax error. If you include everything boost before Qt then 
there's no problem.

Ben

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

(o__      Benjamin Collar
//\          GAMIC mbH  ++49 (0)241 889 110
V_/_      Developer/System Administrator 

To know recursion, you must first know recursion




From RaoulGough at yahoo.co.uk  Mon Dec  1 19:04:49 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Mon, 01 Dec 2003 18:04:49 +0000
Subject: [C++-sig] Re: vector<foo*> -> list, preserving identity
References: <tyfbrqw39vg.fsf@pcepsft001.cern.ch> <u3cc8se8i.fsf@yahoo.co.uk>
	<tyf1xro3mhn.fsf@pcepsft001.cern.ch>
Message-ID: <uekvoquri.fsf@yahoo.co.uk>

Jacek Generowicz <jacek.generowicz at cern.ch> writes:

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
>> Jacek Generowicz <jacek.generowicz at cern.ch> writes:
>
> [snip]
>
>> > How should I write a converter for the std::vector<foo*>, in order to
>> > preserve the identity of the foos ?
>> >
>> > (In the library I am wrapping, the return type of makefoos is actually
>> > const std::vector<const foo*>&)
>> 
>> I'm not sure how you would handle this, except by switching to
>> boost::shared_ptr instead of plain pointers. You would end up with
>> something like this:
>> 
>> std::vector<boost::shared_ptr<const foo> > makefoos(int n) {
>>   // ...
>> }
>
> Unfortunately "makefoos" is part of a library over which I have no
> control, so I cannot make it return shared pointers.

Bummer.

>
>> BOOST_PYTHON_MODULE( nocopy ) {
>>   class_<foo, boost::shared_ptr<foo> >("foo", no_init)
>>     .def("pointer", &foo::pointer);
>> 
>>   class_<std::vector<boost::shared_ptr<foo const> > > ("foo_vector")
>>     .def (SOMETHING<std::vector<boost::shared_ptr<foo const> >());
>> 
>>   def ("makefoos", makefoos);
>> }
>> 
>> Where SOMETHING would use either the current indexing suite (available
>> from CVS)
>
> Once again, I am obliged to use the local offical Boost version
> (1.30.2, at the moment), as that is what my users have. The Boost
> version I use is beyond my control.

OK. That still leaves the boost::python::list class.

>
> How does reference_existing_object work?  Using it as the return value
> policy for functions returning foo* preserves identity just fine.
> It's just when I get a whole vector of them and try to put them in a
> Python list that I don't seem to manage to avoid copying the objects
> themselves.

I've never actually used reference_existing_object, but if you think
about it, a reference to an existing vector object won't really help
you access the void * pointers that it contains. What you could
probably do is something along these lines (untested):

  typedef std::vector<foo const *> foo_ptr_vector;
  typedef foo const * (foo_ptr_vector::*memfn_type)(size_t) const;
  class_<> ("foo_ptr_vector")
    .def ("__getitem__"
        , static_cast<memfn_type>(&foo_ptr_vector::at)
        , return_value_policy<reference_existing_object>());

Providing __getitem__ will allow you to use a foo_ptr_vector from
Python via things like vec[n] or "for x in vec".

Alternatively, you might still be able to use a boost::python::list by
appending boost::shared_ptr objects that have do-nothing deleters
(search for "custom deallocator" in the shared_ptr docs). This could
be a better solution than trying to expose the vector interface, I
guess. Any way you cut it though, plain pointers won't play nicely
with Python.


-- 
Raoul Gough.
export LESS='-X'




From jacek.generowicz at cern.ch  Tue Dec  2 10:39:12 2003
From: jacek.generowicz at cern.ch (Jacek Generowicz)
Date: 02 Dec 2003 10:39:12 +0100
Subject: [C++-sig] Re: vector<foo*> -> list, preserving identity
References: <tyfbrqw39vg.fsf@pcepsft001.cern.ch> <u3cc8se8i.fsf@yahoo.co.uk>
	<tyf1xro3mhn.fsf@pcepsft001.cern.ch> <uekvoquri.fsf@yahoo.co.uk>
Message-ID: <tyfu14j1run.fsf@pcepsft001.cern.ch>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> Jacek Generowicz <jacek.generowicz at cern.ch> writes:
>
> [snip]
>
> OK. That still leaves the boost::python::list class.

Indeed, all my original attempts involved trying to stuff the foos
into one of these, but whatever I tried, I always ended up copying the
foos in the process.

> > How does reference_existing_object work?  Using it as the return
> > value policy for functions returning foo* preserves identity just
> > fine.  It's just when I get a whole vector of them and try to put
> > them in a Python list that I don't seem to manage to avoid copying
> > the objects themselves.
> 
> I've never actually used reference_existing_object, but if you think
> about it, a reference to an existing vector object won't really help
> you access the void * pointers that it contains.

What I was wondering was whether I could prevent the new foo objects
being created in the process of stuffing them into the
boost::python::list, by using whatever trick it is that copy_const_reference
uses.

> What you could probably do is something along these lines
> (untested):
> 
>   typedef std::vector<foo const *> foo_ptr_vector;
>   typedef foo const * (foo_ptr_vector::*memfn_type)(size_t) const;
>   class_<> ("foo_ptr_vector")
>     .def ("__getitem__"
>         , static_cast<memfn_type>(&foo_ptr_vector::at)
>         , return_value_policy<reference_existing_object>());
> 
> Providing __getitem__ will allow you to use a foo_ptr_vector from
> Python via things like vec[n] or "for x in vec".

Actually, the solution I found is similar: create an iterator for the
vectors, and give the iterator the appropriate policy (which applies
to the iterator's "next" method).

  class_<std::vector<const foo*> >("foovec")
    .def("__iter__", iterator<std::vector<const foo*>,
                     return_value_policy<reference_existing_object> >());

And now, on the Python side I wrap makefoos in something that returns 

  [i for i in makefoos(n)]


Not ideal, but it lets me get on with things.

Thanks.




From benny at kramekweb.com  Tue Dec  2 13:23:33 2003
From: benny at kramekweb.com (Benny Kramek)
Date: Tue, 02 Dec 2003 14:23:33 +0200
Subject: [C++-sig] Trouble wrapping abstract and inherited classes
Message-ID: <3FCC8445.5050701@kramekweb.com>

Hi,
I'm having trouble wrapping some C++ classes. This is the simplest 
example I could come up with that shows my problem:

// --------------------------------------------------------
// bpt.cpp
// --------------------------------------------------------

#include <boost/python.hpp>

using namespace boost::python;

// ----- Classes ------------------------------------------

class Animal
{
     public:
         virtual void eat(void) = 0;
};

class Baboon : public Animal
{
     public:
         void eat(void);
};

class Feeder
{
     public:
         virtual void feedAnimal(Animal* animal) = 0;
};

class Zoo
{
     public:
         Zoo(void);
         ~Zoo();
         void setFeeder(Feeder* f);
         void feedAnimals(void);
     private:
         Baboon* theBaboon;
         Feeder* feeder;
};

// ----- Function Definitions -----------------------------

void Baboon::eat(void)
{
     printf("baboon eating\n");
}

Zoo::Zoo(void)
{
     theBaboon = new Baboon();
     feeder = NULL;
}

Zoo::~Zoo()
{
     delete theBaboon;
}

void Zoo::setFeeder(Feeder* f)
{
     feeder = f;
}

void Zoo::feedAnimals(void)
{
     if(feeder)
         feeder->feedAnimal(theBaboon);
}

// ----- bpt module ---------------------------------------

class FeederWrap : public Feeder
{
     public:
         FeederWrap(PyObject* self_) : self(self_) {}
         void feedAnimal(Animal* animal) { call_method<void>(self, 
"feedAnimal", animal); }
         PyObject* self;
};

BOOST_PYTHON_MODULE(bpt)
{
     class_<Animal, boost::noncopyable>("Animal", no_init)
         ;

     class_<Baboon, bases<Animal>, boost::noncopyable>("Baboon", no_init)
         .def("eat", &Baboon::eat)
         ;

     class_<Feeder, FeederWrap, boost::noncopyable>("Feeder")
         ;

     class_<Zoo, boost::noncopyable>("Zoo")
         .def("setFeeder", &Zoo::setFeeder, with_custodian_and_ward<1, 2>())
         .def("feedAnimals", &Zoo::feedAnimals)
         ;
}

# ----- Testing with python, bpt.py:
import bpt

class SpecialFeeder(bpt.Feeder):
     def __init__(self):
         bpt.Feeder.__init__(self)
     def feedAnimal(self, animal):
         animal.eat()

zoo = bpt.Zoo()
feeder = SpecialFeeder()
zoo.setFeeder(feeder)
zoo.feedAnimals() # <- line 14

# ---------------------------------------

It compiles ok, but when I run the python script, I get this error:

Traceback (most recent call last):
   File "./bpt.py", line 14, in ?
     zoo.feedAnimals()
TypeError: No to_python (by-value) converter found for C++ type: 6Animal

I've tried playing around a lot, but I couldn't figure it out.
Thank you for any help

-- 
Benny Kramek
   http://benny.kramekweb.com
   benny at kramekweb.com





From dave at boost-consulting.com  Tue Dec  2 15:51:59 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 02 Dec 2003 09:51:59 -0500
Subject: [C++-sig] Re: Trouble wrapping abstract and inherited classes
References: <3FCC8445.5050701@kramekweb.com>
Message-ID: <uu14jgtm8.fsf@boost-consulting.com>

Benny Kramek <benny at kramekweb.com> writes:

> I've tried playing around a lot, but I couldn't figure it out.
> Thank you for any help

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

Should provide the answer you seek.

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




From s_sourceforge at nedprod.com  Tue Dec  2 14:01:48 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 02 Dec 2003 13:01:48 -0000
Subject: [C++-sig] Re: Problem using wrapped void* in Python
In-Reply-To: <uk75gkdje.fsf@boost-consulting.com>
Message-ID: <3FCC8D3C.20205.5B79AF7D@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1 Dec 2003 at 6:01, David Abrahams wrote:

> > Does anyone have something to say about converting void* to Python
> > and back?
> 
> If you want it to appear to be an attribute in Python, just write a
> getter (and optional setter) function using the "opaque void_*"
> technique, and use class_<...>.add_property("name", getter, setter) to
> expose it.

I was just about to say that this solution is also in the FAQ, but 
Dave's beaten me to it!

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP8yNPcEcvDLFGKbPEQL7YACglIS3dPRfK0KIMNr3eNC006vbUjgAoLzs
unCEMHZMSIUZzAVFdAnomcyk
=0vLx
-----END PGP SIGNATURE-----



From RaoulGough at yahoo.co.uk  Wed Dec  3 11:00:02 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 03 Dec 2003 10:00:02 +0000
Subject: [C++-sig] Re: vector<foo*> -> list, preserving identity
References: <tyfbrqw39vg.fsf@pcepsft001.cern.ch> <u3cc8se8i.fsf@yahoo.co.uk>
	<tyf1xro3mhn.fsf@pcepsft001.cern.ch> <uekvoquri.fsf@yahoo.co.uk>
	<tyfu14j1run.fsf@pcepsft001.cern.ch>
Message-ID: <un0aap6fx.fsf@yahoo.co.uk>

Jacek Generowicz <jacek.generowicz at cern.ch> writes:

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
[snip]
>> I've never actually used reference_existing_object, but if you think
>> about it, a reference to an existing vector object won't really help
>> you access the void * pointers that it contains.
>
> What I was wondering was whether I could prevent the new foo objects
> being created in the process of stuffing them into the
> boost::python::list, by using whatever trick it is that copy_const_reference
> uses.

OK. I'm probably not the best person to answer this, but it seems to
me that the following should work:

#include <boost/python/to_python_indirect.hpp>

...
  
  pylist.append (
     boost::python::detail::make_reference_holder::execute (foo_ptr));

Of course, things in namespace detail are undocumented and could
easily change from one release to another.

>> What you could probably do is something along these lines
>> (untested):
>> 
>>   typedef std::vector<foo const *> foo_ptr_vector;
>>   typedef foo const * (foo_ptr_vector::*memfn_type)(size_t) const;
>>   class_<> ("foo_ptr_vector")
>>     .def ("__getitem__"
>>         , static_cast<memfn_type>(&foo_ptr_vector::at)
>>         , return_value_policy<reference_existing_object>());
>> 
>> Providing __getitem__ will allow you to use a foo_ptr_vector from
>> Python via things like vec[n] or "for x in vec".
>
> Actually, the solution I found is similar: create an iterator for the
> vectors, and give the iterator the appropriate policy (which applies
> to the iterator's "next" method).
>
>   class_<std::vector<const foo*> >("foovec")
>     .def("__iter__", iterator<std::vector<const foo*>,
>                      return_value_policy<reference_existing_object> >());
>
> And now, on the Python side I wrap makefoos in something that returns 
>
>   [i for i in makefoos(n)]

The good thing about __getitem__ is that it gives you iteration as
well as indexing (Python can generate an iterator automatically given
an indexable object).

-- 
Raoul Gough.
export LESS='-X'




From RaoulGough at yahoo.co.uk  Thu Dec  4 00:54:45 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 03 Dec 2003 23:54:45 +0000
Subject: [C++-sig] Re: indexing_v2 status update
References: <u3ccdwf7b.fsf@yahoo.co.uk> <un0alwahi.fsf@boost-consulting.com>
	<uy8u5ux0u.fsf@yahoo.co.uk> <ullq5unga.fsf@boost-consulting.com>
Message-ID: <ufzg1pid6.fsf@yahoo.co.uk>

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

[snip]
> I don't understand is_reorderable.  How is that different from
>
>   is_convertible<
>       iterator_traits<C::iterator>::iterator_category
>     , forward_iterator_tag
>   >::value
>   && is_non_const_lvalue_iterator<C::iterator>::value
>   && is_assignable<C::value_type>::value
>
> ??
>
> I realize we don't have is_assignable, but shouldn't you phrase this
> in terms of something fundamental like value_type assignability?  We
> can ask all the other questions (see
> boost/iterator/is_lvalue_iterator.hpp).

It looks like assignability is the really important test for
determining whether a container can be reordered (i.e. sorted or
reversed). However, I can't think of any way to implement an
is_assignable template. For instance, std::pair<const int, int> is not
assignable, yet it doesn't have top-level const qualification, and it
*does* have an operator= (which will produce a compile-time error if
used) so I don't think any has_member_function test will help. If
anyone can suggest a workable is_assignable, I'll use it to deduce
is_reorderable, but otherwise I think I'll just stick with
is_mutable_ref and explicit overrides for some containers
(i.e. std::map)

-- 
Raoul Gough.
export LESS='-X'




From dave at boost-consulting.com  Thu Dec  4 03:53:36 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 03 Dec 2003 21:53:36 -0500
Subject: [C++-sig] Re: indexing_v2 status update
References: <u3ccdwf7b.fsf@yahoo.co.uk> <un0alwahi.fsf@boost-consulting.com>
	<uy8u5ux0u.fsf@yahoo.co.uk> <ullq5unga.fsf@boost-consulting.com>
	<ufzg1pid6.fsf@yahoo.co.uk>
Message-ID: <u65gxnvin.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> David Abrahams <dave at boost-consulting.com> writes:
>
> [snip]
>> I don't understand is_reorderable.  How is that different from
>>
>>   is_convertible<
>>       iterator_traits<C::iterator>::iterator_category
>>     , forward_iterator_tag
>>   >::value
>>   && is_non_const_lvalue_iterator<C::iterator>::value
>>   && is_assignable<C::value_type>::value
>>
>> ??
>>
>> I realize we don't have is_assignable, but shouldn't you phrase this
>> in terms of something fundamental like value_type assignability?  We
>> can ask all the other questions (see
>> boost/iterator/is_lvalue_iterator.hpp).
>
> It looks like assignability is the really important test for
> determining whether a container can be reordered (i.e. sorted or
> reversed). However, I can't think of any way to implement an
> is_assignable template. 

Neither can anyone else, other than specializing for known types and
asking the user to specialize for his own.

> For instance, std::pair<const int, int> is not
> assignable, yet it doesn't have top-level const qualification, and it
> *does* have an operator= (which will produce a compile-time error if
> used) so I don't think any has_member_function test will help. 

Right.  But you can provide partial specializations for
std::pair<const T, const U>, 
std::pair<T, const U>, 
std::pair<const T, U>.

> If anyone can suggest a workable is_assignable, I'll use it to
> deduce is_reorderable, but otherwise I think I'll just stick with
> is_mutable_ref and explicit overrides for some containers
> (i.e. std::map)

I *think* I still think that's an inferior solution.

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




From RaoulGough at yahoo.co.uk  Thu Dec  4 11:20:34 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Thu, 04 Dec 2003 10:20:34 +0000
Subject: [C++-sig] Re: indexing_v2 status update
References: <u3ccdwf7b.fsf@yahoo.co.uk> <un0alwahi.fsf@boost-consulting.com>
	<uy8u5ux0u.fsf@yahoo.co.uk> <ullq5unga.fsf@boost-consulting.com>
	<ufzg1pid6.fsf@yahoo.co.uk> <u65gxnvin.fsf@boost-consulting.com>
Message-ID: <ubrqoq3yl.fsf@yahoo.co.uk>

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
>> David Abrahams <dave at boost-consulting.com> writes:
>>
>> [snip]
>>> I don't understand is_reorderable.  How is that different from
>>>
>>>   is_convertible<
>>>       iterator_traits<C::iterator>::iterator_category
>>>     , forward_iterator_tag
>>>   >::value
>>>   && is_non_const_lvalue_iterator<C::iterator>::value
>>>   && is_assignable<C::value_type>::value
>>>
>>> ??
>>>
>>> I realize we don't have is_assignable, but shouldn't you phrase this
>>> in terms of something fundamental like value_type assignability?  We
>>> can ask all the other questions (see
>>> boost/iterator/is_lvalue_iterator.hpp).
>>
>> It looks like assignability is the really important test for
>> determining whether a container can be reordered (i.e. sorted or
>> reversed). However, I can't think of any way to implement an
>> is_assignable template. 
>
> Neither can anyone else, other than specializing for known types and
> asking the user to specialize for his own.

Well, there is already a ValueTraits concept, so I could easily add an
"is_assignable" feature to this, and specialize it for the std::pair
instances that std::map utilizes. That would probably tie up quite
well with the existing equality_comparable and less_than_comparable.

On the other hand, perhaps this does belong purely in the
ContainerTraits concept. I wonder whether assignability is always a
quality of a container (and all instances of it) or just the
particular type of value stored in a particular instance. In the case
of the STL containers, I think all template arguments are required to
be Assignable types, and some of the containers (set and map) add
const qualification somewhere in their value_type.

I've just been taking a look at the unordered_set proposal at
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1518.pdf and
it looks like the unordered_set::value_type is not const qualified,
which would confuse any assignability determination based on the
container's value_type directly. On the other had, the container only
provides const iterators, so I guess this means that
unordered_set<X>::iterator::value_type is "X const", and using the
iterator's value type would still work.

>
>> For instance, std::pair<const int, int> is not
>> assignable, yet it doesn't have top-level const qualification, and it
>> *does* have an operator= (which will produce a compile-time error if
>> used) so I don't think any has_member_function test will help. 
>
> Right.  But you can provide partial specializations for
> std::pair<const T, const U>, 
> std::pair<T, const U>, 
> std::pair<const T, U>.

I guess the only potential problem is weirdo cases where the value
type appears to be assignable but the container still isn't
reorderable, in which case the client code would have to provide a
custom-written ContainerTraits anyway. I'm thinking about some kind of
a dirty std::set wrapper that pretends its value_type is mutable and
uses const_cast internally. For motivation, see e.g.

http://groups.google.com/groups?selm=3c939210.56671713%40news.earthlink.net

or http://home.clara.net/raoulgough/map3/index.html

>
>> If anyone can suggest a workable is_assignable, I'll use it to
>> deduce is_reorderable, but otherwise I think I'll just stick with
>> is_mutable_ref and explicit overrides for some containers
>> (i.e. std::map)
>
> I *think* I still think that's an inferior solution.

It's really a question of how the client code helps the library out
when it would get the wrong answer by itself. Possible options include
specializing an is_assignable template, specializing a value_traits
template or providing an alternative ContainerTraits class (the
current method).

-- 
Raoul Gough.
export LESS='-X'




From david.anderson at calixo.net  Sat Dec  6 17:37:24 2003
From: david.anderson at calixo.net (David Anderson)
Date: Sat, 06 Dec 2003 17:37:24 +0100
Subject: [C++-sig] Passing a C++ object to a python script
Message-ID: <3FD205C4.9030806@calixo.net>

Hello,

I am currently attempting to embed python in a C++ application of mine. 
I have looked around at what can be acheived using various libs, and I'd 
like to try out Boost.Python. My application would require two things:

1) Being able to pass a reference to a C++ object to a python function 
and have it modify this instance of a class (which would have been made 
visible to python using boost). That is, when the python function 
returns, the C++ object should have been altered by it.

2) Being able to use as transparently as possible python extended 
classes (a python class extending an exported C++ base class) from the 
C++ code.

Could someone give me pointers as to how I could accomplish this? I have 
looked through the Boost.Python documentation, as well as some archive 
mails in this list, but have not found exactly what I need...

Thanks in advance
David Anderson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031206/77ca12be/attachment.pgp>

From dave at boost-consulting.com  Mon Dec  8 15:21:25 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 08 Dec 2003 09:21:25 -0500
Subject: [C++-sig] Re: indexing_v2 status update
References: <u3ccdwf7b.fsf@yahoo.co.uk> <un0alwahi.fsf@boost-consulting.com>
	<uy8u5ux0u.fsf@yahoo.co.uk> <ullq5unga.fsf@boost-consulting.com>
	<ufzg1pid6.fsf@yahoo.co.uk> <u65gxnvin.fsf@boost-consulting.com>
	<ubrqoq3yl.fsf@yahoo.co.uk>
Message-ID: <uad638k62.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> David Abrahams <dave at boost-consulting.com> writes:
>
>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>
>>> David Abrahams <dave at boost-consulting.com> writes:
>>>
>>> [snip]
>>>> I don't understand is_reorderable.  How is that different from
>>>>
>>>>   is_convertible<
>>>>       iterator_traits<C::iterator>::iterator_category
>>>>     , forward_iterator_tag
>>>>   >::value
>>>>   && is_non_const_lvalue_iterator<C::iterator>::value
>>>>   && is_assignable<C::value_type>::value
>>>>
>>>> ??
>>>>
>>>> I realize we don't have is_assignable, but shouldn't you phrase this
>>>> in terms of something fundamental like value_type assignability?  We
>>>> can ask all the other questions (see
>>>> boost/iterator/is_lvalue_iterator.hpp).
>>>
>>> It looks like assignability is the really important test for
>>> determining whether a container can be reordered (i.e. sorted or
>>> reversed). However, I can't think of any way to implement an
>>> is_assignable template. 
>>
>> Neither can anyone else, other than specializing for known types and
>> asking the user to specialize for his own.
>
> Well, there is already a ValueTraits concept, so I could easily add an
> "is_assignable" feature to this, and specialize it for the std::pair
> instances that std::map utilizes. That would probably tie up quite
> well with the existing equality_comparable and less_than_comparable.
>
> On the other hand, perhaps this does belong purely in the
> ContainerTraits concept. I wonder whether assignability is always a
> quality of a container (and all instances of it) or just the
> particular type of value stored in a particular instance. In the case
> of the STL containers, I think all template arguments are required to
> be Assignable types

Yes, but...

> and some of the containers (set and map) add
> const qualification somewhere in their value_type.

...that fact tends to make the value_type not Assignable.

> I've just been taking a look at the unordered_set proposal at
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1518.pdf and
> it looks like the unordered_set::value_type is not const qualified,
> which would confuse any assignability determination based on the
> container's value_type directly. 

I'm not sure if that's intentional.  I've asked.

> On the other had, the container only
> provides const iterators, so I guess this means that
> unordered_set<X>::iterator::value_type is "X const", 
> and using the iterator's value type would still work.

No, an iterator's value_type is never const.  You can look at the
mutability of its ``reference`` type, but:

  a. the standard seems to place no requirements on the reference
     type of forward iterators

  b. It barely places requirements on the reference type of
     bidirectional iterators (you have to look for implications in
     the reverse_iterator requirements).

  c. Even having a reference type which is a reference-to-non-const
     doesn't make the value_type assignable.

>>> For instance, std::pair<const int, int> is not
>>> assignable, yet it doesn't have top-level const qualification, and it
>>> *does* have an operator= (which will produce a compile-time error if
>>> used) so I don't think any has_member_function test will help. 
>>
>> Right.  But you can provide partial specializations for
>> std::pair<const T, const U>, 
>> std::pair<T, const U>, 
>> std::pair<const T, U>.
>
> I guess the only potential problem is weirdo cases where the value
> type appears to be assignable but the container still isn't
> reorderable, in which case the client code would have to provide a
> custom-written ContainerTraits anyway. 

There are a number of wierdo cases, but it all comes down to
properties of the value type.

> I'm thinking about some kind of
> a dirty std::set wrapper that pretends its value_type is mutable and
> uses const_cast internally. For motivation, see e.g.
>
> http://groups.google.com/groups?selm=3c939210.56671713%40news.earthlink.net
>
> or http://home.clara.net/raoulgough/map3/index.html

I can't imagine how you plan to use this technique in this case.

>>> If anyone can suggest a workable is_assignable, I'll use it to
>>> deduce is_reorderable, but otherwise I think I'll just stick with
>>> is_mutable_ref and explicit overrides for some containers
>>> (i.e. std::map)
>>
>> I *think* I still think that's an inferior solution.
>
> It's really a question of how the client code helps the library out
> when it would get the wrong answer by itself. 

Yep.

> Possible options include specializing an is_assignable template,
> specializing a value_traits template or providing an alternative
> ContainerTraits class (the current method).

I am not so convinced any more that the current method is worse than
the others.

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




From pierre.barbier at cirad.fr  Mon Dec  8 16:07:58 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Mon, 08 Dec 2003 16:07:58 +0100
Subject: [C++-sig] Problem with boost::python::iterator
Message-ID: <1070896078.1103.8.camel@pbarbier>

I use boost::python::iterator to export a python iterator from STL
containers. More precisely, I use :

  .def("__iter__", boost::python::iterator<Container>())

where Container is a STL container ( vector<foo> for example ). Let's
say that foo is a class that contains an integer 'a'. My problem is with
this following test:

>>> l = vector_foo()
>>> l.append(foo(3))
>>> l.append(foo(2))
>>> l.append(foo(10))
>>> print l
vector_foo{ foo(3), foo(2), foo(10) }
>>> for i in l:
...   i.a = i.a + 3
...
>>> print l
vector_foo{ foo(3), foo(2), foo(10) }

I don't understand !!! It used to work, but it does not anymore ! If you
replace the variable (defined as readwrite) by a function call modifying
the object it does not modify the vector !

This is a very big problem for me !!! What can I do ?

Thanks,

-- 
Pierre Barbier de Reuille

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

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




From RaoulGough at yahoo.co.uk  Mon Dec  8 17:27:58 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Mon, 08 Dec 2003 16:27:58 +0000
Subject: [C++-sig] Re: indexing_v2 status update
References: <u3ccdwf7b.fsf@yahoo.co.uk> <un0alwahi.fsf@boost-consulting.com>
	<uy8u5ux0u.fsf@yahoo.co.uk> <ullq5unga.fsf@boost-consulting.com>
	<ufzg1pid6.fsf@yahoo.co.uk> <u65gxnvin.fsf@boost-consulting.com>
	<ubrqoq3yl.fsf@yahoo.co.uk> <uad638k62.fsf@boost-consulting.com>
Message-ID: <uvfornuk1.fsf@yahoo.co.uk>

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
[snip]
>> On the other hand, perhaps this does belong purely in the
>> ContainerTraits concept. I wonder whether assignability is always a
>> quality of a container (and all instances of it) or just the
>> particular type of value stored in a particular instance. In the case
>> of the STL containers, I think all template arguments are required to
>> be Assignable types
>
> Yes, but...
>
>> and some of the containers (set and map) add
>> const qualification somewhere in their value_type.
>
> ...that fact tends to make the value_type not Assignable.

Of course. I was just thinking about whether it's conceptually related
to the template arguments or rather to some property of the container
template. I guess it doesn't actually make much practical difference
in terms of providing the necessary partial specializations.

>
>> I've just been taking a look at the unordered_set proposal at
>> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1518.pdf and
>> it looks like the unordered_set::value_type is not const qualified,
>> which would confuse any assignability determination based on the
>> container's value_type directly. 
>
> I'm not sure if that's intentional.  I've asked.
>
>> On the other had, the container only
>> provides const iterators, so I guess this means that
>> unordered_set<X>::iterator::value_type is "X const", 
>> and using the iterator's value type would still work.
>
> No, an iterator's value_type is never const.

Hmmmmm... That's really a bit of a shame, since I go to so much
trouble to pass const_iterator or iterator to the iterator_traits base
class, depending on whether the container has top-level const
qualification or not :-) Maybe this doesn't actually gain anything at
all!

>  You can look at the
> mutability of its ``reference`` type, but:
>
>   a. the standard seems to place no requirements on the reference
>      type of forward iterators
>
>   b. It barely places requirements on the reference type of
>      bidirectional iterators (you have to look for implications in
>      the reverse_iterator requirements).
>
>   c. Even having a reference type which is a reference-to-non-const
>      doesn't make the value_type assignable.

Yes, you mentioned before that the reference type is not necessarily a
reliable guide. In fact, the current code relies on the iterator's
reference type and deduces the wrong value for "is_mutable" on some
plaforms.

>
>>>> For instance, std::pair<const int, int> is not
>>>> assignable, yet it doesn't have top-level const qualification, and it
>>>> *does* have an operator= (which will produce a compile-time error if
>>>> used) so I don't think any has_member_function test will help. 
>>>
>>> Right.  But you can provide partial specializations for
>>> std::pair<const T, const U>, 
>>> std::pair<T, const U>, 
>>> std::pair<const T, U>.
>>
>> I guess the only potential problem is weirdo cases where the value
>> type appears to be assignable but the container still isn't
>> reorderable, in which case the client code would have to provide a
>> custom-written ContainerTraits anyway. 
>
> There are a number of wierdo cases, but it all comes down to
> properties of the value type.
>
>> I'm thinking about some kind of
>> a dirty std::set wrapper that pretends its value_type is mutable and
>> uses const_cast internally. For motivation, see e.g.
>>
>> http://groups.google.com/groups?selm=3c939210.56671713%40news.earthlink.net
>>
>> or http://home.clara.net/raoulgough/map3/index.html
>
> I can't imagine how you plan to use this technique in this case.

Maybe it's not really a robust solution, but you could just have
wrappers that const_cast references from std::set or
std::set::iterator to remove the container's const qualification. I'm
thinking of cases where only a portion of the "value_type" is used as
a sorting key, and the remainder can be mutated at will (and
preferably in-place). The value_type is then some UDT (possibly with
safeguards to prevent key modification) which may or may not be
assignable. In fact, a vector of those values might well be
reorderable, whereas the std::set wrapper container isn't. Still, this
is stretching things a long way to try and find a counter-example.

>
>>>> If anyone can suggest a workable is_assignable, I'll use it to
>>>> deduce is_reorderable, but otherwise I think I'll just stick with
>>>> is_mutable_ref and explicit overrides for some containers
>>>> (i.e. std::map)
>>>
>>> I *think* I still think that's an inferior solution.
>>
>> It's really a question of how the client code helps the library out
>> when it would get the wrong answer by itself. 
>
> Yep.
>
>> Possible options include specializing an is_assignable template,
>> specializing a value_traits template or providing an alternative
>> ContainerTraits class (the current method).
>
> I am not so convinced any more that the current method is worse than
> the others.

Oh no! I'm starting to think that the value_traits or is_assignable
templates would actually be better solutions. I say "would be" because
neither of them is at all convenient to do on MSVC6 owing to the lack
of PTS. In fact, that practical difficulty probably means I'll stick
with the current method, although I'm no longer convinced it is the
best solution in theory.

-- 
Raoul Gough.
export LESS='-X'




From jsseo at postech.ac.kr  Tue Dec  9 03:19:56 2003
From: jsseo at postech.ac.kr (Jinseok Seo)
Date: Tue, 9 Dec 2003 11:19:56 +0900
Subject: [C++-sig] std::string assignment problem
Message-ID: <20031209.AAA1070936346@postech.ac.kr>

Hello.

When I passed a string parameter that is longer than 15,
the program hals with the following assertion failed error message.
The error occured only when I built the project for "Debug" mode.
(compiler: Microsoft Visual Studio .NET 2003)

For example, in python interpreter,

from ex1 import * <-- ok
e = Ex("1234567890123456") <-- error
e = Ex("123456789012345") <-- ok
e.name = "1234567890123456" <-- error
e.name = "123456789012345" name = name;
}
void Ex1::setName(std::string name) {
this->name = name;
}
...
-----------------------------

Thanks in advance.


From dave at boost-consulting.com  Tue Dec  9 05:04:38 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 08 Dec 2003 23:04:38 -0500
Subject: [C++-sig] Re: indexing_v2 status update
References: <u3ccdwf7b.fsf@yahoo.co.uk> <un0alwahi.fsf@boost-consulting.com>
	<uy8u5ux0u.fsf@yahoo.co.uk> <ullq5unga.fsf@boost-consulting.com>
	<ufzg1pid6.fsf@yahoo.co.uk> <u65gxnvin.fsf@boost-consulting.com>
	<ubrqoq3yl.fsf@yahoo.co.uk> <uad638k62.fsf@boost-consulting.com>
	<uvfornuk1.fsf@yahoo.co.uk>
Message-ID: <uu14ar609.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> David Abrahams <dave at boost-consulting.com> writes:
>
>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>
> [snip]
>>> On the other hand, perhaps this does belong purely in the
>>> ContainerTraits concept. I wonder whether assignability is always a
>>> quality of a container (and all instances of it) or just the
>>> particular type of value stored in a particular instance. In the case
>>> of the STL containers, I think all template arguments are required to
>>> be Assignable types
>>
>> Yes, but...
>>
>>> and some of the containers (set and map) add
>>> const qualification somewhere in their value_type.
>>
>> ...that fact tends to make the value_type not Assignable.
>
> Of course. I was just thinking about whether it's conceptually related
> to the template arguments or rather to some property of the container
> template. I guess it doesn't actually make much practical difference
> in terms of providing the necessary partial specializations.
>
>>
>>> I've just been taking a look at the unordered_set proposal at
>>> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1518.pdf and
>>> it looks like the unordered_set::value_type is not const qualified,
>>> which would confuse any assignability determination based on the
>>> container's value_type directly. 
>>
>> I'm not sure if that's intentional.  I've asked.
>>
>>> On the other had, the container only
>>> provides const iterators, so I guess this means that
>>> unordered_set<X>::iterator::value_type is "X const", 
>>> and using the iterator's value type would still work.
>>
>> No, an iterator's value_type is never const.
>
> Hmmmmm... That's really a bit of a shame, since I go to so much
> trouble to pass const_iterator or iterator to the iterator_traits base
> class, depending on whether the container has top-level const
> qualification or not :-) 

What does this have to do with the _container's_ const qualification?

I just mean that iterator_traits<I>::value_type is never a const type
for any valid iterator I.

>>> Possible options include specializing an is_assignable template,
>>> specializing a value_traits template or providing an alternative
>>> ContainerTraits class (the current method).
>>
>> I am not so convinced any more that the current method is worse than
>> the others.
>
> Oh no! I'm starting to think that the value_traits or is_assignable
> templates would actually be better solutions. 

OK, I don't feel strongly either way.

> I say "would be" because neither of them is at all convenient to do
> on MSVC6 owing to the lack of PTS.

How does that come into play?  It's my policy not to make major
interface compromises for broken compilers.

> In fact, that practical difficulty probably means I'll stick with
> the current method, although I'm no longer convinced it is the best
> solution in theory.

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




From dave at boost-consulting.com  Tue Dec  9 05:04:46 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 08 Dec 2003 23:04:46 -0500
Subject: [C++-sig] Re: indexing_v2 status update
In-Reply-To: <uvfornuk1.fsf@yahoo.co.uk> (Raoul Gough's message of "Mon, 08
	Dec 2003 16:27:58 +0000")
References: <u3ccdwf7b.fsf@yahoo.co.uk> <un0alwahi.fsf@boost-consulting.com>
	<uy8u5ux0u.fsf@yahoo.co.uk> <ullq5unga.fsf@boost-consulting.com>
	<ufzg1pid6.fsf@yahoo.co.uk> <u65gxnvin.fsf@boost-consulting.com>
	<ubrqoq3yl.fsf@yahoo.co.uk> <uad638k62.fsf@boost-consulting.com>
	<uvfornuk1.fsf@yahoo.co.uk>
Message-ID: <ur7zer601.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> David Abrahams <dave at boost-consulting.com> writes:
>
>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>
> [snip]
>>> On the other hand, perhaps this does belong purely in the
>>> ContainerTraits concept. I wonder whether assignability is always a
>>> quality of a container (and all instances of it) or just the
>>> particular type of value stored in a particular instance. In the case
>>> of the STL containers, I think all template arguments are required to
>>> be Assignable types
>>
>> Yes, but...
>>
>>> and some of the containers (set and map) add
>>> const qualification somewhere in their value_type.
>>
>> ...that fact tends to make the value_type not Assignable.
>
> Of course. I was just thinking about whether it's conceptually related
> to the template arguments or rather to some property of the container
> template. I guess it doesn't actually make much practical difference
> in terms of providing the necessary partial specializations.
>
>>
>>> I've just been taking a look at the unordered_set proposal at
>>> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1518.pdf and
>>> it looks like the unordered_set::value_type is not const qualified,
>>> which would confuse any assignability determination based on the
>>> container's value_type directly. 
>>
>> I'm not sure if that's intentional.  I've asked.
>>
>>> On the other had, the container only
>>> provides const iterators, so I guess this means that
>>> unordered_set<X>::iterator::value_type is "X const", 
>>> and using the iterator's value type would still work.
>>
>> No, an iterator's value_type is never const.
>
> Hmmmmm... That's really a bit of a shame, since I go to so much
> trouble to pass const_iterator or iterator to the iterator_traits base
> class, depending on whether the container has top-level const
> qualification or not :-) 

What does this have to do with the _container's_ const qualification?

I just mean that iterator_traits<I>::value_type is never a const type
for any valid iterator I.

>>> Possible options include specializing an is_assignable template,
>>> specializing a value_traits template or providing an alternative
>>> ContainerTraits class (the current method).
>>
>> I am not so convinced any more that the current method is worse than
>> the others.
>
> Oh no! I'm starting to think that the value_traits or is_assignable
> templates would actually be better solutions. 

OK, I don't feel strongly either way.

> I say "would be" because neither of them is at all convenient to do
> on MSVC6 owing to the lack of PTS.

How does that come into play?  It's my policy not to make major
interface compromises for broken compilers.

> In fact, that practical difficulty probably means I'll stick with
> the current method, although I'm no longer convinced it is the best
> solution in theory.

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




From dave at boost-consulting.com  Tue Dec  9 05:11:11 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 08 Dec 2003 23:11:11 -0500
Subject: [C++-sig] Re: Problem with boost::python::iterator
References: <1070896078.1103.8.camel@pbarbier>
Message-ID: <ullpmr5pc.fsf@boost-consulting.com>

Pierre Barbier de Reuille <pierre.barbier at cirad.fr> writes:

> I use boost::python::iterator to export a python iterator from STL
> containers. More precisely, I use :
>
>   .def("__iter__", boost::python::iterator<Container>())
>
> where Container is a STL container ( vector<foo> for example ). Let's
> say that foo is a class that contains an integer 'a'. My problem is with
> this following test:
>
>>>> l = vector_foo()
>>>> l.append(foo(3))
>>>> l.append(foo(2))
>>>> l.append(foo(10))
>>>> print l
> vector_foo{ foo(3), foo(2), foo(10) }
>>>> for i in l:
> ...   i.a = i.a + 3
> ...
>>>> print l
> vector_foo{ foo(3), foo(2), foo(10) }
>
> I don't understand !!! It used to work

When?  That's surprising.  Does the documentation for the default type
of NextPolicies at
http://www.boost.org/libs/python/doc/v2/iterator.html#iterator-spec
explain why?

> , but it does not anymore ! If you
> replace the variable (defined as readwrite) by a function call modifying
> the object it does not modify the vector !
>
> This is a very big problem for me !!! What can I do ?

   .def(
       "__iter__"
     , boost::python::iterator<
            Container
          , return_internal_reference<>
       >()
   )

??

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




From dave at boost-consulting.com  Tue Dec  9 05:12:33 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 08 Dec 2003 23:12:33 -0500
Subject: [C++-sig] Re: std::string assignment problem
References: <20031209.AAA1070936346@postech.ac.kr>
Message-ID: <ufzfur5n2.fsf@boost-consulting.com>

"Jinseok Seo" <jsseo at postech.ac.kr> writes:

> Hello.
>
> When I passed a string parameter that is longer than 15,
> the program hals with the following assertion failed error message.
                        ^^^^^^^^^^^^^

You left out the message.

> The error occured only when I built the project for "Debug" mode.
> (compiler: Microsoft Visual Studio .NET 2003)
>
> For example, in python interpreter,
>
> from ex1 import * <-- ok
> e = Ex("1234567890123456") <-- error
> e = Ex("123456789012345") <-- ok
> e.name = "1234567890123456" <-- error
> e.name = "123456789012345" name = name;
> }
> void Ex1::setName(std::string name) {
> this->name = name;
> }

Can you post a complete, minimal example which reproduces the problem?

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




From jsseo at postech.ac.kr  Tue Dec  9 06:04:21 2003
From: jsseo at postech.ac.kr (Jinseok Seo)
Date: Tue, 9 Dec 2003 14:04:21 +0900
Subject: [C++-sig] std::string problem
Message-ID: <20031209.AAA1070946095@postech.ac.kr>

When I passed a string parameter that is longer than 15,
the program halts with the following assertion failed error message.
The error occured when I built the project for "Debug" mode.
(compiler: Microsoft Visual Studio .NET 2003)

e.g. in python interpreter,
from ex1 import *
e = Ex("123456789012345") <-- ok
e = Ex("1234567890123456") <-- error
e.name = "123456789012345" <-- ok
e.name = "1234567890123456" name = name;
}
void Ex1::setName(std::string name) {
this->name = name;
}
...
-----------------------------

Thanks in advance.



From jsseo at postech.ac.kr  Tue Dec  9 06:08:08 2003
From: jsseo at postech.ac.kr (jsseo)
Date: Tue, 9 Dec 2003 14:08:08 +0900
Subject: [C++-sig] problems with std::string (complete msg.)
Message-ID: <000001c3be12$6fcfe450$af5edf8d@postech.ac.kr>

I'm sorry but the previous messages I sent were broken because of the
mailing system that I use.
Here is the original message.

When I passed a string parameter that is longer than 15,
the program hals with the following assertion failed error message.
The error occured when I built the project for "Debug" mode.
(compiler: Microsoft Visual Studio .NET 2003)

e.g. in python interpreter,
from ex1 import *
e = Ex("123456789012345") <-- ok
e = Ex("1234567890123456") <-- error
e.name = "123456789012345" <-- ok
e.name = "1234567890123456" <-- error

the error message
-----------------------------
Program:c:\python22\python.exe
File:dbgheap.c
Line: 1132
Expression: _CrtlsValidHeapPointer(pUserData)
-----------------------------

the follwing is the code.

file: idl.cpp
-----------------------------
BOOST_PYTHON_MODULE(ex1)
{
	class_("Ex1")
		.def(init())
		.add_property("name", &Ex1::getName, &Ex1::setName)
	;
}
-----------------------------

file: ex1.h
-----------------------------
class Ex1 {
public:
	Ex1() {};
	Ex1(std::string name);
	void setName(std::string name);
	...
};
-----------------------------

file:ex1.cpp
-----------------------------
Ex1::Ex1(std::string name) {
	this->name = name;
}
void Ex1::setName(std::string name) {
	this->name = name;
}
...
-----------------------------

Thanks in advance.

Jinseok Seo	





From pierre.barbier at cirad.fr  Tue Dec  9 10:41:10 2003
From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille)
Date: Tue, 09 Dec 2003 10:41:10 +0100
Subject: [C++-sig] Re: Problem with boost::python::iterator
In-Reply-To: <ullpmr5pc.fsf@boost-consulting.com>
References: <1070896078.1103.8.camel@pbarbier>
	<ullpmr5pc.fsf@boost-consulting.com>
Message-ID: <1070962861.582.25.camel@pbarbier>

Ok, I solved my problem and deduced that :

 1 - if I need to export an iterator on objects,
return_internal_reference<> works fine
 2 - for types who need to get copyed (the ones who would not require
any call policy), I cannot specify default_call_policies, so I have to
leave the policy blank
 3 - it's not yet tested, but I hope I can specify any call policy I
want if I export pointers

I hope there are no other cases ...

-- 
Pierre Barbier de Reuille

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

tel   : (33) 4 67 61 65 77    fax   : (33) 4 67 61 56 68 
-- 
Pierre Barbier de Reuille

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

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




From RaoulGough at yahoo.co.uk  Tue Dec  9 11:53:22 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Tue, 09 Dec 2003 10:53:22 +0000
Subject: [C++-sig] Re: indexing_v2 status update
References: <u3ccdwf7b.fsf@yahoo.co.uk> <un0alwahi.fsf@boost-consulting.com>
	<uy8u5ux0u.fsf@yahoo.co.uk> <ullq5unga.fsf@boost-consulting.com>
	<ufzg1pid6.fsf@yahoo.co.uk> <u65gxnvin.fsf@boost-consulting.com>
	<ubrqoq3yl.fsf@yahoo.co.uk> <uad638k62.fsf@boost-consulting.com>
	<uvfornuk1.fsf@yahoo.co.uk> <ur7zer601.fsf@boost-consulting.com>
Message-ID: <uhe0anty5.fsf@yahoo.co.uk>

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
>> David Abrahams <dave at boost-consulting.com> writes:
>>
[snip]
>>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>>> On the other hand, perhaps this does belong purely in the
>>>> ContainerTraits concept. I wonder whether assignability is always a
>>>> quality of a container (and all instances of it) or just the
>>>> particular type of value stored in a particular instance. In the case
>>>> of the STL containers, I think all template arguments are required to
>>>> be Assignable types
>>>
>>> Yes, but...
>>>
>>>> and some of the containers (set and map) add
>>>> const qualification somewhere in their value_type.
>>>
>>> ...that fact tends to make the value_type not Assignable.
>>
>> Of course. I was just thinking about whether it's conceptually related
>> to the template arguments or rather to some property of the container
>> template. I guess it doesn't actually make much practical difference
>> in terms of providing the necessary partial specializations.
>> Of course. I was just thinking about whether it's conceptually related
>> to the template arguments or rather to some property of the container
>> template. I guess it doesn't actually make much practical difference
>> in terms of providing the necessary partial specializations.

I've figured out what was bugging me about this. For example,
supporting std::map this way would require a partial specialization
for std::pair<X const, Y>. More generally, there has to be a
value_traits (or is_assignable) specialization for the container's
value_type, which could be something non-obvious to the client code
(e.g. container arguments X and Y, but must specialize on
weird_thing<X, more_weirdness<Y> >).  In the worst case, a container
could use a nested class, for which you can't provide a partial
specialization at all (non-deduced context and all that).

>> David Abrahams <dave at boost-consulting.com> writes:
[snip]
>>> No, an iterator's value_type is never const.
>>
>> Hmmmmm... That's really a bit of a shame, since I go to so much
>> trouble to pass const_iterator or iterator to the iterator_traits base
>> class, depending on whether the container has top-level const
>> qualification or not :-) 
>
> What does this have to do with the _container's_ const qualification?
>
> I just mean that iterator_traits<I>::value_type is never a const type
> for any valid iterator I.

If the container is const qualified then begin() and end() return
const_iterators, so the container_traits have to typedef the right
iterator type. I also try to use the iterator information for
is_reorderable (via has_mutable_ref):

  template<typename Container, typename ValueTraits = detail::no_override>
  struct base_container_traits
    : public ::boost::python::indexing::iterator_traits<
        BOOST_DEDUCED_TYPENAME mpl::if_<
          is_const<Container>,
          BOOST_DEDUCED_TYPENAME Container::const_iterator,
          BOOST_DEDUCED_TYPENAME Container::iterator
        >::type
      >

Of course, top-level const also affects has_insert and so on, but
those aren't related to the iterator type.

>
>>>> Possible options include specializing an is_assignable template,
>>>> specializing a value_traits template or providing an alternative
>>>> ContainerTraits class (the current method).
>>>
>>> I am not so convinced any more that the current method is worse than
>>> the others.
>>
>> Oh no! I'm starting to think that the value_traits or is_assignable
>> templates would actually be better solutions. 
>
> OK, I don't feel strongly either way.

I'm not entirely convinced about this either, so I think I'll just do
less work by leaving it "as is" :-)

>
>> I say "would be" because neither of them is at all convenient to do
>> on MSVC6 owing to the lack of PTS.
>
> How does that come into play?  It's my policy not to make major
> interface compromises for broken compilers.

Good point. It's not that difficult I suppose, just providing an
override for the container_traits ValueTraits parameter in the
workaround templates like set_suite and map_suite. Otherwise it would
all use value_traits<typename Container::value_type> and (without PTS)
get the wrong answers.

Changing subjects, I have thought of a good reason for using bitflags
instead of separate "has_this" or "has_that" static bool consts. When
adding new features, requiring a new constant (e.g. "is_serializable")
would break any existing ContainerTraits implementations that don't
have it. Adding a new bitflag value would not break anything, since
older ContainerTraits simply wouldn't ever set the flag (and wouldn't
get the new feature).

The only downside is the syntactic mess this will probably create:

  BOOST_STATIC_CONSTANT (int, feature_flags =
      (base_class::feature_flags &
       ~(is_const<mumble> ? reorderable_flag : 0)) |
      (something_else ? another_flag : 0));

Then again, maybe it doesn't have to be soooo bad:

private:
  BOOST_STATIC_CONSTANT (int, cancelled =
      is_const<mumble> ? reorderable_flag : 0;

  BOOST_STATIC_CONSTANT (int, added =
      something_else ? another_flag : 0);

public:
  BOOST_STATIC_CONSTANT (int, feature_flags =
      (base_class::feature_flags & ~cancelled) | added);

Any thoughts?

-- 
Raoul Gough.
export LESS='-X'




From RaoulGough at yahoo.co.uk  Tue Dec  9 12:28:39 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Tue, 09 Dec 2003 11:28:39 +0000
Subject: [C++-sig] Re: problems with std::string (complete msg.)
References: <000001c3be12$6fcfe450$af5edf8d@postech.ac.kr>
Message-ID: <ud6aynsbc.fsf@yahoo.co.uk>

"jsseo" <jsseo at postech.ac.kr> writes:

> I'm sorry but the previous messages I sent were broken because of the
> mailing system that I use.
> Here is the original message.
>
> When I passed a string parameter that is longer than 15,
> the program hals with the following assertion failed error message.
> The error occured when I built the project for "Debug" mode.
> (compiler: Microsoft Visual Studio .NET 2003)
>
> e.g. in python interpreter,
> from ex1 import *
> e = Ex("123456789012345") <-- ok
> e = Ex("1234567890123456") <-- error
> e.name = "123456789012345" <-- ok
> e.name = "1234567890123456" <-- error
>
> the error message
> -----------------------------
> Program:c:\python22\python.exe
> File:dbgheap.c
> Line: 1132
> Expression: _CrtlsValidHeapPointer(pUserData)

Looks like heap corruption to me. It could be that the slightly longer
string requires a new memory (re)allocation internal to the
std::string object, which only then detects a corruption that occured
earlier. This could be due to almost anything, of course. Can you
reproduce the problem using straight C++? Might be easier to track
down that way. You mind find some kind of memory leak or
write-past-the-end detection code useful (e.g.
http://dmalloc.com/). Slightly off-topic here I guess, since it seems
likely to be a straight old C++ problem.

-- 
Raoul Gough.
export LESS='-X'




From dave at boost-consulting.com  Tue Dec  9 14:38:49 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 09 Dec 2003 08:38:49 -0500
Subject: [C++-sig] Re: indexing_v2 status update
References: <u3ccdwf7b.fsf@yahoo.co.uk> <un0alwahi.fsf@boost-consulting.com>
	<uy8u5ux0u.fsf@yahoo.co.uk> <ullq5unga.fsf@boost-consulting.com>
	<ufzg1pid6.fsf@yahoo.co.uk> <u65gxnvin.fsf@boost-consulting.com>
	<ubrqoq3yl.fsf@yahoo.co.uk> <uad638k62.fsf@boost-consulting.com>
	<uvfornuk1.fsf@yahoo.co.uk> <ur7zer601.fsf@boost-consulting.com>
	<uhe0anty5.fsf@yahoo.co.uk>
Message-ID: <uiskqp0uu.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> David Abrahams <dave at boost-consulting.com> writes:
>
>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>
>>> David Abrahams <dave at boost-consulting.com> writes:
>>>
> [snip]
>>>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>>>> On the other hand, perhaps this does belong purely in the
>>>>> ContainerTraits concept. I wonder whether assignability is always a
>>>>> quality of a container (and all instances of it) or just the
>>>>> particular type of value stored in a particular instance. In the case
>>>>> of the STL containers, I think all template arguments are required to
>>>>> be Assignable types
>>>>
>>>> Yes, but...
>>>>
>>>>> and some of the containers (set and map) add
>>>>> const qualification somewhere in their value_type.
>>>>
>>>> ...that fact tends to make the value_type not Assignable.
>>>
>>> Of course. I was just thinking about whether it's conceptually related
>>> to the template arguments or rather to some property of the container
>>> template. I guess it doesn't actually make much practical difference
>>> in terms of providing the necessary partial specializations.
>>> Of course. I was just thinking about whether it's conceptually related
>>> to the template arguments or rather to some property of the container
>>> template. I guess it doesn't actually make much practical difference
>>> in terms of providing the necessary partial specializations.
>
> I've figured out what was bugging me about this. For example,
> supporting std::map this way would require a partial specialization
> for std::pair<X const, Y>. More generally, there has to be a
> value_traits (or is_assignable) specialization for the container's
> value_type, which could be something non-obvious to the client code
> (e.g. container arguments X and Y, but must specialize on
> weird_thing<X, more_weirdness<Y> >).  

Well, you could specialize

  template <class T, class U>
  struct is_assignable<std::pair<T,U> >
    : mpl::and_<is_assignable<T>, is_assignable<U> >
  {};
    
But in general I understand what you're saying.

> In the worst case, a container could use a nested class, for which
> you can't provide a partial specialization at all (non-deduced
> context and all that).

Yep, good point.

>>> David Abrahams <dave at boost-consulting.com> writes:
> [snip]
>>>> No, an iterator's value_type is never const.
>>>
>>> Hmmmmm... That's really a bit of a shame, since I go to so much
>>> trouble to pass const_iterator or iterator to the iterator_traits base
>>> class, depending on whether the container has top-level const
>>> qualification or not :-) 
>>
>> What does this have to do with the _container's_ const qualification?
>>
>> I just mean that iterator_traits<I>::value_type is never a const type
>> for any valid iterator I.
>
> If the container is const qualified then begin() and end() return
> const_iterators, so the container_traits have to typedef the right
> iterator type. I also try to use the iterator information for
> is_reorderable (via has_mutable_ref):
>
>   template<typename Container, typename ValueTraits = detail::no_override>
>   struct base_container_traits
>     : public ::boost::python::indexing::iterator_traits<
>         BOOST_DEDUCED_TYPENAME mpl::if_<
>           is_const<Container>,
>           BOOST_DEDUCED_TYPENAME Container::const_iterator,
>           BOOST_DEDUCED_TYPENAME Container::iterator
>         >::type
>       >
>
> Of course, top-level const also affects has_insert and so on, but
> those aren't related to the iterator type.

I still don't see what *that* has to do with the const-ness of an
iterator's value_type.  I can't make the connection.

>>> I say "would be" because neither of them is at all convenient to do
>>> on MSVC6 owing to the lack of PTS.
>>
>> How does that come into play?  It's my policy not to make major
>> interface compromises for broken compilers.
>
> Good point. It's not that difficult I suppose, just providing an
> override for the container_traits ValueTraits parameter in the
> workaround templates like set_suite and map_suite. Otherwise it would
> all use value_traits<typename Container::value_type> and (without PTS)
> get the wrong answers.
>
> Changing subjects, I have thought of a good reason for using bitflags
> instead of separate "has_this" or "has_that" static bool consts. 

I wasn't suggesting that you use static bool consts.

> When adding new features, requiring a new constant
> (e.g. "is_serializable") would break any existing ContainerTraits
> implementations that don't have it. Adding a new bitflag value would
> not break anything, since older ContainerTraits simply wouldn't ever
> set the flag (and wouldn't get the new feature).

That's why I was suggesting a capabilities should be indicated as a
sequence of tag types.

> The only downside is the syntactic mess this will probably create:
>
>   BOOST_STATIC_CONSTANT (int, feature_flags =
>       (base_class::feature_flags &
>        ~(is_const<mumble> ? reorderable_flag : 0)) |
>       (something_else ? another_flag : 0));
>
> Then again, maybe it doesn't have to be soooo bad:
>
> private:
>   BOOST_STATIC_CONSTANT (int, cancelled =
>       is_const<mumble> ? reorderable_flag : 0;
>
>   BOOST_STATIC_CONSTANT (int, added =
>       something_else ? another_flag : 0);
>
> public:
>   BOOST_STATIC_CONSTANT (int, feature_flags =
>       (base_class::feature_flags & ~cancelled) | added);
>
> Any thoughts?

See above.

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




From RaoulGough at yahoo.co.uk  Tue Dec  9 15:29:19 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Tue, 09 Dec 2003 14:29:19 +0000
Subject: [C++-sig] Re: indexing_v2 status update
References: <u3ccdwf7b.fsf@yahoo.co.uk> <un0alwahi.fsf@boost-consulting.com>
	<uy8u5ux0u.fsf@yahoo.co.uk> <ullq5unga.fsf@boost-consulting.com>
	<ufzg1pid6.fsf@yahoo.co.uk> <u65gxnvin.fsf@boost-consulting.com>
	<ubrqoq3yl.fsf@yahoo.co.uk> <uad638k62.fsf@boost-consulting.com>
	<uvfornuk1.fsf@yahoo.co.uk> <ur7zer601.fsf@boost-consulting.com>
	<uhe0anty5.fsf@yahoo.co.uk> <uiskqp0uu.fsf@boost-consulting.com>
Message-ID: <u8ylmnjy8.fsf@yahoo.co.uk>

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
>> David Abrahams <dave at boost-consulting.com> writes:
>>
[snip]
>>> I just mean that iterator_traits<I>::value_type is never a const type
>>> for any valid iterator I.
>>
>> If the container is const qualified then begin() and end() return
>> const_iterators, so the container_traits have to typedef the right
>> iterator type. I also try to use the iterator information for
>> is_reorderable (via has_mutable_ref):
>>
>>   template<typename Container, typename ValueTraits = detail::no_override>
>>   struct base_container_traits
>>     : public ::boost::python::indexing::iterator_traits<
>>         BOOST_DEDUCED_TYPENAME mpl::if_<
>>           is_const<Container>,
>>           BOOST_DEDUCED_TYPENAME Container::const_iterator,
>>           BOOST_DEDUCED_TYPENAME Container::iterator
>>         >::type
>>       >
>>
>> Of course, top-level const also affects has_insert and so on, but
>> those aren't related to the iterator type.
>
> I still don't see what *that* has to do with the const-ness of an
> iterator's value_type.  I can't make the connection.

Oh, right. The iterator_traits base class tries to figure out a value
for is_reorderable. From what you're saying, this is doomed to failure
because (a) the iterator reference type is unpredictable and (b) the
iterator value_type is the same in both const_iterator and iterator.

[snip]
>> Changing subjects, I have thought of a good reason for using bitflags
>> instead of separate "has_this" or "has_that" static bool consts. 
>
> I wasn't suggesting that you use static bool consts.

That's what I have at the moment though, and I'm still wondering about
whether to change it or not.

>
>> When adding new features, requiring a new constant
>> (e.g. "is_serializable") would break any existing ContainerTraits
>> implementations that don't have it. Adding a new bitflag value would
>> not break anything, since older ContainerTraits simply wouldn't ever
>> set the flag (and wouldn't get the new feature).
>
> That's why I was suggesting a capabilities should be indicated as a
> sequence of tag types.

Yes, I now see how this would address the same issue. The problem I
see with using mpl::set or such like is the cost/benefit trade off. I
don't see any way to factor out the Python method registration code
(the class_<>::def calls) into the tag types, since they don't
represent that level of decision - they only describe container
abilities, which in some cases must be combined before deciding what
methods to register. I don't see them ever representing more than
boolean values, in which case there's not much benefit in applying all
that mpl machinery. As for costs, maybe it's just because I haven't
used mpl::set before, but it seems to me to add complexity. I imagine
it introduces additional compile-time costs, big debugging symbols and
maybe insanely long error messages if something breaks (although I get
them already, of course).

-- 
Raoul Gough.
export LESS='-X'




From dave at boost-consulting.com  Tue Dec  9 21:01:38 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 09 Dec 2003 15:01:38 -0500
Subject: [C++-sig] Re: indexing_v2 status update
References: <u3ccdwf7b.fsf@yahoo.co.uk> <un0alwahi.fsf@boost-consulting.com>
	<uy8u5ux0u.fsf@yahoo.co.uk> <ullq5unga.fsf@boost-consulting.com>
	<ufzg1pid6.fsf@yahoo.co.uk> <u65gxnvin.fsf@boost-consulting.com>
	<ubrqoq3yl.fsf@yahoo.co.uk> <uad638k62.fsf@boost-consulting.com>
	<uvfornuk1.fsf@yahoo.co.uk> <ur7zer601.fsf@boost-consulting.com>
	<uhe0anty5.fsf@yahoo.co.uk> <uiskqp0uu.fsf@boost-consulting.com>
	<u8ylmnjy8.fsf@yahoo.co.uk>
Message-ID: <ullpln4kd.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> David Abrahams <dave at boost-consulting.com> writes:
>
>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>
>>> David Abrahams <dave at boost-consulting.com> writes:
>>>
> [snip]
>>>> I just mean that iterator_traits<I>::value_type is never a const type
>>>> for any valid iterator I.
>>>
>>> If the container is const qualified then begin() and end() return
>>> const_iterators, so the container_traits have to typedef the right
>>> iterator type. I also try to use the iterator information for
>>> is_reorderable (via has_mutable_ref):
>>>
>>>   template<typename Container, typename ValueTraits = detail::no_override>
>>>   struct base_container_traits
>>>     : public ::boost::python::indexing::iterator_traits<
>>>         BOOST_DEDUCED_TYPENAME mpl::if_<
>>>           is_const<Container>,
>>>           BOOST_DEDUCED_TYPENAME Container::const_iterator,
>>>           BOOST_DEDUCED_TYPENAME Container::iterator
>>>         >::type
>>>       >
>>>
>>> Of course, top-level const also affects has_insert and so on, but
>>> those aren't related to the iterator type.
>>
>> I still don't see what *that* has to do with the const-ness of an
>> iterator's value_type.  I can't make the connection.
>
> Oh, right. The iterator_traits base class

What iterator_traits are we talking about here?  The one I know about
doesn't know anything about "reorderability".

>  tries to figure out a value for is_reorderable. From what you're
> saying, this is doomed to failure because (a) the iterator reference
> type is unpredictable and (b) the iterator value_type is the same in
> both const_iterator and iterator.

And regardless none of that tells you whether it's assignable.

> [snip]
>> That's why I was suggesting a capabilities should be indicated as a
>> sequence of tag types.
>
> Yes, I now see how this would address the same issue. The problem I
> see with using mpl::set or such like is the cost/benefit trade off. I
> don't see any way to factor out the Python method registration code
> (the class_<>::def calls) into the tag types, since they don't
> represent that level of decision - they only describe container
> abilities, which in some cases must be combined before deciding what
> methods to register. 

In that case all they offer is "infinite" extensibility.

> I don't see them ever representing more than boolean values, in
> which case there's not much benefit in applying all that mpl
> machinery. As for costs, maybe it's just because I haven't used
> mpl::set before, but it seems to me to add complexity.

It does.

> I imagine it introduces additional compile-time costs, big debugging
> symbols and maybe insanely long error messages if something breaks
> (although I get them already, of course).

Yeah, what's one more? ;-)

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




From jsseo at postech.ac.kr  Wed Dec 10 01:37:46 2003
From: jsseo at postech.ac.kr (jsseo)
Date: Wed, 10 Dec 2003 09:37:46 +0900
Subject: [C++-sig] Re: Re: problems with std::string (complete msg.) 
Message-ID: <000001c3beb5$d5432010$af5edf8d@postech.ac.kr>

> "RaoulGough" writes:
> 
> "jsseo"  writes:
> 
> > I'm sorry but the previous messages I sent were broken because of the
> > mailing system that I use.
> > Here is the original message.
> >
> > When I passed a string parameter that is longer than 15,
> > the program hals with the following assertion failed error message.
> > The error occured when I built the project for "Debug" mode.
> > (compiler: Microsoft Visual Studio .NET 2003)
> >
> > e.g. in python interpreter,
> > from ex1 import *
> > e = Ex("123456789012345") <-- ok
> > e = Ex("1234567890123456") <-- error
> > e.name = "123456789012345" <-- ok
> > e.name = "1234567890123456" <-- error
> >
> > the error message
> > -----------------------------
> > Program:c:\python22\python.exe
> > File:dbgheap.c
> > Line: 1132
> > Expression: _CrtlsValidHeapPointer(pUserData)
> 
> Looks like heap corruption to me. It could be that the slightly longer
> string requires a new memory (re)allocation internal to the
> std::string object, which only then detects a corruption that occured
> earlier. This could be due to almost anything, of course. Can you
> reproduce the problem using straight C++? Might be easier to track
> down that way. You mind find some kind of memory leak or
> write-past-the-end detection code useful (e.g.
> http://dmalloc.com/). Slightly off-topic here I guess, since it seems
> likely to be a straight old C++ problem.
> 
> -- 
> Raoul Gough.
> export LESS='-X'
> 

Thank you for reply.
I tried to reproduce the problem using straight C++.
But, the strait C++ code works well.
In my thought, using "boost_python.dll" makes no problem, 
but using "boost_python_debug.dll" makes "python.exe(python22.dll)"
produce the assertion fail message.
I don't know why the project for "boost python debug version" 
did not link with "python22_d.lib" and it linked with "python22.lib."

Thanks.




From dave at boost-consulting.com  Wed Dec 10 04:23:27 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 09 Dec 2003 22:23:27 -0500
Subject: [C++-sig] Re: problems with std::string (complete msg.)
References: <000001c3beb5$d5432010$af5edf8d@postech.ac.kr>
Message-ID: <ubrqhiceo.fsf@boost-consulting.com>

"jsseo" <jsseo at postech.ac.kr> writes:

> Thank you for reply.
> I tried to reproduce the problem using straight C++.
> But, the strait C++ code works well.
> In my thought, using "boost_python.dll" makes no problem, 
> but using "boost_python_debug.dll" makes "python.exe(python22.dll)"
> produce the assertion fail message.
> I don't know why the project for "boost python debug version" 
> did not link with "python22_d.lib" and it linked with "python22.lib."

Does this answer your question?

http://www.boost.org/libs/python/doc/building.html#variants

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




From RaoulGough at yahoo.co.uk  Wed Dec 10 10:19:33 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 10 Dec 2003 09:19:33 +0000
Subject: [C++-sig] Re: indexing_v2 status update
References: <u3ccdwf7b.fsf@yahoo.co.uk> <un0alwahi.fsf@boost-consulting.com>
	<uy8u5ux0u.fsf@yahoo.co.uk> <ullq5unga.fsf@boost-consulting.com>
	<ufzg1pid6.fsf@yahoo.co.uk> <u65gxnvin.fsf@boost-consulting.com>
	<ubrqoq3yl.fsf@yahoo.co.uk> <uad638k62.fsf@boost-consulting.com>
	<uvfornuk1.fsf@yahoo.co.uk> <ur7zer601.fsf@boost-consulting.com>
	<uhe0anty5.fsf@yahoo.co.uk> <uiskqp0uu.fsf@boost-consulting.com>
	<u8ylmnjy8.fsf@yahoo.co.uk> <ullpln4kd.fsf@boost-consulting.com>
Message-ID: <uzne1m3mi.fsf@yahoo.co.uk>

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
>> David Abrahams <dave at boost-consulting.com> writes:
>>
>>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>>
[snip]
>>>>   template<typename Container, typename ValueTraits = detail::no_override>
>>>>   struct base_container_traits
>>>>     : public ::boost::python::indexing::iterator_traits<
>>>>         BOOST_DEDUCED_TYPENAME mpl::if_<
>>>>           is_const<Container>,
>>>>           BOOST_DEDUCED_TYPENAME Container::const_iterator,
>>>>           BOOST_DEDUCED_TYPENAME Container::iterator
>>>>         >::type
>>>>       >
>>>>
>>>> Of course, top-level const also affects has_insert and so on, but
>>>> those aren't related to the iterator type.
>>>
>>> I still don't see what *that* has to do with the const-ness of an
>>> iterator's value_type.  I can't make the connection.
>>
>> Oh, right. The iterator_traits base class
>
> What iterator_traits are we talking about here?  The one I know about
> doesn't know anything about "reorderability".

::boost::python::indexing::iterator_traits. It provides some typedefs,
has_copyable_iter, is_reorderable and index_style, although
is_reorderable isn't reliable, for the reasons we are currently
discussing.

>
>>  tries to figure out a value for is_reorderable. From what you're
>> saying, this is doomed to failure because (a) the iterator reference
>> type is unpredictable and (b) the iterator value_type is the same in
>> both const_iterator and iterator.
>
> And regardless none of that tells you whether it's assignable.

That's right. Initially I thought that checking whether
remove_reference<typename iter::reference> was const qualified would
do the trick (well, except for std::map) but it doesn't seem to work
on some libraries for std::set either. However, it seems ok for
containers that are normally reorderable but have top-level const
qualification. i.e. it looks like

is_const<remove_reference<container::const_iterator::reference> >

always gives the "right" answer for has_mutable_ref and therefore
is_reorderable as well.

>
>> [snip]
>>> That's why I was suggesting a capabilities should be indicated as a
>>> sequence of tag types.
>>
>> Yes, I now see how this would address the same issue. The problem I
>> see with using mpl::set or such like is the cost/benefit trade off. I
>> don't see any way to factor out the Python method registration code
>> (the class_<>::def calls) into the tag types, since they don't
>> represent that level of decision - they only describe container
>> abilities, which in some cases must be combined before deciding what
>> methods to register. 
>
> In that case all they offer is "infinite" extensibility.
>
>> I don't see them ever representing more than boolean values, in
>> which case there's not much benefit in applying all that mpl
>> machinery. As for costs, maybe it's just because I haven't used
>> mpl::set before, but it seems to me to add complexity.
>
> It does.
>
>> I imagine it introduces additional compile-time costs, big debugging
>> symbols and maybe insanely long error messages if something breaks
>> (although I get them already, of course).
>
> Yeah, what's one more? ;-)

True. Does mpl::set currently work? I seem to remember that you
suggested using mpl::vector at the moment, which raised some doubt
about this.

-- 
Raoul Gough.
export LESS='-X'




From RaoulGough at yahoo.co.uk  Wed Dec 10 10:29:13 2003
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 10 Dec 2003 09:29:13 +0000
Subject: [C++-sig] Re: problems with std::string (complete msg.)
References: <000001c3beb5$d5432010$af5edf8d@postech.ac.kr>
Message-ID: <uvfopm36e.fsf@yahoo.co.uk>

"jsseo" <jsseo at postech.ac.kr> writes:

>> "RaoulGough" writes:
>> 
>> "jsseo"  writes:
[snip]
>> > Program:c:\python22\python.exe
>> > File:dbgheap.c
>> > Line: 1132
>> > Expression: _CrtlsValidHeapPointer(pUserData)
>> 
>> Looks like heap corruption to me. It could be that the slightly longer
>> string requires a new memory (re)allocation internal to the
>> std::string object, which only then detects a corruption that occured
>> earlier. This could be due to almost anything, of course. Can you
>> reproduce the problem using straight C++? Might be easier to track
>> down that way. You mind find some kind of memory leak or
>> write-past-the-end detection code useful (e.g.
>> http://dmalloc.com/). Slightly off-topic here I guess, since it seems
>> likely to be a straight old C++ problem.
>
> Thank you for reply.
> I tried to reproduce the problem using straight C++.
> But, the strait C++ code works well.
> In my thought, using "boost_python.dll" makes no problem, 
> but using "boost_python_debug.dll" makes "python.exe(python22.dll)"
> produce the assertion fail message.
> I don't know why the project for "boost python debug version" 
> did not link with "python22_d.lib" and it linked with "python22.lib."

Just a minute here - I'm sure dbgheap.c is part of the Microsoft
runtime library (i.e. not a Python-specific library). When you link to
the non-debug version of MSVCRT you won't detect this kind of error
(at least, not as reliably). Maybe the real difference is whether you
are linking with MSVCRTD or MSVCRT? I'm pretty sure the dynamic
dependencies for boost_python_debug.dll would include MSVCRTD.DLL.

-- 
Raoul Gough.
export LESS='-X'




From cimca at ise.canberra.edu.au  Tue Dec  9 23:51:04 2003
From: cimca at ise.canberra.edu.au (cimca)
Date: Wed, 10 Dec 2003 09:51:04 +1100
Subject: [C++-sig] CFP: International Conference on Computational
 Intelligence for Modelling,  Control and Automation
Message-ID: <6.0.0.22.1.20031210094922.00a145d0@mercury.ise.canberra.edu.au>

                              CALL FOR PAPERS

      International Conference on Computational Intelligence for Modelling,
                         Control and Automation
                              12-14 July 2004
                              Gold Coast, Australia
        http://www.ise.canberra.edu.au/conferences/cimca04/index.htm

                                Jointly with
      International Conference on Intelligent Agents, Web Technologies
                             and Internet Commerce
                               12-14 July 2004
                              Gold Coast, Australia
        http://www.ise.canberra.edu.au/conferences/iawtic04/index.htm



The international conference on computational intelligence for modelling,
control and automation will be held in Gold Coast, Australia on 12-14 July
2004. The conference provides a medium for the exchange of ideas between
theoreticians
and practitioners to address the important issues in computational
intelligence,
modelling, control and automation.

The conference will consist of both plenary sessions and contributory
sessions, focusing on theory, implementation and applications of
computational intelligence techniques to modelling, control and
automation. For contributory sessions, papers (4 pages or more)
are being solicited. Several well-known keynote speakers will address
the conference. Topics of the conference include, but are not limited
to, the following areas:

Modern and Advanced Control Strategies:
Neural Networks Control,
Fuzzy Logic Control,
Genetic Algorithms & Evolutionary Control,
Model-Predictive Control,
Adaptive and Optimal Control,
Intelligent Control Systems,
Robotics and Automation,
Fault Diagnosis,
Intelligent agents,
Industrial Automations

Hybrid Systems:
Fuzzy Evolutionary Systems,
Fuzzy Expert Systems,
Fuzzy Neural Systems,
Neural Genetic Systems,
Neural-Fuzzy-Genetic Systems,
Hybrid Systems for Optimisation

Data Analysis, Prediction and Model Identification:
Signal Processing,
Prediction & Time Series Analysis,
System Identification,
Data Fusion and Mining,
Knowledge Discovery,
Intelligent Information Systems,
Image Processing,
Image Understanding,
Parallel Computing applications in Identification & Control,
Pattern Recognition,
Clustering,
Classification


Decision Making and Information Retrieval:
Case-Based Reasoning,
Decision Analysis,
Intelligent Databases & Information Retrieval,
Dynamic Systems Modelling,
Decision Support Systems,
Multi-criteria Decision Making,
Qualitative and Approximate-Reasoning


Paper Submission
Papers will be selected based on their originality, significance,
correctness, and clarity of presentation. Papers
(4 pages or more) should be submitted to the following e-mail or
the following address:

CIMCA'2004 Secretariat
School of Computing
University of Canberra
Canberra, 2601, ACT, Australia
E-mail: cimca at ise.canberra.edu.au

E-mail submission is preferred. Papers should present
original work, which has not been published or being reviewed for other
conferences.

Important Dates
? 14 March 2004 Submission of papers
? 30 April 2004 Notification of acceptance
? 21 May 2004 Deadline for camera-ready copies of accepted papers
? 12-14 July 2004 Conference sessions


Special Sessions and Tutorials
Special sessions and tutorials will be organised at the conference.
The conference is calling for special sessions and tutorial proposals.
All proposals should be sent to the conference chair on or before
  27th February 2004. CIMCA'04 will also include a special poster session
  devoted to recent work and work-in-progress. Abstracts are solicited
for this session. Abstracts (3 pages limit) may be submitted up to
30 days before the conference date.

Invited Sessions
Keynote speakers from academia and industry will be addressing the main
issues of the conference.

Visits and social events
Sightseeing visits will be arranged for the delegates and guests. A
separate program will be arranged for companions during the conference.

Further Information
For further information either contact cimca at ise.canberra.edu.au
or see the conference homepage at:
http://www.ise.canberra.edu.au/conferences/cimca04/index.htm





From Masoud.Mohammadian at ise.canberra.edu.au  Mon Dec  8 05:24:37 2003
From: Masoud.Mohammadian at ise.canberra.edu.au (Mohammadian, Masoud)
Date: Mon, 8 Dec 2003 15:24:37 +1100
Subject: [C++-sig] Call for Tutorial Presentations
Message-ID: <A2DBDF9D1E09184D867F4862CF3B415E6E8CB1@mercury.ise.win.canberra.edu.au>




    -~-~--~-~--~-~--~-~--~-~--~-~--~-~--~-~--~-~--~-~--~-~-
   {                 CALL FOR TUTORIALS                                }
   {                        at                                                        }
   { International conference on Computational Intelligence    }
   {      for Modelling, Control and Automation - CIMCA'04     }
   {                Gold Coast - Australia                                  }
   {                                                                                  }
    -~-~--~-~--~-~--~-~--~-~--~-~--~-~--~-~--~-~--~-~--~-~-

The orgainsing committe of the CIMCA'04 invitats researchers and practitioners to submit
proposals for tutorialss in connection with CIMCA'04 
to be held Gold Coast - Australia from 12 to 14 July 2004.

Researchers and practitioners are invited to submit their tutorial-proposals to the conference 
tutorial chair at: cimca at ise.canberra.edu.au 

Tutorial proposals are limited to up to 4 pages for the outline as well as the Biography of the presenter/s. 
The proposal should contain: 

An abstract (briefly describing the aims and technical contents of the tutorial)
An introduction
An outline of the topic
Intended audience (interested audience and required background knowledge)
Biography of presenter/s
Contact information of presenter/s


Each tutorial proposal will be assessed based on significance, originality as well as scientific and technical interest. 

Important dates
Tutorial Proposals due date 16 January 2004 
Proposal Notifications 30 January 2004 




From jsseo at postech.ac.kr  Thu Dec 11 05:41:29 2003
From: jsseo at postech.ac.kr (Jinseok Seo)
Date: Thu, 11 Dec 2003 13:41:29 +0900
Subject: =?iso-8859-1?B?UmU6IFtDKystc2lnXSBSZTogcHJvYmxlbXMgd2l0aCBzdGQ6OnN0cmlu?=
	=?iso-8859-1?B?ZyAoY29tcGxldGUgbXNnLik=?=
Message-ID: <20031211.AAA1071117363@postech.ac.kr>

Thank you for your kind reply.
I fixed the problem.
As you advised me, the reason was a heap mismatch.
I was using static heap(MSVCRTD?) library and 
dynamic heap library, simultaneously.

Thank you.

Jinseok Seo

> 
> "RaoulGough" writes: 
> 
> "jsseo"  writes:
> 
> >> "RaoulGough" writes:
> >> 
> >> "jsseo"  writes:
> [snip]
> >> > Program:c:\python22\python.exe
> >> > File:dbgheap.c
> >> > Line: 1132
> >> > Expression: _CrtlsValidHeapPointer(pUserData)
> >> 
> >> Looks like heap corruption to me. It could be that the slightly longer
> >> string requires a new memory (re)allocation internal to the
> >> std::string object, which only then detects a corruption that occured
> >> earlier. This could be due to almost anything, of course. Can you
> >> reproduce the problem using straight C++? Might be easier to track
> >> down that way. You mind find some kind of memory leak or
> >> write-past-the-end detection code useful (e.g.
> >> http://dmalloc.com/). Slightly off-topic here I guess, since it seems
> >> likely to be a straight old C++ problem.
> >
> > Thank you for reply.
> > I tried to reproduce the problem using straight C++.
> > But, the strait C++ code works well.
> > In my thought, using "boost_python.dll" makes no problem, 
> > but using "boost_python_debug.dll" makes "python.exe(python22.dll)"
> > produce the assertion fail message.
> > I don't know why the project for "boost python debug version" 
> > did not link with "python22_d.lib" and it linked with "python22.lib."
> 
> Just a minute here - I'm sure dbgheap.c is part of the Microsoft
> runtime library (i.e. not a Python-specific library). When you link to
> the non-debug version of MSVCRT you won't detect this kind of error
> (at least, not as reliably). Maybe the real difference is whether you
> are linking with MSVCRTD or MSVCRT? I'm pretty sure the dynamic
> dependencies for boost_python_debug.dll would include MSVCRTD.DLL.
> 
> -- 
> Raoul Gough.
> export LESS='-X'
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 



From jsseo at postech.ac.kr  Thu Dec 11 06:46:46 2003
From: jsseo at postech.ac.kr (jsseo)
Date: Thu, 11 Dec 2003 14:46:46 +0900
Subject: [C++-sig] Re: problems with std::string (complete msg.)
Message-ID: <000001c3bfaa$2a926a90$af5edf8d@postech.ac.kr>

Thank you for your kind reply.
I fixed the problem.
As you advised me, the reason was a heap mismatch.
I was using static heap(MSVCRTD?) library and 
dynamic heap library, simultaneously.

Thank you.

Jinseok Seo
> 
> "RaoulGough" writes:
> 
> "jsseo" writes:
> 
> >> "RaoulGough" writes:
> >> 
> >> "jsseo" writes:
> [snip]
> >> > Program:c:\python22\python.exe
> >> > File:dbgheap.c
> >> > Line: 1132
> >> > Expression: _CrtlsValidHeapPointer(pUserData)
> >> 
> >> Looks like heap corruption to me. It could be that the slightly longer
> >> string requires a new memory (re)allocation internal to the
> >> std::string object, which only then detects a corruption that occured
> >> earlier. This could be due to almost anything, of course. Can you
> >> reproduce the problem using straight C++? Might be easier to track
> >> down that way. You mind find some kind of memory leak or
> >> write-past-the-end detection code useful (e.g.
> >> http://dmalloc.com/). Slightly off-topic here I guess, since it seems
> >> likely to be a straight old C++ problem.
> >
> > Thank you for reply.
> > I tried to reproduce the problem using straight C++.
> > But, the strait C++ code works well.
> > In my thought, using "boost_python.dll" makes no problem, 
> > but using "boost_python_debug.dll" makes "python.exe(python22.dll)"
> > produce the assertion fail message.
> > I don't know why the project for "boost python debug version" 
> > did not link with "python22_d.lib" and it linked with "python22.lib."
> 
> Just a minute here - I'm sure dbgheap.c is part of the Microsoft
> runtime library (i.e. not a Python-specific library). When you link to
> the non-debug version of MSVCRT you won't detect this kind of error
> (at least, not as reliably). Maybe the real difference is whether you
> are linking with MSVCRTD or MSVCRT? I'm pretty sure the dynamic
> dependencies for boost_python_debug.dll would include MSVCRTD.DLL.
> 
> -- 
> Raoul Gough.
> export LESS='-X'
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 






From CiNnAmOnBaBe123 at aol.com  Fri Dec 12 21:08:40 2003
From: CiNnAmOnBaBe123 at aol.com (CiNnAmOnBaBe123 at aol.com)
Date: Fri, 12 Dec 2003 15:08:40 EST
Subject: [C++-sig] hi
Message-ID: <fb.4c0dd4b1.2d0b7a48@aol.com>


hi i'am hoping you can help me out on this i've been trying to figure out the 
unicodes for my fonts but i have no idea on how to do that and its been 
buggin me on how to fine the code for them,,,,, thanks a bunch if you can help.
CinnamonBabe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031212/99712afe/attachment.htm>

From dave at boost-consulting.com  Sat Dec 13 16:34:56 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 13 Dec 2003 10:34:56 -0500
Subject: [C++-sig] Re: indexing_v2 status update
References: <u3ccdwf7b.fsf@yahoo.co.uk> <un0alwahi.fsf@boost-consulting.com>
	<uy8u5ux0u.fsf@yahoo.co.uk> <ullq5unga.fsf@boost-consulting.com>
	<ufzg1pid6.fsf@yahoo.co.uk> <u65gxnvin.fsf@boost-consulting.com>
	<ubrqoq3yl.fsf@yahoo.co.uk> <uad638k62.fsf@boost-consulting.com>
	<uvfornuk1.fsf@yahoo.co.uk> <ur7zer601.fsf@boost-consulting.com>
	<uhe0anty5.fsf@yahoo.co.uk> <uiskqp0uu.fsf@boost-consulting.com>
	<u8ylmnjy8.fsf@yahoo.co.uk> <ullpln4kd.fsf@boost-consulting.com>
	<uzne1m3mi.fsf@yahoo.co.uk>
Message-ID: <usmjowx27.fsf@boost-consulting.com>

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> David Abrahams <dave at boost-consulting.com> writes:
>
>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>
>>> David Abrahams <dave at boost-consulting.com> writes:
>>>
>>>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>>>
> [snip]
>>>>>   template<typename Container, typename ValueTraits = detail::no_override>
>>>>>   struct base_container_traits
>>>>>     : public ::boost::python::indexing::iterator_traits<
>>>>>         BOOST_DEDUCED_TYPENAME mpl::if_<
>>>>>           is_const<Container>,
>>>>>           BOOST_DEDUCED_TYPENAME Container::const_iterator,
>>>>>           BOOST_DEDUCED_TYPENAME Container::iterator
>>>>>         >::type
>>>>>       >
>>>>>
>>>>> Of course, top-level const also affects has_insert and so on, but
>>>>> those aren't related to the iterator type.
>>>>
>>>> I still don't see what *that* has to do with the const-ness of an
>>>> iterator's value_type.  I can't make the connection.
>>>
>>> Oh, right. The iterator_traits base class
>>
>> What iterator_traits are we talking about here?  The one I know about
>> doesn't know anything about "reorderability".
>
> ::boost::python::indexing::iterator_traits. It provides some typedefs,
> has_copyable_iter, is_reorderable and index_style, although

This describes traits of containers, right?  Calling something
iterator_traits which doesn't describe traits of iterators is very
confusing.

> is_reorderable isn't reliable, for the reasons we are currently
> discussing.
>
>>
>>>  tries to figure out a value for is_reorderable. From what you're
>>> saying, this is doomed to failure because (a) the iterator reference
>>> type is unpredictable and (b) the iterator value_type is the same in
>>> both const_iterator and iterator.
>>
>> And regardless none of that tells you whether it's assignable.
>
> That's right. Initially I thought that checking whether
> remove_reference<typename iter::reference> was const qualified would
> do the trick (well, except for std::map) but it doesn't seem to work
> on some libraries for std::set either. However, it seems ok for
> containers that are normally reorderable but have top-level const
> qualification. i.e. it looks like
>
> is_const<remove_reference<container::const_iterator::reference> >
>
> always gives the "right" answer for has_mutable_ref and therefore
> is_reorderable as well.

Ouch!  That seems like it has to be pure luck.  After all, for
std::set, const_iterator == iterator is legal, and it's easy to
imagine a set<T> iterator which returns T const& from dereference.

Further, as I've been trying to tell you, the iterator's "reference"
type is currently not constrained by the standard in many cases.  Much
better to use the same trick used in is_lvalue_iterator.

>>> [snip]
>>>> That's why I was suggesting a capabilities should be indicated as a
>>>> sequence of tag types.
>>>
>>> Yes, I now see how this would address the same issue. The problem I
>>> see with using mpl::set or such like is the cost/benefit trade off. I
>>> don't see any way to factor out the Python method registration code
>>> (the class_<>::def calls) into the tag types, since they don't
>>> represent that level of decision - they only describe container
>>> abilities, which in some cases must be combined before deciding what
>>> methods to register. 
>>
>> In that case all they offer is "infinite" extensibility.
>>
>>> I don't see them ever representing more than boolean values, in
>>> which case there's not much benefit in applying all that mpl
>>> machinery. As for costs, maybe it's just because I haven't used
>>> mpl::set before, but it seems to me to add complexity.
>>
>> It does.
>>
>>> I imagine it introduces additional compile-time costs, big debugging
>>> symbols and maybe insanely long error messages if something breaks
>>> (although I get them already, of course).
>>
>> Yeah, what's one more? ;-)
>
> True. 

That's not to say I'm convinced it's a good idea.  Infinite
extensibility may not be important.

> Does mpl::set currently work? I seem to remember that you
> suggested using mpl::vector at the moment, which raised some doubt
> about this.

see libs/mpl/test/set.cpp.  You can try it yourself and find out.

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




From dave at boost-consulting.com  Sat Dec 13 16:36:58 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 13 Dec 2003 10:36:58 -0500
Subject: [C++-sig] Re: Problem with boost::python::iterator
References: <1070896078.1103.8.camel@pbarbier>
	<ullpmr5pc.fsf@boost-consulting.com>
	<1070962861.582.25.camel@pbarbier>
Message-ID: <un09wwwyt.fsf@boost-consulting.com>

Pierre Barbier de Reuille <pierre.barbier at cirad.fr> writes:

> Ok, I solved my problem and deduced that :
>
>  1 - if I need to export an iterator on objects,
> return_internal_reference<> works fine
>  2 - for types who need to get copyed (the ones who would not require
> any call policy), I cannot specify default_call_policies, so I have to
> leave the policy blank

Does this help?

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

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




From s_sourceforge at nedprod.com  Sun Dec 14 18:39:09 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 14 Dec 2003 17:39:09 -0000
Subject: [C++-sig] Parsing complex C++
Message-ID: <3FDCA03D.9315.9A4DE9CE@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well, it seems the latest release of my library has finally broken 
gccxml :( and I was hoping someone here might know what to do.

Constructs like as follows:

template<typename type, class next, template<class> class instance> 
struct instantiateH<typename item<type, next>, instance>
		: public instance<type>, public instantiateH<next, instance> {};

... seem to confuse gccxml no end and thus pyste won't work anymore. 
So therefore I have two solutions:

(i): Get a gccxml which will handle the above. Will the above work 
with GCC 3.3 or 3.4? This will mean me patching 3.3 or 3.4 myself :(

(ii): Modify the code above to make gccxml happy. GCCXML is based on 
GCC 3.0.4 which I think is half the problem.

Thoughts? BTW, not seen any updates to pyste for a while :(

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP9ygPcEcvDLFGKbPEQIxbACgwGbYPJ2GYAui/i31OhzKBE17J70Animc
3es51wOYa0vkKuH/RPQKbEUy
=X1bZ
-----END PGP SIGNATURE-----



From chouyiyu at hotmail.com  Mon Dec 15 15:36:13 2003
From: chouyiyu at hotmail.com (Yi-Yu Chou)
Date: Mon, 15 Dec 2003 14:36:13 +0000
Subject: [C++-sig] How to integrate python, vtk and C++
Message-ID: <BAY8-F23wMfgZUr3CrJ0002a8ba@hotmail.com>

Dear all,

I need to integrate python, vtk and my own C++ object.
Is it possible to do it by using Booth.Python or it's better to use 
Python/C++ API ? 
Where can I find the examples ?
Thanks in advance !!!!

Best,
YY

_________________________________________________________________
???? MSN Mobile ??????? MSN Messenger ??????  
http://msn.com.tw/msnmobile 




From nicodemus at esss.com.br  Mon Dec 15 17:23:04 2003
From: nicodemus at esss.com.br (Nicodemus)
Date: Mon, 15 Dec 2003 13:23:04 -0300
Subject: [C++-sig] Parsing complex C++
In-Reply-To: <3FDCA03D.9315.9A4DE9CE@localhost>
References: <3FDCA03D.9315.9A4DE9CE@localhost>
Message-ID: <3FDDDFE8.5090708@esss.com.br>

Hi Niall,

Niall Douglas wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Well, it seems the latest release of my library has finally broken 
>gccxml :( and I was hoping someone here might know what to do.
>
>Constructs like as follows:
>
>template<typename type, class next, template<class> class instance> 
>struct instantiateH<typename item<type, next>, instance>
>		: public instance<type>, public instantiateH<next, instance> {};
>
>... seem to confuse gccxml no end and thus pyste won't work anymore. 
>So therefore I have two solutions:
>
>(i): Get a gccxml which will handle the above. Will the above work 
>with GCC 3.3 or 3.4? This will mean me patching 3.3 or 3.4 myself :(
>  
>

I see you already posted in the GCCXML mail list, so I would wait for an 
answer there.

>(ii): Modify the code above to make gccxml happy. GCCXML is based on 
>GCC 3.0.4 which I think is half the problem.
>  
>

If you can change the code, it's a valid option too.

>Thoughts? BTW, not seen any updates to pyste for a while :(
>  
>

I was about to send an email to the list about that. I have been very 
busy lately, without any time for Pyste at all (and my games, an my 
books... 8( ), but that doesn't mean that I abandoned it. As soon as I 
have time (I will be in vacation shortly) I plan to integrate some 
patches that have been sitting in my todo list for some time now.

Regards,
Nicodemus.




From nidoizo at yahoo.com  Mon Dec 15 17:56:10 2003
From: nidoizo at yahoo.com (Nicolas Fleury)
Date: Mon, 15 Dec 2003 11:56:10 -0500
Subject: [C++-sig] How to access boost::python::str buffer
Message-ID: <brkp3b$i18$1@sea.gmane.org>

Hi,
	I have a binary buffer stored in a boost::python::str.  How do I access 
the buffer to store it in a void*?  (I guess I get the size with 
.attr("__len__")() )

Thx and Regards,

Nicolas





From s_sourceforge at nedprod.com  Mon Dec 15 13:30:22 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Mon, 15 Dec 2003 12:30:22 -0000
Subject: [C++-sig] Converting a python exception to a C++ exception
Message-ID: <3FDDA95E.27000.9E599239@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Someone asked for this week before last and I apologise for it being 
a week later than I originally stated. I got bogged down in 
intermediate matters not least getting a tooth extracted (ouch!).

Here's what I've come up with to translate python exceptions:

using namespace boost::python;
void FXPython::int_throwPythonException()
{
	PyObject *err=PyErr_Occurred();
	if(!err) return;
	FXString msg;
	{
		PyObject *_type, *_pvalue, *_ptraceback;
		PyErr_Fetch(&_type, &_pvalue, &_ptraceback);
		PyErr_NormalizeException(&_type, &_pvalue, &_ptraceback);
		if(!_type) return;
		handle<> type(_type), pvalue(_pvalue), ptraceback(_ptraceback);
		object traceback(ptraceback);
		// Ok, build a message
		str etype(type), eparam(pvalue), 
file(traceback.attr("tb_frame").attr("f_code").attr("co_filename"));
		msg.format("%s,%s at line %d in %s",
			extract<const char *>(etype), extract<const char *>(eparam),
			extract<int>(traceback.attr("tb_lineno")), extract<const char 
*>(file));
	}
	FXPythonException e(msg, 0);
	FXERRH_THROW(e);
}

And to test for errors when calling the Python C API directly:

#define FXERRHPY(ret) { if((ret)<=0) 
FXPython::int_throwPythonException(); }

Obviously, others won't have FXString nor FXPythonException, but you 
get the idea. Fetch the python exception, decode it into its bits, 
build an error string and throw as a C++ exception.

BTW Dave, congrats on the really easy to use object interface. I keep 
accidentally writing python itself because it's so similar!

I hope this helps whoever it was who asked. I should warn you that 
due to problems with GCC-XML I can't actually test any code right 
now, but the above does compile.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP92pXsEcvDLFGKbPEQLH7QCcD5kO4aKIKxZdXj86lxZH1/N1Pm4AoOe/
LWwCKubM3y+s3II8w9T4qhvD
=OBA9
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Mon Dec 15 20:11:26 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Mon, 15 Dec 2003 19:11:26 -0000
Subject: Solution for passing a function pointer as an argument (was: Re:
	[C++-sig] Parsing complex C++)
In-Reply-To: <3FDDDFE8.5090708@esss.com.br>
References: <3FDCA03D.9315.9A4DE9CE@localhost>
Message-ID: <3FDE075E.15091.9FC8C41E@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15 Dec 2003 at 13:23, Nicodemus wrote:

> I was about to send an email to the list about that. I have been very
> busy lately, without any time for Pyste at all (and my games, an my
> books... 8( ), but that doesn't mean that I abandoned it. As soon as I
> have time (I will be in vacation shortly) I plan to integrate some
> patches that have been sitting in my todo list for some time now.

v0.5 of TnFOX will be out before Christmas and it provides full 
"embed TnFOX into Python" and "embed Python into TnFOX" 
functionality. There shouldn't be any more outstanding issues with 
python in TnFOX except that pyste still doesn't have AllFromHeader() 
working and thus not everything is represented yet.

BTW, I have a solution to the "installing a python function as a C-
style callback" problem with no alterations required to the original 
C++ library. Basically I've written a generic class which generates X 
static functions taking any arbitrary set of parameters & return 
(specified by a policy) and stores the function pointers into an 
array during construction. Now you can pass one of those strawman 
function addresses to the C++ code which when called indexes the 
array, gets the corresponding python function and calls it with the 
relevent parameters. The solves the FAQ problem "How can I wrap a 
function which takes a function pointer as an argument?".

Unfortunately this solution is based upon TnFOX's compile-time 
library but should provide a very good start for anyone with a 
similar problem. I should warn you that I do a lot of template 
classes inheriting off their template parameters so the logic gets 
quite convoluted.

How about updating the FAQ? Ralf shall I send a diff to you?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP94HX8EcvDLFGKbPEQIv+QCfTEWsUU039VBPSLIr9TPfzfZX0BAAoIm7
CanC6PYwfwdEntT8lnnttkjy
=EY3+
-----END PGP SIGNATURE-----



From CiNnAmOnBaBe123 at aol.com  Mon Dec 15 23:26:40 2003
From: CiNnAmOnBaBe123 at aol.com (CiNnAmOnBaBe123 at aol.com)
Date: Mon, 15 Dec 2003 17:26:40 EST
Subject: [C++-sig] Fwd: hi
Message-ID: <67.1e785b96.2d0f8f20@aol.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031215/e4d643b0/attachment.htm>
-------------- next part --------------
An embedded message was scrubbed...
From: CiNnAmOnBaBe123 at aol.com
Subject: hi
Date: Fri, 12 Dec 2003 15:08:40 EST
Size: 1747
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031215/e4d643b0/attachment.eml>

From mike at nospam.com  Tue Dec 16 00:44:59 2003
From: mike at nospam.com (Mike Rovner)
Date: Mon, 15 Dec 2003 15:44:59 -0800
Subject: [C++-sig] Re: How to integrate python, vtk and C++
References: <BAY8-F23wMfgZUr3CrJ0002a8ba@hotmail.com>
Message-ID: <brlh1o$rvh$1@sea.gmane.org>

Yi-Yu Chou wrote:
> Where can I find the examples ?

http://www.boost.org/libs/python/doc/tutorial/

HTH,
Mike






From dave at boost-consulting.com  Tue Dec 16 01:20:19 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 15 Dec 2003 19:20:19 -0500
Subject: [C++-sig] Re: Fwd: hi
References: <67.1e785b96.2d0f8f20@aol.com>
Message-ID: <uekv5k3zw.fsf@boost-consulting.com>

CiNnAmOnBaBe123 at aol.com writes:

> From: CiNnAmOnBaBe123 at aol.com
> Subject: hi
> To: c++-sig at python.org
> Date: Fri, 12 Dec 2003 15:08:40 EST
>
>
> hi i'am hoping you can help me out on this i've been trying to figure out the 
> unicodes for my fonts but i have no idea on how to do that and its been 
> buggin me on how to fine the code for them,,,,, thanks a bunch if you can help.
> CinnamonBabe

Does this question have something to do with Python/C++ integration?
It doesn't seem to.  If it doesn't, you're posting to the wrong forum.

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




From mike.thompson at day8.com.au  Tue Dec 16 01:39:56 2003
From: mike.thompson at day8.com.au (Mike Thompson)
Date: Tue, 16 Dec 2003 11:39:56 +1100
Subject: [C++-sig] Re: How to integrate python, vtk and C++
References: <BAY8-F23wMfgZUr3CrJ0002a8ba@hotmail.com>
Message-ID: <brlk90$1ll$1@sea.gmane.org>


"Yi-Yu Chou" <chouyiyu at hotmail.com> wrote in message
news:BAY8-F23wMfgZUr3CrJ0002a8ba at hotmail.com...
> Dear all,
>
> I need to integrate python, vtk and my own C++ object.
> Is it possible to do it by using Booth.Python or it's better to use
> Python/C++ API ?
> Where can I find the examples ?
> Thanks in advance !!!!
>

You might be interested in:  http://mayavi.sourceforge.net/

--
Mike






From dave at boost-consulting.com  Tue Dec 16 01:21:59 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 15 Dec 2003 19:21:59 -0500
Subject: [C++-sig] Re: How to access boost::python::str buffer
References: <brkp3b$i18$1@sea.gmane.org>
Message-ID: <u8yldk3x4.fsf@boost-consulting.com>

Nicolas Fleury <nidoizo at yahoo.com> writes:

> Hi,
> 	I have a binary buffer stored in a boost::python::str.  How do I
> 	access the buffer to store it in a void*?  (I guess I get the size
> 	with .attr("__len__")() )
>
> Thx and Regards,

static_cast<void*>(
     const_cast<void const*>( 
           extract<char const*>(x)()
     )
)

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




From prabhu at aero.iitm.ernet.in  Tue Dec 16 02:42:49 2003
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Tue, 16 Dec 2003 07:12:49 +0530
Subject: [C++-sig] Re: How to integrate python, vtk and C++
In-Reply-To: <brlk90$1ll$1@sea.gmane.org>
References: <BAY8-F23wMfgZUr3CrJ0002a8ba@hotmail.com>
	<brlk90$1ll$1@sea.gmane.org>
Message-ID: <16350.25369.836517.732887@monster.linux.in>

>>>>> "MT" == Mike Thompson <mike.thompson at day8.com.au> writes:

    MT> "Yi-Yu Chou" <chouyiyu at hotmail.com> wrote in message
    MT> news:BAY8-F23wMfgZUr3CrJ0002a8ba at hotmail.com...
    >> I need to integrate python, vtk and my own C++ object.  Is it
    >> possible to do it by using Booth.Python or it's better to use
    >> Python/C++ API ?  Where can I find the examples ?  Thanks in
    >> advance !!!!

    MT> You might be interested in: http://mayavi.sourceforge.net/

MayaVi is not going to help in this regard. :( Yi-Yu's should really
search the vtkusers mailing list archives.  This question has been
raised and answered before there and might want to read these threads.

http://public.kitware.com/pipermail/vtkusers/2003-September/020270.html

http://public.kitware.com/pipermail/vtkusers/2003-August/019790.html

http://public.kitware.com/pipermail/vtkusers/2002-October/013951.html

http://public.kitware.com/pipermail/vtkusers/2002-February/009569.html

This is the most recent:

http://public.kitware.com/pipermail/vtkusers/2003-October/020500.html

cheers,
prabhu



From raoulgough at yahoo.co.uk  Tue Dec 16 12:11:37 2003
From: raoulgough at yahoo.co.uk (=?iso-8859-1?q?Raoul=20Gough?=)
Date: Tue, 16 Dec 2003 11:11:37 +0000 (GMT)
Subject: [C++-sig] Re: indexing_v2 status update
Message-ID: <20031216111137.80177.qmail@web25202.mail.ukl.yahoo.com>

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
>> ::boost::python::indexing::iterator_traits. It provides some
typedefs,
>> has_copyable_iter, is_reorderable and index_style, although
>
>This describes traits of containers, right?  Calling something
>iterator_traits which doesn't describe traits of iterators is very
>confusing.

Well, I'm not *so* sure it's wrong. It's supposed to describe features
that can be deduced from properties of the iterator, and since it's in
the indexing:: namespace, I didn't think the name was too bad.
Unfortunately, it looks like the only feature it's guaranteed to
determine reliably is has_copyable_iter. This leaves a problem for
iterator_range, where the iterator is all that there is to go on, and I
suppose it currently breaks on things like
iterator_range<std::map<...>::iterator>.

>> However, it seems ok for
>> containers that are normally reorderable but have top-level const
>> qualification. i.e. it looks like
>>
>> is_const<remove_reference<container::const_iterator::reference> >
>>
>> always gives the "right" answer for has_mutable_ref and therefore
>> is_reorderable as well.
>
>Ouch!  That seems like it has to be pure luck.  After all, for
>std::set, const_iterator == iterator is legal, and it's easy to
>imagine a set<T> iterator which returns T const& from dereference.
>
>Further, as I've been trying to tell you, the iterator's "reference"
>type is currently not constrained by the standard in many cases.  Much
>better to use the same trick used in is_lvalue_iterator.

I understand what you've been saying about the reference type, and all
I'm saying is that it works in practice for const containters on all
the compilers I've tried so far. Things like std::set and std::map
require extra handling anyway, because we actually need is_assignable,
not merely is_lvalue or is_mutable_ref.

Anyway, I think this particular issue will disappear once I move to
bitsets or mpl::set, since it would simply be a question of maksing off
certain features if the container is const qualified. I'll have a
better look at mpl::set when I get a chance (hopefully by next week
sometime). I've been considering whether it would be possible to
provide an abstraction that would allow a change of implementation
between bitsets or mpl::set without affecting client code.

Regards,
Raoul Gough.

________________________________________________________________________
BT Yahoo! Broadband - Save ?80 when you order online today. Hurry! Offer ends 21st December 2003. The way the internet was meant to be. http://uk.rd.yahoo.com/evt=21064/*http://btyahoo.yahoo.co.uk



From s_sourceforge at nedprod.com  Wed Dec 17 20:39:47 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 17 Dec 2003 19:39:47 -0000
Subject: [C++-sig] throw_error_already_set()
Message-ID: <3FE0B103.24673.AA2F70D4@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Now I have my custom exception which interrogates python and builds a 
very useful C++ exception replete with python traceback, I'd like 
this to be generated whenever there's a python exception raised.

Unfortunately, the C++ exception error_already_set appears to be 
thrown not only for python exceptions but also for internal BPL 
errors. I'd far prefer BPL to keep throwing error_already_set when it 
can't match parameter types etc. and throw my exception when it's 
just a plain python problem. OTOH, BPL seems to set the python error 
state when it throws error_already_set so maybe this is okay.

Is it possible to modify BPL to do this or am I relegated to wrapping 
every BPL call with a try...catch(error_already_set &)? I did notice 
there only appears to be one place where error_already_set is caught 
within BPL - therefore couldn't I literally just do a find & replace 
(or better, a #define throw_error_already_set 
FXPython::int_throwPythonException() so I don't have problems with 
merging new releases)

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP+CxBcEcvDLFGKbPEQLZ3gCfRUqDJN3hd8/XGaAPxyve7Nu7/y4An0Y7
Z01dYQKZXCp+snRhWg8NAfFF
=LbA/
-----END PGP SIGNATURE-----



From dave at boost-consulting.com  Wed Dec 17 20:51:12 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 17 Dec 2003 14:51:12 -0500
Subject: [C++-sig] Re: throw_error_already_set()
References: <3FE0B103.24673.AA2F70D4@localhost>
Message-ID: <uu13zi5ov.fsf@boost-consulting.com>

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

> Now I have my custom exception which interrogates python and builds a 
> very useful C++ exception replete with python traceback, I'd like 
> this to be generated whenever there's a python exception raised.
>
> Unfortunately, the C++ exception error_already_set appears to be 
> thrown not only for python exceptions but also for internal BPL 
> errors

Specifics, please.

I think you're misinterpreting things.  Internal errors in BPL are
always handled with assert(), and never with exceptions.

> I'd far prefer BPL to keep throwing error_already_set when it 
> can't match parameter types etc. and throw my exception when it's 
> just a plain python problem. OTOH, BPL seems to set the python error 
> state when it throws error_already_set so maybe this is okay.

OK.  Sorry, is there a problem or not?

> Is it possible to modify BPL to do this

I don't think so.  Well, OK, we could provide a hookable error
handler.  I'd worry how it'd interact with threads, though.

Why don't you just look at the python error state at the catch
point?

> or am I relegated to wrapping every BPL call with a
> try...catch(error_already_set &)? 

I think you need to re-evaluate your EH strategy.  You must be
embedding Python.  You should handle Boost.Python errors in the same
place where you handle other exceptions in your program.

> I did notice there only appears to be one place where
> error_already_set is caught within BPL - therefore couldn't I
> literally just do a find & replace (or better, a #define
> throw_error_already_set FXPython::int_throwPythonException() so I
> don't have problems with merging new releases)

No comment.  Modify your private copy of the Boost.Python sources at
your peril (or not).

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




From Marc.Kwiatkowski at veritas.com  Thu Dec 18 02:26:57 2003
From: Marc.Kwiatkowski at veritas.com (Marc Kwiatkowski)
Date: Wed, 17 Dec 2003 17:26:57 -0800
Subject: [C++-sig] register_ptr_to_python and get_pointer
Message-ID: <16353.609.366000.291557@gargle.gargle.HOWL>


I'm trying to integrate Boost::python templates to expose a bunch of legacy classes.  We have our own reference-counting pointer template, ref_ptr; the moral equivalent of shared_count.  Having gotten basic classes, I set out to figure out how to to expose ref_ptr.  Looking at the notes on this list and the PythonInfoWiki I figured out how to wrap my classes with shared_ptr using register_ptr_to_python.  I then attempted to switch from shared_ptr to our own ref_ptr and kept getting cryptic errors like the following:

    boost\python\object\make_ptr_instance.hpp(31) : error C2784: 'T *boost::python::get_pointer(const boost::python::handle<T> &)' : could not deduce template argument for 'const boost::python::handle<T> &' from 'const ref_ptr<TRef>'

I am not a C++ template god by any stretch of the imagination, but I was determined to try to make this work or at least understand why it wouldn't.  After dissecting pointee, pointer_holder, make_instance, et al., I finally realized that my problem was that there was no get_pointer template function for class instances of my ref_ptr template.  All I needed to do was the following:

  namespace boost { namespace python {

  /* Need to provide get_pointer template function for SigFoundation::ref_ptr, so that boost holder templates
      can use it to extract values. */
 
  template <class T> T* get_pointer(example::ref_ptr<T> const& p) {
    return p.get();
  }
  }} // namespace boost::python


With this in place, I was able to get my version of the register_ptr_to_python sample working.  (It's included below in toto for your reference.)

I guess the question I have ism why isn't this documented anywhere?  I have found boost::python to be the best library for getting at C++ stuff from python, but the terseness of the documentation and lack of examples for integrating with legacy code is frustrating.  Also, if this isn't the correct way to do this, I'd be glad to know what is.


Here is the register_python_to_pointer sample modified for a thirdparty ref-counting-pointer template:

Thanks.

=== test.cpp ===

#include <xstring>
#include <boost/python/class.hpp>
#include <boost/python/module.hpp>
#include <boost/python/def.hpp>
#include <boost/python/call_method.hpp>
#include <boost/python/register_ptr_to_python.hpp>
#include <boost/python/exception_translator.hpp>
#include <boost/python/overloads.hpp>
#include <boost/python/pointee.hpp>
#include <boost/python/converter/arg_from_python.hpp>

namespace boost { namespace python {

/* Need to provide get_pointer template function for example::ref_ptr, so that boost holder templates
   can use it to extract values. */

template <class T> T* get_pointer(example::ref_ptr<T> const& p) {
    return p.get();
}

}} // namespace boost::python

namespace example { namespace test { namespace ref_ptr {

using boost::shared_ptr;
using boost::is_pointer;
using boost::remove_pointer;
using boost::python::call_method;
using boost::python::class_;
using boost::python::def;
using boost::python::init;
using boost::python::pointee;
using boost::python::register_exception_translator;
using boost::python::register_ptr_to_python;
using boost::python::to_python_converter;

using std::wstring;

class C {
public:
    C() : str(L"hello ref_ptr") {}
    C(wstring const& aString) : str(aString) {}
    virtual ~C() {}
        
    virtual wstring GetString() const {
        return str;
    }
        
private:
    wstring str;
};

class Factory {
public:
    Factory() {}
        
    CVxRefPtr< C > NewC(wstring const& aString) {
        return CVxRefPtr< C >(new C(aString));
    }

    wstring frpc(CVxRefPtr< C > c) {return c->GetString();}
    wstring fconstc(C const& c) { return c.GetString();}
    wstring fc(C& c) { return c.GetString();}
};
    
class C_Wrapper: public C {
public:
    C_Wrapper(PyObject* self_) : C(), self(self_) {}
    C_Wrapper(PyObject* self_, wstring const& aString) : C(aString), self(self_) {}
    C_Wrapper(PyObject* self_, const C& c): self(self_), C(c) {}

    ~C_Wrapper() {}
    wstring GetString() const { return call_method<wstring>(self, "GetString"); }    
    wstring default_GetString() const { return C::GetString(); }    
    PyObject* self;
};

BOOST_PYTHON_MODULE(test) {

    class_<C, C_Wrapper >("C")
        .def(init<wstring const&>())
        .def("GetString", &C::GetString, &C_Wrapper::default_GetString);

    register_ptr_to_python< CVxRefPtr< C > >();

    class_<Factory>("Factory")
        .def("NewC", &Factory::NewC)
	.def("frpc", &Factory::frpc)
	.def("fconstc", &Factory::fconstc)
	.def("fc", &Factory::fc);

}

}}} // namespace example::test::ref_ptr

=== test.py ===

from test import C, Factory

f=Factory()

x=f.NewC("fba")

c=C("foo")

f.frpc(x) # succeeds

f.frpc(c) # fails

f.fc(x) # succeeds

f.fc(c) # succeeds

f.fconstc(x) # succeeds

f.fconstc(c) # succeeds

-- 
marc.kwiatkowski at veritas.com





From dave at boost-consulting.com  Thu Dec 18 18:05:23 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 18 Dec 2003 12:05:23 -0500
Subject: [C++-sig] Re: register_ptr_to_python and get_pointer
References: <16353.609.366000.291557@gargle.gargle.HOWL>
Message-ID: <uhdzyawfg.fsf@boost-consulting.com>

Marc Kwiatkowski <Marc.Kwiatkowski at veritas.com> writes:

> I'm trying to integrate Boost::python templates to expose a bunch of
> legacy classes.  We have our own reference-counting pointer template,
> ref_ptr; the moral equivalent of shared_count.  Having gotten basic
> classes, I set out to figure out how to to expose ref_ptr.  Looking at
> the notes on this list and the PythonInfoWiki I figured out how to
> wrap my classes with shared_ptr using register_ptr_to_python.  I then
> attempted to switch from shared_ptr to our own ref_ptr and kept
> getting cryptic errors like the following:
>
>     boost\python\object\make_ptr_instance.hpp(31) : error C2784: 'T
> *boost::python::get_pointer(const boost::python::handle<T> &)' : could
> not deduce template argument for 'const boost::python::handle<T> &'
> from 'const ref_ptr<TRef>'
>
> I am not a C++ template god by any stretch of the imagination, but I
> was determined to try to make this work or at least understand why it
> wouldn't.  After dissecting pointee, pointer_holder, make_instance, et
> al.

The documentation you need is in the CVS at:

  http://tinyurl.com/ytef5

Unfortunately, register_ptr_to_python doesn't document the
Dereferenceable requirement :(

Will fix immediately.

> , I finally realized that my problem was that there was no
> get_pointer template function for class instances of my ref_ptr
> template.  All I needed to do was the following:
>
>   namespace boost { namespace python {
>
>   /* Need to provide get_pointer template function for
> SigFoundation::ref_ptr, so that boost holder templates
>       can use it to extract values. */
>  
>   template <class T> T* get_pointer(example::ref_ptr<T> const& p) {
>     return p.get();
>   }
>   }} // namespace boost::python

This is right if you're using a compiler with broken
Argument-Dependent Lookup such as msvc6 or 7.  VC7.1 supports ADL so
get_pointer should go in the "example" namespace.  I suggest using
#ifdefs to ensure that your code will still work when you move to a
working compiler.

> With this in place, I was able to get my version of the
> register_ptr_to_python sample working.  (It's included below in toto
> for your reference.)
>
> I guess the question I have ism why isn't this documented
> anywhere?  

Pure oversight, sorry.

> I have found boost::python to be the best library for getting at C++
> stuff from python, but the terseness of the documentation 

We'd love to have more time to spend on making the docs friendlier.
Patches are welcome.

> and lack of examples for integrating with legacy code 

I'm not sure what this means.  Are you referring to, for example, the
fact that register_ptr_to_python doesn't show how to work with random
smart pointers?  I can understand that, if so.  Do you have any other
examples?

> is frustrating.  Also, if this isn't the correct way to do this, I'd
> be glad to know what is.
>
>
> Here is the register_python_to_pointer sample modified for a
> thirdparty ref-counting-pointer template:

Wonderful!  Do you intend to contribute this to the documentation
base, and will you agree to have it distributed under the terms of
the Boost Software License 1.0
(http://www.boost-consulting.com/boost/LICENSE_1_0.txt)?

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




From s_sourceforge at nedprod.com  Thu Dec 18 13:37:59 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 18 Dec 2003 12:37:59 -0000
Subject: [C++-sig] extract<const char *>
Message-ID: <3FE19FA7.27422.ADD39FAF@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If I do this:

list result; // some python list
printf("List from C++ is %s\n", extract<const char *>(str(result)));

... the string appear to be corrupted. Yet if I remove the printf() 
and extract to a const char *, the string is correct.

Where does extract<> store its result?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP+Gfp8EcvDLFGKbPEQKYKQCginjlBYDJ4k7J4zogg9fcw0UqYvoAnjJa
k7rgq1f0v6hKMhyDj3obRBD3
=Jxy9
-----END PGP SIGNATURE-----



From s_sourceforge at nedprod.com  Thu Dec 18 12:19:33 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 18 Dec 2003 11:19:33 -0000
Subject: [C++-sig] Re: throw_error_already_set()
In-Reply-To: <uu13zi5ov.fsf@boost-consulting.com>
Message-ID: <3FE18D45.22406.AD8BD0EF@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17 Dec 2003 at 14:51, David Abrahams wrote:

> I think you're misinterpreting things.  Internal errors in BPL are
> always handled with assert(), and never with exceptions.

What about the famous "Attempt to return dangling %s to object of 
type: %s" error? This is generated by setting the python exception 
state and throwing error_already_set.

> > Is it possible to modify BPL to do this
> 
> I don't think so.  Well, OK, we could provide a hookable error
> handler.  I'd worry how it'd interact with threads, though.

Surely almost all the time inside BPL is spent with the GIL held? 
Well, except in my case as I've modified BPL to release the GIL when 
entering C++ code.

> Why don't you just look at the python error state at the catch
> point?

Because that breaks my nested handled exception framework. I've added 
run time code to allow destructors to throw exceptions without 
killing the process via terminate() (it still fatally exits, just 
through a controlled fashion - I really think the ISO C++ standard is 
wrong here - it means a tiny hard-to-find-during-testing mistake will 
kill your entire process which does not aid writing robust code). 
Anyway the entire basis of this requires all compatible exceptions to 
be derived off the base FXException class.

> > or am I relegated to wrapping every BPL call with a
> > try...catch(error_already_set &)? 
> 
> I think you need to re-evaluate your EH strategy.  You must be
> embedding Python.  You should handle Boost.Python errors in the same
> place where you handle other exceptions in your program.

I'll be writing code later on where C++ code will run some python 
which performs operations with C++ objects wrapped via BPL ie; 
multiple layers of embedding. I also want one python interpreter to 
call code in another interpreter seamlessly and new threads to 
automatically handle python being called.

> > I did notice there only appears to be one place where
> > error_already_set is caught within BPL - therefore couldn't I
> > literally just do a find & replace (or better, a #define
> > throw_error_already_set FXPython::int_throwPythonException() so I
> > don't have problems with merging new releases)
> 
> No comment.  Modify your private copy of the Boost.Python sources at
> your peril (or not).

Well it's already modified to unlock the GIL so I was going to merge 
the BPL DLL into the TnFOX.pyd DLL. I can't see any licensing 
problems with that as it's made very clear where the code originally 
comes from.

The good news about all this is that it's already extremely easy to 
embed python snippets into C++ with TnFOX, and once I have these 
other small problems fixed it's about to get much easier. v0.5 will 
be out shortly!

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP+GNR8EcvDLFGKbPEQIGcgCgnb1mZUWYyre+Il2MPEOTp6cJY3MAoOJt
rCqsYnv7I9hVKRafSRjb29IA
=IS/+
-----END PGP SIGNATURE-----



From Marc.Kwiatkowski at veritas.com  Thu Dec 18 19:19:11 2003
From: Marc.Kwiatkowski at veritas.com (Marc Kwiatkowski)
Date: Thu, 18 Dec 2003 10:19:11 -0800
Subject: [C++-sig] Re: register_ptr_to_python and get_pointer
In-Reply-To: <uhdzyawfg.fsf@boost-consulting.com>
References: <uhdzyawfg.fsf@boost-consulting.com>
Message-ID: <16353.61343.411000.702612@gargle.gargle.HOWL>


Thanks for your reply.  With respect to the documentation, I think the biggest simple thing we could do to improve things is to add a keyword and concept index, along the lines of 

David Abrahams writes:
 > Marc Kwiatkowski <Marc.Kwiatkowski at veritas.com> writes:
 > 
 > > I'm trying to integrate Boost::python templates to expose a bunch of
 > > legacy classes.  We have our own reference-counting pointer template,
 > > ref_ptr; the moral equivalent of shared_count.  Having gotten basic
 > > classes, I set out to figure out how to to expose ref_ptr.  Looking at
 > > the notes on this list and the PythonInfoWiki I figured out how to
 > > wrap my classes with shared_ptr using register_ptr_to_python.  I then
 > > attempted to switch from shared_ptr to our own ref_ptr and kept
 > > getting cryptic errors like the following:
 > >
 > >     boost\python\object\make_ptr_instance.hpp(31) : error C2784: 'T
 > > *boost::python::get_pointer(const boost::python::handle<T> &)' : could
 > > not deduce template argument for 'const boost::python::handle<T> &'
 > > from 'const ref_ptr<TRef>'
 > >
 > > I am not a C++ template god by any stretch of the imagination, but I
 > > was determined to try to make this work or at least understand why it
 > > wouldn't.  After dissecting pointee, pointer_holder, make_instance, et
 > > al.
 > 
 > The documentation you need is in the CVS at:
 > 
 >   http://tinyurl.com/ytef5
 > 
 > Unfortunately, register_ptr_to_python doesn't document the
 > Dereferenceable requirement :(
 > 
 > Will fix immediately.
 > 
 > > , I finally realized that my problem was that there was no
 > > get_pointer template function for class instances of my ref_ptr
 > > template.  All I needed to do was the following:
 > >
 > >   namespace boost { namespace python {
 > >
 > >   /* Need to provide get_pointer template function for
 > > SigFoundation::ref_ptr, so that boost holder templates
 > >       can use it to extract values. */
 > >  
 > >   template <class T> T* get_pointer(example::ref_ptr<T> const& p) {
 > >     return p.get();
 > >   }
 > >   }} // namespace boost::python
 > 
 > This is right if you're using a compiler with broken
 > Argument-Dependent Lookup such as msvc6 or 7.  VC7.1 supports ADL so
 > get_pointer should go in the "example" namespace.  I suggest using
 > #ifdefs to ensure that your code will still work when you move to a
 > working compiler.
 > 
 > > With this in place, I was able to get my version of the
 > > register_ptr_to_python sample working.  (It's included below in toto
 > > for your reference.)
 > >
 > > I guess the question I have ism why isn't this documented
 > > anywhere?  
 > 
 > Pure oversight, sorry.
 > 
 > > I have found boost::python to be the best library for getting at C++
 > > stuff from python, but the terseness of the documentation 
 > 
 > We'd love to have more time to spend on making the docs friendlier.
 > Patches are welcome.
 > 
 > > and lack of examples for integrating with legacy code 
 > 
 > I'm not sure what this means.  Are you referring to, for example, the
 > fact that register_ptr_to_python doesn't show how to work with random
 > smart pointers?  I can understand that, if so.  Do you have any other
 > examples?
 > 
 > > is frustrating.  Also, if this isn't the correct way to do this, I'd
 > > be glad to know what is.
 > >
 > >
 > > Here is the register_python_to_pointer sample modified for a
 > > thirdparty ref-counting-pointer template:
 > 
 > Wonderful!  Do you intend to contribute this to the documentation
 > base, and will you agree to have it distributed under the terms of
 > the Boost Software License 1.0
 > (http://www.boost-consulting.com/boost/LICENSE_1_0.txt)?
 > 
 > -- 
 > Dave Abrahams
 > Boost Consulting
 > www.boost-consulting.com
 > 
 > 
 > _______________________________________________
 > C++-sig mailing list
 > C++-sig at python.org
 > http://mail.python.org/mailman/listinfo/c++-sig




From dave at boost-consulting.com  Thu Dec 18 19:29:34 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 18 Dec 2003 13:29:34 -0500
Subject: [C++-sig] Re: register_ptr_to_python and get_pointer
References: <uhdzyawfg.fsf@boost-consulting.com>
	<16353.61343.411000.702612@gargle.gargle.HOWL>
Message-ID: <uk74u9dyp.fsf@boost-consulting.com>

Marc Kwiatkowski <Marc.Kwiatkowski at veritas.com> writes:

> Thanks for your reply.  With respect to the documentation, I think
> the biggest simple thing we could do to improve things is to add a
> keyword and concept index, along the lines of

... ???

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




From dave at boost-consulting.com  Thu Dec 18 19:32:49 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 18 Dec 2003 13:32:49 -0500
Subject: [C++-sig] Re: extract<const char *>
References: <3FE19FA7.27422.ADD39FAF@localhost>
Message-ID: <ubrq69dta.fsf@boost-consulting.com>

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

> If I do this:
>
> list result; // some python list
> printf("List from C++ is %s\n", extract<const char *>(str(result)));
>
> ... the string appear to be corrupted. Yet if I remove the printf() 
> and extract to a const char *, the string is correct.
>
> Where does extract<> store its result?

It doesn't.  You're getting the char const* out of the temporary
Python string you created.  This is the same as the "attempt to return
a dangling reference" issue.  If you want something that will stick
around, extract std::string.

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




From Marc.Kwiatkowski at veritas.com  Thu Dec 18 20:17:26 2003
From: Marc.Kwiatkowski at veritas.com (Marc Kwiatkowski)
Date: Thu, 18 Dec 2003 11:17:26 -0800
Subject: [C++-sig] Re: register_ptr_to_python and get_pointer
In-Reply-To: <uhdzyawfg.fsf@boost-consulting.com>
References: <uhdzyawfg.fsf@boost-consulting.com>
Message-ID: <16353.64838.66000.340548@gargle.gargle.HOWL>


(sorry for the first one, mis-fired)

Thanks for your reply.  With respect to the documentation, I think the biggest simple thing we could do to improve things is to add a keyword and concept index, along the lines of the python library and language index.  Searching for get_pointer from boost.org's search form does not point to the refence documentation you included below, nor does the Reference TOC.  You kind of have to know it's there to find it.  Secondly, now that I've seen it it still isn't clear to me that it's a template the application developer is meant to extend.  They best thing for would be more comprehensive, real-world examples, particularly those emphasing integration the legacy code.  Given that they don't really exist, I'll just report problems I have and submit whatever sample code I can to this list with the hope that others can benefit from it.  Regarding the register_python_to_pointer sample, I will be happy to submit it.

 > Marc Kwiatkowski <Marc.Kwiatkowski at veritas.com> writes:
 > 
 > > I'm trying to integrate Boost::python templates to expose a bunch of
 > > legacy classes.  We have our own reference-counting pointer template,
 > > ref_ptr; the moral equivalent of shared_count.  Having gotten basic
 > > classes, I set out to figure out how to to expose ref_ptr.  Looking at
 > > the notes on this list and the PythonInfoWiki I figured out how to
 > > wrap my classes with shared_ptr using register_ptr_to_python.  I then
 > > attempted to switch from shared_ptr to our own ref_ptr and kept
 > > getting cryptic errors like the following:
 > >
 > >     boost\python\object\make_ptr_instance.hpp(31) : error C2784: 'T
 > > *boost::python::get_pointer(const boost::python::handle<T> &)' : could
 > > not deduce template argument for 'const boost::python::handle<T> &'
 > > from 'const ref_ptr<TRef>'
 > >
 > > I am not a C++ template god by any stretch of the imagination, but I
 > > was determined to try to make this work or at least understand why it
 > > wouldn't.  After dissecting pointee, pointer_holder, make_instance, et
 > > al.
 > 
 > The documentation you need is in the CVS at:
 > 
 >   http://tinyurl.com/ytef5
 > 
 > Unfortunately, register_ptr_to_python doesn't document the
 > Dereferenceable requirement :(
 > 
 > Will fix immediately.
 > 
 > > , I finally realized that my problem was that there was no
 > > get_pointer template function for class instances of my ref_ptr
 > > template.  All I needed to do was the following:
 > >
 > >   namespace boost { namespace python {
 > >
 > >   /* Need to provide get_pointer template function for
 > > SigFoundation::ref_ptr, so that boost holder templates
 > >       can use it to extract values. */
 > >  
 > >   template <class T> T* get_pointer(example::ref_ptr<T> const& p) {
 > >     return p.get();
 > >   }
 > >   }} // namespace boost::python
 > 
 > This is right if you're using a compiler with broken
 > Argument-Dependent Lookup such as msvc6 or 7.  VC7.1 supports ADL so
 > get_pointer should go in the "example" namespace.  I suggest using
 > #ifdefs to ensure that your code will still work when you move to a
 > working compiler.
 > 
 > > With this in place, I was able to get my version of the
 > > register_ptr_to_python sample working.  (It's included below in toto
 > > for your reference.)
 > >
 > > I guess the question I have ism why isn't this documented
 > > anywhere?  
 > 
 > Pure oversight, sorry.
 > 
 > > I have found boost::python to be the best library for getting at C++
 > > stuff from python, but the terseness of the documentation 
 > 
 > We'd love to have more time to spend on making the docs friendlier.
 > Patches are welcome.
 > 
 > > and lack of examples for integrating with legacy code 
 > 
 > I'm not sure what this means.  Are you referring to, for example, the
 > fact that register_ptr_to_python doesn't show how to work with random
 > smart pointers?  I can understand that, if so.  Do you have any other
 > examples?
 > 
 > > is frustrating.  Also, if this isn't the correct way to do this, I'd
 > > be glad to know what is.
 > >
 > >
 > > Here is the register_python_to_pointer sample modified for a
 > > thirdparty ref-counting-pointer template:
 > 
 > Wonderful!  Do you intend to contribute this to the documentation
 > base, and will you agree to have it distributed under the terms of
 > the Boost Software License 1.0
 > (http://www.boost-consulting.com/boost/LICENSE_1_0.txt)?
 > 
 > -- 
 > Dave Abrahams
 > Boost Consulting
 > www.boost-consulting.com
 > 
 > 
 > _______________________________________________
 > C++-sig mailing list
 > C++-sig at python.org
 > http://mail.python.org/mailman/listinfo/c++-sig

-- 
marc.kwiatkowski at veritas.com





From s_sourceforge at nedprod.com  Thu Dec 18 21:14:37 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 18 Dec 2003 20:14:37 -0000
Subject: [C++-sig] Re: extract<const char *>
In-Reply-To: <ubrq69dta.fsf@boost-consulting.com>
Message-ID: <3FE20AAD.14840.1252029@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18 Dec 2003 at 13:32, David Abrahams wrote:

> > Where does extract<> store its result?
> 
> It doesn't.  You're getting the char const* out of the temporary
> Python string you created.  This is the same as the "attempt to return
> a dangling reference" issue.  If you want something that will stick
> around, extract std::string.

Would there be any reason why trying to extract to a FXString (which 
I have previously registered a converter for and it all works fine) 
gives a converter not found error?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP+IKrcEcvDLFGKbPEQKrMwCguQgn/n7uqlSHPEVw6YQHuVUSesYAoPFE
iFgOCyLvql9lPF6po+XZJxN0
=yWMt
-----END PGP SIGNATURE-----



From dave at boost-consulting.com  Thu Dec 18 22:10:34 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 18 Dec 2003 16:10:34 -0500
Subject: [C++-sig] Re: register_ptr_to_python and get_pointer
In-Reply-To: <16353.64838.66000.340548@gargle.gargle.HOWL> (Marc
	Kwiatkowski's message of "Thu, 18 Dec 2003 11:17:26 -0800")
References: <uhdzyawfg.fsf@boost-consulting.com>
	<16353.64838.66000.340548@gargle.gargle.HOWL>
Message-ID: <uvfod7rxx.fsf@boost-consulting.com>

Marc Kwiatkowski <Marc.Kwiatkowski at veritas.com> writes:

F> (sorry for the first one, mis-fired)
>
> Thanks for your reply.  With respect to the documentation, I think the
> biggest simple thing we could do to improve things is to add a keyword
> and concept index, along the lines of the python library and language
> index.  Searching for get_pointer from boost.org's search form does
> not point to the refence documentation you included below, nor does
> the Reference TOC.  You kind of have to know it's there to find it.

Yeah, but that's just because it's only in the CVS documentation and
boost.org's search form only indexes the released Boost site.

> Secondly, now that I've seen it it still isn't clear to me that it's a
> template the application developer is meant to extend.  They best
> thing for would be more comprehensive, real-world examples,
> particularly those emphasing integration the legacy code.  
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You haven't confirmed/denied my understanding of your meaning

> Given that they don't really exist, I'll just report problems I have
> and submit whatever sample code I can to this list with the hope
> that others can benefit from it.  Regarding the
> register_python_to_pointer sample, I will be happy to submit it.

I await your submission.  At that time, please answer the following:

>  >  will you agree to have it distributed under the terms of
>  > the Boost Software License 1.0
>  > (http://www.boost-consulting.com/boost/LICENSE_1_0.txt)?

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




From dave at boost-consulting.com  Thu Dec 18 22:11:54 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 18 Dec 2003 16:11:54 -0500
Subject: [C++-sig] Re: extract<const char *>
References: <ubrq69dta.fsf@boost-consulting.com>
	<3FE20AAD.14840.1252029@localhost>
Message-ID: <ur7z17rvp.fsf@boost-consulting.com>

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

> On 18 Dec 2003 at 13:32, David Abrahams wrote:
>
>> > Where does extract<> store its result?
>> 
>> It doesn't.  You're getting the char const* out of the temporary
>> Python string you created.  This is the same as the "attempt to return
>> a dangling reference" issue.  If you want something that will stick
>> around, extract std::string.
>
> Would there be any reason why trying to extract to a FXString (which 
> I have previously registered a converter for and it all works fine) 
> gives a converter not found error?

If that happens, there's a reason, but I'm not sure what it is
offhand.

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




From ahakim777 at yahoo.com  Fri Dec 19 00:50:08 2003
From: ahakim777 at yahoo.com (Ammar Hakim)
Date: Thu, 18 Dec 2003 15:50:08 -0800 (PST)
Subject: [C++-sig] Returning NULL
In-Reply-To: <000001c3bfaa$2a926a90$af5edf8d@postech.ac.kr>
Message-ID: <20031218235008.77197.qmail@web60707.mail.yahoo.com>

Hello,

How do I wrap a function which can return either an
object or NULL? For example:

int
foo(int i)
{
   if(i == 0)

}

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree



From ahakim777 at yahoo.com  Fri Dec 19 00:50:09 2003
From: ahakim777 at yahoo.com (Ammar Hakim)
Date: Thu, 18 Dec 2003 15:50:09 -0800 (PST)
Subject: [C++-sig] Returning NULL
In-Reply-To: <000001c3bfaa$2a926a90$af5edf8d@postech.ac.kr>
Message-ID: <20031218235009.77204.qmail@web60707.mail.yahoo.com>

Hello,

How do I wrap a function which can return either an
object or NULL? For example:

int
foo(int i)
{
   if(i == 0)

}

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree



From ahakim777 at yahoo.com  Fri Dec 19 00:51:47 2003
From: ahakim777 at yahoo.com (Ammar Hakim)
Date: Thu, 18 Dec 2003 15:51:47 -0800 (PST)
Subject: [C++-sig] Returning NULL
In-Reply-To: <000001c3bfaa$2a926a90$af5edf8d@postech.ac.kr>
Message-ID: <20031218235147.1328.qmail@web60704.mail.yahoo.com>

Hello,

How do I wrap a function which can return either an
object or NULL? For example:

SomeObject
foo(int i)
{
   if(i == 0)
     return AnInstance;
   else 
     return NULL;
}

Cheers,
Ammar



__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree



From rwgk at yahoo.com  Fri Dec 19 02:29:14 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 18 Dec 2003 17:29:14 -0800 (PST)
Subject: [C++-sig] Returning NULL
In-Reply-To: <20031218235147.1328.qmail@web60704.mail.yahoo.com>
Message-ID: <20031219012914.36915.qmail@web20205.mail.yahoo.com>

Your question is not clear at all, but I'll try an answer anyway (untested):

boost::python::object
foo(int i)
{
  if (i == 0) return boost::python::object(AnInstance);
  return boost::python::object(); // None in Python
}

You cannot return NULL to Python, only None.
For this to work you need a class_<SomeObject> somewhere else.

Ralf

--- Ammar Hakim <ahakim777 at yahoo.com> wrote:
> Hello,
> 
> How do I wrap a function which can return either an
> object or NULL? For example:
> 
> SomeObject
> foo(int i)
> {
>    if(i == 0)
>      return AnInstance;
>    else 
>      return NULL;
> }
> 
> Cheers,
> Ammar
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/



From nikolai.kirsebom at siemens.no  Fri Dec 19 15:21:53 2003
From: nikolai.kirsebom at siemens.no (Kirsebom Nikolai)
Date: Fri, 19 Dec 2003 15:21:53 +0100
Subject: [C++-sig] Extracting a byte array from C++ to Python array object
	instance
Message-ID: <5B5544F322E5D211850F00A0C91DEF3B05B305DF@osll007a.siemens.no>


I'm trying to define the interface/code for extracting (and setting) the
byte array of an C++ object into (from) a Python array object (type code
'B').


C++ OBJECT (fragments)
class TheBlob {
	unsigned char *GetBufferRef();
	int Length();
	PyObject *GetBlobIntoPyArray();
	int SetBlobFromPyArray(PyObject *pyArray);
};


Python code:
a = TheBlob.GetBlobIntoPyArray()
# a is object of type array (python built-in)
....
TheBlob.SetBlobFromPyArray(a)



Does anyone have hints/links to where I can find info on how to define the
two methods GetBlobIntoPyArray and SetBlobFromPyArray ?

Nikolai






From surffirst at yahoo.com  Mon Dec 22 15:07:59 2003
From: surffirst at yahoo.com (Leo Yee)
Date: Mon, 22 Dec 2003 22:07:59 +0800
Subject: [C++-sig] boost: python may cause memory leaks?
Message-ID: <bs6tml$r5u$1@sea.gmane.org>

Hi, friends,

I use VS 7.1 and I have following code:

#include "stdafx.h"
#include <crtdbg.h>

using namespace boost::python;

class cPart
{
public:

 void set_text( const std::string &t ) { _text = t; }
 std::string text( void )    { return _text; }

private:
 std::string _text;

};

BOOST_PYTHON_MODULE(hello)
{

 class_<cPart, boost::noncopyable >("cPart")
  .add_property( "text", cPart::text, cPart::set_text );
}


int _tmain(int argc, _TCHAR* argv[])
{
    _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

    if (PyImport_AppendInittab("hello", inithello) == -1)
        return 1;

    Py_Initialize();

 PyRun_SimpleString(
  "from hello import *\n"
  "p = cPart()\n"
  "p.text = 'hello'\n"
  "print p.text\n"
  );

    Py_Finalize();

 getchar();

 return 0;
}

I compiled the code and ran it. Everything was ok except I got memory leaks
from the output window of the VS like these:

Detected memory leaks!
Dumping objects ->
{54} normal block at 0x003E5AD8, 8 bytes long.
 Data: < RE   A > 10 52 45 00 83 BE 41 00
{53} normal block at 0x003E5A90, 8 bytes long.
 Data: <(RE   A > 28 52 45 00 D6 B6 41 00
{52} normal block at 0x003E5A48, 8 bytes long.
 Data: <lRE l A > 6C 52 45 00 6C B2 41 00
Object dump complete.

I just wonder if I really got memory leaks or it was just a illusion.
Any suggestion would be appreciated.

Leo Yee








From Marc.Kwiatkowski at veritas.com  Mon Dec 22 23:00:13 2003
From: Marc.Kwiatkowski at veritas.com (Marc Kwiatkowski)
Date: Mon, 22 Dec 2003 14:00:13 -0800
Subject: [C++-sig] Re: register_ptr_to_python and get_pointer
In-Reply-To: <16353.64838.66000.340548@gargle.gargle.HOWL>
References: <16353.64838.66000.340548@gargle.gargle.HOWL>
Message-ID: <16359.26989.171000.735167@gargle.gargle.HOWL>


Yet another question/observation about register_ptr_to_python.

Given a function that returns a ref-ptr, it seems that all that is really necessary is to provide a get_pointer template function for it and then invoke the register_to_python function.  None of the wrapper stuff is necessary.  For example:

    class X {
    public:
        X(wstring const& aValue) : value(aValue) {}
        wstring value;
    };

    my_ref_ptr<X> NewX(wstring const& aValue ) { return my_ref_ptr<X>(new X(aValue)); }
	      
    namespace boost { namespace python {

    template <class T> T* get_pointer(my_ref_ptr<T> const& p) {
        return p.get();
    }
    }}
    
    BOOST_PYTHON_MODULE(test) {

        class_<X>("X", init<wstring const&>())
            .def_readwrite("value", &X::value);

        def("NewX", &NewX);

        register_ptr_to_python< my_ref_ptr< X > >();
   }

That's all there is too it.   This seems so much more straight forward than the sample described in libs/python/doc/v2/register_ptr_to_python.html 

On the other hand, when I used ref-ptrs with a mix of derived and base classes, I can find no permutation of wrapper and smart pointer that will work to get at a base method from a derived object ptr that is downcast to a base object pointer.

For example, given the Base, Derived, and Factory classes attached below, the following script fails

>>> from pytest import Base, Factory, Derived;f=Factory()
>>> d=f.NewDerived("i am derived")
>>> d.GetString()
u'i am derived'
>>> b=f.Downcast(d)
>>> b.GetString()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
Boost.Python.ArgumentError: Python argument types in
    Derived.GetString(Derived)
did not match C++ signature:
    GetString(class Filer::Test::Example::PyDerivedWrapper {lvalue})
    GetString(class Filer::Test::Example::PyDerived {lvalue})
>>> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: x.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031222/3b2279e5/attachment.txt>
-------------- next part --------------

-- 
marc.kwiatkowski at veritas.com


From rwgk at yahoo.com  Tue Dec 23 01:31:41 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 22 Dec 2003 16:31:41 -0800 (PST)
Subject: [C++-sig] RE: Pointers to arrays...
In-Reply-To: <NFBBIBBEGKCGCEGNDLKGKEPMDMAA.phil.hornby@accutest.co.uk>
Message-ID: <20031223003141.48099.qmail@web20209.mail.yahoo.com>

--- Phil Hornby <phil.hornby at accutest.co.uk> wrote:
> I think you have miss-understood what I am doing.

I was almost certain that would be the case. :)

> What I am passing in is
> NOT a string, it is in fact 8 data bytes from a CAN message. CAN is a bus
> system used largely in the automotive industry. I had anti-cipated being
> able to pass a python list or tuple in to the constructor in-place of the
> (BYTE *)

How do you want you 8 bytes to "appear" in Python? A sequence of integers? A
string of 8 characters? A special type that you bind via class_<>? An opaque
pointer? -- You have to make this decision first. It is probably not an easy
decision to make.

One thing to consider is that exchanging data by value (i.e. by copying) rather
than by reference often leads to a significant simplification and is
automatically safe. Eight bytes is not very much to copy, so I'd be inclined to
copy the pointee of BYTE* to a new Python string when you convert to Python and
to copy the string back to the memory where BYTE* lives when you convert from
Python. Which approach exactly will work best for you I don't know. If you only
have a few functions that exchange BYTE* the easiest way would be to work with
thin wrappers as outlined before. If that is not feasible you could try your
hand with custom converters, but this is significantly more involved.

> know there are these new fangled thinks I can use called references.

These are still essentially pointers, you just don't have to write the * (and
references are important because the caller doesn't have to know if the
parameter is used by value or by reference). The juicy bit (one of the juicy
bits) of C++ is something else: support for encapsulating memory management. If
you make use of this in C++ it is often very straightforward to define the
Python bindings. Your case appears to be not so straightforward mainly because
you have to solve two problems at once: (1) make the interface safe, (2) define
the Python bindings. But if you can afford to copy as outlined above it should
not be too hard.

Ralf


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/



From s_sourceforge at nedprod.com  Tue Dec 23 01:42:58 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 23 Dec 2003 00:42:58 -0000
Subject: [C++-sig] boost: python may cause memory leaks?
In-Reply-To: <bs6tml$r5u$1@sea.gmane.org>
Message-ID: <3FE78F92.29302.16B43F0F@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22 Dec 2003 at 22:07, Leo Yee wrote:

> I compiled the code and ran it. Everything was ok except I got memory
> leaks from the output window of the VS like these:
> 
> I just wonder if I really got memory leaks or it was just a illusion.
> Any suggestion would be appreciated.

I personally have not seen any leaks originating from boost.python. 
If you want MSVC to print where the leaked memory was allocated, do 
the following:

Place this at the start of each .cpp file:

static const char *_fxmemdbg_current_file_ = __FILE__;

Include the following header:

#include <crtdbg.h>

#define _FXMEMDBG_NEW_ new(1, _fxmemdbg_current_file_, __LINE__)
#define _FXMEMDBG_MALLOC_(x) _malloc_dbg(x, 1, 
_fxmemdbg_current_file_, __LINE__)

#define new _FXMEMDBG_NEW_
#define malloc(x) _FXMEMDBG_MALLOC_(x)

Now MSVC will print which file and line number the leak was 
allocated. This can be very useful. Obviously define only for debug 
builds.

If you want a real working example, see FXMemDbg.h in my TnFOX 
library http://www.nedprod.com/TnFOX/

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP+ePk8EcvDLFGKbPEQJvzACgpiy+NzLuXxEzdOKEKRibsROfb7oAoOgM
82BqUaZjewHhG1FNUO8srAlH
=aViX
-----END PGP SIGNATURE-----



From gb0519 at hotmail.com  Mon Dec 22 17:16:58 2003
From: gb0519 at hotmail.com (guan bin)
Date: Tue, 23 Dec 2003 00:16:58 +0800
Subject: [C++-sig] Why the document example can't be compiled?
Message-ID: <3FE718FA.8000504@hotmail.com>

Hi,

I've read the document below:
/boost/libs/python/doc/tutorial/doc/extracting_c___objects.html

and want to get a boost::python::list object's length
so I write the following code:
-----------------------------------------------------------
#include "boost/python/list.hpp"

using namespace boost::python;
void PriList(list lst)
{
	int x = extract<int>(lst.attr("__len__")());
//	int y = extract<int>(lst.attr("__len__")())();
}

#include <boost/python/module.hpp>
#include <boost/python/def.hpp>

BOOST_PYTHON_MODULE(GTest)
{
	def("PList", PriList);
}
--------------------------------------------------------
when I compile it, I get the following errors:
----------------------------------------------------------
D:\samples\boost\python>bjam
...found 969 targets...
...updating 4 targets...
vc-C++ bin\GTest.pyd\msvc\debug\runtime-link-dynamic\test.obj
test.cpp
test.cpp(6) : error C2440: 'type cast' : cannot convert from 'class
boost::pytho
n::api::object' to 'struct boost::python::extract<int>'
        Source or target has incomplete type
e:\boost\boost/python/args_fwd.hpp(43) : fatal error C1506:
unrecoverable block
scoping error
------------------------------------------------------------------
after I read the doc below:
http://mail.python.org/pipermail/c++-sig/2003-September/005510.html
I change the code
int x = extract<int>(lst.attr("__len__")()); ------>
int x = extract<int>(lst.attr("__len__")())();
but the error still exist.......

Who can help me ? Thanks advance.

My environment : win2000, vc6+sp5 , python2.2.3, boost-1.30.2


                         guanbin
                         2003.12.23






From dleary at ttlc.net  Tue Dec 23 08:41:24 2003
From: dleary at ttlc.net (Dusty Leary)
Date: Tue, 23 Dec 2003 02:41:24 -0500
Subject: [C++-sig] simple array access?
References: <ubrq69dta.fsf@boost-consulting.com><3FE20AAD.14840.1252029@localhost>
	<ur7z17rvp.fsf@boost-consulting.com>
Message-ID: <000901c3c928$2acabb70$cf2aa8c0@dustnew>

Hi,

I would like to expose a C++ array "naturally" to python.

class myclass {
    int myarray[42];
}





From dleary at ttlc.net  Tue Dec 23 08:45:04 2003
From: dleary at ttlc.net (Dusty Leary)
Date: Tue, 23 Dec 2003 02:45:04 -0500
Subject: [C++-sig] Re: simple array access?
Message-ID: <000e01c3c928$adcaa6c0$cf2aa8c0@dustnew>

Sorry for previous message, I typoed and sent it...

I would like to expose a C++ array "naturally" to python.

class myclass {
    int myarray[42];
}


class_<myclass>("myclass")
    .def_readwrite("myarray", &myclass::myarray)
    ;

is this sort of thing possible in boost.python?

do we have to make our own to_python/from_python handlers?

even with these handlers, I don't think it would be possible to do from
python:

myclassinstance.myarray[40] = 9

or am I mistaken?




From surffirst at yahoo.com  Tue Dec 23 13:37:09 2003
From: surffirst at yahoo.com (Leo Yee)
Date: Tue, 23 Dec 2003 20:37:09 +0800
Subject: [C++-sig] Re: boost: python may cause memory leaks?
References: <bs6tml$r5u$1@sea.gmane.org>
Message-ID: <bs9co0$fj5$1@sea.gmane.org>

If we insert code like this,

     _CrtSetBreakAlloc( 54 );

just after
       _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

we can see where boost::python allocates the memory and I found one of them
was:
    struct py_function
    {
    template <class Caller>
    py_function(Caller const& caller)
        : m_impl(new caller_py_function_impl<Caller>(caller))
    {}
    ...

This is what I saw. If I insert memory leak dectetion code in your way, it
founds nothing.

It is realy confusing.

Leo Yee

"Leo Yee" <surffirst at yahoo.com> ???????? news:bs6tml$r5u$1 at sea.gmane.org...
> Hi, friends,
>
> I use VS 7.1 and I have following code:
>
> #include "stdafx.h"
> #include <crtdbg.h>
>
> using namespace boost::python;
>
> class cPart
> {
> public:
>
>  void set_text( const std::string &t ) { _text = t; }
>  std::string text( void )    { return _text; }
>
> private:
>  std::string _text;
>
> };
>
> BOOST_PYTHON_MODULE(hello)
> {
>
>  class_<cPart, boost::noncopyable >("cPart")
>   .add_property( "text", cPart::text, cPart::set_text );
> }
>
>
> int _tmain(int argc, _TCHAR* argv[])
> {
>     _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
>
>     if (PyImport_AppendInittab("hello", inithello) == -1)
>         return 1;
>
>     Py_Initialize();
>
>  PyRun_SimpleString(
>   "from hello import *\n"
>   "p = cPart()\n"
>   "p.text = 'hello'\n"
>   "print p.text\n"
>   );
>
>     Py_Finalize();
>
>  getchar();
>
>  return 0;
> }
>
> I compiled the code and ran it. Everything was ok except I got memory
leaks
> from the output window of the VS like these:
>
> Detected memory leaks!
> Dumping objects ->
> {54} normal block at 0x003E5AD8, 8 bytes long.
>  Data: < RE   A > 10 52 45 00 83 BE 41 00
> {53} normal block at 0x003E5A90, 8 bytes long.
>  Data: <(RE   A > 28 52 45 00 D6 B6 41 00
> {52} normal block at 0x003E5A48, 8 bytes long.
>  Data: <lRE l A > 6C 52 45 00 6C B2 41 00
> Object dump complete.
>
> I just wonder if I really got memory leaks or it was just a illusion.
> Any suggestion would be appreciated.
>
> Leo Yee






From rwgk at yahoo.com  Tue Dec 23 15:32:13 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 23 Dec 2003 06:32:13 -0800 (PST)
Subject: [C++-sig] Re: simple array access?
In-Reply-To: <000e01c3c928$adcaa6c0$cf2aa8c0@dustnew>
Message-ID: <20031223143213.87683.qmail@web20208.mail.yahoo.com>

--- Dusty Leary <dleary at ttlc.net> wrote:
> I would like to expose a C++ array "naturally" to python.
> 
> class myclass {
>     int myarray[42];
> }
> 
> 
> class_<myclass>("myclass")
>     .def_readwrite("myarray", &myclass::myarray)
>     ;

The indexing suite (in CVS) is meant to give you the rest of the sequence
protocol that you need. See boost/libs/python/test/vector_indexing_suite.* .

> is this sort of thing possible in boost.python?
> 
> do we have to make our own to_python/from_python handlers?

That is another alternative. Which one is best depends on your exact
requirements. Most of the time I prefer to convert small arrays to tuples and
from sequences, mainly to reduce the compile times and the object code size.
To try it out, copy this file to your source code tree:

http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/boost_python/container_conversions.h?rev=1.10&view=auto

There are no dependencies other than boost; you don't have to change the
namespaces. Then:

    using namespace scitbx::boost_python::container_conversions;
    tuple_mapping_fixed_size<myclass>();

For this to work your myclass needs to define size() and operator[](). You can
use boost/array.hpp as an example. If this is not an option you have to copy
and modify the container conversions code. This solution requires a certain
familiarity with C++ but is concise and very powerful.

> even with these handlers, I don't think it would be possible to do from
> python:
> 
> myclassinstance.myarray[40] = 9
> 
> or am I mistaken?

If you want to modify your C++ object in place you will have to use the
class_<> approach and the indexing suite.

Ralf


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/



From rwgk at yahoo.com  Tue Dec 23 15:37:10 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 23 Dec 2003 06:37:10 -0800 (PST)
Subject: [C++-sig] Re: boost: python may cause memory leaks?
In-Reply-To: <bs9co0$fj5$1@sea.gmane.org>
Message-ID: <20031223143710.79105.qmail@web20205.mail.yahoo.com>

--- Leo Yee <surffirst at yahoo.com> wrote:
> >     Py_Finalize();

I don't use embedding myself and therefore I could be wrong, but I believe I
saw messages saying that you cannot use Py_Finalize() if you use Boost.Python.
Ralf


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/



From dave at boost-consulting.com  Tue Dec 23 16:02:52 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 23 Dec 2003 10:02:52 -0500
Subject: [C++-sig] Re: Why the document example can't be compiled?
References: <3FE718FA.8000504@hotmail.com>
Message-ID: <uhdzra86b.fsf@boost-consulting.com>

guan bin <gb0519 at hotmail.com> writes:

> Hi,
>
> I've read the document below:
> /boost/libs/python/doc/tutorial/doc/extracting_c___objects.html
>
> and want to get a boost::python::list object's length
> so I write the following code:
> -----------------------------------------------------------
> #include "boost/python/list.hpp"
>
> using namespace boost::python;
> void PriList(list lst)
> {
> 	int x = extract<int>(lst.attr("__len__")());
> //	int y = extract<int>(lst.attr("__len__")())();
> }
>
> #include <boost/python/module.hpp>
> #include <boost/python/def.hpp>
>
> BOOST_PYTHON_MODULE(GTest)
> {
> 	def("PList", PriList);
> }
> --------------------------------------------------------
> when I compile it, I get the following errors:
> ----------------------------------------------------------
> D:\samples\boost\python>bjam
> ...found 969 targets...
> ...updating 4 targets...
> vc-C++ bin\GTest.pyd\msvc\debug\runtime-link-dynamic\test.obj
> test.cpp
> test.cpp(6) : error C2440: 'type cast' : cannot convert from 'class
> boost::pytho
> n::api::object' to 'struct boost::python::extract<int>'
>         Source or target has incomplete type
> e:\boost\boost/python/args_fwd.hpp(43) : fatal error C1506:
> unrecoverable block
> scoping error
> ------------------------------------------------------------------
> after I read the doc below:
> http://mail.python.org/pipermail/c++-sig/2003-September/005510.html
> I change the code
> int x = extract<int>(lst.attr("__len__")()); ------>
> int x = extract<int>(lst.attr("__len__")())();
> but the error still exist.......
>
> Who can help me ? Thanks advance.

You're missing some #includes, notably

#include "boost/python/extract.hpp"

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




From s_sourceforge at nedprod.com  Tue Dec 23 19:32:30 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 23 Dec 2003 18:32:30 -0000
Subject: [C++-sig] Collection of pyste notes
Message-ID: <3FE88A3E.16139.1A876E14@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just readying TnFOX v0.5 for release and I have a few notes.

1. Guess it's obvious, but pyste generates incorrect code for 
bitfields eg;

struct Foo
{
   unsigned int a:3;
   unsigned int b:2;
};

The problem of course is that you can't take the address of a 
bitfield member. I guess to handle this you need lots of little 
wrapper functions which seems extreme. Can perhaps the bit offset be 
calculated by compile-time magic and then use a custom make_getter()?

2. gccxml from CVS fixes a number of previous problems, including the 
throw() modifier one - or rather, it now tells pyste when throw() is 
specified so pyste can cast it off for you (an easy mod to pyste). 
More good news is that the previous problem with const public static 
data members has been fixed.

3. gccxml from CVS now returns the typedefed type rather than the 
underlying type. Hence if I have typedef char FXchar; and I do things 
like:

const FXchar *getName() const;

... now pyste doesn't recognise that it's a string and complains.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP+iKQMEcvDLFGKbPEQINbwCfRSRaSYoWiYex8gTE3D+h8ipvdbsAn1jT
LMU9UK2BooTnMm+ilHqLJku4
=YsAa
-----END PGP SIGNATURE-----



From surffirst at yahoo.com  Wed Dec 24 05:23:06 2003
From: surffirst at yahoo.com (Leo Yee)
Date: Wed, 24 Dec 2003 12:23:06 +0800
Subject: [C++-sig] Re: Re: boost: python may cause memory leaks?
References: <bs9co0$fj5$1@sea.gmane.org>
	<20031223143710.79105.qmail@web20205.mail.yahoo.com>
Message-ID: <bsb45n$ple$1@sea.gmane.org>

You are right. This seems caused by using

 if (PyImport_AppendInittab("hello", inithello) == -1)
        return 1;

before
    Py_Initialize();

However, I can't find a solution to this problem. There is no documentation
telling me how to remove these memeory leaks.

Leo Yee

"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> ????
news:20031223143710.79105.qmail at web20205.mail.yahoo.com...
> --- Leo Yee <surffirst at yahoo.com> wrote:
> > >     Py_Finalize();
>
> I don't use embedding myself and therefore I could be wrong, but I believe
I
> saw messages saying that you cannot use Py_Finalize() if you use
Boost.Python.
> Ralf
>
>
> __________________________________
> Do you Yahoo!?
> New Yahoo! Photos - easier uploading and sharing.
> http://photos.yahoo.com/






From rwgk at yahoo.com  Wed Dec 24 14:00:22 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 24 Dec 2003 05:00:22 -0800 (PST)
Subject: [C++-sig] Re: Re: boost: python may cause memory leaks?
In-Reply-To: <bsb45n$ple$1@sea.gmane.org>
Message-ID: <20031224130022.53977.qmail@web20209.mail.yahoo.com>

--- Leo Yee <surffirst at yahoo.com> wrote:
> You are right. This seems caused by using
> 
>  if (PyImport_AppendInittab("hello", inithello) == -1)
>         return 1;
> 
> before
>     Py_Initialize();
> 
> However, I can't find a solution to this problem. There is no documentation
> telling me how to remove these memeory leaks.

Have you tried it the "normal" way, i.e. Py_Initialize() first and then
PyImport_ImportModule()? And without calling Py_Finalize()?


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/



From dave at boost-consulting.com  Wed Dec 24 14:03:16 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 24 Dec 2003 08:03:16 -0500
Subject: [C++-sig] Re: boost: python may cause memory leaks?
References: <bs9co0$fj5$1@sea.gmane.org>
	<20031223143710.79105.qmail@web20205.mail.yahoo.com>
	<bsb45n$ple$1@sea.gmane.org>
Message-ID: <uk74m5pwr.fsf@boost-consulting.com>

"Leo Yee" <surffirst at yahoo.com> writes:

> You are right. This seems caused by using
>
>  if (PyImport_AppendInittab("hello", inithello) == -1)
>         return 1;
>
> before
>     Py_Initialize();

That's not the problem.  The problem is that Boost.Python hangs on to
some Python references even after Py_Finalize is called.  When the
application exits, those reference counts are decremented, even
though there's no interpreter running.

> However, I can't find a solution to this problem. There is no
> documentation telling me how to remove these memeory leaks.

I doubt you can do anything about it without solving the problem
described above.  Those references are keeping memory from being
deallocated.

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




From surffirst at yahoo.com  Wed Dec 24 14:23:03 2003
From: surffirst at yahoo.com (Leo Yee)
Date: Wed, 24 Dec 2003 21:23:03 +0800
Subject: [C++-sig] Re: boost: python may cause memory leaks?
References: <bs9co0$fj5$1@sea.gmane.org><20031223143710.79105.qmail@web20205.mail.yahoo.com><bsb45n$ple$1@sea.gmane.org>
	<uk74m5pwr.fsf@boost-consulting.com>
Message-ID: <bsc3q3$d89$1@sea.gmane.org>

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

>>Have you tried it the "normal" way, i.e. Py_Initialize() first and then
>>PyImport_ImportModule()? And without calling Py_Finalize()?

I compiled the code to DLLs and import it from a python script but the
memory leaks were still there.

I guess if we put the following at the beginning of a program we will always
get these memory leaks.

int _tmain(int argc, _TCHAR* argv[])
{
    _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
...

"David Abrahams" <dave at boost-consulting.com> writes:
> I doubt you can do anything about it without solving the problem
> described above.  Those references are keeping memory from being
> deallocated.

I guess you mean that's not a problem and the memory leaks wouldn't made my
programs mal-functional.

Merry Chiristmas.

Leo Yee






From dave at boost-consulting.com  Wed Dec 24 14:23:54 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 24 Dec 2003 08:23:54 -0500
Subject: [C++-sig] Re: register_ptr_to_python and get_pointer
References: <16353.64838.66000.340548@gargle.gargle.HOWL>
	<16359.26989.171000.735167@gargle.gargle.HOWL>
Message-ID: <uekuu5oyd.fsf@boost-consulting.com>

Marc Kwiatkowski <Marc.Kwiatkowski at veritas.com> writes:

> Yet another question/observation about register_ptr_to_python.
>
> Given a function that returns a ref-ptr, it seems that all that is
> really necessary is to provide a get_pointer template function for it
> and then invoke the register_to_python function.  

That's right.

> None of the wrapper stuff is necessary.  

What "wrapper stuff"?  Do you mean A_wrapper in the example in the
docs?

> For example:
>
>     class X {
>     public:
>         X(wstring const& aValue) : value(aValue) {}
>         wstring value;
>     };
>
>     my_ref_ptr<X> NewX(wstring const& aValue )
>         { return my_ref_ptr<X>(new X(aValue)); }
> 	      
>     namespace boost { namespace python {
>
>     template <class T> T* get_pointer(my_ref_ptr<T> const& p) {
>         return p.get();
>     }
>     }}
>     
>     BOOST_PYTHON_MODULE(test) {
>
>         class_<X>("X", init<wstring const&>())
>             .def_readwrite("value", &X::value);
>
>         def("NewX", &NewX);
>
>         register_ptr_to_python< my_ref_ptr< X > >();
>    }
>
> That's all there is too it.  This seems so much more straight forward
> than the sample described in
> libs/python/doc/v2/register_ptr_to_python.html

It illustrates something different from your code.

> On the other hand, when I used ref-ptrs with a mix of derived and base
> classes, I can find no permutation of wrapper and smart pointer that
> will work to get at a base method from a derived object ptr that is
> downcast to a base object pointer.

That's an upcast.

> For example, given the Base, Derived, and Factory classes attached
> below, the following script fails
>
>>>> from pytest import Base, Factory, Derived;f=Factory()
>>>> d=f.NewDerived("i am derived")
>>>> d.GetString()
> u'i am derived'
>>>> b=f.Downcast(d)
>>>> b.GetString()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> Boost.Python.ArgumentError: Python argument types in
>     Derived.GetString(Derived)
> did not match C++ signature:
>     GetString(class Filer::Test::Example::PyDerivedWrapper {lvalue})
>     GetString(class Filer::Test::Example::PyDerived {lvalue})

Well, you didn't include enough information to make this problem
reproducible (a definition of my_ref_ptr is missing, and I don't know
what else), so there's only so much I can do to help.

>From this part of the error message

   Derived.GetString(Derived)

it's clear that b is actually a Python Derived object, not a Base
object as one would expect (try doing print type(b)).  It seems like
there's something very wrong here, and the only explanation I can
come up with is that my_ref_ptr<Base>::element_type is Derived.  See
http://www.boost-consulting.com/boost/libs/python/doc/v2/pointee.html.

The other thing that looks suspicious is that you haven't declared an
inheritance relationship between Base and Derived using bases<...>.
There'd be no need to expose GetString again in Derived if you did
that.

HTH,

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




From s_sourceforge at nedprod.com  Wed Dec 24 19:44:12 2003
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 24 Dec 2003 18:44:12 -0000
Subject: [C++-sig] Re: boost: python may cause memory leaks?
In-Reply-To: <uk74m5pwr.fsf@boost-consulting.com>
Message-ID: <3FE9DE7C.8304.1FB87EEC@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24 Dec 2003 at 8:03, David Abrahams wrote:

> That's not the problem.  The problem is that Boost.Python hangs on to
> some Python references even after Py_Finalize is called.  When the
> application exits, those reference counts are decremented, even though
> there's no interpreter running.

Can't you at least do for those held references specially if(ref && 
Py_IsInitialized()) decref()?

It does seem a shame to leak memory. I guess it's not so important in 
modern days of process boundaries, but I guess a non-leaking program 
shows someone has taken time and care which can only be a good thing. 
Certainly when certain software vendors who I won't mention publicly 
choose to ship debug builds of their retail software because the MSVC 
CRT debug lib doesn't crash!!! :(

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP+nefMEcvDLFGKbPEQIp6ACghIV+NbkBMytCe2LEdmfN2DAGY6gAn0S5
v1YpRyr5IaMRJ0n99jisWBoJ
=uF7j
-----END PGP SIGNATURE-----



From dleary at ttlc.net  Sat Dec 27 23:17:55 2003
From: dleary at ttlc.net (Dusty Leary)
Date: Sat, 27 Dec 2003 17:17:55 -0500
Subject: [C++-sig] python binding problems
References: <16353.64838.66000.340548@gargle.gargle.HOWL><16359.26989.171000.735167@gargle.gargle.HOWL>
	<uekuu5oyd.fsf@boost-consulting.com>
Message-ID: <000301c3ccc7$46f22b60$cf2aa8c0@dustnew>

Hello,

I have used boost::python to make python bindings for a rather large
interface at work.  There, we have lots of virtual interfaces, with python
using and invoking them, and in a few cases, extending them, with no
problem.

Now, at home, I am trying to bind another project.  This one is a bit
different.

The root of the problem is that I want python's "held values" for my types
to usually be pointers.  The project I am binding with makes heavy use of
pointer identity (for serializing structs for network comm.)

I am running into some problems.

Basically, I am calling a python function with structure instances...  like
so:

PyObject* func;
foo* foo_instance;
boost::python::call<void>(func, foo_instance);

But, binding foo is problematic...

If I use:  class_<foo>("foo")...;, then copies of foo instances are made,
and used in the python objects, even though I am calling functions and
passing in foo* parameters.

If I use: class_<foo, boost::noncopyable>("foo")...;, then when I pass in my
foo* values, I get boost python errors (when I call the function), "no
to-python (by-value) convertor for struct foo"...

If I wrap my foo*'s in a simple template "smart pointer" class I made, and
use:  class_<foo, simple_wrap<foo>, boost::noncopyable>("foo")...;, then the
object identity works fine, but it still complains about "no to-python"
convertors if I use raw foo*'s in boost::python::call instead of explicitly
wrapping them in simple_wrap<foo>...


I would have thought this pattern at least somewhat common...  For return
values, you can specify reference_existing_object, return_opaque_pointer,
etc...  How do we do this for input values?





From dave at boost-consulting.com  Sat Dec 27 23:36:22 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 27 Dec 2003 17:36:22 -0500
Subject: [C++-sig] Re: python binding problems
References: <16353.64838.66000.340548@gargle.gargle.HOWL>
	<16359.26989.171000.735167@gargle.gargle.HOWL>
	<uekuu5oyd.fsf@boost-consulting.com>
	<000301c3ccc7$46f22b60$cf2aa8c0@dustnew>
Message-ID: <uekupriqh.fsf@boost-consulting.com>

"Dusty Leary" <dleary at ttlc.net> writes:

> Hello,
>
> I have used boost::python to make python bindings for a rather large
> interface at work.  There, we have lots of virtual interfaces, with python
> using and invoking them, and in a few cases, extending them, with no
> problem.
>
> Now, at home, I am trying to bind another project.  This one is a bit
> different.
>
> The root of the problem is that I want python's "held values" for my types
> to usually be pointers.  The project I am binding with makes heavy use of
> pointer identity (for serializing structs for network comm.)
>
> I am running into some problems.
>
> Basically, I am calling a python function with structure instances...  like
> so:
>
> PyObject* func;
> foo* foo_instance;
> boost::python::call<void>(func, foo_instance);
>
> But, binding foo is problematic...
>
> If I use:  class_<foo>("foo")...;, then copies of foo instances are made,
> and used in the python objects, even though I am calling functions and
> passing in foo* parameters.
>
> If I use: class_<foo, boost::noncopyable>("foo")...;, then when I pass in my
> foo* values, I get boost python errors (when I call the function), "no
> to-python (by-value) convertor for struct foo"...

Pass ptr(x) instead of x if you don't want the foo copied.

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




From dleary at ttlc.net  Sun Dec 28 09:39:42 2003
From: dleary at ttlc.net (Dusty Leary)
Date: Sun, 28 Dec 2003 03:39:42 -0500
Subject: [C++-sig] Re: python binding problems
References: <16353.64838.66000.340548@gargle.gargle.HOWL><16359.26989.171000.735167@gargle.gargle.HOWL><uekuu5oyd.fsf@boost-consulting.com><000301c3ccc7$46f22b60$cf2aa8c0@dustnew>
	<uekupriqh.fsf@boost-consulting.com>
Message-ID: <000301c3cd1e$23ee2b30$cf2aa8c0@dustnew>


>
> Pass ptr(x) instead of x if you don't want the foo copied.
>

Thanks very much.

Is there a way to specify this as the default behavior for a type, maybe via
the to_python handlers or whatever?

Basically, something so that whenever I call python with a foo*, it will do
the pointer_wrapper<> thing...




From dave at boost-consulting.com  Sun Dec 28 14:02:11 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 28 Dec 2003 08:02:11 -0500
Subject: [C++-sig] Re: python binding problems
References: <16353.64838.66000.340548@gargle.gargle.HOWL>
	<16359.26989.171000.735167@gargle.gargle.HOWL>
	<uekuu5oyd.fsf@boost-consulting.com>
	<000301c3ccc7$46f22b60$cf2aa8c0@dustnew>
	<uekupriqh.fsf@boost-consulting.com>
	<000301c3cd1e$23ee2b30$cf2aa8c0@dustnew>
Message-ID: <ufzf5p030.fsf@boost-consulting.com>

"Dusty Leary" <dleary at ttlc.net> writes:

>>
>> Pass ptr(x) instead of x if you don't want the foo copied.
>>
>
> Thanks very much.
>
> Is there a way to specify this as the default behavior for a type, maybe via
> the to_python handlers or whatever?

Nope.

> Basically, something so that whenever I call python with a foo*, it will do
> the pointer_wrapper<> thing...

Sorry, it's explicit for a reason: passing by-raw-pointer is unsafe.
The original C++ object's lifetime can end while the Python object is
still alive, and usage of the Python object thereafter can crash the
interpreter.

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




From dave at boost-consulting.com  Tue Dec 30 16:26:18 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 30 Dec 2003 10:26:18 -0500
Subject: [C++-sig] Re: class_<>::add_property() on CVS-HEAD
References: <1067397479.30557.10.camel@illuvatar>
Message-ID: <uhdzicoo5.fsf@boost-consulting.com>

Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:

> Is there a replacement for this functionality?
>
> Thanks,
> Jonathan Brandmeyer
>
> --------------------------------------------------------------
> #include <boost/python.hpp>
>
> namespace test {
>
> // Hmm.  return_internal_reference<>() wants to wrap a real class.
> class ret_type
> {
>  public:
> 	double i;
> };
>
> class crash_me
> {
> 	private:
> 		ret_type i;
> 	public:
> 		ret_type& get_i() { return i; }
> };
>
> }
>
> BOOST_PYTHON_MODULE( crash_test)
> {
> 	using namespace boost::python;
> 	
> 	class_< test::ret_type>( "ret_type")
> 		.def_readwrite( "i", &test::ret_type::i)
> 		;
> 	
> 	class_< test::crash_me> crash_me_wrapper( "crash_me");
> 	
> 	crash_me_wrapper
> 		.def( "get_i", &test::crash_me::get_i , return_internal_reference<>())
> 		;
> 	
> 	// The following works under Boost 1.30, but not CVS-HEAD 
> 	// (sourceforge repository).
> 	crash_me_wrapper.add_property( "i", crash_me_wrapper.attr("get_i"));
> }

Jonathan,

Sorry it took so long to respond; I'll fix it in CVS momentarily.
In the meantime, you can use:

 	crash_me_wrapper.add_property( 
        "i", object(crash_me_wrapper.attr("get_i"))
    ); 

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




From nickm at sitius.com  Tue Dec 30 20:23:00 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Tue, 30 Dec 2003 14:23:00 -0500
Subject: [C++-sig] args.hpp from CVS
Message-ID: <3FF1D094.E28B3092@sitius.com>

There is a problem in the args.hpp from the CVS(today)

I am getting this error 
H:\work\include\ui/selection.h(145) : warning C4355: 'this' : used in
base member initializer list
D:\Shared\boost_1_31_0\boost\boost/python/args.hpp(145) : error C2039:
',' : is not a member of 'keywords<1>'
        D:\Shared\boost_1_31_0\boost\boost/python/args.hpp(58) : see
declaration of 'keywords<1>'
        H:\work\src\ui\angle_field_py.cpp(130) : see reference to
function template instantiation 'struct
boost::python::detail::keywords<2> __cdecl
boost::python::detail::operator ,(const struct
boost::python::detail::keywords<1> &,
char *)' being compiled


This fixes it:

$ cvs diff args.hpp
Index: args.hpp
===================================================================
RCS file: /boost/boost/boost/python/args.hpp,v
retrieving revision 1.18
diff -r1.18 args.hpp
145c145
<       return l.operator,(arg(name));
---
>       return l,arg(name);


-- 
Nikolay Mladenov
Sitius Automation Inc.
www.sitius.com




From seefeld at sympatico.ca  Tue Dec 30 21:00:30 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 30 Dec 2003 15:00:30 -0500
Subject: [C++-sig] error accessing attribute
Message-ID: <9e011f884051a619c3e7b2f3bb647b2f3ff1d584@Orthosoft.ca>

hi there,

I'm compiling a python frontend for some classes, exposing
a member variable (pointer to object) as a property in python.

Unfortunately, when I access that property, I get the error:

TypeError: bad argument type for built-in operation

What can cause this kind of error ? What built-in operation
is meant here ? And what would be the argument ?

I'm sorry that I can't provide a more detailed description
of the problem, unfortunately I could not yet reproduce the problem
with a simple test case.

Is there any documentation (FAQ, wiki, whatever) that discusses
often encountered error messages (which can get quite cryptic
with the combination of python runtime binding and C++ template
compile-time binding !) and their respective meaning / typical
cause ?

Thanks a lot,
		Stefan




From jbrandmeyer at earthlink.net  Tue Dec 30 21:36:54 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Tue, 30 Dec 2003 15:36:54 -0500
Subject: [C++-sig] error accessing attribute
In-Reply-To: <9e011f884051a619c3e7b2f3bb647b2f3ff1d584@Orthosoft.ca>
References: <9e011f884051a619c3e7b2f3bb647b2f3ff1d584@Orthosoft.ca>
Message-ID: <1072816613.4712.71.camel@illuvatar>

On Tue, 2003-12-30 at 15:00, Stefan Seefeld wrote:
> hi there,
> 
> I'm compiling a python frontend for some classes, exposing
> a member variable (pointer to object) as a property in python.
> 
> Unfortunately, when I access that property, I get the error:
> 
> TypeError: bad argument type for built-in operation
> 
> What can cause this kind of error ? What built-in operation
> is meant here ? And what would be the argument ?
> 
> I'm sorry that I can't provide a more detailed description
> of the problem, unfortunately I could not yet reproduce the problem
> with a simple test case.
> 
> Is there any documentation (FAQ, wiki, whatever) that discusses
> often encountered error messages (which can get quite cryptic
> with the combination of python runtime binding and C++ template
> compile-time binding !) and their respective meaning / typical
> cause ?
> 
> Thanks a lot,
> 		Stefan

If you make a build of your project against the current CVS for
Boost.Python you will get much better error messages.  Otherwise, the
most common source of that error when accessing a property (for me,
anyway) is that you are calling the property's accessor with the wrong
signature, including passing an argument from Python that cannot be
converted to the required C++ type.

HTH,
Jonathan Brandmeyer




From seefeld at sympatico.ca  Tue Dec 30 22:06:56 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 30 Dec 2003 16:06:56 -0500
Subject: [C++-sig] error accessing attribute
References: <9e011f884051a619c3e7b2f3bb647b2f3ff1d584@Orthosoft.ca>
	<1072816613.4712.71.camel@illuvatar>
Message-ID: <9b01a5eaf3dc659a4777f3d4dac7070c3ff1e55a@Orthosoft.ca>

Hi Jonathan,

Jonathan Brandmeyer wrote:

> If you make a build of your project against the current CVS for
> Boost.Python you will get much better error messages.  Otherwise, the

unfortunately I can't, as we are closing up on a release soon, so I have
to rely on released packages only.

> most common source of that error when accessing a property (for me,
> anyway) is that you are calling the property's accessor with the wrong
> signature, including passing an argument from Python that cannot be
> converted to the required C++ type.

hmm, from python I simply called 'obj.value'. As it is
boost::python::make_getter or somesuch that generates the accessor for
me, I must assume that the error is burried somewhere in there, i.e.
the wrong code is generated.

By the way, I just wrote a wrapper *function* that returns the object's
member, and that did work as expected. What didn't was 'make_function'
called with a method, and 'make_getter' called directly on the (public)
member.

Anyways, thanks for the help !

Stefan






From rwgk at yahoo.com  Tue Dec 30 23:48:18 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 30 Dec 2003 14:48:18 -0800 (PST)
Subject: [C++-sig] error accessing attribute
In-Reply-To: <9b01a5eaf3dc659a4777f3d4dac7070c3ff1e55a@Orthosoft.ca>
Message-ID: <20031230224818.65341.qmail@web20204.mail.yahoo.com>

--- Stefan Seefeld <seefeld at sympatico.ca> wrote:
> By the way, I just wrote a wrapper *function* that returns the object's
> member, and that did work as expected. What didn't was 'make_function'
> called with a method, and 'make_getter' called directly on the (public)
> member.

Maybe you need to adjust the return value policies? See:

http://cci.lbl.gov/~rwgk/shortcuts/boost/libs/python/doc/v2/faq.html#topythonconversionfailed

Ralf



__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003



From dave at boost-consulting.com  Wed Dec 31 00:45:40 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 30 Dec 2003 18:45:40 -0500
Subject: [C++-sig] Re: args.hpp from CVS
References: <3FF1D094.E28B3092@sitius.com>
Message-ID: <uy8stamzf.fsf@boost-consulting.com>

Nikolay Mladenov <nickm at sitius.com> writes:

> There is a problem in the args.hpp from the CVS(today)
>
> I am getting this error 
> H:\work\include\ui/selection.h(145) : warning C4355: 'this' : used in
> base member initializer list
> D:\Shared\boost_1_31_0\boost\boost/python/args.hpp(145) : error C2039:
> ',' : is not a member of 'keywords<1>'
>         D:\Shared\boost_1_31_0\boost\boost/python/args.hpp(58) : see
> declaration of 'keywords<1>'
>         H:\work\src\ui\angle_field_py.cpp(130) : see reference to
> function template instantiation 'struct
> boost::python::detail::keywords<2> __cdecl
> boost::python::detail::operator ,(const struct
> boost::python::detail::keywords<1> &,
> char *)' being compiled
>
>
> This fixes it:
>
> $ cvs diff args.hpp
> Index: args.hpp
> ===================================================================
> RCS file: /boost/boost/boost/python/args.hpp,v
> retrieving revision 1.18
> diff -r1.18 args.hpp
> 145c145
> <       return l.operator,(arg(name));
> ---
>>       return l,arg(name);

I'm a little concerned about this fix because using the comma
operator instead of operator, might just be picking up the usual
sequencing operator.  

1. Which version(s) of VC++ are you having this problem with?
2. does it fail with any of the existing tests?
3. Can you enhance one of the tests to reproduce the failure?

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




From dave at boost-consulting.com  Wed Dec 31 01:19:34 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 30 Dec 2003 19:19:34 -0500
Subject: [C++-sig] Re: Deriving python class from a C++ "virtual" class
References: <uoewojabd.fsf@yahoo.co.uk> <3F88957D.18405.218822D6@localhost>
Message-ID: <uvfnxalex.fsf@boost-consulting.com>


I'm sorry that it took so long to respond to this posting.  It's
probably too late, but.

yakumoklesk at yahoo.es writes:

> Imagine we have this C++ class:
>
> class CClassActor
> {
> private:
> 	int		m_iValue;
> public:
> 	CClassActor() { m_iValue = 0; }
> 	virtual ~CClassActor() {}
> 	void SetValue( int iValue ) { m_iValue = iValue; }
> 	int	 GetValue() { return m_iValue; }
> 	virtual int GetConcreteInt();
> };
>
> and we have a derived class from the first:
>
> class CClassActorDerived: CClassActor
> {
> private:
> 	int	m_iOther;
> 	CClassActorDerived() { CClassActor(); m_iOther = 0; }
> 	virtual ~CClassActorDerived() {}
> 	int	GetConcreteInt() { return 10; }
> }
>
> As you can see, CClassActor is virtual

There's no such thing as a "virtual class" in C++.  There are "virtual
bases", but you're not using virtual inheritance.  You must mean that
CClassActor is polymorphic?

> but has a constructor, because it initializes some of the attributes
> of the virtual class that the derived class will eventually use.
>
> But what I want is having a class the same way as CClassActorDerived
> but in Python. As CClassActor is virtual, because it have virtual
> functions, it is supposed that we need a Wrapper class. What I did
> whas this:

<snip lots of code>

This error doesn't seem to have any relationship to the code you
posted.  Furthermore, when I correct all the compilation errors in
that code (see enclosed), it runs fine against the current CVS.

> And I would like also to call to __init__ of CClassActor inside the __init__
> method of the Python Derived classes so that m_iValue gets initialized, but
> when I define
>
> py::class_<CClassActor, CClassActorWrap>( "CppClassActor", py::init<>() ) 
>
> instead of
>
> py::class_<CClassActor, CClassActorWrap, boost::noncopyable>( "CppClassActor", 
> py::no_init )
>
> I get this compile error:
>
> e:\...\value_holder.hpp(137) : error C2661: 'CClassActorWrap::CClassActorWrap' : no 
> overloaded function takes 2 parameters
>        	e:\...\\make_instance.hpp(69) : see reference to function template instantiation 
>         '__thiscall boost::python::objects::value_holder_back_reference<class 
> CClassActor,class CClassActorWrap>::

The code you posted was:

	py::class_<CClassActor, CClassActorWrap, boost::noncopyable>( "CppClassActor" )

Which is equivalent to:

   py::class_<CClassActor, CClassActorWrap, boost::noncopyable>( "CppClassActor", py::init<>() ) 

and it works fine against the current CVS

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031230/6e3c6513/attachment.txt>
-------------- next part --------------

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

From seefeld at sympatico.ca  Wed Dec 31 03:43:46 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 30 Dec 2003 21:43:46 -0500
Subject: [C++-sig] error accessing attribute
In-Reply-To: <20031230224818.65341.qmail@web20204.mail.yahoo.com>
References: <20031230224818.65341.qmail@web20204.mail.yahoo.com>
Message-ID: <3FF237E2.5040801@sympatico.ca>

Ralf W. Grosse-Kunstleve wrote:

> Maybe you need to adjust the return value policies? See:
> 
> http://cci.lbl.gov/~rwgk/shortcuts/boost/libs/python/doc/v2/faq.html#topythonconversionfailed

yes, I guess it's something like that. The error reported
from python is just not useful at all. I'll try boost.python
from cvs next week, just to see whether the generated
messages are more helpful, as suggested in an earlier
mail.

Thanks,
		Stefan




From nickm at sitius.com  Wed Dec 31 16:37:19 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Wed, 31 Dec 2003 10:37:19 -0500
Subject: [C++-sig] Re: args.hpp from CVS
References: <3FF1D094.E28B3092@sitius.com> <uy8stamzf.fsf@boost-consulting.com>
Message-ID: <3FF2ED2F.43FC4B33@sitius.com>



David Abrahams wrote:
> 
> Nikolay Mladenov <nickm at sitius.com> writes:
> 
> > There is a problem in the args.hpp from the CVS(today)
> >
> > I am getting this error
> > H:\work\include\ui/selection.h(145) : warning C4355: 'this' : used in
> > base member initializer list
> > D:\Shared\boost_1_31_0\boost\boost/python/args.hpp(145) : error C2039:
> > ',' : is not a member of 'keywords<1>'
> >         D:\Shared\boost_1_31_0\boost\boost/python/args.hpp(58) : see
> > declaration of 'keywords<1>'
> >         H:\work\src\ui\angle_field_py.cpp(130) : see reference to
> > function template instantiation 'struct
> > boost::python::detail::keywords<2> __cdecl
> > boost::python::detail::operator ,(const struct
> > boost::python::detail::keywords<1> &,
> > char *)' being compiled
> >
> >
> > This fixes it:
> >
> > $ cvs diff args.hpp
> > Index: args.hpp
> > ===================================================================
> > RCS file: /boost/boost/boost/python/args.hpp,v
> > retrieving revision 1.18
> > diff -r1.18 args.hpp
> > 145c145
> > <       return l.operator,(arg(name));
> > ---
> >>       return l,arg(name);
> 
> I'm a little concerned about this fix because using the comma
> operator instead of operator, might just be picking up the usual
> sequencing operator.

That was exactly the reason why I originally had the "," operator member
of keywords<N>.
Why is it that you moved the operator in the outside scope?

> 
> 1. Which version(s) of VC++ are you having this problem with?
>
	VC 6.5

> 2. does it fail with any of the existing tests?

probably does not.

> 3. Can you enhance one of the tests to reproduce the failure?


nickm at nyc /d/Shared/boost_1_31_0/boost/libs/python/test
$ cvs diff args*
Index: args.cpp
===================================================================
RCS file: /boost/boost/libs/python/test/args.cpp,v
retrieving revision 1.5
diff -r1.5 args.cpp
53a54,58
>
>     def("f_", f, (arg("x"), "y", "z")
>         , "This is f's docstring"
>         );
>
Index: args.py
===================================================================
RCS file: /boost/boost/libs/python/test/args.py,v
retrieving revision 1.4
diff -r1.4 args.py
14a15,23
> >>> f_(x= 1, y = 3, z = 'hello')
> (1, 3.0, 'hello')
>
> >>> f_(z = 'hello', x = 3, y = 2.5)
> (3, 2.5, 'hello')
>
> >>> f_(1, z = 'hi', y = 3)
> (1, 3.0, 'hi')

I had to move the #include "test_class.hpp" line up in order to compile
this (msvc iced).

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

-- 
Nikolay Mladenov
Sitius Automation Inc.
www.sitius.com




From rwgk at yahoo.com  Wed Dec 31 18:48:55 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 31 Dec 2003 09:48:55 -0800 (PST)
Subject: [C++-sig] Re: args.hpp from CVS
In-Reply-To: <3FF2ED2F.43FC4B33@sitius.com>
Message-ID: <20031231174855.24868.qmail@web20205.mail.yahoo.com>

--- Nikolay Mladenov <nickm at sitius.com> wrote:
> I had to move the #include "test_class.hpp" line up in order to compile
> this (msvc iced).

Thanks for reporting this observation! I had the same problem when compiling
with VC6 in release mode. The includes are now moved on the CVS head. Will do
the release branch later.
Ralf


__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003



From dave at boost-consulting.com  Wed Dec 31 19:43:31 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 31 Dec 2003 13:43:31 -0500
Subject: [C++-sig] Re: args.hpp from CVS
References: <3FF1D094.E28B3092@sitius.com> <uy8stamzf.fsf@boost-consulting.com>
	<3FF2ED2F.43FC4B33@sitius.com>
Message-ID: <uwu8c6d64.fsf@boost-consulting.com>

Nikolay Mladenov <nickm at sitius.com> writes:

> David Abrahams wrote:
>> 
>> Nikolay Mladenov <nickm at sitius.com> writes:
>> 
>> > There is a problem in the args.hpp from the CVS(today)
>> >
>> > I am getting this error
>> > H:\work\include\ui/selection.h(145) : warning C4355: 'this' : used in
>> > base member initializer list
>> > D:\Shared\boost_1_31_0\boost\boost/python/args.hpp(145) : error C2039:
>> > ',' : is not a member of 'keywords<1>'
>> >         D:\Shared\boost_1_31_0\boost\boost/python/args.hpp(58) : see
>> > declaration of 'keywords<1>'
>> >         H:\work\src\ui\angle_field_py.cpp(130) : see reference to
>> > function template instantiation 'struct
>> > boost::python::detail::keywords<2> __cdecl
>> > boost::python::detail::operator ,(const struct
>> > boost::python::detail::keywords<1> &,
>> > char *)' being compiled
>> >
>> >
>> > This fixes it:
>> >
>> > $ cvs diff args.hpp
>> > Index: args.hpp
>> > ===================================================================
>> > RCS file: /boost/boost/boost/python/args.hpp,v
>> > retrieving revision 1.18
>> > diff -r1.18 args.hpp
>> > 145c145
>> > <       return l.operator,(arg(name));
>> > ---
>> >>       return l,arg(name);
>> 
>> I'm a little concerned about this fix because using the comma
>> operator instead of operator, might just be picking up the usual
>> sequencing operator.
>
> That was exactly the reason why I originally had the "," operator member
> of keywords<N>.
> Why is it that you moved the operator in the outside scope?

I don't know; the log entry says:

  date: 2003/10/29 00:46:08;  author: david_abrahams;  state: Exp;  lines: +46 -34
  bug fix for a single use of arg with no comma operator

There's a corresponding checkin for test/keywords.cpp on the same date.
Does that give you any clues?

>> 1. Which version(s) of VC++ are you having this problem with?
>>
> 	VC 6.5
>
>> 2. does it fail with any of the existing tests?
>
> probably does not.
>
>> 3. Can you enhance one of the tests to reproduce the failure?

Thanks for the test patch; I'll look into it.

> nickm at nyc /d/Shared/boost_1_31_0/boost/libs/python/test
> $ cvs diff args*
> Index: args.cpp
> ===================================================================
> RCS file: /boost/boost/libs/python/test/args.cpp,v
> retrieving revision 1.5
> diff -r1.5 args.cpp
> 53a54,58
>>
>>     def("f_", f, (arg("x"), "y", "z")
>>         , "This is f's docstring"
>>         );
>>
> Index: args.py
> ===================================================================
> RCS file: /boost/boost/libs/python/test/args.py,v
> retrieving revision 1.4
> diff -r1.4 args.py
> 14a15,23
>> >>> f_(x= 1, y = 3, z = 'hello')
>> (1, 3.0, 'hello')
>>
>> >>> f_(z = 'hello', x = 3, y = 2.5)
>> (3, 2.5, 'hello')
>>
>> >>> f_(1, z = 'hi', y = 3)
>> (1, 3.0, 'hi')
>
> I had to move the #include "test_class.hpp" line up in order to compile
> this (msvc iced).
>
>>
>> 
>> --
>> Dave Abrahams
>> Boost Consulting
>> www.boost-consulting.com
>
> -- 
> Nikolay Mladenov
> Sitius Automation Inc.
> www.sitius.com

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




From dave at boost-consulting.com  Wed Dec 31 20:19:10 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 31 Dec 2003 14:19:10 -0500
Subject: [C++-sig] Re: args.hpp from CVS
References: <3FF1D094.E28B3092@sitius.com> <uy8stamzf.fsf@boost-consulting.com>
	<3FF2ED2F.43FC4B33@sitius.com> <uwu8c6d64.fsf@boost-consulting.com>
Message-ID: <uoeto6bip.fsf@boost-consulting.com>

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

>> That was exactly the reason why I originally had the "," operator member
>> of keywords<N>.
>> Why is it that you moved the operator in the outside scope?
>
> I don't know; the log entry says:
>
>   date: 2003/10/29 00:46:08;  author: david_abrahams;  state: Exp;  lines: +46 -34
>   bug fix for a single use of arg with no comma operator
>
> There's a corresponding checkin for test/keywords.cpp on the same date.
> Does that give you any clues?

OK, I have a fix which I'm checking in and moving to the release
branch now.  It restores your member operator, ;-)

Patch enclosed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: args.patch
Type: text/x-patch
Size: 5210 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031231/3190c46f/attachment.bin>
-------------- next part --------------

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