Ненависть к std::chrono
От: Cyberax Марс  
Дата: 28.12.20 11:25
Оценка: +1 :)
Скажите, ну вот какой пиииииии в комитете не догадался сделать так, чтобы часы можно было вызывать через виртуальный метод?!?

Ну типа для простейшего случая:
struct some_class {
  std::chrono::base_clock *clock_ = &std::chrono::system_clock;

  std::string do_something() {
    return make_iso_timestamp(*clock_);
  }
};

// In tests
some_class t;
t.clock = fixed_clock(2020, 12, 23, 11, 22);
ASSERT_EQ("2020-12-23T11:22", t.do_something());


Я уже молчу об отдельном квесте: "напечатай мне время в ISO с наносекундами". Почему-то в комитете не подумали, что это кому-то может быть нужно.

Дубинкой бы их всех там надо пару раз по голове стукнуть.
Sapienti sat!
Re: Ненависть к std::chrono
От: vopl Россия  
Дата: 28.12.20 11:46
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


У разных часов разные временные пространства. Чтобы их оформить виртуальными методами — надо иметь некое общее пространство времени. Такового не придумали... А предложи интерфейс часов с виртуальными методами, как бы это могло выглядеть на твой взгляд?
Re[2]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 28.12.20 12:22
Оценка:
Здравствуйте, vopl, Вы писали:

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

V>У разных часов разные временные пространства. Чтобы их оформить виртуальными методами — надо иметь некое общее пространство времени. Такового не придумали... А предложи интерфейс часов с виртуальными методами, как бы это могло выглядеть на твой взгляд?
Вот так:
    struct timestamp_t {
        int64_t epoch_seconds;
        uint32_t nanos;
    };

    class clock_t
    {
    public:
        virtual ~clock_t() = default;
        virtual timestamp_t now() const;
    };

Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.

Если хочется мастурбировать на шаблоны, и теоретические потребности поддержки разных эпох, то ну сделайте так:
template<class Timespace> struct timestamp_t {
  int64_t epoch_seconds;
  uint32_t nanos;
};

template<class Timespace> class clock_t    {
  public:
    virtual ~clock_t() = default;
    virtual timestamp_t<Timespace> now() const;
};

Т.е. чтобы нельзя было случайно присвоить две отметки времени с разными эпохами.

Но даже это тупо не нужно. Все давно стандартизовались на Unix-эпохе. При необходимости она тривиально преобразуется в любую другую простым прибавлением константы.
Sapienti sat!
Re[3]: Ненависть к std::chrono
От: vopl Россия  
Дата: 28.12.20 12:34
Оценка: :))
Здравствуйте, Cyberax, Вы писали:

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


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

V>>У разных часов разные временные пространства. Чтобы их оформить виртуальными методами — надо иметь некое общее пространство времени. Такового не придумали... А предложи интерфейс часов с виртуальными методами, как бы это могло выглядеть на твой взгляд?
C>Вот так:
C>
C>    struct timestamp_t {
C>        int64_t epoch_seconds;
C>        uint32_t nanos;
C>    };

C>    class clock_t
C>    {
C>    public:
C>        virtual ~clock_t() = default;
C>        virtual timestamp_t now() const;
C>    };
C>

C>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.

Ну, если вопрос закрыт, то круто, конечно . Все мосты к обсуждению, насколько я понял, отрезаны, сопротивление бесполезно ... А зачем это пихать в стандарт? Сделай себе свой clock_t&Co. и пользуй на здоровье?
Re[4]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 28.12.20 12:42
Оценка:
Здравствуйте, vopl, Вы писали:

C>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.

V>Ну, если вопрос закрыт, то круто, конечно . Все мосты к обсуждению, насколько я понял, отрезаны, сопротивление бесполезно ... А зачем это пихать в стандарт? Сделай себе свой clock_t&Co. и пользуй на здоровье?
То есть "зачем"? Чтобы не писать каждый раз своё. И да, видимо для стандартизаторов С++ простота является чем-то недостижмым.

