man kann ja das Kopieren, Zuweisen und auch sämtliche Operatoren einer Klasse verbieten, indem man die entsprechenden Methoden private/explicit macht. Die wenigsten Klassen, die ich so geschrieben habe, sollen kopiert, zugewiesen oder sonst wie mit Operatoren behandelt werden.

Wenn ihr solche Klassen habt, verbietet ihr dann wirklich jeden Operator extra, weil das sind ja schon eine ganze Menge? Oder wie soll sonst der Anwender mitbekommen, dass er Objekte der Klassen beispielsweise nicht inkrementieren kann/soll?

Ich hoffe es versteht einer was ich meine^^

class foo
{
  // ...
private:
  foo(const foo&);
  foo& operator = (const foo&);
};

Fertig.

Ich hatte gedacht dass der Compiler auch automatisch die Operatoren anlegt, wie beim Kon-/Destruktor etc., dass war mein Fehler.

Und ja, natürlich mache ich alle Klassen non-copyable und non-assignable wenn der implizit definierte Copy-Ctor oder Assignment-Operator Mist bauen würde.
Ausgenommen natürlich die Klassen die kopierbar oder zuweisbar sein sollen/müssen, in dem Fall definiere ich dann eben selbst einen passenden Copy-Konstruktor/Assignment-Operator.

ps:
Wenn man nicht in jeder "noncopyable" Klasse den Copy-Konstruktor und Assignent-Operator private machen will bietet sich boost::noncopyable an.
Finde ich auch übersichtlicher/leserlicher

class Foo : private boost::noncopyable
{
...
};

Bzw. wenn man Boost nicht verwenden will/kann ist so eine "noncopyable" Klasse auch in ein paar Sekunden selbst geschrieben.

= delete;

was ich persönlich schöner finde. Die großen 5 (C++11) deklariere ich immer. Wenn ich sie nicht selbst implementiere, deklariere ich sie mit

= default;

.

es werden nur ctor, dtor, copy, assignment von alleine angelegt

In C++11 kommen noch move-Ctor und move-Assignment dazu...

_sone_dreck schrieb:

es werden nur ctor, dtor, copy, assignment von alleine angelegt

In C++11 kommen noch move-Ctor und move-Assignment dazu...

Noch nicht ganz wach? Die werden so nicht automatisch generiert.

pumuckl schrieb:

_sone_dreck schrieb:

es werden nur ctor, dtor, copy, assignment von alleine angelegt

In C++11 kommen noch move-Ctor und move-Assignment dazu...

Noch nicht ganz wach? Die werden so nicht automatisch generiert.

Ich liefer gleich den Standard:

N3337 §12.8 Klausel 9 schrieb:

If the definition of a class X does not explicitly declare a move constructor, one will be implicitly declared
as defaulted if and only if
— X does not have a user-declared copy constructor,
— X does not have a user-declared copy assignment operator,
— X does not have a user-declared move assignment operator,
— X does not have a user-declared destructor, and
— the move constructor would not be implicitly defined as deleted.

N3337 §12.8 Klausel 20 schrieb:

If the definition of a class X does not explicitly declare a move assignment operator, one will be implicitly
declared as defaulted if and only if
— X does not have a user-declared copy constructor,
— X does not have a user-declared move constructor,
— X does not have a user-declared copy assignment operator,
— X does not have a user-declared destructor, and
— the move assignment operator would not be implicitly defined as deleted.

— the move constructor would not be implicitly defined as deleted.

Wann gilt der Punkt denn?

Die großen 5 (C++11) deklariere ich immer.

Lustig, ich fast nie.

Zumindest was die Grossen Drei angeht, sehe ich es von Vorteil, wenn die Member bereits Wertsemantik besitzen und automatisch kopiert werden. Das spart viel Boilerplatecode und auch mögliche Fehler, weil die Kopie eines Members vergessen wird. Bei Klassen, die Exceptions werfen, muss man allerdings etwas aufpassen...

Nexus schrieb:

Cyres schrieb:

Die großen 5 (C++11) deklariere ich immer.

Lustig, ich fast nie.

Ich persönlich finde es übersichtlicher, und auf die zwei Zeilen Code kommt es dann echt nicht mehr an. Rein Interesse halber, benutzt (falls du die Wahl hast) du "#pragma once" oder lieber Header-Guards?

Hm, fast alle aktuellen Compiler scheinen #pragma once zu unterstützen. Kennt ihr Beispiele, wo es nicht funktioniert? Sonst überlege ich mir, das auch in portablem Code zu verwenden.

Wann immer möglich #pragma once . In einer plattformunabhängigen Bibliothek allerdings Header-Guards.

Hm, fast alle aktuellen Compiler scheinen #pragma once zu unterstützen. Kennt ihr Beispiele, wo es nicht funktioniert? Sonst überlege ich mir, das auch in portablem Code zu verwenden.

Mir sind keine Probleme bekannt, als ich rausgefunden habe, dass auch der GCC (und Clang) #pragma once unterstützen, hatte ich auch viel geändert, ich frage deshalb, weil da wieder die beiden Zeilen wären, die man sich bei #pragma once sparen würde

Genau was ich sagte..

Nope. Du sagtest "die werden nicht automatisch generiert". Werden sie aber doch, wenn alle anderen auch automatisch generiert werden.

Eisflamme schrieb:

N3337 §12.8 Klausel 9 schrieb:

— the move constructor would not be implicitly defined as deleted.

Wann gilt der Punkt denn?

Ich überlasse das Flöhen des Standards an der Stelle mal anderen, aber da der generierte Move-Ctor einfach alle Member moved, würde ich mal annehmen, dass das dann der Fall ist, wenn einer der Member nicht movable ist.

Kennt ihr Beispiele, wo es nicht funktioniert?

IBM XL C++ for AIX

Meines Wissens erkenne viele Präprozessoren include-Guards aber als das was sie sind und haben eine spezielle Merkvorrichtung dafür, d.h. #pragma once ist dann auch nicht schneller.

Cyres schrieb:

Die großen 5 (C++11) deklariere ich immer.

Lustig, ich fast nie.

Zumindest was die Grossen Drei angeht, sehe ich es von Vorteil, wenn die Member bereits Wertsemantik besitzen und automatisch kopiert werden. Das spart viel Boilerplatecode und auch mögliche Fehler, weil die Kopie eines Members vergessen wird. Bei Klassen, die Exceptions werfen, muss man allerdings etwas aufpassen...

Kannst du bitte das etwas genauer erklären, warum es bei Klassen die Execptions werfen schwieriger ist die rulez-of-three zu implementieren?

Kannst du bitte das etwas genauer erklären, warum es bei Klassen die Execptions werfen schwieriger ist die rulez-of-three zu implementieren?

Es geht vor allem darum, was passiert wenn die entsprechenden Operationen der Member Exceptions werfen. Beispiel:

class AssignmentThrows; //Name sagt alles...

class Problematic
{
  int* p1;
  AssignmentThrows at;
  int* p2;

  //INVARIANTE: p2 > p1
};

So, was passiert, wenn ich ein "Problematic" einem anderen zuweise?
p1 wird kopiert. OK. at wird kop...BUMM
Übrig bleibt ein "Problematic", bei dem p1 geändert wurde, p2 aber nicht. Die Invariante wird vermutlich nicht mehr gelten, und alles was sich darauf verlässt (z.B. der Destruktor) spielt Russisch Roulette. Kurz: der default-generierte op= ist nicht exceptoinsicher.
Das ist jetzt ein sehr merkwürdig konstruiertes Beispiel, aber es zeigt die Problematik, und die gibts in allen Formen, Farben und Geschmacksrichtungen.

Oder liege ich da so falsch?

Die Bombe explodiert doch hier schon beim Anlegen des Objekte und nicht erst beim kopieren???

Ich bin verwirrt...

cooky451 schrieb:

Genau was ich sagte..

Nope. Du sagtest "die werden nicht automatisch generiert". Werden sie aber doch, wenn alle anderen auch automatisch generiert werden.

Ich tu jetzt einfach mal so, als ob cooky das richtige meinte.

cooky451 schrieb:

pumuckl schrieb:

_sone_dreck schrieb:

es werden nur ctor, dtor, copy, assignment von alleine angelegt

In C++11 kommen noch move-Ctor und move-Assignment dazu...

Noch nicht ganz wach? Die werden so nicht automatisch generiert.

Da nimmt man ja auch std::unique_ptr wenn p1 ein Objekt hält, ansonsten eben gleich ein Int anstelle eines Pointers auf int nutzen

Oder liege ich da so falsch?

Ich habe die int* jetzt als Beispiel genommen, einfach um aufzuzeigen, dass es darum geht, dass evtl voneinander abhängige Objekte nur zum Teil kopiert werden, bevor die Exception zuschlägt. Meinetwegen nimm zwei ints a und b, die als Invariante haben, dass a+b=100 oder etwas in der Art (ja ich weiß, da gibts auch wieder ein "aber"...)

Butterbrot schrieb:

Die Bombe explodiert doch hier schon beim Anlegen des Objekte und nicht erst beim kopieren???

Assignment ist der Zuweisungsoperator. Es ist nicht der Copy-Ctor gemeint. Gehe davon aus, dass beide Objekte voneinander unabhängig erstellt wurden (Ctor wirft keine Exception) und irgendwann danach das eine dem anderen zugewiesen wird.

Was passiert eigentlich wenn a und b ein Objekt mit Resourcen ist und ich die Zuweisung a = b mache? Dann habe ich zwei mal die gleiche Resource in zwei verschiedenen Objekten?

Wenn du die Big5, besonders den op= nicht ordentlich implementierst, ja. Und im Normalfall kommst du in Teufels Küche, wenn das erste Objekt zerstört wurde und das zweite Objekt sie versucht weiter zu nutzen. Spätestens aber wenn das zweite Objekt zerstört wird und der Dtor die gleiche Ressource das zweite mal freigeben will...