Pourquoi la documentation de certaines langues dit-elle «équivalent à» plutôt que «est»?

Pourquoi la documentation de certaines langues dit "équivalent à" plutôt que "est"?

Par exemple, les documents Python disent

itertools.chain(*iterables)

...

Équivalent à:

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

Ou cette référence C ++ sur find_if:

Le comportement de ce modèle de fonction équivaut à:

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

Si ce n'est pas le code réel, ne peuvent-ils pas le publier? Et si c'est le code réel, pourquoi doivent-ils dire que c'est "équivalent" plutôt que simplement "est"?

— Jon McClung
source

Notez que ce que vous voyez find_ifn'est pas "la" documentation pour C ++. Si c'était le cas, alors le casting vers bool(que vous voyez dans la réponse ci-dessous) serait faux.

— Mehrdad

Dans le cas de python, si vous recherchez le code source, vous trouverez qu'il chainest implémenté directement en C, il est donc "équivalent" à ce code python car il produit le même résultat, mais il évite un peu de surcharge d'interprétation bytecode.

— Bakuriu

@Mehrdad Je sais que ce n'est pas la documentation officielle, c'est juste la ressource que j'ai trouvée la plus utile pour découvrir les détails du C ++

— Jon McClung

Ils seraient obligés d'utiliser toute approche définie dans la norme, même si une approche nettement meilleure était disponible.

— Kevin

Parce que les rédacteurs standard ne veulent pas réellement affirmer une implémentation. Ils veulent définir ce qu'il fait , mais pas nécessairement comment il le fait. Ainsi, par exemple, si vous regardez la version GNU C ++ defind_if , vous verrez que l'implémentation est légèrement différente de ce que vous donnez, qui est basée sur la norme 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;
}

Ceci est fonctionnellement équivalent à ce que la norme a, mais pas exactement le même. Cela donne aux rédacteurs du compilateur une flexibilité. Il peut y avoir une meilleure façon de le faire pour une plate-forme particulière. Le réalisateur peut souhaiter utiliser un style de codage différent.

Cela est particulièrement vrai pour les langages de script comme python dans la mesure où l'implémenteur peut décider de l'implémenter dans un langage complètement différent pour des raisons de performances. Une personne implémentant python peut, par exemple, écrire itertools.chain(*iterables)en C ++. C'est parfaitement bien si le standard dit "équivalent à" tant que le code fait la même chose que le python fourni. Si la norme dit «est» à la place, les implémenteurs devraient soit implémenter dans ce langage, soit ne pas respecter la norme.

En résumé:

Parce qu'ils ne veulent pas empêcher une implémentation d'écrire un meilleur code que le standard fourni
Parce qu'ils ne veulent pas empêcher une implémentation d'utiliser un langage entièrement différent, pour améliorer les performances

— Gort le robot
source

Merci pour la réponse éclairante! Je soupçonnais que la réponse allait dans ce sens.

— Jon McClung

@lerenard, vous trouverez peut-être plus instructif de lire l'implémentation complète de find_if à partir du lien de Steven. (Ce qu'il a là-bas n'est vraiment qu'un extrait.)

— Winston Ewert

@WinstonEwert, Malheureusement, je ne suis pas tout à fait au niveau de la compréhension complète du code comme ça, mais l'utilisation libérale des traits de soulignement est certainement un point d'intérêt!

— Jon McClung

@lerenard: Ces traits de soulignement principaux supplémentaires sont là pour que les internes de la bibliothèque standard n'interfèrent pas avec le code que vous pourriez écrire (les noms avec des soulignements doubles doubles sont réservés à l'usage des compilateurs / rédacteurs de bibliothèque standard).

— Bart van Ingen Schenau

Eh bien, en C et C ++, il y a toujours la règle comme si, donc même si le standard dit est au lieu d'être équivalent à, l'implémentation réelle peut différer.

— Déduplicateur