И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков.
Sapienti sat!
Re[5]: Ненависть к std::chrono
От: vopl Россия  
Дата: 28.12.20 12:57
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.

V>>Ну, если вопрос закрыт, то круто, конечно . Все мосты к обсуждению, насколько я понял, отрезаны, сопротивление бесполезно ... А зачем это пихать в стандарт? Сделай себе свой clock_t&Co. и пользуй на здоровье?
C>То есть "зачем"? Чтобы я не писал каждый раз своё. И да, видимо для стандартизаторов С++ простота является чем-то недостижмым.
Подправил чуть. Не благодари.

C>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков.

Хм.. покажи на примере C#, где там наносекунды есть? И 200 миллиардов лет?
Re[5]: Ненависть к std::chrono
От: vopl Россия  
Дата: 28.12.20 13:02
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.

V>>Ну, если вопрос закрыт, то круто, конечно . Все мосты к обсуждению, насколько я понял, отрезаны, сопротивление бесполезно ... А зачем это пихать в стандарт? Сделай себе свой clock_t&Co. и пользуй на здоровье?
C>То есть "зачем"? Чтобы не писать каждый раз своё. И да, видимо для стандартизаторов С++ простота является чем-то недостижмым.

C>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков.


Покажи, где в Go 200 миллиардов лет? Было бы справедливо к Go тоже организовать ненависть?
Re[5]: Ненависть к std::chrono
От: vopl Россия  
Дата: 28.12.20 13:18
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.

V>>Ну, если вопрос закрыт, то круто, конечно . Все мосты к обсуждению, насколько я понял, отрезаны, сопротивление бесполезно ... А зачем это пихать в стандарт? Сделай себе свой clock_t&Co. и пользуй на здоровье?
C>То есть "зачем"? Чтобы не писать каждый раз своё. И да, видимо для стандартизаторов С++ простота является чем-то недостижмым.

C>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков.


И в Java похоже тоже нету наносекундной точности для 200 миллиардов лет.. По крайней мере я такого не нашел, но может плохо искал . Покажи?
Re[6]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 28.12.20 14:20
Оценка:
Здравствуйте, 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 тысяч лет.
Sapienti sat!
Re[6]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 28.12.20 14:22
Оценка:
Здравствуйте, 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'.

Они решили, видимо, ограничить всего одним миллиардом лет.
Sapienti sat!
Re[6]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 28.12.20 14:28
Оценка: :)
Здравствуйте, vopl, Вы писали:

C>>И ладно бы это было бы чем-то сверхумным, так ведь такой подход уже много лет использует Java, C#, Go и куча других языков.

V>Покажи, где в Go 200 миллиардов лет? Было бы справедливо к Go тоже организовать ненависть?
В Go — наносекунды (а timestamp — просто псевдоним для int64). Это плохое решение, так как теряет диапазон. Но хорошее с практической точки зрения — API очень простой (можно делать так "time.Add(10*time.Second)").
Sapienti sat!
Re[7]: Ненависть к std::chrono
От: vopl Россия  
Дата: 28.12.20 14:28
Оценка:
Здравствуйте, 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 миллиардов лет тоже нет. То есть, Сишарп не предоставляет "правильную работу с датами". Выписываем Сишарпу ненависть?
Re[8]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 28.12.20 14:32
Оценка: +2 :)
Здравствуйте, vopl, Вы писали:

C>>https://docs.microsoft.com/en-us/dotnet/api/system.datetime.ticks?view=net-5.0 — разрешение 100 наносекунд, диапазон в 50 тысяч лет.

V>То есть, наносекундной точности нет и диапазона в 200 миллиардов лет тоже нет. То есть, Сишарп не предоставляет "правильную работу с датами". Выписываем Сишарпу ненависть?
100нс — достаточная для большинства практических целей точность, так что нет. Диапазон тоже достаточен.

