Software Design Patterns Are Not Goals, They Are Tools

Re:Software Design Patterns Are Not Goals, They Are Tools by gpderetta on Thursday May 19, 2016 @08:52AM (#11729733)

That's honestly sounds like FUD. The Boost community has rejected OO design and abstractions from the very beginning embracing the STL design instead.

Dates and times is a complex problem, you won't find a simple solution for it. For the record boost.date_time ony has concrete classes and no abstractions. It barely uses templates.

"Then I've discovered that Google at that time forbade developers using the whole boost"

Their loss.

[ Parent | on HN ]

Re:Software Design Patterns Are Not Goals, They Are Tools by acqq on Thursday May 19, 2016 @09:08AM (#11729840)

I haven't checked recently, at that time the classes didn't support the historical time zone calculations. I've looked at a lot of code (yes, they were not hierarchical classes, but there was a lot of code) but there were really only the most trivial things supported.

And I admit, I never liked Boost, I am biased. But that doesn't mean that I'm misrepresenting how little what it had matched my needs, and the "bloat" feeling I've (and obviously Google too then) had.

[ Parent | on HN ]

Re:Software Design Patterns Are Not Goals, They Are Tools by gpderetta on Thursday May 19, 2016 @09:26AM (#11729982)

Not sure what you mean by historical time zones. If you are referring to DST rules, boost.Date_Time released in Boost 1.34, which was released almost 10 years ago has a member function dst_local_start_time(year) for a time_zone object which returns 'The date and time daylight savings time begins in given year'.

The doc links for older releases seem to be broken on boost.org, so I can't check if the functionality is even older.

[ Parent | on HN ]