Warnung: Historischer Unglücksfall bei C++! Hää?
-
Im Original steht da sicherlich nicht Unglücksfall, sondern accident, was man wohl besser mit Zufall übersetzt hätte (auch wenn es auch Unfall heissen kann)
BTW bringt es in der Praxis eigentlich irgendwelche Vorteile, dass man & selbstdefinieren kann?
-
BTW bringt es in der Praxis eigentlich irgendwelche Vorteile, dass man & selbstdefinieren kann?
wenn man nen SmartPointer oder ne andere Klasse fürs Speichermanagment schreiben will..
-
Versteh ich jetzt nicht. auto_ptr hat jedenfalls keinen &, boost::$FOO_ptr auch nicht.
-
something like
Smarty<T> p= new T;
T*t= &p; //gibt den Pointer raus, anstelle der Adresse des Smartpointers..
weiß nicht ob das sinnvoll ist, aber wär zumindest n Grund den Op zu überladen
-
Alexandrescu (Modern C++ Design) warnt ja sogar davor den & Operator für Smart-Pointer zu überladen. Leider fällt mir gerade nicht die Begründung ein, werde das gleich aber mal nachlesen.
-
Auf jeden Fall funktioniert dann der Test auf Selbszuweisung
if(this == &other)
nichtmehr wie gewünscht.
Das halte ich für ziemlich gefährlich, denn die Zeile sieht wirklich unschuldig aus.Ich kann mir ehrlich gesagt keine Situation vorstellen wo eine Überladung des operator& mehr Vorteile als Ärger mit sich bringt.
MfG Jester
-
(Huch, wie habe ich das Doppelposting hier denn hingekriegt?)
-
Shady schrieb:
Smarty<T> p= new T;
T*t= &p; //gibt den Pointer raus, anstelle der Adresse des Smartpointers..
Den Autoren würd ich aber hauen. &p ist nicht analog zur Verwendung eines normalen Zeigers, man *muss* sich eben etwas Eigenes ausdenken, das der User dann lernen muss. Da sollte man dann IMHO eher eine normale Elementfunktion nehmen, damit man den Smart-Ptr selbst überhaupt noch adressieren kann (ja, sowas macht man tatsächlich, ich zumindest).
operator= und den Copy-Konstruktor finde ich eigentlich ziemlich nützlich so, obwohl es schöner wäre, wenn man solche Aktionen auf alle Elementvariablen über Metaprogramming selbst definieren könnte.
Dass , ein Operator ist und was er macht, finde ich allgemein fragwürdig *duck*
-
Sagt mal und dann wunderet ihr euch, warum man mit C/C++ BufferOverflows und sonstigen unsicheren Code basteln kann?
Nehmt Delphi (Delphi Language) und ihr müsst euch um sowas keine Gedanken mehr machen. 
Wie heißt es doch so schön:
Während C/C++ Programmierer noch über legen wie sie was programmieren, überlegen Delphi Programmierer schon was sie programmieren sollen.
-
ja, C++ setzt voraus das man weiß was man tut :p
-
@Jester
deswegen schreibt der vorsichtige Programmierer auch immer&*this
dann sagt der Compiler auch wenigstens keine Fehlermeldung, wenn man den & Operator überladen hat
@Luckie
bitte kein Flamewar starten