С# далеко до маразма С++ (и защищающих его!), который ОДНОВРЕМЕННО умудрился потерять гарантии по диапазону значений и точности. Стандартный комитет, видимо, очень долго работал над этим достижением. Но им это удалось!
Sapienti sat!
Re[7]: Ненависть к std::chrono
От: vopl Россия  
Дата: 28.12.20 14:32
Оценка: +1
Здравствуйте, 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-битным счетчиком. Выписываем ему ненависть?
Re[7]: Ненависть к std::chrono
От: vopl Россия  
Дата: 28.12.20 14:39
Оценка:
Здравствуйте, 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 ненависть не выписываем.
Re[9]: Ненависть к std::chrono
От: vopl Россия  
Дата: 28.12.20 14:51
Оценка: +1
Здравствуйте, 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 миллиардов лет, с точностью до наносекунд.
Хвост виляет собакой? Двойные стандарты? Кумовство? Своим можно? А нас то за что?
Re[8]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 28.12.20 14:55
Оценка: +1 -1
Здравствуйте, vopl, Вы писали:

C>>В Go — наносекунды (а timestamp — просто псевдоним для int64). Это плохое решение, так как теряет диапазон. Но хорошее с практической точки зрения — API очень простой (можно делать так "time.Add(10*time.Second)").

V>То есть, в Go та же самая сетка времени что и в плюсном chrono::nanoseconds с 64-битным счетчиком. Выписываем ему ненависть?
Вот так выглядит печать времени с наносекундами в Go:
package main
import "time"
func main() {
  tm := time.Now()
  println(tm.Format("2006-01-02T15:04:05.999999999Z07:00"))
  // Или:
  println(tm.Format(time.RFC3339Nano))
}

Всё полностью запускаемо: https://play.golang.org/p/ZQqlZodi-up

Метод формата даты — вообще гениален. Единственный минус — неудачно выбранная эталонная дата.

А теперь то же самое для 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), но не додумались добавить формат для наносекунд. Да что там, они даже для миллисекунд формат не добавили.

Эпичный фэйл.
Sapienti sat!
Re[9]: Ненависть к std::chrono
От: vopl Россия  
Дата: 28.12.20 14:59
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>В Go — наносекунды (а timestamp — просто псевдоним для int64). Это плохое решение, так как теряет диапазон. Но хорошее с практической точки зрения — API очень простой (можно делать так "time.Add(10*time.Second)").

V>>То есть, в Go та же самая сетка времени что и в плюсном chrono::nanoseconds с 64-битным счетчиком. Выписываем ему ненависть?
C>Вот так выглядит печать времени с наносекундами в Go:

Не надо вилять. 200 миллиардов лет есть? Нет. Выписываем ненависть. А тебе — кубок вилятора.
Re[10]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 28.12.20 15:07
Оценка:
Здравствуйте, vopl, Вы писали:

C>>Вот так выглядит печать времени с наносекундами в Go:

V>Не надо вилять. 200 миллиардов лет есть? Нет. Выписываем ненависть. А тебе — кубок вилятора.
Фича в том, что для Go взамен 200 миллиардов лет есть очень красивый API. Это вполне себе неплохой инженерный компромис.

В C# — аналогичная история. Только они пожертвовали точностью для того, чтобы уметь представлять даты из практического диапазона (9999AD до 9999BC).

Но в С++ комитет абсолютно и непреклонно бескомпромисный. Так что они пожертвовали ВСЕМ одновременно. Так что в С++ нет ни красивого API, ни интервала в миллиарды лет.
Sapienti sat!
Re[11]: Ненависть к std::chrono
От: vopl Россия  
Дата: 28.12.20 15:35
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

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


C>>>Вот так выглядит печать времени с наносекундами в Go:

V>>Не надо вилять. 200 миллиардов лет есть? Нет. Выписываем ненависть. А тебе — кубок вилятора.
C>Фича в том, что для Go взамен 200 миллиардов лет есть очень красивый API. Это вполне себе неплохой инженерный компромис.

Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
Всё, вопрос закрыт. Этот код решает проблемы потому что красивый API.

