Dlaczego dokumentacja niektórych języków mówi „odpowiednik”, a nie „jest”?

23

Dlaczego w dokumentacji niektórych języków jest napisane „odpowiednik” zamiast „jest”?

Na przykład, mówią Python Docs

itertools.chain(*iterables)

...

Odpowiednik :

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

Lub to odwołanie do C ++ nafind_if :

Zachowanie tego szablonu funkcji jest równoważne z:

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;
}

Jeśli to nie jest prawdziwy kod, czy nie mogą go opublikować? A jeśli jest to rzeczywisty kod, dlaczego muszą powiedzieć, że to „ekwiwalent”, a nie po prostu „jest”?

Jon McClung
źródło
2
Zauważ, że to, co widzisz, niefind_if jest dokumentacją dla C ++. Gdyby tak było, rzutowanie na (co widać w odpowiedzi poniżej) byłoby błędne. bool
Mehrdad
3
W przypadku Pythona, jeśli szukasz kodu źródłowego, przekonasz się, że chainjest on zaimplementowany bezpośrednio w C, więc jest „równoważny” temu kodowi Pythona, ponieważ daje ten sam wynik, ale unika się narzutu związanego z interpretacją tego kod bajtowy.
Bakuriu
@ Mehrdad Wiem, że to nie jest oficjalna dokumentacja, to tylko zasób, który najbardziej pomógł mi w poznaniu szczegółów C ++
Jon McClung
Byliby zmuszeni do zastosowania jakiegokolwiek podejścia określonego w standardzie, nawet gdyby dostępne było znacznie lepsze podejście.
Kevin

Odpowiedzi:

67

Ponieważ zwykli pisarze nie chcą faktycznie potwierdzać implementacji. Chcą zdefiniować, co robi , ale niekoniecznie jak to robi. Na przykład, jeśli spojrzysz na wersję GNU C ++find_if , zobaczysz, że implementacja różni się nieco od tego, co dajesz, który jest oparty na standardzie 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;
}

Jest to funkcjonalnie równoważne z tym, co ma standard, ale nie dokładnie takie samo. Daje to autorom kompilatorów elastyczność. Może być lepszy sposób na zrobienie tego dla konkretnej platformy. Implementator może chcieć użyć innego stylu kodowania.

Jest to szczególnie prawdziwe w przypadku języków skryptowych takich jak Python, ponieważ implementator może zdecydować się na implementację w zupełnie innym języku ze względu na wydajność. Ktoś implementujący python może na przykład pisaćitertools.chain(*iterables) w C ++. Jest to całkowicie w porządku, jeśli standard mówi „ekwiwalent”, o ile kod robi to samo co podany python. Jeśli zamiast tego standard mówi „jest”, wówczas implementatorzy będą musieli albo wdrożyć w tym języku, albo nie spełnić standardu.

W podsumowaniu:

  1. Ponieważ nie chcą uniemożliwić implementacji pisania lepszego kodu niż podany standard
  2. Ponieważ nie chcą uniemożliwić implementacji użycia zupełnie innego języka, aby poprawić wydajność
Gort the Robot
źródło
Dziękuję za pouczającą odpowiedź! Podejrzewałem, że odpowiedź była podobna.
Jon McClung
@lerenard, może być bardziej pouczające, aby przeczytać pełną implementację find_if z linku Stevena. (To, co tam ma, to naprawdę tylko fragment.)
Winston Ewert
@WinstonEwert, Niestety nie jestem do końca w stanie w pełni zrozumieć takiego kodu, ale liberalne stosowanie podkreślników jest z pewnością przedmiotem zainteresowania!
Jon McClung
9
@lerenard: Te dodatkowe wiodące podkreślenia są tam, aby standardowe wewnętrzne biblioteki nie zakłócały kodu, który możesz napisać (nazwy z podwójnymi wiodącymi podkreślnikami są zarezerwowane do użytku przez kompilator / standardowych autorów bibliotek).
Bart van Ingen Schenau
5
Cóż, w C i C ++ istnieje zawsze zasada „tak, jakby”, więc nawet jeśli wspomniany standard jest zamiast równoważny, rzeczywista implementacja może się różnić.
Deduplicator