Convert boost::shared_ptr to std::shared_ptr for boost::dll::import
Hello, In my application I use std::shared_ptr in the public API for loading plugins. I wanted to use boost::dll to import dynamically plugins as well. It looks like for some reasons that it still use boost::shared_ptr instead of std::shared_ptr even though C++11 is 7 years old. I wanted to convert the boost shared_ptr to std with the following function: std::shared_ptr<plugin> load(boost::shared_ptr<plugin> ptr) { return std::shared_ptr<plugin>(ptr.get(), [ptr] (auto) {}); } It works at perfectly at runtime, however my application segfaults at end, when destroying objects. I suspect that it's because the internal boost::dll shared_library is destroyed **before** my own shared_ptr. The backtrace: (gdb) bt #0 0x00007ffff3f054d8 in ?? () #1 0x00007fffffffdb80 in ?? () #2 0x00007ffff4109400 in ?? () #3 0x00007ffff4add6f8 in _nl_current_default_domain () from /lib64/libc.so.6 #4 0x00007ffff47641d8 in __run_exit_handlers () from /lib64/libc.so.6 #5 0x00007ffff476422a in exit () from /lib64/libc.so.6 #6 0x00007ffff474df31 in __libc_start_main () from /lib64/libc.so.6 #7 0x0000000000413c1a in _start () Is there any chance I can safely convert the smart pointer? Regards, -- David
On Thu, Apr 12, 2018 at 2:48 PM, David Demelier via Boost-users < boost-users@lists.boost.org> wrote:
Hello,
In my application I use std::shared_ptr in the public API for loading plugins. I wanted to use boost::dll to import dynamically plugins as well.
It looks like for some reasons that it still use boost::shared_ptr instead of std::shared_ptr even though C++11 is 7 years old.
I wanted to convert the boost shared_ptr to std with the following function:
std::shared_ptr<plugin> load(boost::shared_ptr<plugin> ptr) { return std::shared_ptr<plugin>(ptr.get(), [ptr] (auto) {}); }
Look at < https://stackoverflow.com/questions/12314967/cohabitation-of-boostshared-ptr-and-stdshared-ptr>, which does a ptr.reset() in the deleter. It also describes the caveats with this hack. -- Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>> +1-847-691-1404
On Thu, 2018-04-12 at 15:20 -0500, Nevin Liber wrote:
Look at <https://stackoverflow.com/questions/12314967/cohabitation-of -boostshared-ptr-and-stdshared-ptr>, which does a ptr.reset() in the deleter. It also describes the caveats with this hack.
Hmmm, it effectively works with ptr.reset() in the shared_ptr destructor. But I can't understand why it is needed though. Thanks! Regards -- David
On 12 April 2018 at 13:48, David Demelier via Boost-users < boost-users@lists.boost.org> wrote:
It looks like for some reasons that it still use boost::shared_ptr instead of std::shared_ptr even though C++11 is 7 years old.
Boost needs to support (a.o.) VC7.1 till eternity (needs to run on WinXP), so this will stay this way forever... "We don't support VC7.1" or "Move on", is NOT an option in 2018 as far as Boost is concerned. degski
What?! Good to know because it seems the friction between boost and its std counterparts (also with error_code, etc.) is steadily growing. Knowing that, I'll have a much lower threshold for _not_ choosing boost when evaluating libraries. -- Stian ________________________________ From: Boost-users <boost-users-bounces@lists.boost.org> on behalf of degski via Boost-users <boost-users@lists.boost.org> Sent: Thursday, April 12, 2018 11:11 PM To: boost-users@lists.boost.org Cc: degski Subject: Re: [Boost-users] Convert boost::shared_ptr to std::shared_ptr for boost::dll::import On 12 April 2018 at 13:48, David Demelier via Boost-users <boost-users@lists.boost.org<mailto:boost-users@lists.boost.org>> wrote: It looks like for some reasons that it still use boost::shared_ptr instead of std::shared_ptr even though C++11 is 7 years old. Boost needs to support (a.o.) VC7.1 till eternity (needs to run on WinXP), so this will stay this way forever... "We don't support VC7.1" or "Move on", is NOT an option in 2018 as far as Boost is concerned. degski
On 4/13/2018 2:58 AM, Stian Zeljko Vrba via Boost-users wrote:
What?! Good to know because it seems the friction between boost and its std counterparts (also with error_code, etc.) is steadily growing.
Knowing that, I'll have a much lower threshold for _not_ choosing boost when evaluating libraries.
The reason some libraries use boost::shared_ptr rather than std::shared_ptr has nothing to do with supporting VC7.1 at all. The most obvious reason is that a given library works with code at the c++03 level and does not require c++11 on up. You may feel that this is wrong, but this is another issue entirely than still having to support VC7.1. I offered a preprocessor based solution to supporting std::shared_ptr when it was available as opposed to boost::shared_ptr, along with the same sort of choice between other boost libraries and their c++ standard library counterparts, in my CXX Dual library at https://github.com/eldiener/cxx_dual. But it was not a popular solution for other Boost library developers and so almost nobody in Boost was interested in it. I still feel it is an eminently workable solution to the sort of problem which started this e-mail. But of course it is up to the individual library developer to decide what he wants to support.
-- Stian
------------------------------------------------------------------------ *From:* Boost-users <boost-users-bounces@lists.boost.org> on behalf of degski via Boost-users <boost-users@lists.boost.org> *Sent:* Thursday, April 12, 2018 11:11 PM *To:* boost-users@lists.boost.org *Cc:* degski *Subject:* Re: [Boost-users] Convert boost::shared_ptr to std::shared_ptr for boost::dll::import On 12 April 2018 at 13:48, David Demelier via Boost-users <boost-users@lists.boost.org <mailto:boost-users@lists.boost.org>> wrote:
It looks like for some reasons that it still use boost::shared_ptr instead of std::shared_ptr even though C++11 is 7 years old.
Boost needs to support (a.o.) VC7.1 till eternity (needs to run on WinXP), so this will stay this way forever... "We don't support VC7.1" or "Move on", is NOT an option in 2018 as far as Boost is concerned.
degski
On Fri, 13 Apr 2018 at 08:24 Edward Diener via Boost-users < boost-users@lists.boost.org> wrote:
The reason some libraries use boost::shared_ptr rather than std::shared_ptr has nothing to do with supporting VC7.1 at all. The most obvious reason is that a given library works with code at the c++03 level and does not require c++11 on up. You may feel that this is wrong, but this is another issue entirely than still having to support VC7.1.
There are of course other reasons for choosing the boost variant over the std variant, even outside of boost. Four that often influence me are: - Boost often offers an extended API - Boost components can be forward declared - Boost offers the same implementation across platforms - I can fix a boost version should I need to My projects tend to reach for boost over std for most components as a result of this. -- chris
On 4/13/2018 8:49 AM, Chris Glover via Boost-users wrote:
On Fri, 13 Apr 2018 at 08:24 Edward Diener via Boost-users <boost-users@lists.boost.org <mailto:boost-users@lists.boost.org>> wrote:
The reason some libraries use boost::shared_ptr rather than std::shared_ptr has nothing to do with supporting VC7.1 at all. The most obvious reason is that a given library works with code at the c++03 level and does not require c++11 on up. You may feel that this is wrong, but this is another issue entirely than still having to support VC7.1.
There are of course other reasons for choosing the boost variant over the std variant, even outside of boost. Four that often influence me are:
- Boost often offers an extended API - Boost components can be forward declared - Boost offers the same implementation across platforms - I can fix a boost version should I need to
My projects tend to reach for boost over std for most components as a result of this.
I totally understand your reasons. One of the uses of my CXX Dual library is that it is easy to override the choice of the standard version of a dual library when it is available for the Boost version of a dual library, while still using the exact same code.
-- chris
On 13 April 2018 at 06:49, Chris Glover via Boost-users < boost-users@lists.boost.org> wrote:
There are of course other reasons for choosing the boost variant over the std variant, even outside of boost. Four that often influence me are:
There are good reasons to use the std variants as well.
- Boost often offers an extended API
This means the implementation does not adhere to the standard, documentation problems (or lack thereof are often the result). Furthermore, subtle differences between std and Boost variants exist (filesystem, random) and can lead to hard to understand bugs or difficulty in use of the lib. - Boost components can be forward declared
It was recently posted here that Boost itself actually forward declares STL stuff (dis-allowed according to the std, and confirmed by the author).
- Boost offers the same implementation across platforms
Adhering to the std serves the same purpose. It also, due to inter-dependencies, obliges one to pull in large parts of Boost, possibly just to use one feature. - I can fix a boost version should I need to
Yes you can. However, parts of Boost (CMT) are not maintained (apart from serious bugs). Some (many it seems) PR's are outstanding for years. Libraries become stale (BGL, multiarray, pool f.e.) and basically just preserve the status quo (if you're lucky), with no recourse (other than DIY). degski
On Friday, April 13, 2018, Chris Glover wrote:
There are of course other reasons for choosing the boost variant over the std variant, even outside of boost. Four that often influence me are:
- Boost often offers an extended API - Boost components can be forward declared - Boost offers the same implementation across platforms - I can fix a boost version should I need to
My projects tend to reach for boost over std for most components as a result of this.
-- chris
Additionally, speaking specifically about boost::shared_ptr here: 1. Reasons some users choose boost::shared_ptr in C++11 and C++14 code: - shared_ptr<T[]> (C++17 only) - local_shared_ptr<T> (Boost only, interoperates with boost::shared_ptr<T>) 2. Reasons some users choose boost::shared_ptr in C++17 code: - make_shared<T[]> and allocate_shared<T[]> (C++20 only) - local_shared_ptr<T> (Boost only, interoperates with boost::shared_ptr<T>) 3. Reasons some users choose boost::shared_ptr in C++2a code: - make_shared<T[]> and allocate_shared<T[]> (until all vendors implement it) - local_shared_ptr<T> (Boost only, interoperates with boost::shared_ptr<T>) Glen
On do, 2018-04-12 at 15:11 -0600, degski via Boost-users wrote:
On 12 April 2018 at 13:48, David Demelier via Boost-users <boost-user s@lists.boost.org> wrote:
It looks like for some reasons that it still use boost::shared_ptr instead of std::shared_ptr even though C++11 is 7 years old.
Boost needs to support (a.o.) VC7.1 till eternity (needs to run on WinXP), so this will stay this way forever... "We don't support VC7.1" or "Move on", is NOT an option in 2018 as far as Boost is concerned.
degski _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Wouldn't it be an option to test for the existence of std::make_shared. This could be done using SFINAE. If it exists we can alias the functionality from std:: into boost:: and if not we use the boost implementation. To make it less hairy the header could also be generated b2 before building. This way we maintain compatibility with older and competely unsupported compilers running on unsupported operating systems (why are we doing that again?) without causing interoperability trouble for others.
On 13 April 2018 at 01:12, Martijn Otto via Boost-users < boost-users@lists.boost.org> wrote:
Wouldn't it be an option to test for the existence of std::make_shared. This could be done using SFINAE. If it exists we can alias the functionality from std:: into boost:: and if not we use the boost implementation.
To make it less hairy the header could also be generated b2 before building.
This way we maintain compatibility with older and competely unsupported compilers running on unsupported operating systems (why are we doing that again?) without causing interoperability trouble for others.
All of the above already exists: https://eldiener.github.io/cxx_dual/doc/html/index.html#cxxd.introduction degski
On 4/12/2018 5:11 PM, degski via Boost-users wrote:
On 12 April 2018 at 13:48, David Demelier via Boost-users <boost-users@lists.boost.org <mailto:boost-users@lists.boost.org>> wrote:
It looks like for some reasons that it still use boost::shared_ptr instead of std::shared_ptr even though C++11 is 7 years old.
Boost needs to support (a.o.) VC7.1 till eternity (needs to run on WinXP), so this will stay this way forever... "We don't support VC7.1" or "Move on", is NOT an option in 2018 as far as Boost is concerned.
This is not the reason why some Boost libraries use boost:;shared_ptr rather than std::shared_ptr, and I am sure you know it. So please don't post ridiculous nonsense as you have above.
degski
participants (6)
-
Chris Glover -
David Demelier -
degski -
Edward Diener -
Glen Fernandes -
Martijn Otto -
Nevin Liber -
Stian Zeljko Vrba