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

[;fricky]

hustbaer schrieb:

hier: http://hz211.blogspot.com/2006/03/regular-expression-to-find-c-style.html
aber mal ehrlich, nach casts zu suchen kommt ja wohl sehr selten vor.

ja klar, man will sich ja auch nie vergewissern dass keiner irgendwo nen const_cast macht (und dann böses damit anstellt). kommt auch gerade beim fehler-suchen nie vor.

ich hab' gerade überlegt, wann ich mal code nach casts durchsucht habe, aber mir ist echt nichts eingefallen. kann natürlich sein, dass suchen nach casts unter c++ üblich ist (vielleicht weil's verschiedene casts gibt, die man verwechseln kann?), aber das entzieht sich meiner kenntnis.
zu dem code-beispiel: falls du zeigen wolltest, dass man absichtlich fehler einbauen kann, so isses dir gelungen. nur, mit c++-cast hättest du ebenso fehler produzieren können. man muss wissen was man tut. ich sehe nicht, dass c++ casts einem das abnehmen.

[otze]

abc.w schrieb:

Ich will aber nicht, dass jemand diese Parameter ändert, weil wenn er es tut, dann kann er dabei etwas falsch machen, es sei denn, er ist wirklich gut, aber wer kann denn schon von sich behaupten, er wäre wirklich gut

Dann kopiert er einfach. Das können auch schlechte Programmierer. Du hast also nichts gewonnen. Das Interface ist schwerer verständlich, der Profi ist genervt, und der Anfänger macht den selben Müll wie sonst auch immer.

@ Basher. oder Basher_ist_nicht_Bashar (Wettschulden sind Ehrenschulden)

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.

[;fricky]

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.

[hustbaer]

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

ach, vergessen. ich hab dich nicht mit der nase drauf gestossen. aber hätte ich es, hättest du es genauso überlesen bzw. ignoriert, wie du es mit allem machst was ich schreibe.

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

[hustbaer]

;fricky schrieb:

hustbaer schrieb:

hier: http://hz211.blogspot.com/2006/03/regular-expression-to-find-c-style.html
aber mal ehrlich, nach casts zu suchen kommt ja wohl sehr selten vor.

ja klar, man will sich ja auch nie vergewissern dass keiner irgendwo nen const_cast macht (und dann böses damit anstellt). kommt auch gerade beim fehler-suchen nie vor.

ich hab' gerade überlegt, wann ich mal code nach casts durchsucht habe, aber mir ist echt nichts eingefallen.

;fricky schrieb:

DrGreenthumb schrieb:

machst du einfach immer erstmal eine Kopie von deinem Buffer bevor du eine Fremdfunktion aufrufst? Oder verfolgst du den Weg den der Buffer so beschreitet?

ich vergewissere mich zumindest, ob meine daten verändert werden können oder nicht. ein 'const' im funktionskopf ist schon mal ein guter hinweis, aber keine garantie.

hm.
was glaubst du wohl, wieso ich jemals auf die idee kommen könnte, nach casts zu suchen. hmmmmmm.

;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?
keine natürlich, denn man muss ja wissen was man tut!

[;fricky]

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.

[;fricky]

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

[;fricky]

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

[;fricky]

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