Perché i compilatori C ++ non definiscono operator == e operator! =?

Sono un grande fan di lasciare che il compilatore faccia il maggior lavoro possibile per te. Quando si scrive una classe semplice, il compilatore può fornire quanto segue come "gratuito":

• Un costruttore predefinito (vuoto)
• Un costruttore di copie
• Un distruttore
• Un operatore di assegnazione ( operator=)

Ma non può darti alcun operatore di confronto - come operator==o operator!=. Per esempio:

class foo
{
public:
    std::string str_;
    int n_;
};

foo f1;        // Works
foo f2(f1);    // Works
foo f3;
f3 = f2;       // Works

if (f3 == f2)  // Fails
{ }

if (f3 != f2)  // Fails
{ }

C'è una buona ragione per questo? Perché eseguire un confronto tra i membri sarebbe un problema? Ovviamente se la classe alloca memoria allora vorresti stare attento, ma per una semplice classe sicuramente il compilatore potrebbe fare questo per te?

Il compilatore non saprebbe se si desidera un confronto puntatore o un confronto approfondito (interno).

È più sicuro non implementarlo e lasciare che il programmatore lo faccia da solo. Quindi possono fare tutte le ipotesi che vogliono.

L'argomento secondo cui se il compilatore può fornire un costruttore di copie predefinito, dovrebbe essere in grado di fornire un valore predefinito simile operator==()ha un certo senso. Penso che il motivo della decisione di non fornire un valore predefinito generato dal compilatore per questo operatore possa essere intuito da ciò che Stroustrup ha detto a proposito del costruttore di copie predefinito in "The Design and Evolution of C ++" (Sezione 11.4.1 - Controllo della copia) :

Personalmente ritengo sfortunato che le operazioni di copia siano definite per impostazione predefinita e proibisco la copia di oggetti di molte delle mie classi. Tuttavia, C ++ ha ereditato la sua assegnazione predefinita e copia i costruttori da C, e vengono spesso utilizzati.

Quindi, invece di "perché C ++ non ha un valore predefinito operator==()?", La domanda avrebbe dovuto essere "perché C ++ ha un compito predefinito e un costruttore di copie?", Con la risposta che tali elementi sono stati inclusi con riluttanza da Stroustrup per la retrocompatibilità con C (probabilmente la causa della maggior parte delle verruche del C ++, ma probabilmente anche il motivo principale della popolarità del C ++).

Per i miei scopi, nel mio IDE lo snippet che utilizzo per le nuove classi contiene dichiarazioni per un operatore di assegnazione privato e costruttore di copia in modo che quando creo una nuova classe non ottengo operazioni di assegnazione e copia predefinite, devo rimuovere esplicitamente la dichiarazione di tali operazioni dal private: sezione se voglio che il compilatore sia in grado di generarle per me.

Anche in C ++ 20, il compilatore non genererà ancora implicitamente operator==per te

struct foo
{
    std::string str;
    int n;
};

assert(foo{"Anton", 1} == foo{"Anton", 1}); // ill-formed

Ma otterrai la possibilità di eseguire il default in modo esplicito == dal C ++ 20 :

struct foo
{
    std::string str;
    int n;

    // either member form
    bool operator==(foo const&) const = default;
    // ... or friend form
    friend bool operator==(foo const&, foo const&) = default;
};

L' impostazione predefinita ==fa il membro ==(nello stesso modo in cui il costruttore di copie predefinito fa la costruzione della copia del membro). Le nuove regole forniscono anche la relazione prevista tra ==e !=. Ad esempio, con la dichiarazione sopra, posso scrivere entrambi:

assert(foo{"Anton", 1} == foo{"Anton", 1}); // ok!
assert(foo{"Anton", 1} != foo{"Anton", 2}); // ok!

Questa caratteristica specifica (default operator==e simmetria tra ==e !=) proviene da una proposta che faceva parte della più ampia funzionalità linguistica che è operator<=>.

