[C/C++] const auf integrale typen in einer Funktion sinnvoll?

[;fricky]

Nexus schrieb:

;fricky schrieb:

naja, wäre ja nicht schlecht, wenn reinterpret-cast und c-cast, bei absolut unsinnigen konvertierungen, auch exceptions werfen könnten. erstmal müsste sich c++ dann nicht vorwerfen lassen, schwach typisiert zu sein und zweitens wärs der stabilität der programme zuträglich. stattdessen überlässt man lieber dem OS das werfen von exceptions und der user sieht hässliche crash-meldungen.

Und wie soll entschieden werden, was sinnvoll ist und was nicht? Und wer kann den Laufzeitoverhead für so einen Schwachsinn vertreten? Abgesehen davon crashen Konvertierungen nicht, sondern höchstens der nachfolgende Zugriff.

vielleicht konfigurierbar über'n compiler-switch oder so. RTTI lässt sich ja auch ein- und ausschalten. klar können konvertierungen auch schon selber abschmieren. dazu brauchte noch nicht mal 'nen dynamic cast, der sich durch die vererbungsliste hangelt und plötzlich auf einen 0-pointer trifft.

Nexus schrieb:

C++ hat eben den Vorteil, dass man genauso Low-Level arbeiten kann, und zwar ohne Einschränkungen.

doch mit einschränkungen: http://www.mikrocontroller.net/articles/C_vs_C-Plusplus

Nexus schrieb:

P.S.: Das, was rüdiger angetönt hat, ist eins der Standardargumente gegen C++ - "man brauchts nicht". Klar, ist wunderbar anwendbar auf Mehrfachvererbung, Operatorüberladung, Zeigerarithmetik, Const-Correctness und sonst alle C++-Features, die andere Sprachen nicht bieten "und ja auch ohne auskommen". Das ideale Argument, was will man mehr?

aber im prinzip stimmt es, z.b:
mehrfachvererbung -> sehr selten sinnvoll, fördert schlechtes design
operatorüberladung -> geringer nutzen, wird oft falsch verwendet
zeiger/zeigerarithmetik -> in low-level sprachen sinnvoll, in höheren sprachen nicht
const-correctness -> idiomatisch in C++, in der realität ausserhalb von c++ aber ohne bedeutung.

[volkard]

;fricky schrieb:

aber im prinzip stimmt es, z.b:
mehrfachvererbung -> sehr selten sinnvoll, fördert schlechtes design
operatorüberladung -> geringer nutzen, wird oft falsch verwendet
zeiger/zeigerarithmetik -> in low-level sprachen sinnvoll, in höheren sprachen nicht
const-correctness -> idiomatisch in C++, in der realität ausserhalb von c++ aber ohne bedeutung.

Ach, halt doch einfach die Klappe. Du hast keinen Schimmer von C++ und Deine Aussagen sind größtenteils falsch.

[Fricky-Fan]

;fricky schrieb:

Nexus schrieb:

C++ hat eben den Vorteil, dass man genauso Low-Level arbeiten kann, und zwar ohne Einschränkungen.

doch mit einschränkungen: http://www.mikrocontroller.net/articles/C_vs_C-Plusplus

Der Link war wohl ein Eigentor, zumindest sehe ich hier keinen einzigen Nachteil von C++ gegenüber C. In allen aufgezählten Punkten ging C++ als Sieger hervor in Bezug darauf, dass es Funktionalität liefert die man in C händisch nachbauen muss oder gar nicht hat. Und was ganz wichtig ist: wenn man sie nicht benutzt, dann kosten sie nichts.

[Shade Of Mine]

;fricky schrieb:

klar können konvertierungen auch schon selber abschmieren.

EPIC fail.
reinterpret_cast kann nicht abschmieren.

gib dir bitte mühe beim trollen, mittlerweile kann meine oma deine "argumente" widerlegen... uU vl mal mit der materie befassen...?

[camper]

Shade Of Mine schrieb:

reinterpret_cast kann nicht abschmieren.

cast in einen Typ, für den der Operand nicht hinreichend ausgerichtet ist?

[Shade Of Mine]

camper schrieb:

Shade Of Mine schrieb:

reinterpret_cast kann nicht abschmieren.

