Ограничение std :: sort для итераторов с произвольным доступом

Question

Мне было просто интересно, поскольку в любом случае вы можете только передавать итераторы произвольного доступа в std::sort, почему бы не применить это ограничение, определив его только для итераторов произвольного доступа?

#include <iterator>
#include <type_traits>

template <typename ForwardIterator>
typename std::enable_if<
    std::is_same<
        typename std::iterator_traits<ForwardIterator>::iterator_category,
        std::random_access_iterator_tag>::value,
    void>
::type sort(ForwardIterator begin, ForwardIterator end)
{
    // ...
}

Iнайти однострочное сообщение об ошибке намного проще для чтения, чем страницы и страницы сообщений об ошибках, возникающих из-за ошибок типа, находящихся далеко внизу в реализации.

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

Answer 1

Базовый язык всегда был достаточно выразительным, чтобы обрабатывать такие проверки, но когда готовился первый стандарт (около 1996/1997), уловки, с которыми можно поиграть с SFINAE (на чем основан enable_if ) по факту) еще не были известны, и поддержка расширенных шаблонных шаблонов была ограничена в компиляторах.

Итак, причина, по которой стандарт не предписывал его, заключалась в том, что необходимые методы еще не были изобретены.
Причина, по которой авторы компиляторов / библиотек не добавили ее после этого факта, вероятно, просто экономическая причина: мало людей спрашивали об этой функции, а когда люди начали спрашивать о лучшей диагностике, появилась надежда на предложение concept позаботиться об этом. К сожалению, это оказалось слишком сложно, чтобы завершить его вовремя.

Answer 2

Я предполагаю, что SFINAE был изобретен (или обнаружен) после того, как реализации стандартной библиотеки достигли определенной зрелости.После этого изменения в базовой библиотеке должны были быть очень оправданы, чтобы предотвратить введение регрессий, и я предполагаю, что простые косметические средства несколько трудно оправдать. имеет много диагностики для сообщений об ошибках, связанных с шаблоном, например, макросов, которые выполняют своего рода проверку концепции.Например, GCC-libstdc ++ имеет следующее:

// concept requirements
__glibcxx_function_requires(_Mutable_RandomAccessIteratorConcept<
   _RandomAccessIterator>)
__glibcxx_function_requires(_LessThanComparableConcept<_ValueType>)
__glibcxx_requires_valid_range(__first, __last);

Answer 3

На самом деле, когда есть только одна перегрузка алгоритма, вы почти всегда получаете лучшую диагностику, вызывая ошибку компиляции только внутри, используя что-то вроде Boost.ConceptCheck или __glibcxx_function_requires.Когда SFINAE (что и используется enable_if) оставляет вас с пустым набором перегрузки, большинство компиляторов просто говорят вам, что «нет функции соответствия», что, как правило, не очень полезно.

Answer 4

Одной из приятных особенностей шаблонов в C ++ является то, что они могут иметь своего рода статическую «типизацию». Я не могу говорить об этом конкретном случае, но во многих шаблонах, если вы сохраняете интерфейс одинаковым, вся бессмысленность иерархии не имеет значения. И это хорошо.