C>В C# — аналогичная история. Только они пожертвовали точностью для того, чтобы уметь представлять даты из практического диапазона (9999AD до 9999BC).


Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.
Всё, вопрос закрыт. Этот код решает проблемы потому что тоже самое, да еще и практический диапазон (9999AD до 9999BC).

Re[12]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 28.12.20 15:43
Оценка: +2 :))
Здравствуйте, vopl, Вы писали:

V>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.

V>Всё, вопрос закрыт. Этот код решает проблемы потому что тоже самое, да еще и практический диапазон (9999AD до 9999BC).
V>
Я понял. Вы из этого комитета.

Ну что же, сочуствую. Сложно жить без моска.
Sapienti sat!
Re[3]: Ненависть к std::chrono
От: 3V Россия  
Дата: 28.12.20 22:11
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.

Не хочу с точностью до наносекунд.
Хочу с точностью до 1/60-й секунды.
Т.е. квант должен быть ровно 1/60-я.
Ну или там 1/37-я.
Re[3]: Ненависть к std::chrono
От: landerhigh Пират  
Дата: 28.12.20 23:16
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.


А мне, к примеру, нужно представление времени с показателем качества часов (тут в соседней теме про IEC61850 спрашивали, там такое есть)
www.blinnov.com
Re[4]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 29.12.20 02:59
Оценка:
Здравствуйте, 3V, Вы писали:

C>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.

3V>Не хочу с точностью до наносекунд.
3V>Хочу с точностью до 1/60-й секунды.
Кстати, это называется "терция".

3V>Т.е. квант должен быть ровно 1/60-я.

3V>Ну или там 1/37-я.
Ну пиши тогда свой класс и не занимайся сексом с мозгами других людей. Один фиг, или придётся писать все функции форматированного вывода с нуля, или преобразовывать в десятичные.
Sapienti sat!
Re[4]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 29.12.20 02:59
Оценка:
Здравствуйте, landerhigh, Вы писали:

C>>Всё, вопрос закрыт. Этот код решает проблемы с временим на ближайшие 200 миллиардов лет, с точностью до наносекунд.

L>А мне, к примеру, нужно представление времени с показателем качества часов (тут в соседней теме про IEC61850 спрашивали, там такое есть)
struct time_with_quality_t {
   timestamp_t time_;
   quality_t quality_;
};


И всё.
Sapienti sat!
Re[5]: Ненависть к std::chrono
От: PM  
Дата: 29.12.20 10:13
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

3V>>Т.е. квант должен быть ровно 1/60-я.

3V>>Ну или там 1/37-я.
C>Ну пиши тогда свой класс и не занимайся сексом с мозгами других людей. Один фиг, или придётся писать все функции форматированного вывода с нуля, или преобразовывать в десятичные.

В С++20 добавленно форматирование, в том числе и для std::chrono. С fmtlib это можно использовать чуть ли ни в C++11: https://godbolt.org/z/1WKoG8
#include <chrono>

#include <fmt/core.h>
#include <fmt/chrono.h>

int main()
{
    using namespace std::literals::chrono_literals;

    using deciseconds = std::chrono::duration<int64_t, std::ratio<1, 10>>;
    using tertia = std::chrono::duration<int64_t, std::ratio<1, 60>>;

    fmt::print("Custom duration: {}\n", std::chrono::seconds{1} + deciseconds{1} + tertia{3});
    fmt::print("Standard durations: {} {} {} {}\n", 1h, 5min, 6s, 10ns );
}


Program returned: 0
Program stdout
Custom duration: 69[1/60]s
Standard durations: 1h 5m 6s 10ns

Re[5]: Ненависть к std::chrono
От: landerhigh Пират  
Дата: 29.12.20 10:24
Оценка:
Здравствуйте, Cyberax, Вы писали:

L>>А мне, к примеру, нужно представление времени с показателем качества часов (тут в соседней теме про IEC61850 спрашивали, там такое есть)

C>
C>struct time_with_quality_t {
C>   timestamp_t time_;
C>   quality_t quality_;
C>};
C>


C>И всё.


Да вот не все. Там есть особенности.
Короче, попаболь понятна, но стандартом покрыть все потребности в любом случае не выйдет.
www.blinnov.com
Re[6]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 29.12.20 10:38
Оценка: +1
Здравствуйте, PM, Вы писали:

C>>Ну пиши тогда свой класс и не занимайся сексом с мозгами других людей. Один фиг, или придётся писать все функции форматированного вывода с нуля, или преобразовывать в десятичные.

PM>В С++20 добавленно форматирование, в том числе и для std::chrono. С fmtlib это можно использовать чуть ли ни в C++11: https://godbolt.org/z/1WKoG8
Ну я очень рад за терции и тем 10 людям в мире, которым они потребуются. Но какой чёрт до сих пор нет форматирования для миллисекунд в put_time?
Sapienti sat!
Re[6]: Ненависть к std::chrono
От: 4058  
Дата: 29.12.20 20:19
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>Короче, попаболь понятна, но стандартом покрыть все потребности в любом случае не выйдет.


Задача любого стандарта заключается в том, чтобы (на сколько возможно) покрыть потребности "99% пользователей", Java/C# с этим прилично справляются с мохнатых времен, во всяком случае, разработчики не тратят время на обсуждение подобных вещей, а если нужен тот самый уникальный "1%" — велосипедьте себе на здоровье, никто не мешает.
Re: Ненависть к std::chrono
От: _NN_ www.nemerleweb.com
Дата: 29.12.20 20:51
Оценка:
Здравствуйте, 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>();   
}


2020-12-29T20:45:46.149347442Z

http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[7]: Ненависть к std::chrono
От: landerhigh Пират  
Дата: 29.12.20 21:46
Оценка:
Здравствуйте, 4058, Вы писали:

4>Задача любого стандарта заключается в том, чтобы (на сколько возможно) покрыть потребности "99% пользователей", Java/C# с этим прилично справляются с мохнатых времен,


Это в свою очередь может говорить об ограниченности потребностей 99% пользователей данных языков.
Это не хорошо и не плохо. Просто нужно об этом помнить.

4>во всяком случае, разработчики не тратят время на обсуждение подобных вещей, а если нужен тот самый уникальный "1%" — велосипедьте себе на здоровье, никто не мешает.


Везде есть свои погремушки. Для Java есть костыли типа Azul, которые решают проблемы, которой в плюсах просто нет.
www.blinnov.com
Re[8]: Ненависть к std::chrono
От: AeroSun  
Дата: 29.12.20 23:01
Оценка:
Здравствуйте, landerhigh, Вы писали:

4>>Задача любого стандарта заключается в том, чтобы (на сколько возможно) покрыть потребности "99% пользователей", Java/C# с этим прилично справляются с мохнатых времен,


Да ладно! Цифра 99% как раз и говорит о том что эти мифические продвинутые возможности нафиг никому не впарились. Надо было просто сделать нормально, а тот 1% пусть сам себе велосипедит что хочет.

GC: кроме того на какой форум не заглянь — везде про chrono куча вопросов (элементарных/житейских) — это явный признак плохой библиотеки.
Re[9]: Ненависть к std::chrono
От: landerhigh Пират  
Дата: 30.12.20 01:15
Оценка: +1 :)
Здравствуйте, AeroSun, Вы писали:

AS>GC: кроме того на какой форум не заглянь — везде про chrono куча вопросов (элементарных/житейских) — это явный признак плохой библиотеки.


Старческое брюзжание
www.blinnov.com
Re[2]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 30.12.20 05:42
Оценка:
Здравствуйте, _NN_, Вы писали:

C>>Дубинкой бы их всех там надо пару раз по голове стукнуть.

