Re: [boost] Potential project: Resolving boost::chrono conflicts with std::chrono
On 8/9/19 3:01 AM, Howard Hinnant via Boost wrote:
The pitch: boost::chrono, and other boost::libs needs to defer to std::chrono for C++11 and later. This would make
This should be done with great care. Boost.Asio does exactly this for its timer classes -- use boost::chrono if compiled pre-C++11 and otherwise use std::chrono. As implemented, this is a pain from the users perspective, because the user has to pass a type-strong expiration parameter which can be either, say, std::chrono::seconds or boost::chrono::seconds. This means, that your code that works perfectly suddenly yields compilation errors when your users change the compiler flags. boost::asio::steady_timer timer; timer.expires_from_now(boost::chrono::seconds(5)); // Fails post C++03 The Boost.Asio way is to import all chrono symbols into its own namespace: boost::asio::steady_timer timer; timer.expires_from_now(boost::asio::chrono::seconds(5)); // Okay Another solution is to use the timer template classes, e.g. basic_waitable_timer instead of steady_timer, so the user can work around the problem by selecting whether to use std::chrono or boost::chrono: boost::asio::basic_waitable_timerboost::chrono::steady_clock timer; timer.expires_from_now(boost::chrono::seconds(5)); // Okay PS: I am not arguing for or against the project, nor am I recommending any particular solution. I am just sharing some experience.
The Boost.Asio way is to import all chrono symbols into its own namespace:
boost::asio::steady_timer timer; timer.expires_from_now(boost::asio::chrono::seconds(5)); // Okay
PS: I am not arguing for or against the project, nor am I recommending any particular solution. I am just sharing some experience.
I use the local namespace bind approach in my own libraries. Then people do nialllib::filesystem::path, or whatever. Niall
participants (2)
-
Bjorn Reese
-
Niall Douglas