cast in einen Typ, für den der Operand nicht hinreichend ausgerichtet ist?

Dann schmiert der Zugriff ab, oder?

[;fricky]

Shade Of Mine schrieb:

reinterpret_cast kann nicht abschmieren.

probier dies:

int a = 0;
puts ("hallo-1");
int &b = *reinterpret_cast<int*>(a);   // hier
puts ("hallo-2");
char *c = reinterpret_cast<char*>(b);  // oder hier
puts ("hallo-3");

[camper]

Shade Of Mine schrieb:

camper schrieb:

Shade Of Mine schrieb:

reinterpret_cast kann nicht abschmieren.

cast in einen Typ, für den der Operand nicht hinreichend ausgerichtet ist?

Dann schmiert der Zugriff ab, oder?

Der Standard ist hier etwas mehrdeutig formuliert.

5.2.10/7
A pointer to an object can be explicitly converted to a pointer to an object of different type.65) Except that converting an rvalue of type “pointer to T1” to the type “pointer to T2” (where T1 and T2 are object types and where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value, the result of such a pointer conversion is unspecified.

Beschränkt die in Klammern genannte Bedingung nur die Gleichheit der Konvertierungskette T1*->T2*->T1* oder ist die ausreichende Ausrichtung eine Voraussetzung, damit die Konvertierung überhaupt ein definiertes Ergebnis hat?

C90 schrieb:

6.3.4
...
A pointer to an object or incomplete type may be converted to a pointer to a different object type or a different incomplete type. The resulting pointer might not be valid if it is improperly aligned for the type pointed to. It is guaranteed, however, that a pointer to an object of a given alignment may be converted to apointer to an object of the same alignmet or a less strict alignmet and back again: the result shall compare equal to the original pointer.

Was ein "invalid pointer" sein soll, ist wahrscheinlich nirgendwo definiert.

C99 schrieb:

6.3.2.3
7 A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned57) for the pointed-to type, the behavior is undefined. Otherwise, when converted back again, the result shall compare equal to the original pointer. When a pointer to an object is converted to a pointer to a character type, the result points to the lowest addressed byte of the object. Successive increments of the result, up to the size of the object, yield pointers to the remaining bytes of the object.

wenigstens diese Formulierung ist eindeutig - fraglich nur, ob man sie übertragen darf...

[Shade Of Mine]

;fricky schrieb:

probier dies:

epic fail.

reinterpret_cast schmiert nicht ab. der zugriff danach schmiert ab.

[;fricky]

Shade Of Mine schrieb:

reinterpret_cast schmiert nicht ab. der zugriff danach schmiert ab.

es wird doch nirgends zugegriffen, nur umgewandelt.

[Shade Of Mine]

;fricky schrieb:

es wird doch nirgends zugegriffen, nur umgewandelt.

Dann lern mal c++

int &b = *reinterpret_cast<int*>(a);
ich sehe hier eine dereferenzierung des gecasteten wertes.

char *c = reinterpret_cast<char*>(b);
ich sehe hier einen zugriff auf das gecastete objekt von vorher.

[Tippgeber]

;fricky schrieb:

Shade Of Mine schrieb:

reinterpret_cast schmiert nicht ab. der zugriff danach schmiert ab.

es wird doch nirgends zugegriffen, nur umgewandelt.

Siehst du, du solltest wirklich einmal die Syntax und Semantik von C++ lernen, bevor du argumentieren willst. Wenn du in C++ programmierst, wie oben, dann präsentierst du das typische Bild eines Fricklers, der einfach so lange rumhackt bis der Compiler irgendwie das gewünschte ausspuckt. Mit einem sauberen C++ Programm hat das nichts gemeinsam.

[;fricky]

Shade Of Mine schrieb:

int &b = *reinterpret_cast<int*>(a);
ich sehe hier eine dereferenzierung des gecasteten wertes.

char *c = reinterpret_cast<char*>(b);
ich sehe hier einen zugriff auf das gecastete objekt von vorher.

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.

[Shade Of Mine]

;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.

[;fricky]

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?

[hustbaer]

bitte halt einfach das maul fricky

[otze]

;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*

[;fricky]

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.

[Shade Of Mine]

;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.

[;fricky]

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.