Скажите, что курили в комитете по С++ и как можно сделать кроссплатформенный timestamp с наносекундной точностью? Такого бреда, как в интерфейсе std::chrono я не видел уже давно.

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

C>Скажите, что курили в комитете по С++ и как можно сделать кроссплатформенный timestamp с наносекундной точностью? Такого бреда, как в интерфейсе std::chrono я не видел уже давно.

Я тоже не раскурил std::chrono. Когда нужен timestamp, использую boost::posix_time. Там есть наносекунды, не смотря на название. Но они задизаблены по-умолчанию: https://stackoverflow.com/questions/37654384/using-nanoseconds-with-boostposix-time
PS: Мне лично хватало микросекунд.

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

C>Скажите, что курили в комитете по С++ и
Иногда они всякое покуривают...

C>как можно сделать кроссплатформенный timestamp с наносекундной точностью?
А в каком месте "комитет по С++" обязал всех делать именно "timestamp с наносекундной точностью"?

C>Такого бреда, как в интерфейсе std::chrono я не видел уже давно.
Подозрительно звучит.. Оно появилось 10 лет назад

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

C>Скажите, что курили в комитете по С++ и как можно сделать кроссплатформенный timestamp с наносекундной точностью? Такого бреда, как в интерфейсе std::chrono я не видел уже давно.

Курили они, видимо, POSIX и SUS, главу про clock_gettime(). Они всегда их курят, там страниц много, на всех хватит.

С чего ты взял, что они требуют наносекундную точность? Я бы предположил, что там имеется ввиду не точность, а resolution.

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

C>Скажите, что курили в комитете по С++ и как можно сделать кроссплатформенный timestamp с наносекундной точностью? Такого бреда, как в интерфейсе std::chrono я не видел уже давно.

Вижу противоречие между "кроссплатформенный" и "наносекундой точностью". Емнип, в Windows это до сих минимальное разрешение 100 нс, и сомневаюсь, что Linux на х86 может выдавать сильно точнее. На RDTSCP надежды нет — может плавать в виртуальной машине.

А std::chrono, на мой взгляд, хорошо спроектирован — типобезопасно, расширяемо, с нулевым оверхедом. Только вот с high_resolution_clock оплошность вышла:

The high_resolution_clock is not implemented consistently across different standard library implementations, and its use should be avoided. It is often just an alias for std::chrono::steady_clock or std::chrono::system_clock, but which one it is depends on the library or configuration. When it is a system_clock, it is not monotonic (e.g., the time can go backwards). For example, for gcc's libstdc++ it is system_clock, for MSVC it is steady_clock, and for clang's libc++ it depends on configuration.

Generally one should just use std::chrono::steady_clock or std::chrono::system_clock directly instead of std::chrono::high_resolution_clock: use steady_clock for duration measurements, and system_clock for wall-clock time.

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

C>>Скажите, что курили в комитете по С++ и как можно сделать кроссплатформенный timestamp с наносекундной точностью? Такого бреда, как в интерфейсе std::chrono я не видел уже давно.
Pzz>Курили они, видимо, POSIX и SUS, главу про clock_gettime(). Они всегда их курят, там страниц много, на всех хватит.
clock_gettime() — это верх разума. Он возвращает простую структуру с двумя полями: секундами и наносекундами. На всех системах. А вот физическая точность возвращаемого результата уже зависит от ОС.

Pzz>С чего ты взял, что они требуют наносекундную точность? Я бы предположил, что там имеется ввиду не точность, а resolution.
Понятно, что реальной наносекундной точности не будет. Но мне нужна точность/разрешение менее микросекунды.

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

