Re[4]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 30.12.20 08:15
Оценка:
Здравствуйте, _NN_, Вы писали:

_NN>У всего есть достоинства и недостатки.

_NN>Я бы не сказал, что стандартная библиотека эталон качества кода.
_NN>Количество банальнейших багов там не так мало.
Проблема не в качестве, а в поддержке. Стандартная библиотека будет поддерживаться вечно, а вот сторонние библиотеки могут в какой-то момент просто перестать обновляться.

Потому при добавлении библиотеки в проект всегда надо этот риск учитывать. Т.е. если библиотека делается автором-одиночкой, то нужно быть готовым перехватить её поддержку.

C>>Ради форматирования, которое в других языках есть в стандартной библиотеке (поддерживаемой авторами языка).

_NN>Это другое дело.
_NN>Осталось предложение в стандарт внести.
Я не очень понимаю что они там делают, если сами догадаться не могут.
Sapienti sat!
Re[15]: Ненависть к std::chrono
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 30.12.20 08:28
Оценка: 14 (2)
Здравствуйте, Cyberax, Вы писали:

C>Задача простая — есть электронная таблица, где есть тип "отметка времени". Туда пользователи могут добавлять любые даты из разумного диапазона. Это могут быть как исторические даты (скажем, даты начала и конца войн), так и данные с наносекундной точностью (скажем, результаты профилирования кода). Для всех дат надо поддерживать арифметику, стандартные операции и т.п.

C>Так что неплохо бы иметь тип данных, который поддерживал бы все требования.

Так у тебя это в принципе не получится одним числом, можешь и не пытаться.

До нынешних часовых поясов время было своё в каждом городе, около астрономического => тебе надо представлять "10:30:00 по Хох-Торгау, которое 10:36:40 по GMT+1".

Замена юлианского календаря на григорианский в разных странах шла по-разному — и тебе надо представлять дату, как она принята, и в современном счёте.

Наконец, для древнего Египта есть три возможных хронологии, по сравнению с описанными небесными явлениями, которые отличаются для самых древних дат на сотни лет. События выверены в рамках хронологии до уровня общего консенсуса, но даты приводятся по какой-то одной хронологии; большинство выступают за "короткую", но консенсуса всё ещё нет. Будешь его описывать — тебе потребуется отдельный тип данных "древнеегипетская дата" и уточнения на ограничение условий пересчёта.

Обломись, бабка, мы на корабле ™.
The God is real, unless declared integer.
Re[15]: Ненависть к std::chrono
От: night beast СССР  
Дата: 30.12.20 11:45
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Задача простая — есть электронная таблица, где есть тип "отметка времени". Туда пользователи могут добавлять любые даты из разумного диапазона. Это могут быть как исторические даты (скажем, даты начала и конца войн), так и данные с наносекундной точностью (скажем, результаты профилирования кода). Для всех дат надо поддерживать арифметику, стандартные операции и т.п.


это точно хорошая идея, все в одну кучу сваливать?
Re[16]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 30.12.20 11:59
Оценка:
Здравствуйте, night beast, Вы писали:

C>>Задача простая — есть электронная таблица, где есть тип "отметка времени". Туда пользователи могут добавлять любые даты из разумного диапазона. Это могут быть как исторические даты (скажем, даты начала и конца войн), так и данные с наносекундной точностью (скажем, результаты профилирования кода). Для всех дат надо поддерживать арифметику, стандартные операции и т.п.

NB>это точно хорошая идея, все в одну кучу сваливать?
Если можно без сильных проблем, то почему нет? В противном случае, нужно вводить разные типы данных и запутывать пользователей.
Sapienti sat!
Re[17]: Ненависть к std::chrono
От: night beast СССР  
Дата: 30.12.20 12:09
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>Задача простая — есть электронная таблица, где есть тип "отметка времени". Туда пользователи могут добавлять любые даты из разумного диапазона. Это могут быть как исторические даты (скажем, даты начала и конца войн), так и данные с наносекундной точностью (скажем, результаты профилирования кода). Для всех дат надо поддерживать арифметику, стандартные операции и т.п.