IMHO, non esiste una "buona" ragione. Il motivo per cui ci sono così tante persone che concordano con questa decisione progettuale è perché non hanno imparato a dominare il potere della semantica basata sul valore. Le persone devono scrivere molti costruttori di copie personalizzate, operatori di confronto e distruttori perché usano puntatori non elaborati nella loro implementazione.

Quando si utilizzano i puntatori intelligenti appropriati (come std :: shared_ptr), il costruttore di copie predefinito di solito va bene e l'ovvia implementazione dell'ipotetico operatore di confronto predefinito andrebbe bene.

Ha risposto che C ++ non ha fatto == perché C no, ed ecco perché C fornisce solo default = ma no == al primo posto. C voleva mantenerlo semplice: C implementato = da memcpy; tuttavia, == non può essere implementato da memcmp a causa del riempimento. Poiché il padding non è inizializzato, memcmp afferma che sono diversi anche se sono uguali. Lo stesso problema esiste per la classe vuota: memcmp dice che sono diversi perché la dimensione delle classi vuote non è zero. Si può vedere dall'alto che l'implementazione == è più complicata dell'implementazione = in C. Alcuni esempi di codice al riguardo. La tua correzione è apprezzata se sbaglio.

In questo video Alex Stepanov, il creatore di STL affronta questa domanda alle 13:00 circa. Riassumendo, avendo osservato l'evoluzione del C ++, sostiene che:

• È un peccato che == e! = Non siano dichiarati implicitamente (e Bjarne è d'accordo con lui). Un linguaggio corretto dovrebbe avere quelle cose pronte per te (prosegue suggerendo che non dovresti essere in grado di definire un ! = Che rompe la semantica di == )
• Il motivo per cui questo è il caso ha le sue radici (come molti dei problemi di C ++) in C. Lì, l'operatore di assegnazione è implicitamente definito con assegnazione bit per bit ma ciò non funzionerebbe per == . Una spiegazione più dettagliata può essere trovata in questo articolo di Bjarne Stroustrup.
• Nella domanda di follow-up Perché allora non è stato usato un membro per confronto dei membri , dice una cosa incredibile : C era una specie di linguaggio casalingo e il ragazzo che implementava queste cose per Ritchie gli disse che trovava difficile implementarlo!

Quindi dice che in un futuro (distante) == e ! = Verranno generati implicitamente.

C ++ 20 fornisce un modo per implementare facilmente un operatore di confronto predefinito.

Esempio da cppreference.com :

class Point {
    int x;
    int y;
public:
    auto operator<=>(const Point&) const = default;
    // ... non-comparison functions ...
};

// compiler implicitly declares operator== and all four relational operators work
Point pt1, pt2;
if (pt1 == pt2) { /*...*/ } // ok, calls implicit Point::operator==
std::set<Point> s; // ok
s.insert(pt1); // ok
if (pt1 <= pt2) { /*...*/ } // ok, makes only a single call to Point::operator<=>

Non è possibile definire il valore predefinito ==, ma è possibile definire il valore predefinito !=tramite il ==quale di solito è necessario definire voi stessi. Per questo dovresti fare le seguenti cose:

#include <utility>
using namespace std::rel_ops;
...

class FooClass
{
public:
  bool operator== (const FooClass& other) const {
  // ...
  }
};

Puoi vedere http://www.cplusplus.com/reference/std/utility/rel_ops/ per i dettagli.

Inoltre, se definito operator< , gli operatori per <=,>,> = possono essere dedotti da esso durante l'utilizzo std::rel_ops.

Ma dovresti stare attento quando lo usi std::rel_opsperché gli operatori di confronto possono essere dedotti per i tipi che non ti aspetti.

È preferibile utilizzare un modo più preferito di dedurre l'operatore correlato da quello base boost :: operatori .

L'approccio utilizzato in boost è migliore perché definisce l'utilizzo dell'operatore per la classe desiderata, non per tutte le classi nell'ambito.

Puoi anche generare "+" da "+ =", - da "- =", ecc ... (vedi l'elenco completo qui )

C ++ 0x ha avuto una proposta per funzioni predefinite, quindi potresti dire default operator==; che abbiamo imparato che aiuta a rendere esplicite queste cose.

Concettualmente non è facile definire l'uguaglianza. Anche per i dati POD, si potrebbe sostenere che anche se i campi sono uguali, ma è un oggetto diverso (a un indirizzo diverso) non è necessariamente uguale. Questo in realtà dipende dall'uso dell'operatore. Sfortunatamente il tuo compilatore non è sensitivo e non può dedurlo.

Oltre a ciò, le funzioni predefinite sono ottimi modi per spararsi al piede. Le impostazioni predefinite che descrivi sono sostanzialmente lì per mantenere la compatibilità con le strutture POD. Tuttavia, causano il caos più che sufficiente con gli sviluppatori che se ne dimenticano o la semantica delle implementazioni predefinite.

C'è una buona ragione per questo? Perché eseguire un confronto tra i membri sarebbe un problema?

Potrebbe non essere un problema dal punto di vista funzionale, ma in termini di prestazioni, il confronto predefinito membro per membro può essere più subottimale rispetto all'assegnazione / copia dei membri predefiniti. Diversamente dall'ordine di assegnazione, l'ordine di confronto influisce sulle prestazioni poiché il primo membro disuguale implica che il resto può essere ignorato. Quindi, se ci sono alcuni membri che di solito sono uguali, si desidera confrontarli per ultimi e il compilatore non sa quali membri hanno più probabilità di essere uguali.

Considera questo esempio, in cui verboseDescriptionè selezionata una stringa lunga da una serie relativamente piccola di possibili descrizioni meteorologiche.

class LocalWeatherRecord {
    std::string verboseDescription;
    std::tm date;
    bool operator==(const LocalWeatherRecord& other){
        return date==other.date
            && verboseDescription==other.verboseDescription;
    // The above makes a lot more sense than
     // return verboseDescription==other.verboseDescription
     //     && date==other.date;
    // because some verboseDescriptions are liable to be same/similar
    }
}

(Ovviamente il compilatore avrebbe il diritto di ignorare l'ordine dei confronti se riconosce che non hanno effetti collaterali, ma presumibilmente prenderebbe comunque la sua coda dal codice sorgente dove non ha migliori informazioni.)

Solo così le risposte a questa domanda rimangono complete col passare del tempo: dal C ++ 20 può essere generato automaticamente con comando auto operator<=>(const foo&) const = default;

Genererà tutti gli operatori: ==,! =, <, <=,> E> =, vedi https://en.cppreference.com/w/cpp/language/default_comparisons per i dettagli.

A causa dell'aspetto dell'operatore <=>, si chiama operatore dell'astronave. Vedi anche Perché è necessario l'operatore navicella spaziale <=> in C ++? .

EDIT: anche in C ++ 11 un sostituto abbastanza pulito per questo è disponibile con std::tievedere https://en.cppreference.com/w/cpp/utility/tuple/tie per un esempio di codice completo con bool operator<(…). La parte interessante, modificata per funzionare ==è:

#include <tuple>

struct S {
………
bool operator==(const S& rhs) const
    {
        // compares n to rhs.n,
        // then s to rhs.s,
        // then d to rhs.d
        return std::tie(n, s, d) == std::tie(rhs.n, rhs.s, rhs.d);
    }
};

std::tie funziona con tutti gli operatori di confronto ed è completamente ottimizzato dal compilatore.

Sono d'accordo, per le classi di tipo POD il compilatore potrebbe farlo per te. Tuttavia, ciò che potresti considerare semplice potrebbe essere sbagliato nel compilatore. Quindi è meglio lasciare che il programmatore lo faccia.

Una volta ho avuto un caso POD in cui due dei campi erano unici, quindi un confronto non sarebbe mai stato considerato vero. Tuttavia, il confronto di cui avevo bisogno solo rispetto al payload - qualcosa che il compilatore non avrebbe mai capito o avrebbe mai potuto capire da solo.

Inoltre - non ci mettono molto a scrivere, vero ?!