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

From: Robert Ramey (ramey_at_[hidden])
Date: 2019-08-10 05:48:59

On 8/8/19 6:01 PM, Howard Hinnant via Boost wrote:
> Possible project for someone looking for a boost project to contribute to:
> 
> boost::chrono was created soon after std::chrono was proposed and served people well for experimenting with this library prior to migrating to C++11.  Fast forward 8 years:  Now we have two competing chrono libraries:  boost::chrono and std::chrono.  And it is not rare for people to use non-chrono boost libraries, which in turn use boost::chrono, and for those same people to use std::chrono.  Invariably what happens is they get horribly complicated compile-time errors which boil down to: boost::chrono does not interoperate with std::chrono.  And these errors often come from deep within libraries which people are simply trying to use.
> 

I'm wondering if given the existence of a boost and std version of the 
same library, it might be better policy to prefer the boost version.

The boost version is one body of source code which is portable across 
C++ versions 11 or newer.  The std version is supplied by the compiler 
vendor.  Each one makes his own version which has it's own quirks, 
interpretations of ambiguities the standard, etc. The probability that 
there are not hidden, subtle differences between them is very small.
Each vendor creates his own test suite (I presume) which as users, we 
aren't privy to.  So when something goes haywire, we can't just run the 
test suite - we have to embark on very long cat and mouse game.

And not all vendors provide documentation of their libraries.

A standard is released and the distinct compiler vendors don't provide 
all the new libraries at the same time.  So we have to include a bunch 
of code on our libraries which determine which aspects of C++ supported 
by which vendors compiler.  Boost Config does a great job.  But it's 
still a nightmare.

It's inexplicable to me why vendors make their own (often inferior) 
versions of the boost library versions.  Have they nothing better to do 
with their money?  If they want, the could send some my way.

The only real motivation for using the std versions is to address the 
C++ dependency/deployment problems - which no one as really thought 
enough about yet.

Back to the original point, seems to be that the best policy would be: 
If the same library is in boost and the std library, one should prefer 
the boost version.

Robert Ramey