Boost logo

Boost :

From: Edward Diener (eldiener_at_[hidden])
Date: 2019-08-09 18:27:26

On 8/9/2019 9:57 AM, Alexander Grund via Boost wrote:
> > Obviously cxxd does not have to go to great lengths to make this work
> for the end-user,
> Just picked this quote but it applies to more: The use-case for cxxd is
> another than what is intended for a boost-wide solution. As you write
> yourself: It is great for one-off code.
> In most projects using Boost you don't manually link a boost lib, but
> use CMake (or similar). Having more variants means more switches and
> complicate the process
> >So you want to all Boost libraries which currently support
> boost::chrono to also support std::chrono in c++11 mode or higher with
> additional interfaces for using std::chrono ? Sure, go ahead if you
> think that is viable. That's what everybody currently does now anyway. I
> personally do not relish that sort of work, which is why I created cxxd
> in the first place.
> No. What I and Atharva propose is essentially: `namespace boost::chrono{
> using namespace std::chrono; }`. All libraries which use boost::chrono
> will now automatically work with std::chrono and users can use
> boost::chrono or std::chrono to call into any boost library.

As long as there is no difference in functionality between boost::chrono
and std::chrono, and as long as boost:;chrono is fine with being a C++11
on up library, your technique as specified above should work. But in
that case we might as well tell end-users about it and that they might
want to transition directly to std::chrono and stop using boost::chrono.

> The idea is: (Almost?) all types in std::chrono have exact equivalents
> in boost which can simply be used and the boost types can be removed.
> Additional functionality provided by Boost (if there is any) should be
> changed to rely on std::chrono types (if they even need to, due to the
> aliasing above)

If there is additional functionality in boost::chrono that is not in
std::chrono it probably can not rely on std::chrono to provide it.
Furthermore if there is additional functionality in std::chrono that is
not in boost::chrono your technique will expose it to users of
boost::chrono, and they would need to be told about it in the docs.

> What I added was to NOT provide alternatives to C++11 and simply require
> them which avoids the need to create variants for the different standards.

Sure, because with your suggested change you are assuming a standard of
C++11 on up for boost::chrono and all Boost libraries which use

Boost list run by bdawes at, gregod at, cpdaniel at, john at