 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Georg Maaß
Guest
|
 Posted: Sun Feb 20, 2005 5:07 pm Post subject: Unerwartetes Verhalten nach Compilerwechsel... |
 |
|
unsigned int from;
w.getValue(static_cast<unsigned long>(from));
Das ruft w.getValue(unsigned long&) auf, welches den Wert 1 in sein
Funktionsargument reinschreibt, trotzdem ist bei g++ 3.3.2 im
Unterschied zum alten 2.95.3 from nicht etwa 1, wie erwartet, sondern 0.
Es scheint, als würde ich da beim 3.3.2er irgendwas temporäres befüllen
und nicht das from, wie eigentlich beabsichtigt.
Hätte ich das auf eine Referenz casten sollen, oder wäre das genauso
falsch? Warum hat der alte 2.95.3er verstanden, was ich meinte,
wohingegen der 3.3.2er mich mißversteht?
Genau genommen, ist das from ein Typ, der sich letztlich als unsigned
int erweist. Solange es ein unsigned int oder unsigned long ist, brauche
ich den cast nicht, weil das w dann passende Methoden bereit stellt.
Wenn es aber größer wäre als ein unsigned long (z.B. unsigned long
long), dann soll der interne unsigned long des w nicht automatisch als
double geliefert werden, sondern weiterhin als unsigned long, der ja
ohne Informationsverlust in ein unsigned long long, oder was es da sonst
noch an richtig fetten Ganzzahltypen gibt, paßt.
Der Cast ist also nur für den Fall gedacht, daß from ein Typ ist, der
größer ist als ein unsigned long. Neben der getValue-Methode hat das w
auch einen Cast-Operator. Wenn from größer oder gleich einem unsigned
long ist, könnte man es auch so formulieren:
unsigned long long from = (unsigned long) w;
Im Prinzip entscheidet sich, ob ein Tipp (liefere als unsigned long)
erfordelich ist, oder eher kontra produktiv, zur Kompilezeit in
Abhängigkeit davon, als was für ein Typ das from implementiert ist. Das
aber hängt nicht von mir ab, sondern von der Kiste, auf der kompiliert
wird, d.h. z.B. vom Compiler und dem Geraffel, das er so mit bringt.
Soll ich da jetzt mit einem sizeof-Vergleich eine Weiche drum rum legen?
Ein Ausdruck der Art
if(sizeof(unsigned long long) > sizeof(unsigned long))
{
from = (unsigned long) w;
}
else
{
w.getValue(from);
}
wie die Condition des if ist ja eine zur Compilezeit (nicht aber zur
Designzeit) bekannte Konstante, so daß der Compiler theoretisch den
überflüssigen Zweig wegoptimieren kann.
Gruß, Georg
--
Georg Maaß - bioshop.de D-76227 Karlsruhe, Westmarkstraße 82
HTML, XML / JavaScript, C++, Java, PHP, VB / CGI, JSP, ASP, ASP.net
- The ultimate DHTML engine: http://gml-modul.de -
live at: http://gml-modul.dyndns.org
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
 |
