Pourquoi utiliser “b < a ? a : b” au lieu de “a < b ? b:” pour mettre en œuvre max modèle?

Les Modèles C++ - Le Guide Complet de la 2e Édition introduit le max modèle: 

template<typename T>
T max (T a, T b)
{
  //if b < a then yield a else yield b
  return  b < a ? a : b;
}

Et il explique à l'aide de “b < a ? a : b” au lieu de “a < b ? b : a”:

Noter que le max() modèle selon [StepanovNotes]
intentionnellement renvoie “b < a ? a : b” au lieu de “a < b ? b:” à
s'assurer que la fonction se comporte correctement, même si les deux valeurs sont
équivalent, mais n'est pas égal.

Comment comprendre les "even if the two values are equivalent but not equal."? “a < b ? b : a” semble avoir le même résultat pour moi.

  • Regarde mal pour moi... les Deux réponses sont "correctes", mais si a et b sont équivalent, puis !(a < b) && !(b < a) est vrai, alors a < b et b < a sont faux, donc dans b < a ? a : b, b est retourné, ce qui n'est pas ce que vous voulez... Vous voulez a < b ? b : a.
  • Vous pouvez souvent distinguer entre l'équivalent a et b avec std::addressof et. al.
  • Si vous ne a = max(a, b); (à plusieurs reprises), vous pourriez ne pas vouloir remplacer a inutilement.
  • BTW, ce modèle doit prendre des paramètres par const-références et de les retourner par la const-référence, sinon, vous faites un tas de copies inutiles (et vous allez remplacer a avec une copie de a).
  • L'canonique de type qui a à la fois de l'équivalence et de l'égalité est la CaseInsensitiveString. Pour ce type, ni un<A ni<un. Mais std::addressof n'est pas pertinent. En fait, pour le T max(T a, T b) nous savons déjà addressof(a) != addressof(b).
  • ah, je pensais std::max, n'a pas remarqué le modèle de valeur
  • Vous pouvez consulter Stepano v Notes sur la Programmation pour plus de détails j'ai tweeté à propos de cette après la lecture que parce que l'explication n'était pas assez détaillée.
  • Hilarant. Combien de programmeurs c++ ne prend-il pour écrire le max fonction? Ils devraient peut-être faire deux fonctions maxFirstIfEqual et maxSecondIfEqual juste pour rendre les choses encore plus risible.

