-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
integrate support of std::shared_ptr in addition to boost::shared_ptr and perhaps other smart pointers implementing similar concepts #29
Comments
Could do with this. |
👍 |
This is the original ticket: https://svn.boost.org/trac/boost/ticket/6545 and the missing functionality with std::shared_ptr (no implciit upcasting) was discussed at c++-sig http://thread.gmane.org/gmane.comp.python.c++/15759/focus=15771 . |
Did something change here between 1.59 and 1.60? I'm just testing the new version and we're getting testing errors now with things like:
We have recently changed these from using boost::shared_ptr to std::shared_ptr, but everything works in Boost 1.56 to 1.59 but it fails now with 1.60. The wrapper is here. I saw the post linked above, but have no idea where to put that. I don't think this is affected anyway as there is no class hierarchy involved. |
I'm not aware of any related changes in Boost.Python. In particular, I don't think std::shared_ptr was ever supported in Boost.Python (I do want to add support for this, but haven't had the time to set up builds with a C++11 compatible compiler to test this.) |
Thanks. Sounds like I ought to convert all of the std::shared_ptr to boost::shared_ptr though anyway. Hopefully that will work. EDIT: Ok, that didn't work either. I don't really have time to dive down deeply into this today. Will try again in a few days |
The same for me here. |
@ycollet What are the actual errors that you see? Are you seeing the same sort of errors we are? We're getting problems in the type registry:
I've switched between |
I've got the same error message as you: TypeError: No to_python (by-value) converter found for C++ type: boost::shared_ptr<*> ----- Mail original ----- @ycollet What are the actual errors that you see? Are you seeing the same sort of errors we are? We're getting problems in the type registry: TypeError: No to_python (by-value) converter found for C++ type: boost::shared_ptrfostlib::jsondb::local I've switched between std::shared_ptr and boost::shared_ptr and it doesn't make any difference. I wonder what changes were made to shared_ptr between 1.59 and 1.60.... — |
There's nothing in the release notes about changes to either the python or pointer libraries. I think it's fair to say that if we're both getting the same sort of problem it's less likely that we're both doing the same stupid thing that triggers it. I've been meaning to set up a build mechanism that would allow me to build against the current development version of Boost. If I can do that then bisecting between 1.59 and 1.60 might find the problem. BTW, I'm doing C++14 builds and get the same problem on both gcc and clang. |
I fear that this problem comes from a change from a change on another lib. |
Thanks for investigating this ! |
@stefanseefeld This may help you: https://github.com/KayEss/fost-py/blob/master/Cpp/fost-json-py/Jamfile The It is also possible to pass in compiler flags to the bjam command line, but I forget how to do that :) It is nearly impossible to find this stuff in the docs :( |
you can ask on the boost or boost-build mailing list, from experience, On 11 January 2016 at 04:22, Kirit Sælensminde notifications@github.com
|
See http://www.boost.org/build/doc/html/bbv2/overview/builtins/features.html for the "cxxflags" feature. |
I'm also experiencing the error with boost::shared_ptr referenced by @KayEss and @ycollet. I managed to bisect with a simple test program and script. It appears to come from an update/rewrite of type_traits around commit f0da159e1f52e87ad71e4747de6b042c54578e0e (in the type_traits submodule, although that commit won't compile for me). Unfortunately, it looks like a big rewrite in one commit, so I don't know the exact cause, but I hope this helps |
Well found @bennybp Here's a link to the commit. Not really surprised there was a regression in it given how large it is. |
Concerning the boost regression between 1.59 and 1.60, I had a similar one ad I created a post on stackoverflow about it: If we do have the same issue, it is completely unrelated to smart pointers. |
Just as a reminder, the problem with missing converter which arose between 1.59 and 1.60 is, as far as I see, orthogonal to this issue (though certainly valid) -- which is to support std::shared_ptr (and perhaps other smart pointer types) at the same level as boost::shared_ptr (including e.g. automatic upcasting). |
I definitely agree: I have this issue without any smart pointer. On Wed, 10 Feb 2016 at 09:58 eudoxos notifications@github.com wrote:
|
I have just merged support for |
I can't find this feature in the notes for the 1.63 release svn-milestone-1.63-link. Is it just not in that list, or will it be delayed? |
It will be part of 1.63. See http://www.boost.org/users/history/version_1_63_0.html for tentative release notes. (I doubt trac will reflect current efforts, as more and more projects move over to github issue tracking.) |
Nice. Looking forward to it! |
Boost version 1.63 and newer [supports](boostorg/python#29) `std::shared_ptr` python converters. Thus, in this PR, all boost shared pointers are replaced with standard library shared pointers everywhere in the library. The required C++ standard is also increased to C++17, since shared pointers for allocated C arrays do not work with the older standards. In the process, this PR also updates the cereal library to the latest version (1.3.2) without any patching.
currently the support of boost::shared_ptr islands code using std::shared_ptr. While in some cases the user can simply choose to use boost::shared_ptr over std::shared_ptr, this does not work on a pre-existing library whom chose to use std::shared_ptr.
It may also be worth considering older libraries out there who'm had chosen to implement their own smart ptr ( e.g. OpenSceneGraph, ITK/VTK) though I'm not sure they'll support 1:1 the same exact concepts shared_ptr does.
The text was updated successfully, but these errors were encountered: