Surcharge à la fois opérateur et lt; et opérateur & gt; dans la même classe

Dans mes devoirs, je dois concevoir une classe de Message; entre autres attributs, il a l'attribut de "priorité" (objectif principal est de mettre en œuvre la priorité de la file d'attente).

Comme dans un conteneur je doit vérifier si un objet est plus grande que les autres, j'ai surchargé l'opérateur " >'. Maintenant, j'ai quelques questions d'ordre général à ce sujet...

Question:

En cas de surcharge de l'opérateur " >', dois-je la surcharge de l'opérateur "< " pour les arguments (const Message&, const Message&)?

Mon avis est que la surcharge à la fois > et < et de l'utiliser dans le code génère une erreur:

if(message1 > message2)
   { ... }

(Le code suivant appelle l'opérateur > pour message1 objet, ou de l'opérateur < message2 objet?)

Mais, si j'utilise l'opérateur comme ceci:

if(message1 < message2)
   { ... }

?

opérateur> est déclaré en tant qu'ami de la fonction:

friend bool operator>(const Message& m1, const Message& m2)

T-il besoin d'être déclarés en tant que membre de la fonction?

Merci.

source d'informationauteur Nemanja Boric

  1. 23

    En cas de surcharge de l'opérateur " >', dois-je la surcharge de l'opérateur "< " pour argumenst (const Message&, const Message&)?

    Oui. En fait, c'est la convention dans la plupart des code de préférer l'utilisation de < sur > (ne me demandez pas pourquoi, probablement historique). Mais plus généralement, toujours la surcharge de l'ensemble des opérateurs; dans votre cas, ce serait sans doute également être ==!=<= et >=.

    (Le code suivant appelle l'opérateur > pour message1 objet, ou de l'opérateur < message2 objet?)

    Il appelle toujours ce qu'il trouve dans le code. Pour le compilateur C++, il n'y a absolument aucun lien entre > et <. Pour nous, ils ont l'air semblables, mais le compilateur voit deux choses complètement différentes, sans rapport avec les symboles. Donc il n'y a pas d'ambiguïté: le compilateur appelle ce qu'il voit.

    T-il besoin d'être déclarés en tant que membre de la fonction?

    Pas. En fait, il est préférable de ne pas déclarée en tant que membre de la fonction. Déclarant comme une fonction membre qui signifie que le premier argument (c'est à dire la partie gauche de l'expression) doit vraiment être un Message objet, plutôt qu'un objet qui est implicitement convertible en un Message.

    Pour le comprendre, considérons le cas suivant:

    struct RealFraction {
    RealFraction(int x) { this.num = x; this.den = 1; }
    RealFraction(int num, int den) { normalize(num, den); }
    //Rest of code omitted.

    bool operator <(RealFraction const& rhs) {
        return num * rhs.den < den * rhs.num;
    }
};

    Maintenant, vous pouvez écrire la comparaison suivante:

    int x = 1;
RealFraction y = 2;
if (y < x) …

    mais vous ne peut pas écrire ce qui suit:

    if (x < y) …

    bien qu'il en existe une conversion implicite de int à RealFraction (en utilisant le premier constructeur).

    Si, d'autre part, on avait utilisé une non-fonction membre pour mettre en œuvre l'opérateur, à la fois les comparaisons de travail parce que le C++ serait de savoir à l'appel implicite du constructeur sur le premier argument.

  2. 10

    Oui, vous devriez vous... mais vous pouvez (et devraient sans doute) de mettre en œuvre trois des <><=>= en termes de l'autre. Cela leur permet de se comporter de manière cohérente. Généralement < est celui dont les autres sont mises en œuvre en termes de parce qu'il est l'opérateur par défaut utilisé dans sets et maps.

    E. g. si vous avez mis en œuvre <vous pouvez définir ><= et >= comme ça.

    inline bool operator>(const Message& lhs, const Message& rhs)
{
    return rhs < lhs;
}

inline bool operator<=(const Message& lhs, const Message& rhs)
{
    return !(rhs < lhs);
}

inline bool operator>=(const Message& lhs, const Message& rhs)
{
    return !(lhs < rhs);
}

    == et != sont souvent mises en œuvre séparément. Parfois, les classes implémentent == tels que a == b si et seulement si !(a < b) && !(b < a) mais parfois == est mis en œuvre comme une plus stricte relation de !(a < b) && !(b < a). Cela n'résultat plus de complexité pour les clients de la classe, si.

    Dans certaines situations, peut être acceptable d'avoir <><= et >= mais pas == ou !=.

  3. 5

    Si l'affectation n'est pas explicitement que l'utilisation de la surcharge d'opérateur, vous pourriez aussi envisager d'utiliser un objet de fonction. La raison en est qu'il ya probablement plus d'une façon de comparer deux Messages pour le "moins-que" (e.g de comparer le contenu de manière lexicographique, affichage de l'heure, etc.), et donc le sens de operator< n'est pas intuitivement clair.

    Avec std::priority_queue l'objet de fonction à utiliser est spécifié en tant que troisième paramètre du modèle (malheureusement, vous devez également spécifier le deuxième sous-jacent type de conteneur):

    #include <queue>
#include <string>
#include <functional>
#include <vector>

class Message
{
    int priority;
    std::string contents;
    //...
public:
    Message(int priority, const std::string msg):
        priority(priority),
        contents(msg)
    {}
    int get_priority() const { return priority; }
    //...
};

struct ComparePriority:
    std::binary_function<Message, Message, bool> //this is just to be nice
{
    bool operator()(const Message& a, const Message& b) const
    {
        return a.get_priority() < b.get_priority();
    }
};

int main()
{
    typedef std::priority_queue<Message, std::vector<Message>, ComparePriority> MessageQueue;
    MessageQueue my_messages;
    my_messages.push(Message(10, "Come at once"));
}

    Lors de la mise en œuvre de votre propre file d'attente de priorité, vous pouvez aller à ce sujet de la manière suivante:

    class MessageQueue
{
    std::vector<Message> messages;
    ComparePriority compare;
    //...
    void push(const Message& msg)
    {
        //...
        if (compare(msg, messages[x])) //msg has lower priority
        //...
    }
};