[Boost-users] Convert boost::shared_ptr to std::shared_ptr for boost::dll::import

[David Demelier via Boost-users]

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
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

[Nevin Liber via Boost-users]

On Thu, Apr 12, 2018 at 2:48 PM, David Demelier via Boost-users <boost...@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:ne...@cplusplusguy.com>  +1-847-691-1404

[degski via Boost-users]

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

[David Demelier via Boost-users]

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

[Stian Zeljko Vrba via Boost-users]

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-use...@lists.boost.org> on behalf of degski via Boost-users <boost...@lists.boost.org>
Sent: Thursday, April 12, 2018 11:11 PM
To: boost...@lists.boost.org
Cc: degski
Subject: Re: [Boost-users] Convert boost::shared_ptr to std::shared_ptr for boost::dll::import

 

[Martijn Otto via Boost-users]

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...@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 via Boost-users]

On 13 April 2018 at 01:12, Martijn Otto via Boost-users <boost...@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 via Boost-users]

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...@lists.boost.org <mailto:boost...@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

[Edward Diener via Boost-users]

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-use...@lists.boost.org> on behalf of
> degski via Boost-users <boost...@lists.boost.org>
> *Sent:* Thursday, April 12, 2018 11:11 PM
> *To:* boost...@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...@lists.boost.org <mailto:boost...@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 via Boost-users]

On Fri, 13 Apr 2018 at 08:24 Edward Diener via Boost-users <boost...@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 via Boost-users]

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 via Boost-users]

On 13 April 2018 at 06:49, Chris Glover via Boost-users <boost...@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 via Boost-users]

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