[C++-sig] function return a shared_ptr
Hi, I will use a shared pointer to my Python script
I expose my class :
class_ >("Target")
.def("getRadius", &handler::Target::getRadius)
.def("setRadius", &handler::Target::setRadius)
.def("setPosition", &handler::Target::setPosition)
; and I use a method "getTestTarget" who return a shared pointer on my
member variable vgd::Shp
InterfaceScriptBoost::getTestTarget()
{
return UlisBoost::m_testTarget;
}
And the exposition of is methode is : def("getTestTarget",
&dtUlis::InterfaceScriptBoost::getTestTarget,
python::return_value_policy());
I want to know if it is true ? Any help would be appreciated, thank you
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] boost::python with virtual inheritance and g++ c++0x/11 (testcase attached)
On 21 May 2012 at 18:43, Jonas Wielicki wrote: > On 21.05.2012 17:55, Niall Douglas wrote: > > 1. Does the bug occur in non-optimised as well as optimised builds? > It does. Joy. > > 2. Does the bug occur when C++11 is turned off? > It does not. Not so much joy. It could, technically speaking, be a misinterpretation of C++03 by either BPL or GCC. Still, at least it narrows things down. > > 5. Are you using precompiled headers? If so, does the bug occur when > > you turn those off? > I think I am not. I would know if I did, wouldn't I? At least I can > browse through the header sources at /usr/include/boost/.. Precompiled headers on GCC are basically a dump of state just after processing the headers. As a result, the file is huge. That might help you find out if they're on. I believe bjam defaults them to off. > > 6. Can you spot where in the assembly it's making a pointer > > dereferencing mistake? > That is in the template, but the pointer value changes inside code which > is compiled in the boost library. Are you saying that the *offset* changes inside the code? So, class A has vtable at this[-8]. I access a->foo() which indexes this[-8] by 0x16 in the headers. But inside the compiland, a->foo() indexes this[-8] by 0x20, which is wrong. > Within the function defined around inheritance.cpp:392, the value of the > object pointer (I think it's called p) changes. I was yet unable to find > the specific point where the value is changed, because a lot of > subfunctions get called in there and, to be honest, I'm not that > familiar with gcc yet. Also it seems as maybe the wrong value is only > passed, while it is still intact on stack (gcc at least shows me > differing values for the two stackframes), but that might be due to > debug data or gcc magic? Yeah the GCC ABI is a bit fusty. Got a lot better in 3.2 onwards though. You might find http://sourcery.mentor.com/public/cxx-abi/cxx-vtable-ex.html useful as a reference for the C++03 ABI. Of course, almost certainly the bug you're seeing is related to the ABI changes they're making for C++11, of which there are quite a few. If I had to take a guess, your problems might have something to do with fixing bugs in decltype support e.g. one of the changelog items in 4.7 is "The representation of C++ virtual thunks and aliases (both implicit and defined via the alias attribute) has been re-engineered. Aliases no longer pose optimization barriers and calls to an alias can be inlined and otherwise optimized." BTW - can I just clarify you ARE compiling the entire of BPL using C++11 throughout? Linking C++11 to C++03 is *supposed* to work (but not the other way round), but I can see nests of vipers in it. > > If you're *really* unlucky, the bug is that different assembler is > > being generated in different compilands and the fact you're seeing a > > problem is due to sheer chance because of the stochastic choice the > > linker made :) > Actually, the problem is deterministic. I compiled the binary many times > now and with gcc 4.7 I always get the segfault, at the same instruction, > with the same surroundings (changed pointer value from one stack frame > to the other). Given the information so far, you have an excellent chance of getting it fixed. Another thought - I once persuaded the GCC devs to accept a bug when I demonstrated that ICC (Intel's compiler) got it right. ICC is free on Linux, so that might be worth a shot too. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/ ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] function return a shared_ptr
On May 22, 2012 8:38 AM, "Yoann Chaumy" wrote:
>
>
> Hi,
> I will use a shared pointer to my Python script
>
> I expose my class :
>
> class_ >("Target")
> .def("getRadius", &handler::Target::getRadius)
> .def("setRadius", &handler::Target::setRadius)
> .def("setPosition", &handler::Target::setPosition)
> ;
>
>
> and I use a method "getTestTarget" who return a shared pointer on my
member variable
>
> vgd::Shp InterfaceScriptBoost::getTestTarget()
> {
> return UlisBoost::m_testTarget;
> }
>
>
>
> And the exposition of is methode is :
>
> def("getTestTarget", &dtUlis::InterfaceScriptBoost::getTestTarget,
python::return_value_policy());
>
>
>
> I want to know if it is true ?
>
> Any help would be appreciated, thank you
>
If you are returning a smart pointer, there is no need to use a call policy
like return_value_policy<...>. However, you have wrapped the class with
boost::shared_ptr and are returning a different kind of shared pointer.
That won't work. It's easier if you can just use boost::shared_ptr
everywhere, but it is also possible to set up conversions for a custom
smart pointer.
HTH
Jim
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] boost::python with virtual inheritance and g++ c++0x/11 (testcase attached)
When I had this problem I had not built BPL using C++11, how would I instruct bjam to use gcc at a specific location and with the -std=c++0x flag? -- Gabe Rives-Corbett Cell: (805) 570-8395 On Tuesday, May 22, 2012 at 10:43 AM, Niall Douglas wrote: > On 21 May 2012 at 18:43, Jonas Wielicki wrote: > > > On 21.05.2012 17:55, Niall Douglas wrote: > > > 1. Does the bug occur in non-optimised as well as optimised builds? > > > > It does. > > > > > Joy. > > > > 2. Does the bug occur when C++11 is turned off? > > It does not. > > > > > Not so much joy. It could, technically speaking, be a > misinterpretation of C++03 by either BPL or GCC. Still, at least it > narrows things down. > > > > 5. Are you using precompiled headers? If so, does the bug occur when > > > you turn those off? > > > > > > > I think I am not. I would know if I did, wouldn't I? At least I can > > browse through the header sources at /usr/include/boost/.. > > > > > Precompiled headers on GCC are basically a dump of state just after > processing the headers. As a result, the file is huge. That might > help you find out if they're on. I believe bjam defaults them to off. > > > > 6. Can you spot where in the assembly it's making a pointer > > > dereferencing mistake? > > > > > > > That is in the template, but the pointer value changes inside code which > > is compiled in the boost library. > > > > > Are you saying that the *offset* changes inside the code? > > So, class A has vtable at this[-8]. > > I access a->foo() which indexes this[-8] by 0x16 in the headers. > > But inside the compiland, a->foo() indexes this[-8] by 0x20, which is > wrong. > > > Within the function defined around inheritance.cpp:392, the value of the > > object pointer (I think it's called p) changes. I was yet unable to find > > the specific point where the value is changed, because a lot of > > subfunctions get called in there and, to be honest, I'm not that > > familiar with gcc yet. Also it seems as maybe the wrong value is only > > passed, while it is still intact on stack (gcc at least shows me > > differing values for the two stackframes), but that might be due to > > debug data or gcc magic? > > > > > Yeah the GCC ABI is a bit fusty. Got a lot better in 3.2 onwards > though. You might find > http://sourcery.mentor.com/public/cxx-abi/cxx-vtable-ex.html useful > as a reference for the C++03 ABI. > > Of course, almost certainly the bug you're seeing is related to the > ABI changes they're making for C++11, of which there are quite a few. > If I had to take a guess, your problems might have something to do > with fixing bugs in decltype support e.g. one of the changelog items > in 4.7 is "The representation of C++ virtual thunks and aliases (both > implicit and defined via the alias attribute) has been re-engineered. > Aliases no longer pose optimization barriers and calls to an alias > can be inlined and otherwise optimized." > > BTW - can I just clarify you ARE compiling the entire of BPL using > C++11 throughout? Linking C++11 to C++03 is *supposed* to work (but > not the other way round), but I can see nests of vipers in it. > > > > If you're *really* unlucky, the bug is that different assembler is > > > being generated in different compilands and the fact you're seeing a > > > problem is due to sheer chance because of the stochastic choice the > > > linker made :) > > > > > > > Actually, the problem is deterministic. I compiled the binary many times > > now and with gcc 4.7 I always get the segfault, at the same instruction, > > with the same surroundings (changed pointer value from one stack frame > > to the other). > > > > > Given the information so far, you have an excellent chance of getting > it fixed. > > Another thought - I once persuaded the GCC devs to accept a bug when > I demonstrated that ICC (Intel's compiler) got it right. ICC is free > on Linux, so that might be worth a shot too. > > Niall > > -- > Technology & Consulting Services - ned Productions Limited. > http://www.nedproductions.biz/. VAT reg: IE 9708311Q. > Work Portfolio: http://careers.stackoverflow.com/nialldouglas/ > > > > ___ > Cplusplus-sig mailing list > Cplusplus-sig@python.org (mailto:Cplusplus-sig@python.org) > http://mail.python.org/mailman/listinfo/cplusplus-sig > > ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] boost::python with virtual inheritance and g++ c++0x/11 (testcase attached)
On 22.05.2012 16:43, Niall Douglas wrote: > Precompiled headers on GCC are basically a dump of state just after > processing the headers. As a result, the file is huge. That might > help you find out if they're on. I believe bjam defaults them to off. Well, in that case I'm not using them. They would've sprung into my eyes if they're located in the default -I-paths (which I assume). >>> 6. Can you spot where in the assembly it's making a pointer >>> dereferencing mistake? >> That is in the template, but the pointer value changes inside code which >> is compiled in the boost library. > > Are you saying that the *offset* changes inside the code? Hm, I was unclear I guess. I'm going to paste some gdb bt output: #0 0x00405af7 in boost::python::objects::polymorphic_id_generator::execute (p_=0x40a268) at /usr/include/boost/python/object/inheritance.hpp:43 #1 0x77dcb684 in boost::(anonymous namespace)::convert_type (p= 0x666db0, src_t=..., dst_t=..., polymorphic=true) at /usr/src/debug/boost_1_48_0/libs/python/src/object/inheritance.cpp:405 Here we see that to convert_type, p=0x666db0 has been passed, while 0x40a268 arrived in execute. While the first value is a valid pointer to a Foo instance, 0x40a268 is anything but that (actually I did not find out yet what was going on there). However, p is just passed on to execute without modification (as far as I can see in the code). > BTW - can I just clarify you ARE compiling the entire of BPL using > C++11 throughout? Linking C++11 to C++03 is *supposed* to work (but > not the other way round), but I can see nests of vipers in it. Ehm, I guess not, so I just downloaded and rebuilt boost 1.48 in the virtual machine (no fun) with -std=c++11 flag (I added this in the project-options.jam file at the using line; running ./b2 -d2 showed me that the flag was passed to the gcc too). Still, the crash occurs at the same place. > Given the information so far, you have an excellent chance of getting > it fixed. Okay, so I'm taking you suggest I submit both compilation attempts (inheritance.cpp and crashtest.cpp) with -save-temps for comparision to the gcc devs? Of course with all the information I gathered so far. -- Jonas ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] boost::python with virtual inheritance and g++ c++0x/11 (testcase attached)
On 22.05.2012 18:07, Gabe Rives-Corbett wrote:
> how would I instruct bjam to use gcc at a specific location and with the
> -std=c++0x flag?
I found that the following works if you replace the existing section of
the project-config.jam file in the boost source tarball:
>>> snip
# Compiler configuration. This definition will be used unless
# you already have defined some toolsets in your user-config.jam
# file.
if ! gcc in [ feature.values ]
{
using gcc : : : -std=c++11 ;
}
<<< snip
Verify that it works for you by calling b2 or bjam with -d2. This will
print you the g++ calls to the terminal. Check that the -std=c++11 flag
is present there.
--
Jonas
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] boost::python with virtual inheritance and g++ c++0x/11 (testcase attached)
On 22 May 2012 at 18:33, Jonas Wielicki wrote: > > BTW - can I just clarify you ARE compiling the entire of BPL using > > C++11 throughout? Linking C++11 to C++03 is *supposed* to work (but > > not the other way round), but I can see nests of vipers in it. > Ehm, I guess not, so I just downloaded and rebuilt boost 1.48 in the > virtual machine (no fun) with -std=c++11 flag (I added this in the > project-options.jam file at the using line; running ./b2 -d2 showed me > that the flag was passed to the gcc too). Still, the crash occurs at the > same place. Ok. > > Given the information so far, you have an excellent chance of getting > > it fixed. > Okay, so I'm taking you suggest I submit both compilation attempts > (inheritance.cpp and crashtest.cpp) with -save-temps for comparision to > the gcc devs? Of course with all the information I gathered so far. Include the answers to the questions I asked about force inlining, is BPL compiled as c++11, the problem doesn't show in c++03 etc. It shows you've been thorough. Do post the bugzilla link here, I'd like to CC into it. Thanks, Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/ ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] boost::python with virtual inheritance and g++ c++0x/11 (testcase attached)
On 22.05.2012 19:05, Niall Douglas wrote: > Do post the bugzilla link here, I'd like to CC into it. There you go: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455 I hope they won't murder me for the .gz ;). -- Jonas ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
