[C/C++] const auf integrale typen in einer Funktion sinnvoll?
-
;fricky schrieb:
b ist eine referenz, a muss nicht dereferenziert werden weil int& und int* äquivalent sind. selbiges bei b nach c, umwandlung von referenz in zeiger.
hast du es ausprobiert? wo stürzt es bei dir ab? eigentlich sollte nichts passieren.
Grundlagen lernen fricky.
Natürlich sollte etwas passieren.
Bei der 1. dereferenzierung wird nichts passieren, da eine referenz intern ein zeiger ist, bei der dereferenzierung in dem 2. cast macht es aber peng, da ein null zeiger dereferenziert wird.oh wunder.
kann ich dir ohne testen sagen.
du hast in jedem reinterpret_cast nunmal einen zugriff auf einen gecasteten wert. und das funktioniert nicht. der zugriff schmiert ab, nicht der cast.
ist auch leicht testbar:
int a = 0; puts("hallo-1"); int* b = reinterpret_cast<int*>(a); puts("hallo-2"); int& b2=*b; puts("hallo-3"); int b3=b2; puts("hallo-4"); char *c = reinterpret_cast<char*>(b3); puts("hallo-5");und schon schmiert es bei der zuweisung
int b3=b2;
ab.keine magie, keine hexerei.
-
Shade Of Mine schrieb:
Bei der 1. dereferenzierung wird nichts passieren, da eine referenz intern ein zeiger ist, bei der dereferenzierung in dem 2. cast macht es aber peng, da ein null zeiger dereferenziert wird.
wieso findet im zweiten cast eine dereferenzierung statt? ich wandle eine referenz in einen pointer um, wo ist der unterschied zum ersten cast, der dasselbe nur umgekehrt macht und von dem du oben noch gesagt hast, dass er auch abschmieren würde?
-
bitte halt einfach das maul fricky
-
;fricky schrieb:
wieso findet im zweiten cast eine dereferenzierung statt? ich wandle eine referenz in einen pointer um, wo ist der unterschied zum ersten cast, der dasselbe nur umgekehrt macht und von dem du oben noch gesagt hast, dass er auch abschmieren würde?
Anfänger. Die Referenz ist ein Abstraktes Ding. das gibt es gar nicht. Du greifst auf das Originalobjekt zu.
//edit da Unklar:
char *c = reinterpret_cast<char*>(b3);Ist kein cast int&->char* sondern von int->char*
-
otze schrieb:
Anfänger. Die Referenz ist ein Abstraktes Ding. das gibt es gar nicht. Du greifst auf das Originalobjekt zu.
oh stimmt, im zweiten cast hätte ja noch ein & hingemusst. mein fehler. ich muss zugeben: meine letzten experimente mit c++ liegen schon etwas zurück.
-
;fricky schrieb:
otze schrieb:
Anfänger. Die Referenz ist ein Abstraktes Ding. das gibt es gar nicht. Du greifst auf das Originalobjekt zu.
oh stimmt, im zweiten cast hätte ja noch ein & hingemusst. mein fehler. ich muss zugeben: meine letzten experimente mit c++ liegen schon etwas zurück.
Ich sage ja, einfach einmal mit der Materie befassen bevor man trollt, das wirkt dann besser.
-
Shade Of Mine schrieb:
;fricky schrieb:
otze schrieb:
Anfänger. Die Referenz ist ein Abstraktes Ding. das gibt es gar nicht. Du greifst auf das Originalobjekt zu.
oh stimmt, im zweiten cast hätte ja noch ein & hingemusst. mein fehler. ich muss zugeben: meine letzten experimente mit c++ liegen schon etwas zurück.
Ich sage ja, einfach einmal mit der Materie befassen bevor man trollt, das wirkt dann besser.
ach nö, für meine belange reicht der blick aus der vogelperspektive. wieso sollte ich auch 'nen 'schwarzen gürtel' in der cpp-programmierung anstreben, wenn ich c++ voraussichtlich nie verwenden werde? bisherige versuche liegen, wie gesagt, schon eine weile zurück und nur die albtraumhaftesten erlebnisse haben sich bei mir eingeprägt. für mich reicht es aus, c++ code lesen zu können. und ob da irgendwo ein reinterpret_cast oder c-cast auftaucht, ist dabei völlig gleich. ausserdem hast selbst du, als meister des fachs, im ersten cast eine dereferenzierung gesehen, so dass ich mich, als c++-noob, dafür nicht schämen muss.
-
;fricky schrieb:
ach nö, für meine belange reicht der blick aus der vogelperspektive. wieso sollte ich auch 'nen 'schwarzen gürtel' in der cpp-programmierung anstreben, wenn ich c++ voraussichtlich nie verwenden werde?
Die Frage ist nicht warum du C++ lernen sollst, sondern warum du über C++ sprichst wenn du keine Ahnung davon hast.
Fast jeder deiner Posts zeigt dass du die Grundlagen nicht verstanden hast, natürlich kommt dir C++ dann komisch vor. Mir kommt zB japanisch auch komisch vor und ich kann mir nicht vorstellen dass man mit dieser Schrift vernünftig arbeiten kann... Aber ich poste nicht dauernd wie dumm Japanisch ist
bisherige versuche liegen, wie gesagt, schon eine weile zurück und nur die albtraumhaftesten erlebnisse haben sich bei mir eingeprägt.
Weil du vermutlich alles falsch gemacht hast.
für mich reicht es aus, c++ code lesen zu können. und ob da irgendwo ein reinterpret_cast oder c-cast auftaucht, ist dabei völlig gleich. ausserdem hast selbst du, als meister des fachs, im ersten cast eine dereferenzierung gesehen, so dass ich mich, als c++-noob, dafür nicht schämen muss.
Da ist eine dereferenzierung.
****reinterpret_cast<int>(a);
Der erste * ist ein derferentierungs operator.
Solltest du aus C her kennen.
Der cast entspricht einem
(int)a;
in C.
-
Shade Of Mine schrieb:
Fast jeder deiner Posts zeigt dass du die Grundlagen nicht verstanden hast, natürlich kommt dir C++ dann komisch vor.
in der tat, jedesmal wenn ich versuche, etwas davon zu verstehen kommt es mir extrem komisch vor. aber ok, ich bin vielleicht auch etwas zu verwöhnt.
Shade Of Mine schrieb:
für mich reicht es aus, c++ code lesen zu können. und ob da irgendwo ein reinterpret_cast oder c-cast auftaucht, ist dabei völlig gleich. ausserdem hast selbst du, als meister des fachs, im ersten cast eine dereferenzierung gesehen, so dass ich mich, als c++-noob, dafür nicht schämen muss.
Da ist eine dereferenzierung.
****reinterpret_cast<int>(a);
Der erste * ist ein derferentierungs operator.aber wieso stürtzt er nicht schon da ab? schliesslich ist a null. würde er in der zeile a dereferenzieren, dann käme er nicht mehr zum zweiten cast, was er aber schafft (bei mir jedenfalls).
-
;fricky schrieb:
in der tat, jedesmal wenn ich versuche, etwas davon zu verstehen kommt es mir extrem komisch vor. aber ok, ich bin vielleicht auch etwas zu verwöhnt.
Du versuchst es ja nicht, du gehst mit der Einstellung ran dass C++ kaputt ist. So kann das nicht funktionieren.
aber wieso stürtzt er nicht schon da ab? schliesslich ist a null. würde er in der zeile a dereferenzieren, dann käme er nicht mehr zum zweiten cast, was er aber schafft (bei mir jedenfalls).
Mein Gott fricky, muss man dir alles vorkauen?
Es stürtzt deshalb nicht ab, weil der Compiler hier optimiert.
int* p=0;
int& r=*p;stürtzt deshalb nicht ab obwohl p dereferenziert wird, weil der compiler referenzen sofern möglich als zeiger implementiert (bzw als alias wenn das möglich ist). das bedeutet in wahrheit wird der inhalt von p hier nie angesprochen. das ist aber extrem von der plattform abhängig. denn referenzen müssen ja nicht als zeiger implementiert sein. es kann sein dass es hier bereits PENG macht. es ist illegal einen null zeiger zu dereferenzieren, auch wenn der compiler hier diese dereferenzierung einfach wegoptimiert.
der compiler greift also erst bei
int i=r;
auf den speicher zu auf den p zeigt und schmiert also erst hier ab.das ist das problem mit undefinierten verhalten
Ist ähnlich wie ein:
int* p=0;
int* p2=&*p;
in C.p wird zwar dereferenziert, aber da der compiler hier optimiert, passiert nichts.
-
Shade Of Mine schrieb:
;fricky schrieb:
in der tat, jedesmal wenn ich versuche, etwas davon zu verstehen kommt es mir extrem komisch vor. aber ok, ich bin vielleicht auch etwas zu verwöhnt.
Du versuchst es ja nicht, du gehst mit der Einstellung ran dass C++ kaputt ist. So kann das nicht funktionieren.
es war nicht immer so. ich habe bestimmt zwei jahre oder länger gebraucht, bis ich zu dem schluss gekommen bin, dass c++ so ziemlich vermackelt ist. vorher hatte ich auch schon manchmal ein ungutes gefühl, aber dachte mir: 'das muss wohl so sein'.
Shade Of Mine schrieb:
aber wieso stürtzt er nicht schon da ab? schliesslich ist a null. würde er in der zeile a dereferenzieren, dann käme er nicht mehr zum zweiten cast, was er aber schafft (bei mir jedenfalls).
Es stürtzt deshalb nicht ab, weil der Compiler hier optimiert.
int* p=0;
int& r=*p;
stürtzt deshalb nicht ab obwohl p dereferenziert wird, weil der compiler referenzen sofern möglich als zeiger implementiert (bzw als alias wenn das möglich ist). das bedeutet in wahrheit wird der inhalt von p hier nie angesprochen.den ersten teil deiner erklärung halte ich aber für falsch, denn es wird nicht dereferenziert, sondern erst wenn die referenz benutzt wird. daher muss auch nichts optimiert werden, weil ja die referenz (wie du danach schon sagtest) ein alias für *p ist.
-
;fricky schrieb:
den ersten teil deiner erklärung halte ich aber für falsch, denn es wird nicht dereferenziert, sondern erst wenn die referenz benutzt wird. daher muss auch nichts optimiert werden, weil ja die referenz (wie du danach schon sagtest) ein alias für *p ist.
Wenn p ein UDT ist, dann würde ein T& r=*p; sehr wohl einen zugriff auf das referenzierte objekt produzieren.
und wenn referenzen intern keine zeiger sind, kann das natürlich auch bei builtins der fall sein.
es ist also eine optimierung, genau wie &*p eine ist.
-
Was soll hier mit Zugriff gemeint sein?
-
camper schrieb:
Was soll hier mit Zugriff gemeint sein?
reale dereferenzierung.
*p ist eine syntaktische dereferenzierung aber bei &*p wird zB nichts real dereferenziert, es findet kein zugriff auf *p statt.
einen wirklichen zugriff auf *p findet aber zB hier statt: int i=*p;
-
;fricky schrieb:
aber wieso stürtzt er nicht schon da ab? schliesslich ist a null. würde er in der zeile a dereferenzieren, dann käme er nicht mehr zum zweiten cast, was er aber schafft (bei mir jedenfalls).
Ach ja, fricky, vielleicht würde hier die Assembler-Ausgabe des Compilers weiterhelfen, aber dazu müsste man sich mit der CPU beschäftigen, mit den Adressierungsarten usw. - und das ist ja alles Quatsch...
-
abc.w schrieb:
;fricky schrieb:
aber wieso stürtzt er nicht schon da ab? schliesslich ist a null. würde er in der zeile a dereferenzieren, dann käme er nicht mehr zum zweiten cast, was er aber schafft (bei mir jedenfalls).
Ach ja, fricky, vielleicht würde hier die Assembler-Ausgabe des Compilers weiterhelfen
glaub ich nicht, eine 'syntaktische dereferenzierung' (um es mit shade-of-mines worten zu sagen) auf c++ level, muss nicht notwendigerweise eine entsprechung im assemblercode haben.
abc.w schrieb:
und das ist ja alles Quatsch.
allerdings. wieso erzählst du's dann, wenn du weisst das es quatsch ist?
-
;fricky schrieb:
Shade Of Mine schrieb:
;fricky schrieb:
in der tat, jedesmal wenn ich versuche, etwas davon zu verstehen kommt es mir extrem komisch vor. aber ok, ich bin vielleicht auch etwas zu verwöhnt.
Du versuchst es ja nicht, du gehst mit der Einstellung ran dass C++ kaputt ist. So kann das nicht funktionieren.
es war nicht immer so. ich habe bestimmt zwei jahre oder länger gebraucht, bis ich zu dem schluss gekommen bin, dass c++ so ziemlich vermackelt ist. vorher hatte ich auch schon manchmal ein ungutes gefühl, aber dachte mir: 'das muss wohl so sein'.
das lässt jetzt aber weniger rückschlüsse auf C++ zu, als auf dich.
-
hustbaer schrieb:
das lässt jetzt aber weniger rückschlüsse auf C++ zu, als auf dich.
auf beide, würde ich sagen. mag sein, dass ich in gewissen dingen zu pingelig und zu wenig kompromissbereit bin, aber pferd und reiter müssen nunmal zueinander passen, sonst wird das nix. übrigens kann ich mich normalerweise gut mit bugs und macken arrangieren, wenn es keine ausweichmöglichkeit gibt. aber wenn ich alternativen sehe, bei denen bestimmte unzulänglichkeiten garnicht erst existieren, dann hat meine toleranz ein ende.
-
Das nennt man Rigidität, fricky.
-
abc.w schrieb:
Das nennt man Rigidität, fricky.
ach nö, das ist eher 'ne mischung aus pragmatismus, erfahrungswerten (ich habe einige male mitbekommen, wie andere mit c++ gescheitert sind) und rationalen entscheidungen. wäre ich rigide, würde ich in reinem ansi-C ein vernetztes warenwirtschaftssystem oder ähnliches programmieren wollen. sowas würde mir im traum nicht einfallen. ausserdem würde ich, ohne zu murren, selbstverständlich c++ benutzen, wenn's die einzige programmiersprache auf der welt wäre.