InformationsquelleAutor Nan Xiao | 2018-06-13
  1. 151

    std::max(a, b) est en effet spécifié pour revenir a lorsque les deux sont équivalents.

    Qui est considéré comme une erreur par Stepanov et les autres, car il se décompose de la propriété utile que, compte tenu de a et b, vous pouvez toujours les trier avec {min(a, b), max(a, b)}; pour que, vous voulez max(a, b) de retour b lorsque les arguments sont équivalentes.

    • À partir de ce lien ", Il m'est difficile de blâmer les gens qui le faire: après tout, ils ont juste suivre la norme C++ spécification de max écrit par moi. Il m'a fallu plusieurs années pour voir que je me trompais." - wow!
    • tu ne peux pas faire {min(a, b), max(b, a)}?
    • Oui, mais c'est encore moins évident. Je dirais que c'est tout à fait logique que max(a,b) en retourner une si-et-seulement-si min(a,b) retourne b, et vice versa, de sorte qu'ils sont à l'inverse les uns des autres et de la (non ordonnée) ensemble {min(a,b), max(a,b)} est toujours égale à {a,b}.
    • vous avez mentionné non ordonnée, mais j'ai voulu commandé parce que, dans la réponse de T. C. mentionne les "sauts de la propriété utile que [...] vous pouvez toujours les trier avec {min(a, b), max(a, b)}"
    • Oui, j'avais bien compris. Ne pensez-vous pas le bien que je l'ai mentionné plus de sens que d'une mise en œuvre sans? Pour moi, max(a, b) et min(a, b) doit toujours renvoyer des réponses différentes.
    • Ouais, je pense que c'est bien, mais mon commentaire d'origine a été à venir à partir d'un lieu d'incertitude, pas de sarcasme 🙂 Ensuite, j'ai été à essayer de comprendre pourquoi vous avez été de mentionner non ordonnée fixe lorsque l'exemple est une liste ordonnée. (Je comprends maintenant ce que vous vouliez dire "la (non ordonnée) set de {min(a,b), max(a,b)}")
    • Je suis désolé que vous avez compris mon commentaire comme penser que vous êtes sarcastique. Ce n'était pas mon intention, mais plutôt d'expliquer pourquoi la propriété est logique à partir d'un autre point de vue. Si vous suivez le lien vers le papier de Stephanov, vous verrez qu'il donne un autre exemple que celui de T. C. a donné et la façon dont je l'ai mis 🙂
    • Peut ajouter le mot "stable", peut-être? Vous pouvez toujours trier (sans le mot "stable") juste bien si std::max est ce que c'est, si les deux sont équivalents, ils sont triés correctement peu importe à qui on vient en premier et que l'on vient en dernier.
    • L'ordre est bien, faire a, b en a, a ne l'est pas.
    • Comment est-il pas bien que a est équivalent à b? Si ils ne sont pas complètement interchangeables, ils ne devraient pas être égaux. Il me semble que le problème est avec la conception du contenu de a et b, pas avec max ou min.
    • Si l'on est par exemple le tri d'une liste d'évènements en temps, on n'a pas besoin de savoir si l'opération de tri est stable pour se soucier de faire de chaque événement qui apparaît exactement une fois dans l'entrée, de même apparaissent exactement une fois dans la sortie. Certaines opérations (comme c'est de trouver et d'éliminer les événements dupliqués) peut nécessiter l'utilisation d'un ordonnancement complet, mais dans de nombreux autres cas, il peut être acceptable à la liste des événements simultanés dans un ordre arbitraire, mais pas de les reproduire ou de les omettre.
    • L'application de min et max à rien, mais la timestamp (la clé de tri) dans ce scénario n'a aucun sens. Les événements (les objets) eux-mêmes ne devraient même pas être comparables si l'égalité ne signifie pas l'interchangeabilité. La seule façon {min(a, b), max(a, b)} fait aucun sens comme une sorte de mécanisme est si les objets sont interchangeables.

    InformationsquelleAutor T.C.
  2. 63

    Cette réponse explique pourquoi le code est faux à partir d'un C++ standard point-de-vue, mais il est hors de contexte.

    Voir @T. C. la réponse de pour une explication contextuelle.

    La norme définit std::max(a, b) comme suit [alg.min.max] (l'emphase est mienne):

    template<class T> constexpr const T& max(const T& a, const T& b);

    Nécessite: Type T est LessThanComparable (Tableau 18).

    Retourne: la valeur La plus grande.

    Remarques: Renvoie le premier argument lorsque les arguments sont équivalentes.

    Équivalent ici signifie que !(a < b) && !(b < a) est true [alg.le tri#7].

    En particulier, si a et b sont équivalent, les deux a < b et b < a sont false, de sorte que la valeur sur le droit de : sera renvoyé à l'opérateur conditionnel, donc a doit être sur la droite, donc:

    a < b ? b : a

    ...semble être la bonne réponse. C'est la version utilisée par libstdc++ et libc++.

    De sorte que l'information dans votre citation semble erroné selon la norme actuelle, mais le contexte dans lequel elle est définie peuvent être différentes.

    • Godbolt lien qui explique le problème (merci @songyuanyao pour la définition de X).
    • J'ai édité la réponse à préciser que le raisonnement des cibles de la norme actuelle.
    • J'étais en fait référence à "Si nous définissons equiv(a, b)!comp(a, b) && !comp(b, a)". J'ai changé le lien pour une meilleure citation (3 lignes ci-dessous dans la norme... ).
    • Surpris personne n'a mentionné à virgule flottante, où a<b et b<a peut à la fois être faux parce qu'ils sont non ordonnée (un ou deux NaN, donc == est faux aussi). Qui pourrait être considéré comme une sorte d'équivalence. vaguement liés: x86 est maxsd a, b instruction met en œuvre a = max(b,a) = b < a ? a : b. (Quelle est l'instruction qui donne sans branches FP min et max sur x86?). L'instruction continue la source et l'opérande (le 2ème) sur la non-ordonnée, donc une boucle sur un tableau, vous donnera NaN si il y avait des NaNs. Mais max_seen = max(max_seen, a[i]) ignore les NaNs.
    • Voir aussi Stepanov Notes sur la Programmation
    InformationsquelleAutor Holt
  3. 21

    Le point qui devra être retourné quand ils sont l'équivalent; std::max a retourner a (le premier argument) pour ce cas.

    Si elles sont équivalentes, renvoie a.

    Donc a < b ? b : a doit être utilisée; d'autre part, b < a ? a : b; sera de retour b de manière incorrecte.

    (Comme @Holt dit, la citation semble être le contraire.)

    "les deux valeurs sont équivalentes, mais pas l'égalité" signifie qu'ils ont la même valeur lors de la comparaison, mais ils migth être différents objets à certains autres aspects.

    par exemple

    struct X { int a; int b; };
bool operator< (X lhs, X rhs) { return lhs.a < rhs.a; }
X x1 {0, 1};
X x2 {0, 2};
auto x3 = std::max(x1, x2); //it's guaranteed that an X which cantains {0, 1} is returned
    • Pourriez-vous préciser pourquoi std::max(a, b) a retourner a, si a et b sont-elles équivalentes?
    • href="https://timsong-cpp.github.io/cppwp/n4659/alg.min.max#11" >C'est juste un choix arbitraire sur la norme de la partie. Si c'est un peu discutable si elle est bonne.
    • Est-ce juste moi ou est-ce en contradiction avec la question? Si a et b sont équivalentes, alors !(a < b) && !(b < a) est vrai, alors a < b et b < a sont fausses, alors... ?
    • Je suppose que la norme veut juste pour le faire connaître; quand elles sont équivalentes dont l'une doit être retourné.
    • grâce à l'actualisation de mon mémoire sur laquelle un objet serait "l'équivalent", mais pas "égaux".
    InformationsquelleAutor songyuanyao