Re: Potential project: Resolving boost::chrono conflicts with std::chrono

From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2019-08-12 13:42:48

Howard wrote:
> There is truth to this rationale, but I also wanted to point out that it is not absolute.
> [snip]
> 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
and C++20.

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
  e.g.
  * Boost being white-listed as approved open source in many organizations
  * New versions of Boost included in many Linux distribution software
repositories
  * etc.

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
tested, implementation.

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
[C++20] std::allocate_shared.

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.

Glen