C>>Скажите, что курили в комитете по С++ и как можно сделать кроссплатформенный timestamp с наносекундной точностью? Такого бреда, как в интерфейсе std::chrono я не видел уже давно.
PM>Вижу противоречие между "кроссплатформенный" и "наносекундой точностью". Емнип, в Windows это до сих минимальное разрешение 100 нс, и сомневаюсь, что Linux на х86 может выдавать сильно точнее. На RDTSCP надежды нет — может плавать в виртуальной машине.
Проблема в том, что на macOS дефолтная реализация std::chrono::system_clock::now — микросекундная. В Линуксе — наносекундная. И system_clock::now — единственный способ получить время "часов на стене".

Ну ладно, можно наколхозить обёртку. И ещё одну, чтобы не писать две строчки кода для перевода в unix-формат.

PM>А std::chrono, на мой взгляд, хорошо спроектирован — типобезопасно, расширяемо, с нулевым оверхедом. Только вот с high_resolution_clock оплошность вышла:
Спроектирован, кстати, он тоже из рук вон плохо. Например, при переводе из миллисекунд в наносекунды (std::duration_cast) теряется диапазон, так как наносекунды представляют даты от 1677 до 2262. Даты вне этого диапазона вполне могут встречаться в практических применениях, так что std::chrono непригоден для универсального представления отметок времени.

Классического представления из 64 бит для секунд и 32 бит для наносекунд достаточно для диапазона в две сотни миллиардов лет.

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

PM>>А std::chrono, на мой взгляд, хорошо спроектирован — типобезопасно, расширяемо, с нулевым оверхедом. Только вот с high_resolution_clock оплошность вышла:
C>Спроектирован, кстати, он тоже из рук вон плохо. Например, при переводе из миллисекунд в наносекунды (std::duration_cast) теряется диапазон, так как наносекунды представляют даты от 1677 до 2262. Даты вне этого диапазона вполне могут встречаться в практических применениях, так что std::chrono непригоден для универсального представления отметок времени.

Смешались в кучу кони люди.. Возьми более вместительный тип для счетчика, и будет для твоей практики приятно, все даты из практических применений поместятся.

using MyDur = std::chrono::duration<__int128, std::nano>;
MyDur ns = std::chrono::duration_cast<MyDur>(std::chrono::system_clock::now().time_since_epoch());

Либо не пользуй наносекунды, возьми что нибудь менее детальное, больше места останется для дат.

using MyDur = std::chrono::duration<long long, std::milli>;
MyDur ms = std::chrono::duration_cast<MyDur>(std::chrono::system_clock::now().time_since_epoch());

Либо возьми под счетчик экспоненциальные числа, на больших датах просто точность будет меньше, зато их дофига влезет.

using MyDur = std::chrono::duration<double, std::nano>;
MyDur ns = std::chrono::duration_cast<MyDur>(std::chrono::system_clock::now().time_since_epoch());

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

C>>>Скажите, что курили в комитете по С++ и как можно сделать кроссплатформенный timestamp с наносекундной точностью? Такого бреда, как в интерфейсе std::chrono я не видел уже давно.
PM>>Вижу противоречие между "кроссплатформенный" и "наносекундой точностью". Емнип, в Windows это до сих минимальное разрешение 100 нс, и сомневаюсь, что Linux на х86 может выдавать сильно точнее. На RDTSCP надежды нет — может плавать в виртуальной машине.
C>Проблема в том, что на macOS дефолтная реализация std::chrono::system_clock::now — микросекундная. В Линуксе — наносекундная. И system_clock::now — единственный способ получить время "часов на стене".

C>Ну ладно, можно наколхозить обёртку. И ещё одну, чтобы не писать две строчки кода для перевода в unix-формат.

Все равно непонятно, как из микросекундного ограничения system_clock на MacOS платформе следует бред в библиотеке std::chrono.
Может быть на основе какой-нибудь mach_absolute_time() удастся сделать совместимый с std::chrono::system_clock

struct mac_nano_clock
{
    using duration = std::chrono::nanosecond;
    using time_point = std::chrono::time_point<mac_nano_clock, duration>;
    static time_point now() { .. return mach_absolute_time(); }
};

