Я нашел интересную новость с ответом std::numeric_limits<seconds>::max()
0. Ответ заключается в использовании seconds::max()
или std::numeric_limits<seconds::rep>::max()
вместо этого, но мне интересно узнать, почему это происходит. Я ожидал, что это произойдет либо во время компиляции, либо просто будет работать. Следующий код демонстрирует проблему с gcc 4.9.3.
#include <iostream>
#include <limits>
#include <chrono>
using namespace std;
using namespace std::chrono;
int main(int /*argc*/, const char* /*argv*/[])
{
const auto maxSeconds = std::numeric_limits<seconds>::max();
std::cerr << maxSeconds.count() << "\n";
const auto maxSeconds2 = seconds::max();
std::cerr << maxSeconds2.count() << "\n";
return 0;
}
Я не вижу никаких неявных преобразований в файле заголовка chrono. Если a duration
неявно нажал на числовой тип, а знак был потерян или bool
, вы могли бы получить минимум ноль - но максимум нуля не имеет смысла.
Как отмечает TartanLlama, специализация по умолчанию использует конструктор по умолчанию и поэтому возвращает 0.
Включение в старую копию стандарта я вижу следующие дикты:
18.3.2.3 Шаблон класса
numeric_limits
[numeric.limits]Неарифметические стандартные типы, такие как
complex<T>
(26.4.2), не должны иметь специализации.
и немного позже:
По умолчанию шаблон
numeric_limits<T>
должен иметь все члены, но с 0 или ложными значениями.Значение каждого члена специализации
numeric_limits
на cv-квалифицированном типеcv T
должно быть равно значению соответствующий член специализации по неквалифицированному типуT
.
Отсутствует объяснение того, почему комитет считал это лучшей идеей, чем неудача компиляции. Требуется ли отчет о дефекте библиотеки?
Обновление: я поднял это как проблему с комитетом ISO