Дублирование проверок требований концепции. Должны ли мы заботиться о них?

Question

Когда функции вложены друг в друга, проверки требований концепции часто дублируются.
Посмотрите на пример ниже,

      template<typename I>
requires std::forward_iterator<I>
auto fun1(I i){ ... };

template<typename I>
requires std::forward_iterator<I>
auto fun2(I i){
    fun1(i);
    ....
}

fun1 вызывается внутри fun2, поэтому std::forward_iterator<I>проверяется дважды.
Я хочу знать, влияет ли такое дублирование проверок требований отрицательно на время компиляции или нет.
Или вы думаете, что мы должны стремиться уменьшить дублирование проверок требований?
Дополнение:
мы можем избежать дублирования проверок требований, как показано ниже.

      template<typename I>
auto fun1_unchecked(I i) { ... }

template<typename I>
requires std::forward_iterator<I>
auto fun1(I i) {
    return fun1_unchecked(i);
}

template<typename I>
requires std::forward_iterator<I>
auto fun2(I i) {
    fun1_unchecked(i);
    ...
}

Но я не знаю, стоит ли это усилий.

Answer 1

Если называется кем-то другим, кроме , то наличие концепта не является дублированием. Код, который вызывает, также нуждается в концептуальном интерфейсе. Это две независимые функции; так случилось, что один из них звонит другому.

Если fun1вызывается только fun2, то понятие можно убрать. Но в остальном это значимая часть вашей системы и должен иметь надлежащий интерфейс.

Что касается затрат времени на «дублирование» во время компиляции, стандарт предоставляет реализациям C++ всю свободу действий, необходимую для минимизации любых затрат. Для любого заданного типа T, если компилятор (одного файла) видит , компилятор может свободно предположить, что каждое последующее использование concept_name<T>выдаст одно и то же значение. Таким образом, он может эффективно кэшировать его.

Поэтому любые затраты на «дублирование» должны быть сведены к минимуму.

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

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