Thomas Mang
Guest
|
| Posted: Sun Feb 20, 2005 6:00 pm Post subject: Re: Unerwartetes Verhalten nach Compilerwechsel... |
|
|
"Georg Maaß" <georg (AT) bioshop (DOT) de> schrieb im Newsbeitrag
news:4218c391$0$24945$9b4e6d93 (AT) newsread2 (DOT) arcor-online.net...
| Quote: | unsigned int from;
w.getValue(static_cast<unsigned long>(from));
Das ruft w.getValue(unsigned long&) auf, welches den Wert 1 in sein
Funktionsargument reinschreibt, trotzdem ist bei g++ 3.3.2 im
Unterschied zum alten 2.95.3 from nicht etwa 1, wie erwartet, sondern 0.
Es scheint, als würde ich da beim 3.3.2er irgendwas temporäres befüllen
und nicht das from, wie eigentlich beabsichtigt.
|
Undefiniertes Verhalten, außerdem Compiler-bug (sofern wir es nicht auf
undefiniertes Verhalten schieben):
Du machst eine rvalue-Konvertierung eines nicht initialisierten unsigned
int. Außerdem ist das resultat des static_cast ein rvalue, der nicht an eine
Referenz zu non-const gebunden werden kann.
Thomas
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Horst Kraemer
Guest
|
| Posted: Sun Feb 20, 2005 6:22 pm Post subject: Re: Unerwartetes Verhalten nach Compilerwechsel... |
|
|
Georg Maaß <georg (AT) bioshop (DOT) de> wrote:
| Quote: | unsigned int from;
w.getValue(static_cast<unsigned long>(from));
Das ruft w.getValue(unsigned long&) auf, welches den Wert 1 in sein
Funktionsargument reinschreibt, trotzdem ist bei g++ 3.3.2 im
Unterschied zum alten 2.95.3 from nicht etwa 1, wie erwartet, sondern 0.
Es scheint, als würde ich da beim 3.3.2er irgendwas temporäres befüllen
und nicht das from, wie eigentlich beabsichtigt.
Hätte ich das auf eine Referenz casten sollen, oder wäre das genauso
falsch?
|
Ganz falsch. Oder wie man's nimmt: da erzaehlt Dir sogar der 2.95,
dass er ein Temporary generiert, und Du laesst es dann
| Quote: | Warum hat der alte 2.95.3er verstanden, was ich meinte,
wohingegen der 3.3.2er mich mißversteht?
|
Weil der 2.95.3 buggy ist ;-)
Eigentlich geht's mich ja nichts an, aber warum schreibt man eine
Funktion
getValue(unsigned long&)
die eigentlich setValue heissen muesste und nicht schmerzfrei
unsigned long getValue();
from=w.getvalue();
oder
unsigned long getValue(unsigned long)
from=w.getValue(from)
wenn der alte Wert benoetigt werden sollte.
--
Horst
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Georg Maaß
Guest
|
| Posted: Sun Feb 20, 2005 7:04 pm Post subject: Re: Unerwartetes Verhalten nach Compilerwechsel... |
|
|
Thomas Mang wrote:
| Quote: | Undefiniertes Verhalten, außerdem Compiler-bug (sofern wir es nicht auf
undefiniertes Verhalten schieben):
Du machst eine rvalue-Konvertierung eines nicht initialisierten unsigned
int. Außerdem ist das resultat des static_cast ein rvalue, der nicht an eine
Referenz zu non-const gebunden werden kann.
|
Das heißt, die hätten das beide eigentlich nicht kompilieren dürfen,
sondern meckern müssen. Ist es das, was Du mit Compiler-Bug meinst?
Ich habe dem unbrauchbaren static_cast entfernt und statt dessen die
skizzierte Prüfung des sizeof verwendet, um je nach Bedarf mal den
Methoden-Aufruf und mal die Zuweisung zu verwenden. Das funzt mit beiden
und enthält nicht mehr den undefinierten Ausdruck, der das
unterschiedliche Programmverhalten ausgelöst hat.
Gruß, Georg
--
Georg Maaß - bioshop.de D-76227 Karlsruhe, Westmarkstraße 82
HTML, XML / JavaScript, C++, Java, PHP, VB / CGI, JSP, ASP, ASP.net
- The ultimate DHTML engine: http://gml-modul.de -
live at: http://gml-modul.dyndns.org
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Thomas Mang
Guest
|
| Posted: Sun Feb 20, 2005 10:20 pm Post subject: Re: Unerwartetes Verhalten nach Compilerwechsel... |
|
|
"Georg Maaß" <georg (AT) bioshop (DOT) de> schrieb im Newsbeitrag
news:4218def9$0$24934$9b4e6d93 (AT) newsread2 (DOT) arcor-online.net...
| Quote: | Thomas Mang wrote:
Undefiniertes Verhalten, außerdem Compiler-bug (sofern wir es nicht auf
undefiniertes Verhalten schieben):
Du machst eine rvalue-Konvertierung eines nicht initialisierten unsigned
int. Außerdem ist das resultat des static_cast ein rvalue, der nicht an
eine
Referenz zu non-const gebunden werden kann.
Das heißt, die hätten das beide eigentlich nicht kompilieren dürfen,
sondern meckern müssen. Ist es das, was Du mit Compiler-Bug meinst?
|
Ja. Das Ergebnis des static_cast ist ein r-value, der nicht an eine Referenz
an non-const gebunden werden kann.
Eigentlich ist das gut, den das was GCC an die Referenz bindet ist nicht
from, sondern ein temporäres Objekt, das dann in getValue beschrieben wird,
und sofort wieder zerstört wird.
Bsp:
unsigned int from = 1234;
getValue(static_cast<unsigned long>(from)); // kompiliert unter GCC, bug
std::cout << from;
Wie Du siehst, from hat sich gar nicht verändert.
Thomas
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Georg Maaß
Guest
|
| Posted: Sun Feb 27, 2005 2:55 pm Post subject: Re: Unerwartetes Verhalten nach Compilerwechsel... |
|
|
Horst Kraemer wrote:
| Quote: | Eigentlich geht's mich ja nichts an, aber warum schreibt man eine
Funktion
getValue(unsigned long&)
die eigentlich setValue heissen muesste
|
Weil das nicht stimmt, denn sie verändert den Wert des Objekts nicht,
sondern liefert ihn als unsigned long.
| Quote: | und nicht schmerzfrei
unsigned long getValue();
from=w.getvalue();
|
Weil der Rückgabetyp nicht Bestandteil der Signatur der Funktion ist. Es
gibt etwa 10 verschiedene getValue, die sich allein durch den Typ der
Referenz unterscheiden.
Die entsprechemdem setValue gibt es auch. Diese verändern den inneren
Wert des Objekts.
--
Georg Maaß - bioshop.de D-76227 Karlsruhe, Westmarkstraße 82
HTML, XML / JavaScript, C++, Java, PHP, VB / CGI, JSP, ASP, ASP.net
- The ultimate DHTML engine: http://gml-modul.de -
live at: http://gml-modul.dyndns.org
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Real Name
Guest
|
| Posted: Mon Mar 14, 2005 9:21 pm Post subject: Re: Unerwartetes Verhalten nach Compilerwechsel... |
|
|
| Quote: | Weil der Rückgabetyp nicht Bestandteil der Signatur der Funktion ist. Es
gibt etwa 10 verschiedene getValue, die sich allein durch den Typ der
Referenz unterscheiden.
|
Anders ausgedrückt: weil es keine brauchbare Semantik gibt, gibt es auch
keine brauchbare Syntax?!
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
