Здравствуйте, vopl, Вы писали:
V>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд. V>Всё, вопрос закрыт. Этот код решает проблемы потому что тоже самое, да еще и практический диапазон (9999AD до 9999BC). V>
Я понял. Вы из этого комитета.
Здравствуйте, vopl, Вы писали:
C>>https://docs.microsoft.com/en-us/dotnet/api/system.datetime.ticks?view=net-5.0 — разрешение 100 наносекунд, диапазон в 50 тысяч лет. V>То есть, наносекундной точности нет и диапазона в 200 миллиардов лет тоже нет. То есть, Сишарп не предоставляет "правильную работу с датами". Выписываем Сишарпу ненависть?
100нс — достаточная для большинства практических целей точность, так что нет. Диапазон тоже достаточен.
С# далеко до маразма С++ (и защищающих его!), который ОДНОВРЕМЕННО умудрился потерять гарантии по диапазону значений и точности. Стандартный комитет, видимо, очень долго работал над этим достижением. Но им это удалось!
Здравствуйте, Cyberax, Вы писали:
C>Задача простая — есть электронная таблица, где есть тип "отметка времени". Туда пользователи могут добавлять любые даты из разумного диапазона. Это могут быть как исторические даты (скажем, даты начала и конца войн), так и данные с наносекундной точностью (скажем, результаты профилирования кода). Для всех дат надо поддерживать арифметику, стандартные операции и т.п. C>Так что неплохо бы иметь тип данных, который поддерживал бы все требования.
Так у тебя это в принципе не получится одним числом, можешь и не пытаться.
До нынешних часовых поясов время было своё в каждом городе, около астрономического => тебе надо представлять "10:30:00 по Хох-Торгау, которое 10:36:40 по GMT+1".
Замена юлианского календаря на григорианский в разных странах шла по-разному — и тебе надо представлять дату, как она принята, и в современном счёте.
Наконец, для древнего Египта есть три возможных хронологии, по сравнению с описанными небесными явлениями, которые отличаются для самых древних дат на сотни лет. События выверены в рамках хронологии до уровня общего консенсуса, но даты приводятся по какой-то одной хронологии; большинство выступают за "короткую", но консенсуса всё ещё нет. Будешь его описывать — тебе потребуется отдельный тип данных "древнеегипетская дата" и уточнения на ограничение условий пересчёта.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vopl, Вы писали:
C>>>Скажите, ну вот какой пиииииии в комитете не догадался сделать так, чтобы часы можно было вызывать через виртуальный метод?!? V>>У разных часов разные временные пространства. Чтобы их оформить виртуальными методами — надо иметь некое общее пространство времени. Такового не придумали... А предложи интерфейс часов с виртуальными методами, как бы это могло выглядеть на твой взгляд? C>Вот так: C>
C>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
Ну, если вопрос закрыт, то круто, конечно . Все мосты к обсуждению, насколько я понял, отрезаны, сопротивление бесполезно ... А зачем это пихать в стандарт? Сделай себе свой clock_t&Co. и пользуй на здоровье?
Здравствуйте, vopl, Вы писали:
C>>В Go — наносекунды (а timestamp — просто псевдоним для int64). Это плохое решение, так как теряет диапазон. Но хорошее с практической точки зрения — API очень простой (можно делать так "time.Add(10*time.Second)"). V>То есть, в Go та же самая сетка времени что и в плюсном chrono::nanoseconds с 64-битным счетчиком. Выписываем ему ненависть?
Вот так выглядит печать времени с наносекундами в Go:
Метод формата даты — вообще гениален. Единственный минус — неудачно выбранная эталонная дата.
А теперь то же самое для C++:
#include <iostream>
#include <sstream>
#include <chrono>
#include <iomanip>
int main()
{
auto now = std::chrono::system_clock::now();
auto epoch_seconds = std::chrono::system_clock::to_time_t(now);
std::stringstream stream;
stream << std::put_time(gmtime(&epoch_seconds), "%FT%T");
auto truncated = std::chrono::system_clock::from_time_t(epoch_seconds);
auto delta_ns = std::chrono::duration_cast<std::chrono::nanoseconds>(now - truncated).count();
// And append this to the output stream as fractional seconds
// e.g. 2016-08-30T08:18:51.867479
stream << "." << std::fixed << std::setw(9) << std::setfill('0') << delta_ns;
std::cout << stream.str() << std::endl;
}
Кретиноиды из комитета добавили возможность печати даты в китайских символах (四十五 вместо 45), но не додумались добавить формат для наносекунд. Да что там, они даже для миллисекунд формат не добавили.
Здравствуйте, AeroSun, Вы писали:
AS>GC: кроме того на какой форум не заглянь — везде про chrono куча вопросов (элементарных/житейских) — это явный признак плохой библиотеки.
Здравствуйте, PM, Вы писали:
PM>Окей, пишите предложение в комитет языка, проталкивайте какой-нибудь chrono::duration_base::zero. Вдруг увидим это в C++ лет через 15. PM>А я пока буду писать код сравнения с 0s.
А чё, так можно было?
Здравствуйте, B0FEE664, Вы писали:
BFE>Это ещё ерунда. А вот то, что авторы не догадались ввести объект std::chrono::zero — вот это абсурд достойный Рина незнавшего нуля. Вот как сравнить std::chrono::duration с нулём?
Здравствуйте, 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.
Здравствуйте, vopl, Вы писали:
C>>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков. V>Покажи, где в Go 200 миллиардов лет? Было бы справедливо к Go тоже организовать ненависть?
В Go — наносекунды (а timestamp — просто псевдоним для int64). Это плохое решение, так как теряет диапазон. Но хорошее с практической точки зрения — API очень простой (можно делать так "time.Add(10*time.Second)").
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vopl, Вы писали:
C>>>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков. V>>Покажи, где в Go 200 миллиардов лет? Было бы справедливо к Go тоже организовать ненависть? C>В Go — наносекунды (а timestamp — просто псевдоним для int64). Это плохое решение, так как теряет диапазон. Но хорошее с практической точки зрения — API очень простой (можно делать так "time.Add(10*time.Second)").
То есть, в Go та же самая сетка времени что и в плюсном chrono::nanoseconds с 64-битным счетчиком. Выписываем ему ненависть?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vopl, Вы писали:
C>>>https://docs.microsoft.com/en-us/dotnet/api/system.datetime.ticks?view=net-5.0 — разрешение 100 наносекунд, диапазон в 50 тысяч лет. V>>То есть, наносекундной точности нет и диапазона в 200 миллиардов лет тоже нет. То есть, Сишарп не предоставляет "правильную работу с датами". Выписываем Сишарпу ненависть? C>100нс — достаточная для большинства практических целей точность, так что нет. Диапазон тоже достаточен.
Вопрос же был закрыт со следующими требованиями: наносекундная точность, диапазон 200 миллиардов лет. Вспомни: C>> Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
Хвост виляет собакой? Двойные стандарты? Кумовство? Своим можно? А нас то за что?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vopl, Вы писали:
C>>>Вот так выглядит печать времени с наносекундами в Go: V>>Не надо вилять. 200 миллиардов лет есть? Нет. Выписываем ненависть. А тебе — кубок вилятора. C>Фича в том, что для Go взамен 200 миллиардов лет есть очень красивый API. Это вполне себе неплохой инженерный компромис.
Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
Всё, вопрос закрыт. Этот код решает проблемы потому что красивый API.
C>В C# — аналогичная история. Только они пожертвовали точностью для того, чтобы уметь представлять даты из практического диапазона (9999AD до 9999BC).
Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
Всё, вопрос закрыт. Этот код решает проблемы потому что тоже самое, да еще и практический диапазон (9999AD до 9999BC).
Здравствуйте, Cyberax, Вы писали:
3V>>Т.е. квант должен быть ровно 1/60-я. 3V>>Ну или там 1/37-я. C>Ну пиши тогда свой класс и не занимайся сексом с мозгами других людей. Один фиг, или придётся писать все функции форматированного вывода с нуля, или преобразовывать в десятичные.
Здравствуйте, PM, Вы писали:
C>>Ну пиши тогда свой класс и не занимайся сексом с мозгами других людей. Один фиг, или придётся писать все функции форматированного вывода с нуля, или преобразовывать в десятичные. PM>В С++20 добавленно форматирование, в том числе и для std::chrono. С fmtlib это можно использовать чуть ли ни в C++11: https://godbolt.org/z/1WKoG8
Ну я очень рад за терции и тем 10 людям в мире, которым они потребуются. Но какой чёрт до сих пор нет форматирования для миллисекунд в put_time?
Здравствуйте, landerhigh, Вы писали:
4>>Задача любого стандарта заключается в том, чтобы (на сколько возможно) покрыть потребности "99% пользователей", Java/C# с этим прилично справляются с мохнатых времен, L>Это в свою очередь может говорить об ограниченности потребностей 99% пользователей данных языков.
Любая инженерная задача — это поиск компромисов. Вариант: "сделать жизнь сложной для 100% пользователей, чтобы 0.1% пользователей, в теории, могли бы использовать стандартные классы", — очень плохой.
О потребностях. У меня код как раз занимается прикладной астрономией. Так что перевод отметок времени в юлианские дни — это обычная фича. Более того, у нас даже есть код, который пересчитывает время в самые настоящие марсианские дни ("солы"?).
Но мне ни разу даже в голову не пришло, что для этого нужно насиловать стандартную библиотеку. Гораздо проще использовать специально заточенные под эти задачи типы.
Здравствуйте, Cyberax, Вы писали:
V>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд. V>>Всё, вопрос закрыт. Этот код решает проблемы потому что тоже самое, да еще и практический диапазон (9999AD до 9999BC). V>> C>Я понял. Вы из этого комитета.
C>Ну что же, сочуствую. Сложно жить без моска.
Смешались в кучу кони, люди...
У тебя в этом треде три совершенно разных вопроса:
1) Виртуальный метод для часов.
2) Стандартные функции печати времени в чём-то удобном типа ISO8601 с долями секунд.
3) Тип данного хранения времени, чтобы иметь и диапазон, и точность.
(1) — по-моему, никто не понял. что ты вообще хотел.
(2) — согласен.
(3) — ты таки заслужил "орден вилятора" ([vopl@]), когда согласился с тем, что в Go "красивый API" и это тебе перевешивает недостатки (хотя если у тебя действительно были бы проблемы диапазона и/или точности — тебе бы никакой API не помог).
Со своей стороны хотел бы заметить, что я слабо представляю себе цели и времени шире плюс-минус 100 лет в обе стороны, и точности дальше микросекунд. Если это где-то есть, то это спецзадача, для которой нет ресурсных проблем потратиться на реализацию на структуре, которую ты предлагал, или на int128_t (даже самопальном). Но скорее всего такое не нужно.
Жду комментария, почему тебе 1 мкс недостаточно. а 100 нс достаточно.
По поводу печати долей секунды — реально это забывают в до чёрта мест. Я вот с офигением смотрю на наши хаки поверх log4cplus для этого же (интересно, в более новой версии починены? обновляться мы пока не осиливаем).
Здравствуйте, Cyberax, Вы писали:
C>Скажите, ну вот какой пиииииии в комитете не догадался сделать так, чтобы часы можно было вызывать через виртуальный метод?!?
У разных часов разные временные пространства. Чтобы их оформить виртуальными методами — надо иметь некое общее пространство времени. Такового не придумали... А предложи интерфейс часов с виртуальными методами, как бы это могло выглядеть на твой взгляд?
Здравствуйте, vopl, Вы писали:
C>>Скажите, ну вот какой пиииииии в комитете не догадался сделать так, чтобы часы можно было вызывать через виртуальный метод?!? V>У разных часов разные временные пространства. Чтобы их оформить виртуальными методами — надо иметь некое общее пространство времени. Такового не придумали... А предложи интерфейс часов с виртуальными методами, как бы это могло выглядеть на твой взгляд?
Вот так:
Т.е. чтобы нельзя было случайно присвоить две отметки времени с разными эпохами.
Но даже это тупо не нужно. Все давно стандартизовались на Unix-эпохе. При необходимости она тривиально преобразуется в любую другую простым прибавлением константы.
Здравствуйте, vopl, Вы писали:
C>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд. V>Ну, если вопрос закрыт, то круто, конечно . Все мосты к обсуждению, насколько я понял, отрезаны, сопротивление бесполезно ... А зачем это пихать в стандарт? Сделай себе свой clock_t&Co. и пользуй на здоровье?
То есть "зачем"? Чтобы не писать каждый раз своё. И да, видимо для стандартизаторов С++ простота является чем-то недостижмым.
И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vopl, Вы писали:
C>>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд. V>>Ну, если вопрос закрыт, то круто, конечно . Все мосты к обсуждению, насколько я понял, отрезаны, сопротивление бесполезно ... А зачем это пихать в стандарт? Сделай себе свой clock_t&Co. и пользуй на здоровье? C>То есть "зачем"? Чтобы я не писал каждый раз своё. И да, видимо для стандартизаторов С++ простота является чем-то недостижмым.
Подправил чуть. Не благодари.
C>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков.
Хм.. покажи на примере C#, где там наносекунды есть? И 200 миллиардов лет?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vopl, Вы писали:
C>>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд. V>>Ну, если вопрос закрыт, то круто, конечно . Все мосты к обсуждению, насколько я понял, отрезаны, сопротивление бесполезно ... А зачем это пихать в стандарт? Сделай себе свой clock_t&Co. и пользуй на здоровье? C>То есть "зачем"? Чтобы не писать каждый раз своё. И да, видимо для стандартизаторов С++ простота является чем-то недостижмым.
C>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков.
Покажи, где в Go 200 миллиардов лет? Было бы справедливо к Go тоже организовать ненависть?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vopl, Вы писали:
C>>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд. V>>Ну, если вопрос закрыт, то круто, конечно . Все мосты к обсуждению, насколько я понял, отрезаны, сопротивление бесполезно ... А зачем это пихать в стандарт? Сделай себе свой clock_t&Co. и пользуй на здоровье? C>То есть "зачем"? Чтобы не писать каждый раз своё. И да, видимо для стандартизаторов С++ простота является чем-то недостижмым.
C>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков.
И в Java похоже тоже нету наносекундной точности для 200 миллиардов лет.. По крайней мере я такого не нашел, но может плохо искал . Покажи?
Здравствуйте, vopl, Вы писали:
C>>То есть "зачем"? Чтобы я не писал каждый раз своё. И да, видимо для стандартизаторов С++ простота является чем-то недостижмым. V>Подправил чуть. Не благодари.
И не только я, а все остальные, кому нужна правильная работа с датами.
C>>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков. V>Хм.. покажи на примере C#, где там наносекунды есть? И 200 миллиардов лет? https://docs.microsoft.com/en-us/dotnet/api/system.datetime.ticks?view=net-5.0 — разрешение 100 наносекунд, диапазон в 50 тысяч лет.
Здравствуйте, vopl, Вы писали:
C>>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков. V>И в Java похоже тоже нету наносекундной точности для 200 миллиардов лет.. По крайней мере я такого не нашел, но может плохо искал . Покажи? https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html
The maximum supported Instant, '1000000000-12-31T23:59:59.999999999Z'.
The minimum supported Instant, '-1000000000-01-01T00:00Z'.
Они решили, видимо, ограничить всего одним миллиардом лет.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vopl, Вы писали:
C>>>То есть "зачем"? Чтобы я не писал каждый раз своё. И да, видимо для стандартизаторов С++ простота является чем-то недостижмым. V>>Подправил чуть. Не благодари. C>И не только я, а все остальные, кому нужна правильная работа с датами.
C>>>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков. V>>Хм.. покажи на примере C#, где там наносекунды есть? И 200 миллиардов лет? C>https://docs.microsoft.com/en-us/dotnet/api/system.datetime.ticks?view=net-5.0 — разрешение 100 наносекунд, диапазон в 50 тысяч лет.
То есть, наносекундной точности нет и диапазона в 200 миллиардов лет тоже нет. То есть, Сишарп не предоставляет "правильную работу с датами". Выписываем Сишарпу ненависть?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vopl, Вы писали:
C>>>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков. V>>И в Java похоже тоже нету наносекундной точности для 200 миллиардов лет.. По крайней мере я такого не нашел, но может плохо искал . Покажи? C>https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html C>
C> The maximum supported Instant, '1000000000-12-31T23:59:59.999999999Z'.
C> The minimum supported Instant, '-1000000000-01-01T00:00Z'.
C>
C>Они решили, видимо, ограничить всего одним миллиардом лет.
Ок, достаточно близко к тому что ты хотел. К Java ненависть не выписываем.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vopl, Вы писали:
C>>>В Go — наносекунды (а timestamp — просто псевдоним для int64). Это плохое решение, так как теряет диапазон. Но хорошее с практической точки зрения — API очень простой (можно делать так "time.Add(10*time.Second)"). V>>То есть, в Go та же самая сетка времени что и в плюсном chrono::nanoseconds с 64-битным счетчиком. Выписываем ему ненависть? C>Вот так выглядит печать времени с наносекундами в Go:
Не надо вилять. 200 миллиардов лет есть? Нет. Выписываем ненависть. А тебе — кубок вилятора.
Здравствуйте, vopl, Вы писали:
C>>Вот так выглядит печать времени с наносекундами в Go: V>Не надо вилять. 200 миллиардов лет есть? Нет. Выписываем ненависть. А тебе — кубок вилятора.
Фича в том, что для Go взамен 200 миллиардов лет есть очень красивый API. Это вполне себе неплохой инженерный компромис.
В C# — аналогичная история. Только они пожертвовали точностью для того, чтобы уметь представлять даты из практического диапазона (9999AD до 9999BC).
Но в С++ комитет абсолютно и непреклонно бескомпромисный. Так что они пожертвовали ВСЕМ одновременно. Так что в С++ нет ни красивого API, ни интервала в миллиарды лет.
Здравствуйте, Cyberax, Вы писали:
C>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
Не хочу с точностью до наносекунд.
Хочу с точностью до 1/60-й секунды.
Т.е. квант должен быть ровно 1/60-я.
Ну или там 1/37-я.
Здравствуйте, Cyberax, Вы писали:
C>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
А мне, к примеру, нужно представление времени с показателем качества часов (тут в соседней теме про IEC61850 спрашивали, там такое есть)
Здравствуйте, 3V, Вы писали:
C>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд. 3V>Не хочу с точностью до наносекунд. 3V>Хочу с точностью до 1/60-й секунды.
Кстати, это называется "терция".
3V>Т.е. квант должен быть ровно 1/60-я. 3V>Ну или там 1/37-я.
Ну пиши тогда свой класс и не занимайся сексом с мозгами других людей. Один фиг, или придётся писать все функции форматированного вывода с нуля, или преобразовывать в десятичные.
Здравствуйте, landerhigh, Вы писали:
C>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд. L>А мне, к примеру, нужно представление времени с показателем качества часов (тут в соседней теме про IEC61850 спрашивали, там такое есть)
Здравствуйте, Cyberax, Вы писали:
L>>А мне, к примеру, нужно представление времени с показателем качества часов (тут в соседней теме про IEC61850 спрашивали, там такое есть) C>
Здравствуйте, landerhigh, Вы писали:
L>Короче, попаболь понятна, но стандартом покрыть все потребности в любом случае не выйдет.
Задача любого стандарта заключается в том, чтобы (на сколько возможно) покрыть потребности "99% пользователей", Java/C# с этим прилично справляются с мохнатых времен, во всяком случае, разработчики не тратят время на обсуждение подобных вещей, а если нужен тот самый уникальный "1%" — велосипедьте себе на здоровье, никто не мешает.
Здравствуйте, Cyberax, Вы писали:
C>Я уже молчу об отдельном квесте: "напечатай мне время в ISO с наносекундами". Почему-то в комитете не подумали, что это кому-то может быть нужно.
C>Дубинкой бы их всех там надо пару раз по голове стукнуть.
В стандарте с недостатком концептов тоже беда, но ничего, кушаем, что дают
В чём проблема взять готовое решение в интернете:
#include <iostream>
#include <string>
using namespace std;
template <class Precision>
string getISOCurrentTimestamp()
{
auto now = chrono::system_clock::now();
return date::format("%FT%TZ", date::floor<Precision>(now));
}
int main() {
cout << getISOCurrentTimestamp<chrono::nanoseconds>();
}
Здравствуйте, 4058, Вы писали:
4>Задача любого стандарта заключается в том, чтобы (на сколько возможно) покрыть потребности "99% пользователей", Java/C# с этим прилично справляются с мохнатых времен,
Это в свою очередь может говорить об ограниченности потребностей 99% пользователей данных языков.
Это не хорошо и не плохо. Просто нужно об этом помнить.
4>во всяком случае, разработчики не тратят время на обсуждение подобных вещей, а если нужен тот самый уникальный "1%" — велосипедьте себе на здоровье, никто не мешает.
Везде есть свои погремушки. Для Java есть костыли типа Azul, которые решают проблемы, которой в плюсах просто нет.
Здравствуйте, landerhigh, Вы писали:
4>>Задача любого стандарта заключается в том, чтобы (на сколько возможно) покрыть потребности "99% пользователей", Java/C# с этим прилично справляются с мохнатых времен,
Да ладно! Цифра 99% как раз и говорит о том что эти мифические продвинутые возможности нафиг никому не впарились. Надо было просто сделать нормально, а тот 1% пусть сам себе велосипедит что хочет.
GC: кроме того на какой форум не заглянь — везде про chrono куча вопросов (элементарных/житейских) — это явный признак плохой библиотеки.
Здравствуйте, _NN_, Вы писали:
C>>Дубинкой бы их всех там надо пару раз по голове стукнуть. _NN>В стандарте с недостатком концептов тоже беда, но ничего, кушаем, что дают _NN>В чём проблема взять готовое решение в интернете:
Потому, что это БЛДЖАД, около 10000 строк дополнительного кода. С непонятной поддержкой ("Дядя Вася Inc.") и гарантиями по безопасности. Если этот "Дядя Вася Inc." завтра забросит эту библиотеку, то придётся вникать в эти 10 тысяч строк весьма нетривиального кода.
Ради форматирования, которое в других языках есть в стандартной библиотеке (поддерживаемой авторами языка).
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, _NN_, Вы писали:
C>>>Дубинкой бы их всех там надо пару раз по голове стукнуть. _NN>>В стандарте с недостатком концептов тоже беда, но ничего, кушаем, что дают _NN>>В чём проблема взять готовое решение в интернете: C>Потому, что это БЛДЖАД, около 10000 строк дополнительного кода. С непонятной поддержкой ("Дядя Вася Inc.") и гарантиями по безопасности. Если этот "Дядя Вася Inc." завтра забросит эту библиотеку, то придётся вникать в эти 10 тысяч строк весьма нетривиального кода.
У всего есть достоинства и недостатки.
Я бы не сказал, что стандартная библиотека эталон качества кода.
Количество банальнейших багов там не так мало.
C>Ради форматирования, которое в других языках есть в стандартной библиотеке (поддерживаемой авторами языка).
Это другое дело.
Осталось предложение в стандарт внести.
Здравствуйте, Cyberax, Вы писали:
C>>>Вот так выглядит печать времени с наносекундами в Go: V>>Не надо вилять. 200 миллиардов лет есть? Нет. Выписываем ненависть. А тебе — кубок вилятора. C>Фича в том, что для Go взамен 200 миллиардов лет есть очень красивый API. Это вполне себе неплохой инженерный компромис.
C>В C# — аналогичная история. Только они пожертвовали точностью для того, чтобы уметь представлять даты из практического диапазона (9999AD до 9999BC).
В C# вообще особо не думали, они применили 1:1 подход и точность часов Windows NT (64 бита и 100 нс), только сместили точку отсчёта и добавили знак. С другой стороны, у них были причины полагать, что подход NT практически пригоден "в целом по больнице".
C>Но в С++ комитет абсолютно и непреклонно бескомпромисный. Так что они пожертвовали ВСЕМ одновременно. Так что в С++ нет ни красивого API, ни интервала в миллиарды лет.
Я вот таки не понимаю, чем тебе, например, 1 мкс недостаточно, а 100 нс — достаточно. Что за задача такая?
64 бита в микросекундах — вполне достижимо на chrono стандартными средствами и даёт 290 000 лет со знаком.
Здравствуйте, netch80, Вы писали:
C>>В C# — аналогичная история. Только они пожертвовали точностью для того, чтобы уметь представлять даты из практического диапазона (9999AD до 9999BC). N>В C# вообще особо не думали, они применили 1:1 подход и точность часов Windows NT (64 бита и 100 нс), только сместили точку отсчёта и добавили знак. С другой стороны, у них были причины полагать, что подход NT практически пригоден "в целом по больнице".
Время в NT было сделано так, чтобы представлять все четырёхзначные даты (64 бит по 100 нс имеют диапазон значений в 50 тысяч лет) с достаточной точностью. В принципе, они могли бы сделать квант в 50 нс, но это уже мелочь.
C>>Но в С++ комитет абсолютно и непреклонно бескомпромисный. Так что они пожертвовали ВСЕМ одновременно. Так что в С++ нет ни красивого API, ни интервала в миллиарды лет. N>Я вот таки не понимаю, чем тебе, например, 1 мкс недостаточно, а 100 нс — достаточно. Что за задача такая?
100нс мне недостаточно, но я считаю решение в C# неплохим компромисом.
Здравствуйте, netch80, Вы писали:
C>>Ну что же, сочуствую. Сложно жить без моска. N>Смешались в кучу кони, люди... N>У тебя в этом треде три совершенно разных вопроса: N>1) Виртуальный метод для часов.
Да.
N>2) Стандартные функции печати времени в чём-то удобном типа ISO8601 с долями секунд.
Да.
N>3) Тип данного хранения времени, чтобы иметь и диапазон, и точность.
Да.
N>(1) — по-моему, никто не понял. что ты вообще хотел.
Простейшая вещь — возможность заменять часы в тестах.
N>Со своей стороны хотел бы заметить, что я слабо представляю себе цели и времени шире плюс-минус 100 лет в обе стороны, и точности дальше микросекунд.
Задача простая — есть электронная таблица, где есть тип "отметка времени". Туда пользователи могут добавлять любые даты из разумного диапазона. Это могут быть как исторические даты (скажем, даты начала и конца войн), так и данные с наносекундной точностью (скажем, результаты профилирования кода). Для всех дат надо поддерживать арифметику, стандартные операции и т.п.
Так что неплохо бы иметь тип данных, который поддерживал бы все требования.
Здравствуйте, _NN_, Вы писали:
_NN>У всего есть достоинства и недостатки. _NN>Я бы не сказал, что стандартная библиотека эталон качества кода. _NN>Количество банальнейших багов там не так мало.
Проблема не в качестве, а в поддержке. Стандартная библиотека будет поддерживаться вечно, а вот сторонние библиотеки могут в какой-то момент просто перестать обновляться.
Потому при добавлении библиотеки в проект всегда надо этот риск учитывать. Т.е. если библиотека делается автором-одиночкой, то нужно быть готовым перехватить её поддержку.
C>>Ради форматирования, которое в других языках есть в стандартной библиотеке (поддерживаемой авторами языка). _NN>Это другое дело. _NN>Осталось предложение в стандарт внести.
Я не очень понимаю что они там делают, если сами догадаться не могут.
Здравствуйте, 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 задача не тривиальная:
Если и нетривиальная, то только потому, что для общего случая нельзя сказать, что правильнее: сначала вычесть, потом округлить, или сначала округлить, потом вычесть.
Здравствуйте, 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 — это строготипизированный ноль.