Am 04.09.25 um 10:48 schrieb Ion Gaztañaga via Boost:
El 04/09/2025 a las 9:54, Samuel Debionne via Boost escribió:
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 I'm wary of using a macro to change things unless you can completely rule out ODR violations. Boost is used widely enough that you can end up linking a library not defining the macro together with one that does. So be sure that it doesn't affect your usage. I think providing a function taking either type as an argument is fine. But using either type inside a function with the same signature is not. 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. Another way I support at one point is a template function supporting a foo-like. I.e. I have an SFINAE that allows passing something that is "filesystem::path-enough". This way you get Boost and std types in a single function. Generally I'd encourage accepting either variant. Returning one is harder of course. 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. See above: If it is internal you can run into ODR issues.