Y>The local time zone is the time zone on the computer where the code is executing.
Y>Это не любая.
Блин, что за хрень!? Разговор про виртуальные методы одного класса (!абстрактного), а ты копипастишь описание СТАТИЧЕСКОГО свойства другого класса. WTF!?
Ну это же не политика, блин, это другой раздел — меру то нужно знать!
Всё сказанное выше — личное мнение, если не указано обратное.
Ф>>>А вот сделать часы в заданной таймзоне есть: Ф>>>Вот этот метод Ф>>> Ф>>> public virtual TimeZoneInfo LocalTimeZone { get => TimeZoneInfo.Local; } Ф>>>
Ф>>>плюс вот этот Ф>>> Ф>>> public DateTimeOffset GetLocalNow() Ф>>> { Ф>>> DateTimeOffset utcDateTime = GetUtcNow(); Ф>>> TimeZoneInfo zoneInfo = LocalTimeZone; Ф>>>
Ф>>>дают нам часы в любой таймзоне. Y>>В каком смысле в любой? Y>>https://learn.microsoft.com/en-us/dotnet/api/system.timezoneinfo.local?view=net-7.0 Y>>
Y>>The local time zone is the time zone on the computer where the code is executing.
Y>>Это не любая.
Ф>Блин, что за хрень!? Разговор про виртуальные методы одного класса (!абстрактного), а ты копипастишь описание СТАТИЧЕСКОГО свойства другого класса. WTF!? Ф>Ну это же не политика, блин, это другой раздел — меру то нужно знать!
Что-то ты сильно разволновался с утра, молюсь за твоё здоровье. Ты ж первый начал копипастить реализации.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали: S>>В чем проблема? S>В ограничениях на иерархию наследования.
В смысле!? Ты хочешь сказать, что если бы TimeProvider был интерфейсом, то ты бы мог свой треугольник сделать TimeProvider'ом — сделать реализацию это интерфейса? Типа так не получается — ты об этом?
Треугольник — это я конечно совсем загнул, но например стрим, или сервис.... Ты об этом, вот так?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали: Ф>В смысле!? Ты хочешь сказать, что если бы TimeProvider был интерфейсом, то ты бы мог свой треугольник сделать TimeProvider'ом — сделать реализацию это интерфейса? Типа так не получается — ты об этом? Ф>Треугольник — это я конечно совсем загнул, но например стрим, или сервис.... Ты об этом, вот так?
Конечно. Я мог бы сделать свою реализацию ITimeProvider более-менее где угодно, в том числе и в классе, который реализует пачку провайдеров разных сервисов согласованным образом.
После введения default interface members польза от абстрактных классов в API упала до примерно нуля.
Это если вообще опираться на предположение, что методы тайм-провайдера сильно связаны между собой. В противном случае имело бы смысл отказаться и от интерфейса в пользу отдельных функций.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Конечно. Я мог бы сделать свою реализацию ITimeProvider более-менее где угодно, в том числе и в классе, который реализует пачку провайдеров разных сервисов согласованным образом.
Это нарушение SRP
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>·>Так это надо наследника писать и переопределять метод. Ф>И в чём проблема? А как ты хотел?
Через setter, wither или конструктор.
Представь себе у тебя есть инстанс timeProvider и тебе нужно получить такой же, но в другой таймзоне. Придётся писать наследника-делегата с переопределением одного метода.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Qbit86, Вы писали:
Q>>Microsoft добавили абстракцию TimeProvider в каком-то превью .NET 8: https://github.com/dotnet/runtime/blob/main/src/libraries/Common/src/System/TimeProvider.cs Q>>И принимают его в некоторых своих API вроде CancellationTokenSource или PeriodicTimer.
НС>Абстрактный класс как основа API в 2023 году?
Здравствуйте, ·, Вы писали:
Ф>>·>Так это надо наследника писать и переопределять метод. Ф>>И в чём проблема? А как ты хотел? ·>Через setter, wither или конструктор. ·>Представь себе у тебя есть инстанс timeProvider и тебе нужно получить такой же, но в другой таймзоне. Придётся писать наследника-делегата с переопределением одного метода.
А с учётом этого, когда они добавят очередной виртуальнй метод в своё поделие, твой делегат по тихому сломается, будет делегировать всё, кроме этого нового метода.
Ну не умеют в микрософте вменяемый api делать, лучше бы тупо с явы передирали, и то бы лучше получалось.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Абстрактный класс как основа API в 2023 году?
Это ради невиртуального:
public TimeSpan GetElapsedTime (long startingTimestamp);
Собсно, это целевой метод, вокруг которого всё работает, он должен быть максимально легковесным, т.к. может вызываться в бесконечном цикле какого-нить диспетчера.
Здравствуйте, vdimas, Вы писали:
V>Можно переопределить на более легковесный Environment.TickCount
Он не более легковесный — точно такой же. Это разные счётчки: твой считает кол-во миллисекунд о старта системы, а то что ты хочешь заменить считает тики вроде-бы со 100 ns точностью.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, vdimas, Вы писали:
V>GetTickCount64 — это просто чтение кешированной переменной, значение которой обновляется каждый раз при срабатывании системного таймера.
В случае Stopwatch.GetTimestamp() даже записи в переменную может не быть.
V>В общем, первый способ имеет низкую разрешающую способность, но дешевый. V>Второй способ имеет лучшую разрешающую способность, но дорогой. ))
В абсолютном большинстве случаев он столь же дешёвый, если не дешевле: за кадром выполняется команда RDTSC, которая копирует содержимое MSR в EDX:EAX — обращение к памяти не происходит. А MSR обновляется сам, всегда.
Такое поведение в абсолютном большинстве случаев. Иное — если недоступна RDTSC, то такого на практике под виндой ни у кого пока не было (ни у кого из миллиардов пользователей). Иное поведение может быть, если винда принудительно настроена на использование HPET.
Если недоступны HPET и RDTS, то будет использован тот же таймер что ты предлагаешь, с соответствующей точностью.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
V>>GetTickCount64 — это просто чтение кешированной переменной, значение которой обновляется каждый раз при срабатывании системного таймера. Ф>В случае Stopwatch.GetTimestamp() даже записи в переменную может не быть.
Это всё-равно в разы дороже.
Просто замерь и убедись.
V>>Второй способ имеет лучшую разрешающую способность, но дорогой. )) Ф>В абсолютном большинстве случаев он столь же дешёвый, если не дешевле: за кадром выполняется команда RDTSC, которая копирует содержимое MSR в EDX:EAX — обращение к памяти не происходит.
Ой, блин, из глаз кровь читать эту чушь.
Это вызов ф-ии АПИ QueryPerformanceCounter, которая вызывает драйвер через KeQueryPerformanceCounter, а драйвер зависит от проца/чипсета, бо входу еще процы, где RDTSC возвращала разные значения для каждого ядра и это длилось почти десятилетие, такой беспредел. Плюс требуется запрашивать QueryPerformanceFrequency, а она у процов тоже гуляла постоянно.
Чтобы избежать ошибок и проблем с переносимостью, настоятельно рекомендуется использовать QPC вместо регистра TSC или инструкций процессора RDTSC или RDTSCP .
У старых чипсетов в итоге дойдёт до RDTSC — а пока дойдёт это уже дорого, и еще привет кучи багов, с которыми не раз боролся, когда таймстэмп надо было из разных потоков отмечать.
Ф>Такое поведение в абсолютном большинстве случаев.
Если дрова на чипсет нашлись — будет поставлено устройство high precision event timer.
В общем, не спорьте.
Если охота брать дешевое время — это GetTickCount64.
Здравствуйте, vdimas, Вы писали:
v> Ой, блин, из глаз кровь читать эту чушь. v> Плюс требуется запрашивать QueryPerformanceFrequency, а она у процов тоже гуляла постоянно.
А чушь писать ничего не кровоточит?
The frequency of the performance counter is fixed at system boot and is consistent across all processors. Therefore, the frequency need only be queried upon application initialization, and the result can be cached.
The frequency of the performance counter is fixed at system boot and is consistent across all processors. Therefore, the frequency need only be queried upon application initialization, and the result can be cached.
