Convert boost::shared_ptr to std::shared_ptr for boost::dll::import

David Demelier

12 Apr 2018 12 Apr '18

7:48 p.m.

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

Show replies by date

Nevin Liber

12 Apr 12 Apr

8:20 p.m.

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 > +1-847-691-1404

David Demelier

13 Apr 13 Apr

6:21 a.m.

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

degski

12 Apr 12 Apr

9:11 p.m.

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

Stian Zeljko Vrba

13 Apr 13 Apr

6:58 a.m.

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 on behalf of degski via Boost-users 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 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

Edward Diener

12:24 p.m.

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 on behalf of degski via Boost-users *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 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

Chris Glover

12:49 p.m.

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

Edward Diener

1:19 p.m.

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 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

degski

2:27 p.m.

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

Glen Fernandes

4:48 p.m.

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 (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 and allocate_shared (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 and allocate_shared (until all vendors implement it) - local_shared_ptr<T> (Boost only, interoperates with boost::shared_ptr<T>) Glen

Martijn Otto

7:12 a.m.

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 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.

degski

11:16 a.m.

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

Edward Diener

12:12 p.m.

On 4/12/2018 5:11 PM, degski via Boost-users wrote:

...

On 12 April 2018 at 13:48, David Demelier via Boost-users 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

2419

Age (days ago)

2420

Last active (days ago)

List overview

Download

12 comments

8 participants

participants (8)

Chris Glover
David Demelier
degski
Edward Diener
Glen Fernandes
Martijn Otto
Nevin Liber
Stian Zeljko Vrba