PM>>А std::chrono, на мой взгляд, хорошо спроектирован — типобезопасно, расширяемо, с нулевым оверхедом. Только вот с high_resolution_clock оплошность вышла:
C>Спроектирован, кстати, он тоже из рук вон плохо. Например, при переводе из миллисекунд в наносекунды (std::duration_cast) теряется диапазон, так как наносекунды представляют даты от 1677 до 2262. Даты вне этого диапазона вполне могут встречаться в практических применениях, так что std::chrono непригоден для универсального представления отметок времени.

C>Классического представления из 64 бит для секунд и 32 бит для наносекунд достаточно для диапазона в две сотни миллиардов лет.

Это же C++, тут все понимают что диапазон значений ограничен. Никто не ожидает, что вычисление INT_MAX — INT_MIN даст верный результат. Хотите универсальности, попробуйте `my_universum_duration = std::duration<int4096_t, std::yocto>`

:
C>Спроектирован, кстати, он тоже из рук вон плохо. Например, при переводе из миллисекунд в наносекунды (std::duration_cast) теряется диапазон, так как наносекунды представляют даты от 1677 до 2262. Даты вне этого диапазона вполне могут встречаться в практических применениях, так что std::chrono непригоден для универсального представления отметок времени.

Это ты где прочел?

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

C>Скажите, что курили в комитете по С++ и как можно сделать кроссплатформенный timestamp с наносекундной точностью? Такого бреда, как в интерфейсе std::chrono я не видел уже давно.

Комитет, как известно, это такое место, где попросишь сконструировать лошадь — тебе сделают верблюда на курногах.

C++ это касается не меньше.

Видимо, несмотря на комментарии типа "потребности в колбасе нет" (как у vopl), действительно под полные хотелки нужен int128_t, иначе в одно значение всё не поместится.
Ну или таки парой чисел с собственной арифметикой.

Вот что при всём при этом хорошо в C++ — что после того, как это напишешь, результат получится достаточно эффективным (например — деление на константу, где оно нужно, захардкодится оптимально для процессора).

Меня у chrono больше удручала многословность с кучей всяких промежуточных duration_cast — после Unix выглядит странно.

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

v> using MyDur = std::chrono::duration<__int128, std::nano>;
v> using MyDur = std::chrono::duration<long long, std::milli>;
Мде... Стандартизовали, стандартизовали, да невыстандартизовали. Для переносимого кода опять приходится использовать либо нестандартные расширения, либо иметь разные результаты на разных платформах.

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

Pzz>>Курили они, видимо, POSIX и SUS, главу про clock_gettime(). Они всегда их курят, там страниц много, на всех хватит.
C>clock_gettime() — это верх разума. Он возвращает простую структуру с двумя полями: секундами и наносекундами. На всех системах. А вот физическая точность возвращаемого результата уже зависит от ОС.

Верхом разума он был бы, если бы возвращал один int64_t.

Pzz>>С чего ты взял, что они требуют наносекундную точность? Я бы предположил, что там имеется ввиду не точность, а resolution.
C>Понятно, что реальной наносекундной точности не будет. Но мне нужна точность/разрешение менее микросекунды.

Ну это же от платформы зависит, а не от языка.

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

C>Скажите, что курили в комитете по С++ и как можно сделать кроссплатформенный timestamp с наносекундной точностью? Такого бреда, как в интерфейсе std::chrono я не видел уже давно.

Так-то не пох?

Для риалтайма у всех свои велики давно

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

Pzz>>>Курили они, видимо, POSIX и SUS, главу про clock_gettime(). Они всегда их курят, там страниц много, на всех хватит.
C>>clock_gettime() — это верх разума. Он возвращает простую структуру с двумя полями: секундами и наносекундами. На всех системах. А вот физическая точность возвращаемого результата уже зависит от ОС.

Pzz>Верхом разума он был бы, если бы возвращал один int64_t.