NB>>это точно хорошая идея, все в одну кучу сваливать?
C>Если можно без сильных проблем, то почему нет? В противном случае, нужно вводить разные типы данных и запутывать пользователей.

не знаю специфику, но почему-то кажется, что разные типы данных все равно есть.
еще один не должен кардинально изменить ситуацию.
зато не теряется информация, которая может быть использована для специфической для этого типа обработки.
Re: Ненависть к std::chrono
От: B0FEE664  
Дата: 30.12.20 21:04
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Скажите, ну вот какой пиииииии в комитете не догадался сделать так, чтобы часы можно было вызывать через виртуальный метод?!?


Это ещё ерунда. А вот то, что авторы не догадались ввести объект std::chrono::zero — вот это абсурд достойный Рима незнавшего нуля. Вот как сравнить std::chrono::duration с нулём?

Или я туплю или округлить разницу двух time точек до секунд? в рамках С++14 задача не тривиальная:
   namespace co = std::chrono

   const auto                     diff_time         = time1 - time2;
   const decltype(diff_time)      zero{};
   const co::seconds              diff_seconds      = co::duration_cast<co::seconds>( zero < diff_time ? diff_time + co::microseconds(500)
                                                                                                       : diff_time - co::microseconds(500)
                                                                                    );


Не, я понимаю, что вместо zero < diff_time можно написать time1 > time2, но это усложнение на ровном месте. И вообще, как можно было написать duration_cast, а с round тормозить 6 лет?
И каждый день — без права на ошибку...
Отредактировано 04.01.2021 10:22 B0FEE664 . Предыдущая версия .
Re[2]: Ненависть к std::chrono
От: rg45 СССР  
Дата: 30.12.20 21:17
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Это ещё ерунда. А вот то, что авторы не догадались ввести объект std::chrono::zero — вот это абсурд достойный Рина незнавшего нуля. Вот как сравнить std::chrono::duration с нулём?


Ну так duration, сконструированный по умолчанию, это он и есть

BFE>Или я туплю или округлить разницу двух time точек до секунд? в рамках С++14 задача не тривиальная:


Если и нетривиальная, то только потому, что для общего случая нельзя сказать, что правильнее: сначала вычесть, потом округлить, или сначала округлить, потом вычесть.
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[2]: И кстати! :)
От: rg45 СССР  
Дата: 30.12.20 21:21
Оценка: 1 (1)
Здравствуйте, B0FEE664, Вы писали:

BFE>Это ещё ерунда. А вот то, что авторы не догадались ввести объект std::chrono::zero — вот это абсурд достойный Рина незнавшего нуля. Вот как сравнить std::chrono::duration с нулём?


Алле-оп!
https://en.cppreference.com/w/cpp/chrono/duration/zero
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[3]: И кстати! :)
От: B0FEE664  
Дата: 04.01.21 10:48
Оценка:
Здравствуйте, 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() должно чем-то различаться? Иначе какой в этом смысл?
И каждый день — без права на ошибку...
Re[4]: И кстати! :)
От: rg45 СССР  
Дата: 05.01.21 10:50
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>

BFE>Почему значение 0 зависит от Rep и Period ?:
BFE>И как этим пользоваться?

Я вообще не понимаю, зачем он нужен в таком виде. Насколько я могу судить, он просто конструирует объект duration по умолчанию и выражение duration<T,U>::zero() эквивалентно выражению duration<T,U>(). Кому нужен этот синтаксический шум, я не понимаю.

http://coliru.stacked-crooked.com/a/82fe20506a83cf67
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[4]: И кстати! :)
От: PM  
Дата: 05.01.21 11:10
Оценка:
Здравствуйте, 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);
}


