Dear list,
how should I export functions to python which return smart pointers to
const-pointers, e.g. shared_ptr?
For my own classes I always tried to avoid this problem by always
providing a methods which returns shared_ptr.
Now I need to export the following method in a class provided by some
on Tue Sep 20 2011, "Niall Douglas" wrote:
> On 19 Sep 2011 at 17:03, Jim Bosch wrote:
>
>> I'd like to see support for static, template-based conversions. These
>> would be defined by [partial-]specializing a traits class, and I tend to
>> think they should only be invoked after attempting a
On 10/05/2011 07:21 AM, Dave Abrahams wrote:
> on Tue Sep 20 2011, "Niall Douglas" wrote:
>
>> On 19 Sep 2011 at 17:03, Jim Bosch wrote:
>>
>>> I'd like to see support for static, template-based conversions. These
>>> would be defined by [partial-]specializing a traits class, and I tend to
>>>
On 10/05/2011 07:21 AM, Dave Abrahams wrote:
on Tue Sep 20 2011, "Niall Douglas" wrote:
On 19 Sep 2011 at 17:03, Jim Bosch wrote:
I'd like to see support for static, template-based conversions. These
would be defined by [partial-]specializing a traits class, and I tend to
think they should
On 10/05/2011 09:03 AM, Stefan Seefeld wrote:
...combined with some hints users can add to their modules. Again, I
think we should favor explicit conversion policy settings over implicit
ones.
Sorry, I haven't yet managed to find time to sketch this out in any
detail. I hope to be able to do tha
On 10/05/2011 09:18 AM, Jim Bosch wrote:
>
> I have one (perhaps unusual) use case that's extremely important for
> me: I have a templated matrix/vector/array class, and I want to define
> converters between those types and numpy that work with any
> combination of template parameters. I can do th
On 10/05/2011 09:26 AM, Stefan Seefeld wrote:
On 10/05/2011 09:18 AM, Jim Bosch wrote:
I have one (perhaps unusual) use case that's extremely important for
me: I have a templated matrix/vector/array class, and I want to define
converters between those types and numpy that work with any
combinat
On 10/05/2011 03:08 AM, Holger Brandsmeier wrote:
Dear list,
how should I export functions to python which return smart pointers to
const-pointers, e.g. shared_ptr?
For my own classes I always tried to avoid this problem by always
providing a methods which returns shared_ptr.
Now I need to exp
Jim,
how do you handle smart_ptr in boost python? Do you simply
cast away the constness?
For my custom smart pointer I provide a class extending
to_python_converter, rcp_to_python, true>
now I decided to also implement
to_python_converter, rcp_to_python_const, true>
where I simply cast away
on Wed Oct 05 2011, Jim Bosch wrote:
> On 10/05/2011 07:21 AM, Dave Abrahams wrote:
>
>> I don't understand why you guys would want compile-time converters at
>> all, really. Frankly, I think they should all be eliminated. They
>> complicate the model Boost.Python needs to support and cause co
Hi
I have a C++ application that uses Boost.Python. We build it on Centos 5.3,
with Python 2.4 and Boost 1.34.
Our makefile uses explicit paths to find Python and Boost. For the headers we
use:
PYTHON = /usr/include/python2.4
BOOST_INC = /usr/include/boost
INCPATH=$(PYTHON)
INCPATH+=$(BOOST_
On 10/05/2011 11:31 AM, Holger Brandsmeier wrote:
Jim,
how do you handle smart_ptr in boost python? Do you simply
cast away the constness?
For my custom smart pointer I provide a class extending
to_python_converter, rcp_to_python, true>
now I decided to also implement
to_python_converte
On 5 Oct 2011 at 7:21, Dave Abrahams wrote:
> >> I'd like to see support for static, template-based conversions. These
> >> would be defined by [partial-]specializing a traits class, and I tend to
> >> think they should only be invoked after attempting all registry-based
> >> conversions.
> >
On 5 Oct 2011 at 9:18, Jim Bosch wrote:
> I think this might turn into something that approaches the same mass of
> complexity Niall describes, because a Python module can be imported into
> several places in a hierarchy at once, and it seems we'd have to track
> which instance of the module is
On 5 Oct 2011 at 11:30, Dave Abrahams wrote:
> > I think this might turn into something that approaches the same mass
> > of complexity Niall describes,
>
> Nothing ever needs to be quite as complex as what Niall describes ;-)
>
> (no offense intended, Niall)
And here I am thinking I am clear
On 10/05/2011 03:28 PM, Niall Douglas wrote:
On 5 Oct 2011 at 9:18, Jim Bosch wrote:
I think this might turn into something that approaches the same mass of
complexity Niall describes, because a Python module can be imported into
several places in a hierarchy at once, and it seems we'd have to
On 10/05/2011 11:30 AM, Dave Abrahams wrote:
on Wed Oct 05 2011, Jim Bosch wrote:
On 10/05/2011 07:21 AM, Dave Abrahams wrote:
I don't understand why you guys would want compile-time converters at
all, really. Frankly, I think they should all be eliminated. They
complicate the model Boost
on Wed Oct 05 2011, "Niall Douglas" wrote:
> On 5 Oct 2011 at 7:21, Dave Abrahams wrote:
>
> What I was proposing was that the compile-time registry is identical
> to the runtime registry.
I don't even know what that means.
> Hence the order of lookup so a lot of the simpler conversion can b
On 2011-10-5 18:12, David Aldrich wrote:
Hi
I have a C++ application that uses Boost.Python. We build it on Centos
5.3, with Python 2.4 and Boost 1.34.
Our makefile uses explicit paths to find Python and Boost. For the
headers we use:
PYTHON = /usr/include/python2.4
BOOST_INC = /usr/include/b
19 matches
Mail list logo
