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

hustbaer schrieb:

;fricky schrieb:

otze schrieb:

das stimmt doch garnicht. du schreibst in die klammern rein, wohin gecastet werden soll. da ist nichts unbeabsichtigt und auch nicht schlecht sichtbar.

Aber Interfaces ändern sich. Der cast macht aber trotzdem weiterhin, was er immer macht. Dann geht etwas kaputt und niemand merkt es, weil der Compiler bevormundet wird.

^^endlich ein gutes argument gegen c-casts, dazu fällt mir keine lästerei mehr ein. static- und dynamic-casts scheitern, wenn die typen nicht mehr zueinander passen, ne?
das klappt natürlich nicht, wenn einer reinterpret-cast verwendet hat.

fricky, säufst du?
das ist genau das, was ich geschrieben habe.

nö, du schreibst immer, dass diese dinge existieren, um den programmierer vor sich selbst zu schützen (und wenn das nicht reicht, dann müssen zusätzliche regeln her). für diese haltung hab ich kein verständnis. ich bin eher ein anhänger des 'spirit of C': http://www.cnblogs.com/WarrenTang/archive/2008/03/16/1108873.html
wir haben hier gerade mal ein beispiel, bei dem diese unterschiedlichen c++ casts (richtige angewendet) was bringen. demgegenüber steht die verwechslungsgefahr und das bedürfnis, den code nach casts durchsuchen zu müssen.

hustbaer schrieb:

p.S.: vielleicht kommt es auch nur daher, dass du nie C++ programmierst. dann solltest du dich aber vielleicht auch bei C++ themen raushalten.

'const', um das es hier geht, betrifft auch C. ausserdem bin ich sehr glücklich darüber, nicht in C++ programmieren zu müssen. *fg*

hustbaer schrieb:

;fricky schrieb:

man muss wissen was man tut. ich sehe nicht, dass c++ casts einem das abnehmen.

sie decken *manche* fehler auf. was ist besser: manche fehler aufdecken, oder keine fehler aufdecken?

sie decken eine mögliche fehlerquelle auf, führen aber zwei oder drei neue ein. dieser effekt ist typisch für C++.

Tyrdal

@DEvent

Ich habe gemeint, wenn du etwas als private/protected/usw deklarierst, dann bleibt es auch dabei.

Nein, das ist nicht unbedingt der Fall. Guck mal using an.

otze

;fricky schrieb:

sie decken eine mögliche fehlerquelle auf, führen aber zwei oder drei neue ein. dieser effekt ist typisch für C++.

Jein. Sie zwingen den Programmierer dazu, darüber nachzudenken, was er eigentlich will. Er muss zwischen 4 casts wählen, die jeweils andere Hinweise geben:

const_cast wirft die Frage auf, ob ich das Objekt wirklich entconsten muss - wahrscheinlich ist es doch keine so gute Idee, darauf jetzt rumzuschreiben. Andererseits ist entconsten notwendig, wenn ich eine Klasse verwende, die const correctness nicht kennt(übrigens ist das der Grund, weswegen const_cast eingeführt wurde. Das Feature war schließlich nicht in Version 1 von C++ enthalten, deswegen gab es bereits eine Menge Code, die von dem Feature beeinflusst wurden. Und den musste man kompatibel machen).

reinterpret_cast lässt die Alarmglocken schrillen: was du da machst, ist potentiell Fehleranfällig und nicht portabel. Denk noch einmal drüber nach, was da passiert. Brauchst du es wirklich?

dynamic_cast sagt: okay, teste mal, ob das Ding diese Basisklasse ist. funktioniert natürlich nur bei polymorphen Typen, und darauf passt der Compiler auf. Also keine Gefahr. Oder doch: Auf 0 testen, oder Exception fangen. Nur für den Fall.

static_cast keine Gefahr, was da passiert schaltet normalerweise nur eine Warnung aus. Wenn was schief geht, meckert der Compiler rum.

C-Cast: ??? Potentiell gefährlich. Effekt nicht abschätzbar, ohne alles drum herum zu kennen.

hustbaer

fricky, glaub was du willst.
ich kann dich echt nicht mehr ernst nehmen.
geh uns spiel mit deinem C compiler.

camper

Don06 schrieb:

Mit const_cast kann man auch volatile wegcasten. const_cast ist ein schlechter Name. Damit kann man cv-Qualifizierungen umwandeln.

Nur das entfernen von const benötigt allerdings einen const_cast. Alles andere (Hinzufügen von const; Hinzufügen/Entfernen von volatile) ist auch mit allen anderen cast-Formen möglich. Das ist auch unproblematisch: im Gegensatz zum Entfernen von const, bedeutet das Entfernen von volatile (sagen wir beim Funktionsaufruf) nicht die potentielle Verletzung einer Garantie beim Aufrufer.

hustbaer