R>>Алле-оп!

R>>https://en.cppreference.com/w/cpp/chrono/duration/zero
BFE>
BFE>Почему значение 0 зависит от Rep и Period ?:
BFE>
BFE>std::chrono::duration<Rep,Period>::zero()
BFE>


Предполагаю, что для облегчения написания шаблонного кода, где Duration может быть любым типом.

BFE>И как этим пользоваться?

BFE>
BFE>const auto diff_time = time1 - time2;
BFE>if ( diff_time.zero() < diff_time )
BFE>{
BFE>}
BFE>

BFE>Так?
BFE>
BFE>if ( decltype(diff_time)::zero() < diff_time )
BFE>{
BFE>}
BFE>

BFE>Или так?
BFE>Или, может быть, так, с указанием типа для тиков:
BFE>
BFE>if ( std::chrono::duration<std::chrono::seconds::rep>::zero() < diff_time )
BFE>{
BFE>}
BFE>


BFE>Или просто сравниваем с точностью до секунды?:

BFE>
BFE>if ( std::chrono::seconds::zero() < diff_time )
BFE>{
BFE>}
BFE>

BFE>Ведь если так сделано, то наверное не просто так, наверное сравнение diff_time с std::chrono::seconds::zero() и с std::chrono::milliseconds::zero() должно чем-то различаться? Иначе какой в этом смысл?


Это же C++, можно любым из указанных выше и наверно еще несколькими более странными, про которые автор chrono и подумать не мог. Лишь бы отловить попытку сравнения яблок с апельсинами на этапе компиляции.
Re[5]: И кстати! :)
От: B0FEE664  
Дата: 05.01.21 12:00
Оценка:
Здравствуйте, PM, Вы писали:

PM>Строгая тизпизация — это хорошо, в C++ и так слишком много неявных нулей: Is Zero a Butterfly?


Разве я предлагаю добавить ещё один неявный нуль? Нет. Я предлагаю добавить zero с таким типом, который понимают все std::chrono::duration. Как nullptr для всех типов указателей, так std::chrono::duration::zero для всех типов std::chrono::duration. Вот в статье не смогли привести ни одного проблемного места с nullptr — это потому, что nullptr — это строготипизированный ноль.
И каждый день — без права на ошибку...
Re[6]: И кстати! :)
От: rg45 СССР  
Дата: 05.01.21 12:12
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Разве я предлагаю добавить ещё один неявный нуль? Нет. Я предлагаю добавить zero с таким типом, который понимают все std::chrono::duration. Как nullptr для всех типов указателей, так std::chrono::duration::zero для всех типов std::chrono::duration. Вот в статье не смогли привести ни одного проблемного места с nullptr — это потому, что nullptr — это строготипизированный ноль.


Если это так принципиально, ты можешь завести в своей внутренней библиотеке нужную тебе константу, по образу и подобию, как заводили nullptr до C++11: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf

Или еще проще:

namespace my {

const std::chrono::duration<int> zero_duration{};

}
--
Не можешь достичь желаемого — пожелай достигнутого.
Отредактировано 05.01.2021 12:20 rg45 . Предыдущая версия . Еще …
Отредактировано 05.01.2021 12:19 rg45 . Предыдущая версия .
Re[6]: И кстати! :)
От: PM  
Дата: 05.01.21 15:23
Оценка: 1 (1)
Здравствуйте, 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.

А я пока буду писать код сравнения с 0s.
Re[7]: И кстати! :)
От: B0FEE664  
Дата: 05.01.21 15:54
Оценка: :))
Здравствуйте, PM, Вы писали:

PM>Окей, пишите предложение в комитет языка, проталкивайте какой-нибудь chrono::duration_base::zero. Вдруг увидим это в C++ лет через 15.

PM>А я пока буду писать код сравнения с 0s.
А чё, так можно было?
И каждый день — без права на ошибку...
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.