Почему в документации на некоторых языках написано «эквивалентно», а не «есть»?

itertools.chain(*iterables)

...

Эквивалентно :

def chain(*iterables):
    # chain('ABC', 'DEF') --> A B C D E F
    for it in iterables:
        for element in it:
            yield element

Или эта ссылка на C ++find_if :

Поведение этого шаблона функции эквивалентно :

template<class InputIterator, class UnaryPredicate>
  InputIterator find_if (InputIterator first, InputIterator last, UnaryPredicate pred)
{
  while (first!=last) {
    if (pred(*first)) return first;
    ++first;
  }
  return last;
}

Если это не настоящий код, не могут ли они опубликовать его? И если это фактический код, почему они должны говорить, что это «Эквивалент», а не просто «есть»?

— Джон МакКлюнг
источник

Обратите внимание , что то , что вы видите find_ifэто не «» Документация для C ++. Если это так, то приведение к bool(которое вы видите в ответе ниже) будет неправильным.

— Мердад

В случае с python, если вы посмотрите на исходный код, вы обнаружите, что chainон реализован непосредственно в C, поэтому он «эквивалентен» к тому же коду Python, потому что он дает тот же результат, но избегает некоторых накладных расходов при интерпретации этого кода. байткод.

— Бакуриу

@Mehrdad Я знаю, что это не официальная документация, это ресурс, который я нашел наиболее полезным для выяснения особенностей C ++

— Джон МакКлюнг

Они будут вынуждены использовать любой подход, установленный в стандарте, даже если будет доступен значительно лучший подход.

— Кевин

Потому что стандартные авторы не хотят фактически утверждать реализацию. Они хотят определить, что он делает , но не обязательно, как он это делает. Так, например, если вы посмотрите на версию GNU C ++find_if , вы увидите, что реализация немного отличается от того, что вы даете, который основан на стандарте C ++:

template<typename _InputIterator, typename _Predicate>
inline _InputIterator
__find_if(_InputIterator __first, _InputIterator __last,
    _Predicate __pred, input_iterator_tag)
{
    while (__first != __last && !bool(__pred(*__first)))
     ++__first;
       return __first;
}

Это функционально эквивалентно тому, что имеет стандарт, но не совсем то же самое. Это дает авторам гибкости гибкость. Там может быть лучший способ сделать это для конкретной платформы. Разработчик может захотеть использовать другой стиль кодирования.

Это особенно верно для языков сценариев, таких как python, поскольку разработчик может решить реализовать его на совершенно другом языке по соображениям производительности. Кто-то, реализующий Python, может, например, писать itertools.chain(*iterables)на C ++. Это прекрасно, если стандарт говорит «эквивалентно», если код делает то же самое, что и предоставленный Python. Если в стандарте вместо этого указано «есть», то разработчики должны будут либо реализовать на этом языке, либо не соответствовать стандарту.

В итоге:

Потому что они не хотят помешать реализации писать лучший код, чем предусмотрено стандартом
Потому что они не хотят помешать реализации использовать совершенно другой язык, чтобы улучшить производительность

— Горт Робот
источник

Спасибо за поучительный ответ! Я подозревал, что ответ был что-то в этом роде.

— Джон МакКлюнг

@lerenard, вам может показаться более полезным прочитать полную реализацию find_if по ссылке Стивена. (То, что у него там, на самом деле просто отрывок.)

— Уинстон Эверт

@WinstonEwert, к сожалению, я не совсем на уровне полного понимания такого кода, но либеральное использование подчеркиваний, безусловно, представляет интерес!

— Джон МакКлюнг

@lerenard: эти дополнительные начальные подчеркивания существуют для того, чтобы внутренние компоненты стандартной библиотеки не мешали написанному вами коду (имена с двойными нижними подчеркиваниями зарезервированы для использования авторами компиляторов / стандартных библиотек).

— Барт ван Инген Шенау

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

— Дедупликатор