Если наносекунды, это на 500 лет (584.5).
Ну, конечно, хватит до следующего изменения интерфейса... хотя вспоминается анекдот про 9998 год и программиста на Коболе.
Но и пересчитывать тогда в unixtime сложно.
clock_gettime как раз оптимален тем, что целая часть — уже устоявшийся unixtime, а дробная — наносекунды. Не надо ничего сложно калькулировать.


Pzz>>>С чего ты взял, что они требуют наносекундную точность? Я бы предположил, что там имеется ввиду не точность, а resolution.
C>>Понятно, что реальной наносекундной точности не будет. Но мне нужна точность/разрешение менее микросекунды.
Pzz>Ну это же от платформы зависит, а не от языка.

Сейчас почти любая это позволяет.

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

N>Если наносекунды, это на 500 лет (584.5).
N>Ну, конечно, хватит до следующего изменения интерфейса... хотя вспоминается анекдот про 9998 год и программиста на Коболе.

Надеюсь, Кобол еще 500 лет не проживет

N>clock_gettime как раз оптимален тем, что целая часть — уже устоявшийся unixtime, а дробная — наносекунды. Не надо ничего сложно калькулировать.

Ну поделить вроде не сложно...

Время в виде структуры очень неудобно для вычисления временных интервалов (сколько прошло времени от T1 до T2). И сравнивать их на больше/меньше тоже не слишком удобно.

Pzz>>>>С чего ты взял, что они требуют наносекундную точность? Я бы предположил, что там имеется ввиду не точность, а resolution.
C>>>Понятно, что реальной наносекундной точности не будет. Но мне нужна точность/разрешение менее микросекунды.
Pzz>>Ну это же от платформы зависит, а не от языка.

N>Сейчас почти любая это позволяет.

Я думаю, на большинстве платформ C++'ное время будет иметь такую же точность, как платформенное.

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

N>>Если наносекунды, это на 500 лет (584.5).
N>>Ну, конечно, хватит до следующего изменения интерфейса... хотя вспоминается анекдот про 9998 год и программиста на Коболе.
Pzz>Надеюсь, Кобол еще 500 лет не проживет

А Unix?

N>>clock_gettime как раз оптимален тем, что целая часть — уже устоявшийся unixtime, а дробная — наносекунды. Не надо ничего сложно калькулировать.
Pzz>Ну поделить вроде не сложно...

Ну ещё надо было ввести соответствующие функции пересчёта в стандарт.
Видимо, не захотели.

Pzz>Я думаю, на большинстве платформ C++'ное время будет иметь такую же точность, как платформенное.

Если не загрубить явно.

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

N>>>Ну, конечно, хватит до следующего изменения интерфейса... хотя вспоминается анекдот про 9998 год и программиста на Коболе.
Pzz>>Надеюсь, Кобол еще 500 лет не проживет

N>А Unix?

Я думаю, за 500 лет само понятие компьютера изменится до неузнаваемости. А UNIX займет весьма почетное место в археологическом музее.

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

C>>Спроектирован, кстати, он тоже из рук вон плохо. Например, при переводе из миллисекунд в наносекунды (std::duration_cast) теряется диапазон, так как наносекунды представляют даты от 1677 до 2262. Даты вне этого диапазона вполне могут встречаться в практических применениях, так что std::chrono непригоден для универсального представления отметок времени.
V>Это ты где прочел?
Ээээ.... 2^64 наносекунд — это 548 лет.

1970 — (548/2) = 1696, ну да, чуть промахнулся.

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

Pzz>Время в виде структуры очень неудобно для вычисления временных интервалов (сколько прошло времени от T1 до T2). И сравнивать их на больше/меньше тоже не слишком удобно.
А что там сложного-то? Просто сравнить оба поля. Временные интервалы — вычесть оба поля с переносом.

Pzz>>>Ну это же от платформы зависит, а не от языка.
N>>Сейчас почти любая это позволяет.
Pzz>Я думаю, на большинстве платформ C++'ное время будет иметь такую же точность, как платформенное.
Да, но интерфейс везде разный.