_NN>В стандарте с недостатком концептов тоже беда, но ничего, кушаем, что дают
_NN>В чём проблема взять готовое решение в интернете:
Потому, что это БЛДЖАД, около 10000 строк дополнительного кода. С непонятной поддержкой ("Дядя Вася Inc.") и гарантиями по безопасности. Если этот "Дядя Вася Inc." завтра забросит эту библиотеку, то придётся вникать в эти 10 тысяч строк весьма нетривиального кода.

Ради форматирования, которое в других языках есть в стандартной библиотеке (поддерживаемой авторами языка).
Sapienti sat!
Re[8]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 30.12.20 05:52
Оценка: +1
Здравствуйте, landerhigh, Вы писали:

4>>Задача любого стандарта заключается в том, чтобы (на сколько возможно) покрыть потребности "99% пользователей", Java/C# с этим прилично справляются с мохнатых времен,

L>Это в свою очередь может говорить об ограниченности потребностей 99% пользователей данных языков.
Любая инженерная задача — это поиск компромисов. Вариант: "сделать жизнь сложной для 100% пользователей, чтобы 0.1% пользователей, в теории, могли бы использовать стандартные классы", — очень плохой.

О потребностях. У меня код как раз занимается прикладной астрономией. Так что перевод отметок времени в юлианские дни — это обычная фича. Более того, у нас даже есть код, который пересчитывает время в самые настоящие марсианские дни ("солы"?).

Но мне ни разу даже в голову не пришло, что для этого нужно насиловать стандартную библиотеку. Гораздо проще использовать специально заточенные под эти задачи типы.
Sapienti sat!
Re[3]: Ненависть к std::chrono
От: _NN_ www.nemerleweb.com
Дата: 30.12.20 06:00
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>Дубинкой бы их всех там надо пару раз по голове стукнуть.

_NN>>В стандарте с недостатком концептов тоже беда, но ничего, кушаем, что дают
_NN>>В чём проблема взять готовое решение в интернете:
C>Потому, что это БЛДЖАД, около 10000 строк дополнительного кода. С непонятной поддержкой ("Дядя Вася Inc.") и гарантиями по безопасности. Если этот "Дядя Вася Inc." завтра забросит эту библиотеку, то придётся вникать в эти 10 тысяч строк весьма нетривиального кода.
У всего есть достоинства и недостатки.
Я бы не сказал, что стандартная библиотека эталон качества кода.
Количество банальнейших багов там не так мало.

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

Это другое дело.
Осталось предложение в стандарт внести.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[11]: Ненависть к std::chrono
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 30.12.20 07:18
Оценка:
Здравствуйте, 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 лет со знаком.
The God is real, unless declared integer.
Re[13]: Ненависть к std::chrono
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 30.12.20 07:29
Оценка: +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 для этого же (интересно, в более новой версии починены? обновляться мы пока не осиливаем).
The God is real, unless declared integer.
Re[12]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 30.12.20 08:08
Оценка:
Здравствуйте, 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# неплохим компромисом.
Sapienti sat!
Re[14]: Ненависть к std::chrono
От: Cyberax Марс  
Дата: 30.12.20 08:14
Оценка:
Здравствуйте, netch80, Вы писали:

C>>Ну что же, сочуствую. Сложно жить без моска.

N>Смешались в кучу кони, люди...
N>У тебя в этом треде три совершенно разных вопроса:
N>1) Виртуальный метод для часов.
Да.

N>2) Стандартные функции печати времени в чём-то удобном типа ISO8601 с долями секунд.

Да.

N>3) Тип данного хранения времени, чтобы иметь и диапазон, и точность.

Да.

N>(1) — по-моему, никто не понял. что ты вообще хотел.

Простейшая вещь — возможность заменять часы в тестах.

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

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

Так что неплохо бы иметь тип данных, который поддерживал бы все требования.
Sapienti sat!
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...
Пока на собственное сообщение не было ответов, его можно удалить.