Stl: Questions about Boost and other third party dependencies.

[SunnyWar]

What are the guidelines or best practices for adding, removing, or using features from third-party libraries?

Case study: <complex> The functionality here and elsewhere can be replaced by implementations available by Boost. Since the dependency already exists, why re-implement it? It's possible that the Boost implementation is not as good as the Microsft STL implementation but then one could simply contribute to the Boost project to bring it up to par.

[sylveon]

Boost does no effort at assuring ABI stability, and polluting the standard
library users with boost symbols is undesired (especially if a different
version of boost is being consumed by the code).

On Tue, Feb 25, 2020, 17:54 SunnyWar [e-mail] wrote:

What are the guidelines or best practices for adding, removing, or using
features from third-party libraries?

Case study: The functionality here and elsewhere can be replaced by
implementations available by Boost. Since the dependency already exists,
why re-implement it? It's possible that the Boost implementation is not as
good as the Microsft STL implementation but then one could simply
contribute to the Boost project to bring it up to par.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/STL/issues/534?email_source=notifications&email_token=ABRELNRGCDAV5BBWX4L5MKLREWORTA5CNFSM4K3VIOMKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IQHFDEQ,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRELNRUY34K4QJ77U22NRTREWORTANCNFSM4K3VIOMA
.

[SunnyWar]

Boost does no effort at assuring ABI stability

I'm not concerned about this as I was _not suggesting_ that this project present Boost on the interface layer.

polluting the standard library users with boost symbols is undesired

This is already a problem that needs to be solved. See #362

[StephanTLavavej]

This is an important question with many layers. Here are some of the factors to consider:

1. Licensing. At this time, we know we can use code under two licenses: the Boost Software License, and the Apache License v2.0 with LLVM Exception. We need to evaluate any other licenses on a case-by-case basis.

2. Logistics. When we implemented Special Math, directly using Boost.Math led to #362. Also, because we separately compiled it, that required a "satellite DLL" msvcp140_2.dll which adds additional complexity to the build system and user redistribution. When we implemented <charconv>, transforming ulfjack/ryu's source code was necessary (to convert separately compiled C into header-only C++ and adapt the behavior to the Standard's requirements). That prevented #362 (and didn't require any separate compilation), but led to #326 - syncing with upstream Ryu is now a manual, highly work-intensive process. (Similarly, I adapted the UCRT's strtod() into from_chars() through a manual process - but at this point I consider the code to be permanently forked.)

3. Long-term maintenance. Related to the previous point, we need to think about how we'll handle bug fixes and WG21 changes, as the Standard is constantly evolving. It's tempting to take on a third-party dependency when a domain is particularly challenging, but if the code doesn't work perfectly and for all time, it will need maintenance, so we need sufficient expertise among microsoft/STL maintainers to avoid such dependencies turning into problems. (A cautionary example, not third-party open-source but still relevant, is the STL's dependency on ConcRT in VS 2012 - that was a mistake that has taken many years to mostly unwind.)

4. Binary compatibility. I still need to write up the Contribution Guidelines that will explain this in more detail, but it's generally very difficult to make significant changes to existing classes (even if they're header-only), which is what would happen if we replaced them with a different implementation from another open-source project. (Functions, including individual member functions, are easier to change.) Note that in the cases of Special Math and <charconv>, those were entirely new components, whereas (for example) replacing regex with Boost.Regex would be an ABI-breaking change.