Warum gibt es keinen Standard-Vergleichsoperator?

peterchen

wie gesagt, das gleiche bekommst du ja auch mit einem member hin, statt des Macros - mußt dem halt nur einen namen geben. (weiß nur nicht, ob der compiler den ohne speicher anlegen darf)

Ich würd ein Macro nur verwenden, wenn es wirklich nicht anders geht.

volkard

peterchen schrieb:

wie gesagt, das gleiche bekommst du ja auch mit einem member hin, statt des Macros - mußt dem halt nur einen namen geben. (weiß nur nicht, ob der compiler den ohne speicher anlegen darf)

darf er nicht. aber dafür benutzt das makro netterweise mit #ifndef NDEBUG...
also nullkosten in der release-version.

peterchen

schad - also basisklasse

Walli

peterchen schrieb:

Ich würd ein Macro nur verwenden, wenn es wirklich nicht anders geht.

Ich würde ehrlich gesagt so nen Mist garnicht verwenden. Mir passiert es so selten, dass ein Objekt nicht kopiert werden darf... Ich sage ja nur, dass ich es logischer finde als eine Basisklasse.

volkard

MaSTaH schrieb:

peterchen schrieb:

Ich würd ein Macro nur verwenden, wenn es wirklich nicht anders geht.

Ich würde ehrlich gesagt so nen Mist garnicht verwenden. Mir passiert es so selten, dass ein Objekt nicht kopiert werden darf...

falsche sichtweise.
es geht nicht darum, ob der rechner beim kopieren abschmieren würde, sondern darum, ob das kopieren irgendeinen sinn hat.
klar kann man nicht sachen wie File, Semaphore oder Process kopieren.
klar ist es sinnvoll Datum, String oder Schuhgroesse zu kopieren.
aber Person, Subnetz und FtpServer dürfen inhaltlich nicht kopiert werden. wer das tut, hat im programm sicher nen ligischen fehler.
im weiteren ist es sogar so signifikant oft schwachfug, LinkedList, HashTable und FileHandle zu kopieren, daß man die ruhig auch verbieten sollte.
lies "effektiv c++ programmieren". das tut helfen, die einstellung ein wenig in richtung bewußter bugvermeidung zu lenken.

Walli

Danke, ich habe es gelesen. Dass ich es nicht zu 100%ig verinnerlicht habe, da es für mich auch Bildung jenseits von C++ gibt mag man mir verzeihen. Ausserdem hast du meine Aussage vollkommen aus dem Zusammenhang gerissen. Ich habe nicht das verbieten des Copy-C'tors und des Zuweisungsoperators als Mist bezeichnet, sondern die "abkürzenden" Lösungen, von (denen ich selber eine gepostet hatte). In den paar Fällen, in denen man das Kopieren verbieten will ist es ein durchaus vertretbarer Aufwand die Sachen per Copy&Paste einzufügen.

otze

volkard schrieb:

otze schrieb:
sicher kann man sonen op machen:
foo& operator=(foo Operand){
    std::swap(*this,temp);
}
aber das wäre bei simpel klassen von der performance her absolute verschwendung...
jo. evtl fehlt da noch
foo temp(Operand);
eigentlich sollte das der automatisch generierte sein. kommt ja vielleicht im c++-standard 2070 rein.
simple typen, insbesondere pods kann der optimierer ja wieder raushauen. und wenn der typ fett genug ist, ne exception zu werfen, sind die kosten eher irrelevant.

da muss kein foo temp(Operand) rein, ich übergeb ja keine referenz sondern eine kopie,aber der fehler im swap kommte daher, da ichd en operator erst in der form hatte:

foo& operator=(const foo& Operand){
    foo temp(Operand);
    std::swap(*this,Operand);
}

dann hab ich aus dem operand ne kopie gemacht, und bei swap dann aus müdigkeit vergessen temp durch operand zu ersetzen^^

HumeSikkins

In den paar Fällen, in denen man das Kopieren verbieten will ist es ein durchaus vertretbarer Aufwand die Sachen per Copy&Paste einzufügen.

Imo ist ein Makro bzw. eine Klasse hier kein Mittel zur Aufwandsreduzierung sondern zur Dokumentationsverbesserung. Ich bau mir ein Konzept "Nicht kopierbar" und verwende es da wo nötig. Mit den schönen Vorteilen wie:
1. Ich habe nur genau einen Punkt an dem das Konzept implementiert ist. Nicht 3423. Damit habe ich auch nur eine Stelle, die ich im Zweifelsfalls ändern muss.

2. Ich habe einen klaren sprechenden Namen der die Semantik nicht die Implementation in den Vordergrund stellt statt drei komischer Zeilen Quellcode die in drei Projekten sechsmal anders kommentiert wurden.

3. Ich kann zusätzliche Dokumentation an genau eine Stelle schreiben.

Usw...

peterchen

@otze:
warte...

Wenn ich dich recht verstehe, willst du aus dem operator= 'ne Transaktion machen? d.h. wenn eine exception fliegt, soll der komplette alte Stand drin bleiben.

Wenn aber jetzt im swap(*this, temp) (das ja wieder ein operator= macht) eine exception fliegt, bin ich doch nicht besser dran als vorher, oder?
oder raff' ich's nicht?

otze

in swap darf keine exception geworfen werden, swap hat die höchste sicherheitsgarantie: unter keinen umständen darf eine exception nach außen dringen

peterchen

Das gilt aber nur für die speziellen Versionen von Container-Klassen, oder?
Das globale Template ist ja als temp(a); a=b; b=temp implementiert (wüßte auch gar nicht wie sonst)

otze

arrgh jetzt weis ich was du meinst, und keiner hier hats vorher gemerkt

foo& operator=(const foo& Operand){
    foo temp(Operand);
    std::swap(*this,Operand);
}

des erzeugt ne schöne rekursion

class foo{
        int member;
    public:
        foo& operator=(const foo& Operand){
             foo temp(Operand);
             std::swap(this->member,Operand.member);
        }

das erzeugt keine rekursion, und nie fehler