El 04/09/2025 a las 9:54, Samuel Debionne via Boost escribió:
Dear all,
Some libraries have APIs that rely on type from Boost libraries that have std alternative in C++17 (think filesystem, variant, optional). I wonder if there are some guidelines available for library maintainers to support both alternatives (or concerns if it is not a good idea)?
For example, in Boost.MPI, the foreseen solution is to introduce an alias for optional in the boost::mpi namespace that will conditionally refer to std::optional or boost::optional depending on BOOST_NO_CXX17_HDR_OPTIONAL and a new BOOST_MPI_FORCE_BOOST_OPTIONAL macro. See https://github.com/boostorg/mpi/issues/168
Thank you, Samuel
I don't think we have an agreed guideline. In some corner cases, specially if the library is template-based I try to support both alternatives. E.g. Interprocess supports both std::chrono and boost::chrono in the synchronization primitives. For your use case, if it's an internal dependency (not exported to the API), you could just choose one variant. When the API is involved, the situation is a bit tricky and a compilation flag could do the job, but things can be fragile and error prone, specially if a user can choose between std or boost when both alternatives are available. Depending on Boost libraries also increases coupling and the general trend in recent Boost versions is to reduce dependencies as much as possible. Best, Ion