Здравствуйте, ononim, Вы писали:

N>>"duration не нужен" — это, как говорят автомобилисты, до первого столба, когда у тебя вдруг где-то образуется 4050 год потому, что неправильно применены объекты на сложение, или 1 год вдруг преобразовался к юлианскому календарю и сократился на 10 дней потому, что вычитание.
O>duration как самостоятельный объект — ок (хотя название конечно опять же — period было бы читабельнее и писабельнее), а вот duration в качестве скоупа для seconds — лишнее. Создается впечатление что писатели STL забыли что они пишут не код для самих себя, а бибилиотеку для людей, которым вобщемто начхать на ее внутренности.

Вопрос дискретности представления временны́х параметров вообще-то существенный. Параметризовать, например, секундами и наносекундами — совершенно разный результат по цене. Особенно это было важно при создании библиотеки, да и сейчас — на 32-битной платформе оперировать 64-битными целыми сложно, а если потребуется ещё толще — тем более.
"Скоуп" в моей записи был не прямо из chrono, там дискрет представления — параметр шаблона.

O>UPD: мне тут написали

Автор: ·
Дата: 04.02.25

что есть есть и альяс std::chrono::seconds ну чтож, вот она, борьба бобра с ослом в пределах отдельно взятого комитета. Еслиб они документировали в первую очередь понятные альясы, а многоэтажные оставляли для внутреннего пользования — мир был бы чуточку лучше.

До определённой степени так и есть.

std::chrono::seconds(C++11) duration type with Period std::ratio<1>

O>>> но к сожалению с hash_map это не прокатило, трындючие ящики таки утрындели приверженцев здравого смысла.
N>>cppreference.com переадресовывает hash_map в unordered_map. Ты что имел в виду?
O>Я имел ввиду то, что hash_map вначале появился в бусте. И shared_ptr вначале появился в бусте, но при принятии в стандарт — наименование первого показалось черезчур коротким некоторым любителям длинный речей. А shared_ptr повезло больше.
O>Верните в комитет прагматиков, которые придумали названия std::map, std::set, std::iota, std::cerr и уберите любителей потрындеть. Изза них плюсы сильно отрываются от реальных проблем. Нейминг — это лишь одна и наиболее очевидная грань этой проблемы.

К unordered_map у меня другие претензии, посерьёзнее, чем просто именование. По-нормальному это должен был быть концепт, лишённый всех специфических граблей типа перебора корзин.
Стандартизация того, что корзины 1) есть, 2) их только один набор — очень жёстко зажимает реализацию до closed addressing hash map с рывочной пересборкой. По эффективности получается амортизированное O(1), но не стабильное O(1), как было раньше в Dinkumware и вслед Microsoft STL. А это значит, что критичные к постоянству времени приложения не могут его использовать.