Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

over-engineering in std::chrono ?

65 views
Skip to first unread message

Thiago Adams

unread,
Dec 18, 2019, 2:05:00 PM12/18/19
to
Who likes the design of std::chrono?
For me, std::chrono is a sample of over-engineering
and too abstractions.

And it is becoming even more complex in C++ 20.
E.g
https://en.cppreference.com/w/cpp/chrono/month_day


Öö Tiib

unread,
Dec 18, 2019, 3:12:05 PM12/18/19
to
Gregorian calendar is a total mess. Few on this planet have implemented
it properly down to single second. Additionally the local time in it is
political decision that changes from year to year. So one needs database
to find out what wall clock did show at time of certain event few
years ago. I guess Boost.Date_Time for example is still defective. It
sure was when I last tried it out of boredom.

The chrono just tries to make Gregorian calendar a bit less pain to
use but grisly aspects of it are still there. Also it likely does
not link stuff that you don't use into your program (unlike
Boost.Date_Time did).

Cholo Lennon

unread,
Dec 18, 2019, 10:10:57 PM12/18/19
to
Here is the rational (for all of them who didn't watch it):

Opening Keynote Meeting C++ 2019 - Howard Hinnant - Design Rationale for
the chrono Library
https://youtu.be/adSAN282YIw?list=WL

Regards

--
Cholo Lennon
Bs.As.
ARG

Thiago Adams

unread,
Dec 19, 2019, 7:19:18 AM12/19/19
to
I think some design decisions, like automatic conversions ms->h etc,
have a consequence and everything must be a type.

I prefer to think about day as just a number. The only think
we need to think about is to check the range if it starts with
0 or 1 for instance.

I believe 99% of the time what we need is something very basic
and conversions between different time formats.




bol...@nowhere.co.uk

unread,
Dec 19, 2019, 11:31:20 AM12/19/19
to
Another wheel reinvention. Perhaps they should have just incorporated the
Posix time API into C++ so Windows users could have a decent API instead of
creating an entirely new one. The only reason for this library existing is
cross platform development as per the threading library (which is still less
comprehensive than pthreads).

Thiago Adams

unread,
Dec 27, 2019, 8:13:04 AM12/27/19
to
On Thursday, December 19, 2019 at 12:10:57 AM UTC-3, Cholo Lennon wrote:
In my view the valuable part is here:

http://howardhinnant.github.io/date_algorithms.html

Algorithms, tests and reasoning.
Very good reference.



0 new messages