From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2019-08-12 13:42:48
> There is truth to this rationale, but I also wanted to point out that it is not absolute.
> Not providing a boost implementation does not preclude enhancing a std::lib.
> But it can certainly help in changing existing signatures,
Indeed. Of course, someone who wants to prototype some breaking change
to a library like chrono or smart_ptr can do it without Boost. For
example, we could have reimplemented ALL of shared_ptr in
github/JohnDoe/smart_ptr to prototype the extensions added in C++17
But here were some advantages of not doing so, and using Boost instead:
- NOT reimplementing ALL of shared_ptr
- Access to a bigger user base than github/JohnDoe/smart_ptr would have
* Boost being white-listed as approved open source in many organizations
* New versions of Boost included in many Linux distribution software
So it was an easy choice to go through Boost because boost::shared_ptr
wasn't just an alias for std::shared_ptr, and had a quality, well
Still, even with Smart_Ptr, you have the option to convince the
maintainer of Smart_Ptr to make boost::shared_ptr just an alias for
[C++17] std::shared_ptr, and make boost::allocate_shared just defer to
It would make users unhappy. There are already users of
boost::local_shared_ptr which depends on the implementation of
boost::shared_ptr, that would continue using Boost even after C++20
features are implemented everywhere.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk