Fun-Soft - Programmierforum

Autor

Thread - Seiten: [ 1 ] > 2 <

010
05.12.2007, 14:34 Uhr
Kest
saint

Tun sie schon, aber schade ist, dass man sich auf solche Umweg-Lösungen nicht verlassen sollte.
--
Wenn man einen Hufschlag hört, sollte man >Pferd< denken und nicht >Zebra<.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

011
05.12.2007, 15:04 Uhr
ao

(Operator)

Zitat von Kest:

Tun sie schon, aber schade ist, dass man sich auf solche Umweg-Lösungen nicht verlassen sollte.

Wieso nicht? Was kann schiefgehen?

Dass es kein guter Stil ist, in C++ alte C-Tricks anzuwenden, und dass es saubere Wege gibt, das weiß ich. Ich frage aber nach konkreten Fehlern oder Gefahren.

ao

Dieser Post wurde am 05.12.2007 um 15:08 Uhr von ao editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

012
05.12.2007, 15:51 Uhr
Kest
saint

Das wurde mir so beigebracht. Hab eigentlich nie darüber nachgedacht, bis jetzt. Naja, und auf Anhieb fällt mir nichts Konkretes ein.
--
Wenn man einen Hufschlag hört, sollte man >Pferd< denken und nicht >Zebra<.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

013
05.12.2007, 16:07 Uhr
0xdeadbeef
Gott
(Operator)

Referenzen müssen nicht als Pointer repräsentiert werden, der Compiler kann das Gepushe zum Beispiel wegoptimieren. Das bedeutet, dass du da unter Umständen versuchst, Konstanten umzuschreiben.

Davon abgesehen würde ich mich nicht darauf verlassen, dass dir das mit z.B. der vtbl keinen Unfug treibt, und wenn das Objekt zum Beispiel Zeiger auf Objekte innerhalb sich selbst enthält - oder auch eines der enthaltenen Objekte das tut, oder da smart pointer enthalten sind, oder vergleichbare Dinge, fliegt dir das ganze aber ganz schnell um die Ohren. So oder so erzeugt das äußerst undefiniertes Verhalten.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Dieser Post wurde am 05.12.2007 um 16:11 Uhr von 0xdeadbeef editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

014
05.12.2007, 19:37 Uhr
Hans
Library Walker
(Operator)

Hi,

also der Borland C++ 5.5 hat's ohne zu mosern geschluckt. Kommt auch das richtige Ergebniss bei raus:

Code:

a = Hallo b = Welt
a = Welt b = Hallo

Andere Compiler hab ich gerade nicht Verfügbar, um es darauf auch testen zu können.

Hans
--
Man muss nicht alles wissen, aber man sollte wissen, wo es steht. Zum Beispiel hier: Nachdenkseiten oder Infoportal Globalisierung.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

015
05.12.2007, 19:46 Uhr
0xdeadbeef
Gott
(Operator)

Joa, das kann bei undefiniertem Verhalten schon mal passieren; das darf auch funktionieren. Muss es aber nicht, und kann dir jederzeit um die Ohren fliegen. Genausogut darf das Programm die Festplatte formatieren.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

016
07.12.2007, 06:02 Uhr
stephanw
localhorst

Schön, irgendwie ist das cool, keine extra Variable zu benötigen.

Vielleicht kann man sich ja darauf beschränken, dass man auf diese Weise Speicherbereiche austauschen kann (byteweise). Das sollte doch für eingebauten Typen sowie PODs funktionieren. Sobald das Kopieren eines Objekts nicht mehr trivial ist, ist das Verhalten undefiniert, also katastrophal. Nicht mehr trivial ist es eben, wenn Zeiger, Referenzzähler usw. im Spiel sind, also in den üblichen Fällen, die einen Kopierkonstruktor, Destruktor und Zuweisungsoperator erfordern oder verbieten.

Für Leute mit Paranoia gibt es ja auch noch "voliatile", vielleicht kann man damit übereifrige Compiler-Optimierungen vermeiden ?

Mein g++ macht das übrigens auch richtig, obwohl std::string schon nicht mehr trivial sein sollte. Von daher -> Glück gehabt

Code:

$ ./main
a = Hallo b = Welt
a = Welt b = Hallo

--
Reden ist Schweigen und Silber ist Gold.

Dieser Post wurde am 07.12.2007 um 06:13 Uhr von stephanw editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

017
07.12.2007, 15:12 Uhr
0xdeadbeef
Gott
(Operator)

Auch mit volatile kommst du da im Standard nicht weit. Und das auch aus gutem Grund - nimm an, du vertauschst mit einer abgeleiteten Klasse und machst dir die vtbl kaputt. Oder die Objekte liegen auf dem Heap - oder auch nur eins davon - und die Implementierung des Heaps kommt dadurch völlig durcheinander.

Jedenfalls definiert der Standard für solche Scherze keine Semantik, also kannst du dich nicht darauf verlassen, dass das funktioniert. Und wenn ich mir Sektion 3.9 so ankucke, könnte man fast sagen, dass er es ausdrücklich verbietet. Davon abgesehen - was ist denn das Problem mit einem temporären Objekt? Für einfache Datentypen, bei denen diese Methode funktionieren würde, läuft es doch laufzeittechnisch so ziemlich auf das selbe hinaus, und bei komplexen Datentypen hast du auf die Art eine definierte Semantik, die du eh brauchst.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

018
11.12.2007, 15:23 Uhr
stephanw
localhorst

Da hast Du schon recht. Deswegen habe ich das ja auch eingeschränkt für Typen mit trivialer Kopiersemantik. Der Reiz liegt für mich vor allem darin, keine temporäre Variable zu benötigen. Mehr als eine Spielerei ist es wohl nicht. Praktisch wird eine derartige Optimierung von swap() wohl kaum wirklich nötig sein, um ein System speicher- oder laufzeiteffizienter zu machen.
--
Reden ist Schweigen und Silber ist Gold.

Dieser Post wurde am 11.12.2007 um 15:23 Uhr von stephanw editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

Seiten: [ 1 ] > 2 < [ C / C++ (ANSI-Standard) ]

ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: