Здравствуйте, _NN_, Вы писали:
_NN>У всего есть достоинства и недостатки. _NN>Я бы не сказал, что стандартная библиотека эталон качества кода. _NN>Количество банальнейших багов там не так мало.
Проблема не в качестве, а в поддержке. Стандартная библиотека будет поддерживаться вечно, а вот сторонние библиотеки могут в какой-то момент просто перестать обновляться.
Потому при добавлении библиотеки в проект всегда надо этот риск учитывать. Т.е. если библиотека делается автором-одиночкой, то нужно быть готовым перехватить её поддержку.
C>>Ради форматирования, которое в других языках есть в стандартной библиотеке (поддерживаемой авторами языка). _NN>Это другое дело. _NN>Осталось предложение в стандарт внести.
Я не очень понимаю что они там делают, если сами догадаться не могут.
Здравствуйте, Cyberax, Вы писали:
C>Задача простая — есть электронная таблица, где есть тип "отметка времени". Туда пользователи могут добавлять любые даты из разумного диапазона. Это могут быть как исторические даты (скажем, даты начала и конца войн), так и данные с наносекундной точностью (скажем, результаты профилирования кода). Для всех дат надо поддерживать арифметику, стандартные операции и т.п. C>Так что неплохо бы иметь тип данных, который поддерживал бы все требования.
Так у тебя это в принципе не получится одним числом, можешь и не пытаться.
До нынешних часовых поясов время было своё в каждом городе, около астрономического => тебе надо представлять "10:30:00 по Хох-Торгау, которое 10:36:40 по GMT+1".
Замена юлианского календаря на григорианский в разных странах шла по-разному — и тебе надо представлять дату, как она принята, и в современном счёте.
Наконец, для древнего Египта есть три возможных хронологии, по сравнению с описанными небесными явлениями, которые отличаются для самых древних дат на сотни лет. События выверены в рамках хронологии до уровня общего консенсуса, но даты приводятся по какой-то одной хронологии; большинство выступают за "короткую", но консенсуса всё ещё нет. Будешь его описывать — тебе потребуется отдельный тип данных "древнеегипетская дата" и уточнения на ограничение условий пересчёта.
Здравствуйте, Cyberax, Вы писали:
C>Задача простая — есть электронная таблица, где есть тип "отметка времени". Туда пользователи могут добавлять любые даты из разумного диапазона. Это могут быть как исторические даты (скажем, даты начала и конца войн), так и данные с наносекундной точностью (скажем, результаты профилирования кода). Для всех дат надо поддерживать арифметику, стандартные операции и т.п.
это точно хорошая идея, все в одну кучу сваливать?
Здравствуйте, night beast, Вы писали:
C>>Задача простая — есть электронная таблица, где есть тип "отметка времени". Туда пользователи могут добавлять любые даты из разумного диапазона. Это могут быть как исторические даты (скажем, даты начала и конца войн), так и данные с наносекундной точностью (скажем, результаты профилирования кода). Для всех дат надо поддерживать арифметику, стандартные операции и т.п. NB>это точно хорошая идея, все в одну кучу сваливать?
Если можно без сильных проблем, то почему нет? В противном случае, нужно вводить разные типы данных и запутывать пользователей.
Здравствуйте, Cyberax, Вы писали:
C>>>Задача простая — есть электронная таблица, где есть тип "отметка времени". Туда пользователи могут добавлять любые даты из разумного диапазона. Это могут быть как исторические даты (скажем, даты начала и конца войн), так и данные с наносекундной точностью (скажем, результаты профилирования кода). Для всех дат надо поддерживать арифметику, стандартные операции и т.п. NB>>это точно хорошая идея, все в одну кучу сваливать? C>Если можно без сильных проблем, то почему нет? В противном случае, нужно вводить разные типы данных и запутывать пользователей.
не знаю специфику, но почему-то кажется, что разные типы данных все равно есть.
еще один не должен кардинально изменить ситуацию.
зато не теряется информация, которая может быть использована для специфической для этого типа обработки.
Здравствуйте, Cyberax, Вы писали:
C>Скажите, ну вот какой пиииииии в комитете не догадался сделать так, чтобы часы можно было вызывать через виртуальный метод?!?
Это ещё ерунда. А вот то, что авторы не догадались ввести объект std::chrono::zero — вот это абсурд достойный Рима незнавшего нуля. Вот как сравнить std::chrono::duration с нулём?
Или я туплю или округлить разницу двух time точек до секунд? в рамках С++14 задача не тривиальная:
Не, я понимаю, что вместо zero < diff_time можно написать time1 > time2, но это усложнение на ровном месте. И вообще, как можно было написать duration_cast, а с round тормозить 6 лет?
Здравствуйте, B0FEE664, Вы писали:
BFE>Это ещё ерунда. А вот то, что авторы не догадались ввести объект std::chrono::zero — вот это абсурд достойный Рина незнавшего нуля. Вот как сравнить std::chrono::duration с нулём?
Ну так duration, сконструированный по умолчанию, это он и есть
BFE>Или я туплю или округлить разницу двух time точек до секунд? в рамках С++14 задача не тривиальная:
Если и нетривиальная, то только потому, что для общего случая нельзя сказать, что правильнее: сначала вычесть, потом округлить, или сначала округлить, потом вычесть.
Здравствуйте, B0FEE664, Вы писали:
BFE>Это ещё ерунда. А вот то, что авторы не догадались ввести объект std::chrono::zero — вот это абсурд достойный Рина незнавшего нуля. Вот как сравнить std::chrono::duration с нулём?
Здравствуйте, rg45, Вы писали:
BFE>>Это ещё ерунда. А вот то, что авторы не догадались ввести объект std::chrono::zero — вот это абсурд достойный Рина незнавшего нуля. Вот как сравнить std::chrono::duration с нулём?
R>Алле-оп! R>https://en.cppreference.com/w/cpp/chrono/duration/zero
Почему значение 0 зависит от Rep и Period ?:
std::chrono::duration<Rep,Period>::zero()
И как этим пользоваться?
const auto diff_time = time1 - time2;
if ( diff_time.zero() < diff_time )
{
}
Так?
if ( decltype(diff_time)::zero() < diff_time )
{
}
Или так?
Или, может быть, так, с указанием типа для тиков:
if ( std::chrono::duration<std::chrono::seconds::rep>::zero() < diff_time )
{
}
Или просто сравниваем с точностью до секунды?:
if ( std::chrono::seconds::zero() < diff_time )
{
}
Ведь если так сделано, то наверное не просто так, наверное сравнение diff_time с std::chrono::seconds::zero() и с std::chrono::milliseconds::zero() должно чем-то различаться? Иначе какой в этом смысл?
Здравствуйте, B0FEE664, Вы писали:
BFE> BFE>Почему значение 0 зависит от Rep и Period ?: BFE>И как этим пользоваться?
Я вообще не понимаю, зачем он нужен в таком виде. Насколько я могу судить, он просто конструирует объект duration по умолчанию и выражение duration<T,U>::zero() эквивалентно выражению duration<T,U>(). Кому нужен этот синтаксический шум, я не понимаю.
Здравствуйте, B0FEE664, Вы писали: BFE>Здравствуйте, rg45, Вы писали: BFE>>>Это ещё ерунда. А вот то, что авторы не догадались ввести объект std::chrono::zero — вот это абсурд достойный Рина незнавшего нуля. Вот как сравнить std::chrono::duration с нулём?
Строгая тизпизация — это хорошо, в C++ и так слишком много неявных нулей: Is Zero a Butterfly?
TLDR
Можно сравнивать со значением, сконструированным из литерала, например 0s:
#include <chrono>
int main()
{
using namespace std::literals::chrono_literals;
const auto d = 3s;
const bool b1 = (d > 0s);
const bool b2 = (d == 0ns);
}
BFE>Ведь если так сделано, то наверное не просто так, наверное сравнение diff_time с std::chrono::seconds::zero() и с std::chrono::milliseconds::zero() должно чем-то различаться? Иначе какой в этом смысл?
Это же C++, можно любым из указанных выше и наверно еще несколькими более странными, про которые автор chrono и подумать не мог. Лишь бы отловить попытку сравнения яблок с апельсинами на этапе компиляции.
Здравствуйте, PM, Вы писали:
PM>Строгая тизпизация — это хорошо, в C++ и так слишком много неявных нулей: Is Zero a Butterfly?
Разве я предлагаю добавить ещё один неявный нуль? Нет. Я предлагаю добавить zero с таким типом, который понимают все std::chrono::duration. Как nullptr для всех типов указателей, так std::chrono::duration::zero для всех типов std::chrono::duration. Вот в статье не смогли привести ни одного проблемного места с nullptr — это потому, что nullptr — это строготипизированный ноль.
Здравствуйте, B0FEE664, Вы писали:
BFE>Разве я предлагаю добавить ещё один неявный нуль? Нет. Я предлагаю добавить zero с таким типом, который понимают все std::chrono::duration. Как nullptr для всех типов указателей, так std::chrono::duration::zero для всех типов std::chrono::duration. Вот в статье не смогли привести ни одного проблемного места с nullptr — это потому, что nullptr — это строготипизированный ноль.
Здравствуйте, B0FEE664, Вы писали:
PM>>Строгая тизпизация — это хорошо, в C++ и так слишком много неявных нулей: Is Zero a Butterfly?
BFE>Разве я предлагаю добавить ещё один неявный нуль? Нет. Я предлагаю добавить zero с таким типом, который понимают все std::chrono::duration. Как nullptr для всех типов указателей, так std::chrono::duration::zero для всех типов std::chrono::duration. Вот в статье не смогли привести ни одного проблемного места с nullptr — это потому, что nullptr — это строготипизированный ноль.
Окей, пишите предложение в комитет языка, проталкивайте какой-нибудь chrono::duration_base::zero. Вдруг увидим это в C++ лет через 15.
Здравствуйте, PM, Вы писали:
PM>Окей, пишите предложение в комитет языка, проталкивайте какой-нибудь chrono::duration_base::zero. Вдруг увидим это в C++ лет через 15. PM>А я пока буду писать код сравнения с 0s.
А чё, так можно было?
