Здравствуйте, Cyberax, Вы писали:
C>Скажите, ну вот какой пиииииии в комитете не догадался сделать так, чтобы часы можно было вызывать через виртуальный метод?!?
У разных часов разные временные пространства. Чтобы их оформить виртуальными методами — надо иметь некое общее пространство времени. Такового не придумали... А предложи интерфейс часов с виртуальными методами, как бы это могло выглядеть на твой взгляд?
Здравствуйте, vopl, Вы писали:
C>>Скажите, ну вот какой пиииииии в комитете не догадался сделать так, чтобы часы можно было вызывать через виртуальный метод?!? V>У разных часов разные временные пространства. Чтобы их оформить виртуальными методами — надо иметь некое общее пространство времени. Такового не придумали... А предложи интерфейс часов с виртуальными методами, как бы это могло выглядеть на твой взгляд?
Вот так:
Т.е. чтобы нельзя было случайно присвоить две отметки времени с разными эпохами.
Но даже это тупо не нужно. Все давно стандартизовались на Unix-эпохе. При необходимости она тривиально преобразуется в любую другую простым прибавлением константы.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vopl, Вы писали:
C>>>Скажите, ну вот какой пиииииии в комитете не догадался сделать так, чтобы часы можно было вызывать через виртуальный метод?!? V>>У разных часов разные временные пространства. Чтобы их оформить виртуальными методами — надо иметь некое общее пространство времени. Такового не придумали... А предложи интерфейс часов с виртуальными методами, как бы это могло выглядеть на твой взгляд? C>Вот так: C>
C>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
Ну, если вопрос закрыт, то круто, конечно . Все мосты к обсуждению, насколько я понял, отрезаны, сопротивление бесполезно ... А зачем это пихать в стандарт? Сделай себе свой clock_t&Co. и пользуй на здоровье?
Здравствуйте, 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'.
Они решили, видимо, ограничить всего одним миллиардом лет.
Здравствуйте, vopl, Вы писали:
C>>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков. V>Покажи, где в Go 200 миллиардов лет? Было бы справедливо к Go тоже организовать ненависть?
В Go — наносекунды (а timestamp — просто псевдоним для int64). Это плохое решение, так как теряет диапазон. Но хорошее с практической точки зрения — API очень простой (можно делать так "time.Add(10*time.Second)").
Здравствуйте, 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 миллиардов лет тоже нет. То есть, Сишарп не предоставляет "правильную работу с датами". Выписываем Сишарпу ненависть?
Здравствуйте, vopl, Вы писали:
C>>https://docs.microsoft.com/en-us/dotnet/api/system.datetime.ticks?view=net-5.0 — разрешение 100 наносекунд, диапазон в 50 тысяч лет. V>То есть, наносекундной точности нет и диапазона в 200 миллиардов лет тоже нет. То есть, Сишарп не предоставляет "правильную работу с датами". Выписываем Сишарпу ненависть?
100нс — достаточная для большинства практических целей точность, так что нет. Диапазон тоже достаточен.
С# далеко до маразма С++ (и защищающих его!), который ОДНОВРЕМЕННО умудрился потерять гарантии по диапазону значений и точности. Стандартный комитет, видимо, очень долго работал над этим достижением. Но им это удалось!
Здравствуйте, 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>>>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует 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>>>https://docs.microsoft.com/en-us/dotnet/api/system.datetime.ticks?view=net-5.0 — разрешение 100 наносекунд, диапазон в 50 тысяч лет. V>>То есть, наносекундной точности нет и диапазона в 200 миллиардов лет тоже нет. То есть, Сишарп не предоставляет "правильную работу с датами". Выписываем Сишарпу ненависть? C>100нс — достаточная для большинства практических целей точность, так что нет. Диапазон тоже достаточен.
Вопрос же был закрыт со следующими требованиями: наносекундная точность, диапазон 200 миллиардов лет. Вспомни: C>> Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
Хвост виляет собакой? Двойные стандарты? Кумовство? Своим можно? А нас то за что?
Здравствуйте, 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), но не додумались добавить формат для наносекунд. Да что там, они даже для миллисекунд формат не добавили.
Здравствуйте, 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>Здравствуйте, vopl, Вы писали:
C>>>Вот так выглядит печать времени с наносекундами в Go: V>>Не надо вилять. 200 миллиардов лет есть? Нет. Выписываем ненависть. А тебе — кубок вилятора. C>Фича в том, что для Go взамен 200 миллиардов лет есть очень красивый API. Это вполне себе неплохой инженерный компромис.
Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
Всё, вопрос закрыт. Этот код решает проблемы потому что красивый API.
C>В C# — аналогичная история. Только они пожертвовали точностью для того, чтобы уметь представлять даты из практического диапазона (9999AD до 9999BC).
Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
Всё, вопрос закрыт. Этот код решает проблемы потому что тоже самое, да еще и практический диапазон (9999AD до 9999BC).