camper schrieb:

Don06 schrieb:

Mit const_cast kann man auch volatile wegcasten. const_cast ist ein schlechter Name. Damit kann man cv-Qualifizierungen umwandeln.

Nur das entfernen von const benötigt allerdings einen const_cast. Alles andere (Hinzufügen von const; Hinzufügen/Entfernen von volatile) ist auch mit allen anderen cast-Formen möglich. Das ist auch unproblematisch: im Gegensatz zum Entfernen von const, bedeutet das Entfernen von volatile (sagen wir beim Funktionsaufruf) nicht die potentielle Verletzung einer Garantie beim Aufrufer.

hm.
bist du sicher?

Comeau C/C++ 4.3.10.1 (Oct  6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
Copyright 1988-2008 Comeau Computing.  All rights reserved.
MODE:strict errors C++ C++0x_extensions

"ComeauTest.c", line 4: error: static_cast cannot cast away const or other type
          qualifiers
      int* p = static_cast<int*>(&i);
               ^

1 error detected in the compilation of "ComeauTest.c".

p.S.: hab "i" natürlich volatile gemacht, und nicht const.

@otze: klingt sehr einleuchtend was du sagst. ich, in meiner eigenschaft als radikaler c++-hasser, muss jetzt zwar einwenden, dass es sich bei diesen vielen verschiedenen casts offensichtlich um einen konzeptuellen fehler in C++ handelt (welche andere programmiersprache braucht sowas noch?), aber gut, das ist wohl nun mal so.

camper schrieb:

Das ist auch unproblematisch: im Gegensatz zum Entfernen von const, bedeutet das Entfernen von volatile (sagen wir beim Funktionsaufruf) nicht die potentielle Verletzung einer Garantie beim Aufrufer.

begründung?
wenn du volatile von z.b. einem pointer wegmachst, der ursprünglich volatile deklariert wurde, haste auch undefiniertes verhalten (wie bei const): https://www.securecoding.cert.org/confluence/display/seccode/EXP32-C.+Do+not+access+a+volatile+object+through+a+non-volatile+reference
oder gehört du auch zu den leuten, die 'volatile' für sinnlos halten?

Shade Of Mine

;fricky schrieb:

@otze: klingt sehr einleuchtend was du sagst. ich, in meiner eigenschaft als radikaler c++-hasser, muss jetzt zwar einwenden, dass es sich bei diesen vielen verschiedenen casts offensichtlich um einen konzeptuellen fehler in C++ handelt (welche andere programmiersprache braucht sowas noch?), aber gut, das ist wohl nun mal so.

Brauchen tut man garnix. Mach C Casts wenn du dumm sein willst. Es ist eine Hilfe die kluge Leute annehmen. Brauchen tut man das nicht, aber braucht man wirklich streng typisierte Sprachen? Oder braucht man Hochsprachen?

Kluge Leute verwenden die Tools die man ihnen gibt um die qualität oder produktivität der Arbeit zu steigern. Die C++ casts erhöhen die qualität des Codes.

Shade Of Mine schrieb:

Mach C Casts wenn du dumm sein willst.

besser noch: meide einfach programmiersprachen, die fünf verschiedene casts brauchen. dann stellt sich die frage garnicht erst, ob du dumm oder schlau sein willst.

hustbaer

;fricky schrieb:

Shade Of Mine schrieb:

Mach C Casts wenn du dumm sein willst.

besser noch: meide einfach programmiersprachen, die fünf verschiedene casts brauchen. dann stellt sich die frage garnicht erst, ob du dumm oder schlau sein willst.

fricky, dich will in der C++ welt sowieso keiner. bleib bei C. lass uns in ruhe.

Shade Of Mine

;fricky schrieb:

Shade Of Mine schrieb:

Mach C Casts wenn du dumm sein willst.

besser noch: meide einfach programmiersprachen, die fünf verschiedene casts brauchen. dann stellt sich die frage garnicht erst, ob du dumm oder schlau sein willst.

Du brauchst die Casts nicht, genauso wie du beim Autofahren keine Sicherheitsgurte brauchst oder Vekehrszeichen kennen musst. Kluge Leute tun sich aber anschnallen und auf Vekehrszeichen achten

Shade Of Mine schrieb:

Du brauchst die Casts nicht, genauso wie du beim Autofahren keine Sicherheitsgurte brauchst oder Vekehrszeichen kennen musst. Kluge Leute tun sich aber anschnallen und auf Vekehrszeichen achten

unpassender vergleich. *confused*
kluge leute fahren vorausschauend und situationsangemessen, dazu gehört ein wenig fahrpraxis. anschnallen und auf verkehrszeichen achten macht jeder fahrschüler bereits in der ersten stunde.

DEvent

Shade Of Mine schrieb:

Die C++ casts erhöhen die qualität des Codes.

C++ kennt doch Exceptions, oder? Wieso wurde nicht einfach vollgendes gemacht:

try {
    Foo* foo = (foo*)something;
} catch (ConstCastException e) {
    // cannot cast const * something to Foo*
} catch (PolymorphCastException e) {
    // cannot cast from something to Foo*
}

Foo foo = (Foo) something;
// ist wie static_cast: Wenn was schief geht, meckert der Compiler rum. 

Foo* foo = (foo*)something;
// ist wie reinterpret_cast, entweder es wird eine der 2 Exceptions geworfen oder es gibt wie
// bei reinterpret_cast undifiniertes Verhalten.

Keine 4 casts-Typen und kombatibel zu allen C++ Code, dass die C-Style casts kennt und Exceptions kann.

camper

hustbaer schrieb:

hm.
bist du sicher?

nein. hab unfug geschrieben.

Shade Of Mine

DEvent schrieb:

C++ kennt doch Exceptions, oder? Wieso wurde nicht einfach vollgendes gemacht:

dynamic_cast macht btw. genau das. es wirft ne exception wenn der cast fehlschlägt. und warum statische casts nix werfen sollte eigentlich klar sein.

unterschiedliche sachen die unterschiedliche arbeit machen und unterschiedliche auswirkungen haben sehen halt unterschiedlich aus.

was ist zB bei

T* t=(T*)f;

absolut mehrdeutig solange du nicht genau weisst was f ist...

Shade Of Mine schrieb:

DEvent schrieb:

C++ kennt doch Exceptions, oder? Wieso wurde nicht einfach vollgendes gemacht:

dynamic_cast macht btw. genau das. es wirft ne exception wenn der cast fehlschlägt.

nicht bei pointern, da gibt er einfach 0 zurück, wenn es fehlschlägt. warum dieses unterschiedliche verhalten? könnte er nicht in beiden fällen eine exception werfen?

Shade Of Mine

;fricky schrieb:

nicht bei pointern, da gibt er einfach 0 zurück, wenn es fehlschlägt. warum dieses unterschiedliche verhalten? könnte er nicht in beiden fällen eine exception werfen?

Exceptions nur in ausnahmefällen.
Und jetzt denk mal an die möglichen Anwendungen für dynamic_cast. Dann wirst du sehen dass es meistens zum testen verwendet wird ob eine bestimmte beziehung zwischen dem objekt und einer klasse besteht.

Wenn du dich ein bisschen mit der Materie befassen würdest, wüsstest du sowas.

DEvent

Shade Of Mine schrieb:

;fricky schrieb:

nicht bei pointern, da gibt er einfach 0 zurück, wenn es fehlschlägt. warum dieses unterschiedliche verhalten? könnte er nicht in beiden fällen eine exception werfen?

Exceptions nur in ausnahmefällen.
Und jetzt denk mal an die möglichen Anwendungen für dynamic_cast. Dann wirst du sehen dass es meistens zum testen verwendet wird ob eine bestimmte beziehung zwischen dem objekt und einer klasse besteht.

Wenn du dich ein bisschen mit der Materie befassen würdest, wüsstest du sowas.

Andere Sprachen haben ein instance_of.
Wenn ein Cast einfach eine exception werfen wuerde, so koennte man sich diese xxx_cast sparen und alle Casts haetten ein konsistentes Verhalten.

Shade Of Mine schrieb:

Exceptions nur in ausnahmefällen.

man hört immer, exceptions werden in c++ dem prüfen von rückgabewerten vorgezogen. wieso plötzlich diese ausnahme, dass beim dynamic-cast, auf pointer angewendet, der rückgabewert getestet werden muss?

Shade Of Mine schrieb:

Und jetzt denk mal an die möglichen Anwendungen für dynamic_cast. Dann wirst du sehen dass es meistens zum testen verwendet wird ob eine bestimmte beziehung zwischen dem objekt und einer klasse besteht.

hat c++ nicht 'typeid' um sowas zu testen?

camper

;fricky schrieb:

Shade Of Mine schrieb:

Exceptions nur in ausnahmefällen.

man hört immer, exceptions werden in c++ dem prüfen von rückgabewerten vorgezogen. wieso plötzlich diese ausnahme, dass beim dynamic-cast, auf pointer angewendet, der rückgabewert getestet werden muss?

hören ist gut, zuhören solltest du auch noch.

;fricky schrieb:

Shade Of Mine schrieb:

Und jetzt denk mal an die möglichen Anwendungen für dynamic_cast. Dann wirst du sehen dass es meistens zum testen verwendet wird ob eine bestimmte beziehung zwischen dem objekt und einer klasse besteht.

hat c++ nicht 'typeid' um sowas zu testen?

[/quote]nein. typeid gibt Informationen über den am weitesten abgeleiteten Typ, der interessiert in cross-cast-Fällen überhaupt nicht.