ait for his reply).
Unfortunately I don't have the time to do the analysis right now, but I
agree with you that it should have worked.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
___
Cplusplus-sig mailing list
Cplusplus-sig@pyt
his` variant. The issues are all as
> reported before.
>
> -Holger
>
> On Mon, Apr 23, 2012 at 22:25, Dave Abrahams wrote:
>>
>> on Mon Apr 23 2012, Holger Brandsmeier wrote:
>>
>>> In fact the statement
>>> class_, boost::noncopyable
>>&g
> give a segmentation fault. Note that the destructor for the class `K`
> has not been called, which would have printed a statement.
Please post a reduced example without any of the "J" business that
illustrates exactly the problem you're having for this one particular
case.
27;ll
be able to do that conversion. I see you've done that with "J" in your
example, but not with "I". Why not?
If you use enable_shared_from_this, the internal weak_ptr will be
initialized from the first shared_ptr that is constructed to manage the
object. Everything
on Mon Apr 16 2012, John Reid wrote:
> On 15/04/12 03:23, Dave Abrahams wrote:
>>
>> You can't do this; don't even try. Each C++ class has to have a unique
>> Python identity. If you just want to refer to the same class by a
>> different name, you can o
o from the boost.python
> registry.
BOOST_PYTHON_MODULE( _sandbox )
{
namespace bp = ::boost::python;
{
bp::scope scope = bp::class_< Outer1 >( "Outer1" );
bp::class_< Inner >( "Inner" );
}
{
object outer2 = bp::class_< Outer2 >( "Outer2" );
outer2.attr("Inner") = scope().attr("Outer1").attr("Inner");
}
}
HTH-ly y'rs,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
> Best regards,
> Ta,
> Avi
There's no explicit support for it, no.
Sorry,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
ess-model=32 stage
> b2 --toolset=msvc-10.0 --with-python --build-type=complete
> --debug-configuration architecture=x86 address-model=32 stage
> debug-symbols=on debug-store=database python-debugging=on
>
>
>
> _______
> Cplusplus-
ut I don't think that model is what was intended - it doesn't scale
> well to multiple target languages,
In what way?
> and it doesn't explain why the module_builder classes in the proposal
> (I'm looking here: http://www.boostpro.com/writing/oopsla04.html)
isitorBase_wrapper( PyObject* o , const VisitorBase& b) : self( o ),
VisitorBase(b) {};
Also, you could try using & (address-of) instead of boost::ref.
Also, I suggest following this post up on the C++-sig instead of here;
you'll get better help.
Cheers,
--
Dave Abrahams
BoostPro
std::string&?
Yep. Use a thin wrapper that returns by value.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
ue function which creates a Python Foo instance
> based on all members of C++ foo passed separately to it? As far as I
> am aware, Python converters are not intended to help here.
>
> The docs claim, that BOOST::PYTHON::Object can not be used as a
> replacement of PyObject, i.e. e
work on the 64 bit CentOS 4.8. It looks
> like there is such member method number limit on this 64 bit gcc3.4.6
> platform. Please help.
My intuition is that you must be misinterpreting the results. If you
can reproduce this problem in minimal code, I'd be highly surprised.
--
on Wed Oct 05 2011, Jim Bosch wrote:
> On 10/05/2011 11:30 AM, Dave Abrahams wrote:
>
>> on Wed Oct 05 2011, Jim Bosch wrote:
>>
>>> With runtime conversions, I have to explicitly declare all the
>>> template parameter combinations I intend to use.
>&g
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
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.Pyth
tion type into DLL D where it doesn't belong. At this point,
> the program will almost certainly segfault.
Sorry, you completely lost me here.
> As I mentioned earlier, this is a very semantically similar problem
> to supporting multiple python interpreters anyway with each ca
on Mon Oct 03 2011, "Niall Douglas" wrote:
> On 3 Oct 2011 at 8:34, Dave Abrahams wrote:
>
>> Last time I looked at BE it was not really ready for primetime. You're
>> motivating me to check it out again.
>>
>> *checks it out*
>>
>>
on Sun Aug 28 2011, "Niall Douglas" wrote:
> On 27 Aug 2011 at 12:29, Dave Abrahams wrote:
>
>> In that case, if I were you, I would actually start using Git with the
>> modularized / CMake-ified Boost at http://github.com/boost-lib.
>
> If you do go for g
ile.
I suggest you try the Boost Build mailing list for this question if you
don't get an answer here.
Cheers,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.or
st.langbinding available anywhere? Or is it currently only a
> design description?
Yes, there is some code, and there are tests, in
http://svn.boost.org/svn/boost/sandbox/langbinding/
HTH,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
___
C
} catch (boost::python::error_already_set const &) {
std::string perror = parse_python_exception();
std::cerr << "Error in Python: " << perror << std::endl;
}
}
HTH,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
ou reduce your question to a minimal case that doesn't
involve any of your domain-specific stuff. Then it will be easy to
answer.
>
> On Fri, Sep 2, 2011 at 12:19 PM, Dave Abrahams wrote:
>>
>> on Thu Sep 01 2011, Jim Bosch wrote:
>>
>>> boost::python::regist
even one that doesn't hold a
> shared_ptr) into a shared_ptr with correct reference
> counting.
I might have forgotten by now, but I don't think you need to register
shared_ptr, and I don't think the above will have any effect. IIRC I
made sure shared_ptr support "just wor
on Sat Aug 27 2011, Stefan Seefeld wrote:
> On 08/27/2011 04:40 PM, Dave Abrahams wrote:
>>> Hmm. I'm guessing the global type registry would still be the
>>> default, and per-module registries would override these when
>>> available? It sounds like Stefa
on Fri Aug 26 2011, Jim Bosch wrote:
> On 08/26/2011 01:09 PM, Dave Abrahams wrote:
>>
>> Well, speaking for myself, mostly time. I'd be inclined to do a rewrite
>> along the lines of the langbinding ideas if I had time.
>>
>
> I had only been vaguely aw
s in the SVN directory hierarchy.
> I imagine most communication would just happen on the C++-sig list,
> maybe with the [Boost.Python v3] subtitle I've used in this email.
Sure.
> On 08/26/2011 01:09 PM, Dave Abrahams wrote:
>>
>> Trying to catch up here, so responding to every
Boost.Python wrapped classes to inherit from Python classes.
+1
> - An actual "boost.python" Python module to make exceptions and other
> types used in wrappers easily accessible from Python.
Nice.
> - Some limited degree of priority-based overload matching. Not sure
> how best to approach this one yet, though.
+1
This is a solved problem... just not in Boost.Python. Daniel Wallin
worked it out for luabind and we were going to incorporate it into
langbinding. Happy to discuss it further.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
28 matches
Mail list logo
