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

[;fricky]

DEvent schrieb:

Interesanterweise gibt es das Kozept des const-correctness nur in C++.

naja, aber so'nem konzept vertraut der erfinder von c++ wohl selbst nicht, denn sonst hätte wohl kaum einen 'const_cast' mitgeliefert.

Shade Of Mine schrieb:

Es gibt ja genug stimmen die auch ein const in Java fordern.

bis vor 4...5 jahren etwa, aber die 'anti-const'-fraktion hat schliesslich gewonnen.

[Shade Of Mine]

;fricky schrieb:

DEvent schrieb:

Interesanterweise gibt es das Kozept des const-correctness nur in C++.

naja, aber so'nem konzept vertraut der erfinder von c++ wohl selbst nicht, denn sonst hätte wohl kaum einen 'const_cast' mitgeliefert.

Dann traut wohl Niemand dem Typen Konzept, denn warum sonst gibt es type-casts?

Shade Of Mine schrieb:

Es gibt ja genug stimmen die auch ein const in Java fordern.

bis vor 4...5 jahren etwa, aber die 'anti-const'-fraktion hat schliesslich gewonnen.

ich sage nicht dass const in java eine gute idee ist, nur dass man es sich ernsthaft überlegt hat.

[;fricky]

Shade Of Mine schrieb:

;fricky schrieb:

DEvent schrieb:

Interesanterweise gibt es das Kozept des const-correctness nur in C++.

naja, aber so'nem konzept vertraut der erfinder von c++ wohl selbst nicht, denn sonst hätte wohl kaum einen 'const_cast' mitgeliefert.

Dann traut wohl Niemand dem Typen Konzept, denn warum sonst gibt es type-casts?

nicht das typen-konzept an sich, sondern das 'irgendwas-correctness'-konzept ist zu unhandlich. niemand spricht von char- float- oder long-correctness, weil's klar ist, dass gewisse sinnvolle typkonvertierungen möglich sein müssen. und genauso isses mit 'const' und dem const-cast. mit const-correctness macht man sich nur unnötig das leben schwer, ohne gross was zu gewinnen. auch ein nicht const-korrektes programm kann sonst korrekt sein.
btw, wieso hört man eigentlich nichts von 'static'- oder 'volatile'-correctness?

[DrGreenthumb]

;fricky schrieb:

mit const-correctness macht man sich nur unnötig das leben schwer, ohne gross was zu gewinnen. auch ein nicht const-korrektes programm kann sonst korrekt sein.

du hast noch nie im team programmiert oder sonst großartig mit fremdcode zu tun gehabt, oder? die welt ist größer als die eigenen 2000 zeilen wo man immer schön den durchblick hat.

btw, wieso hört man eigentlich nichts von 'static'- oder 'volatile'-correctness?

weil das überhaupt keinen sinn macht. Weißt du was die wörter bedeuten?!

[;fricky]

DrGreenthumb schrieb:

du hast noch nie im team programmiert oder sonst großartig mit fremdcode zu tun gehabt, oder?

doch, beides.

DrGreenthumb schrieb:

Weißt du was die wörter bedeuten?!

in C? schau mal hier:
http://en.wikipedia.org/wiki/Static_variable
http://en.wikipedia.org/wiki/Volatile_variable

[DrGreenthumb]

;fricky schrieb:

DrGreenthumb schrieb:

Weißt du was die wörter bedeuten?!

in C? schau mal hier:
http://en.wikipedia.org/wiki/Static_variable
http://en.wikipedia.org/wiki/Volatile_variable

das "?!" sollte andeuten, dass ich dir frecherweise unterstelle, dass DU es nicht weißt.

Schonmal versucht static oder volatile wegzucasten? Die Eigenschaften sind überhaupt nicht mit const vergleichbar.

[Nexus]

DrGreenthumb schrieb:

Schonmal versucht static oder volatile wegzucasten? Die Eigenschaften sind überhaupt nicht mit const vergleichbar.

Ach nein? Dann ist es also Zufall, dass man von CV-Qualifizierern spricht, wenn man const und volatile meint?

static ist hingegen eine Speicherklasse und hat wirklich nichts damit zu tun.

[hustbaer]

@DrGreenthumb:
Doch, volatile verhält sich *exakt so wie const *.
static natürlich nicht, das ist klar.

EDIT: es heisst auch nicht umsonst "cv-qualified"

Und von volatile hört man in dem Zusammenhang nichts, weil volatile einfach keine sinnvolle Anwendung hat.

@fricky:

nicht das typen-konzept an sich, sondern das 'irgendwas-correctness'-konzept ist zu unhandlich.

Sehe ich genau andersrum: unpraktisch finde ich, dass C++ viel zu wenig solche Checks ermöglicht.

niemand spricht von char- float- oder long-correctness, weil's klar ist, dass gewisse sinnvolle typkonvertierungen möglich sein müssen

Versuch mal in C# eine Konvertierung von int nach short zu machen. Oder von int nach unsigned int.
Und darüber sprechen auch genug Leute, bzw. schreiben.
Ich kann also nicht ganz nachvollziehen was du meinst.

Falls du meinst es spricht keiner darüber im Zusammenhang mit C++: das liegt vermutlich daran, dass es in C++ eben nicht geht, da C++ solche Konvertierungen nunmal implizit erlaubt.

[;fricky]

DrGreenthumb schrieb:

das "?!" sollte andeuten, dass ich dir frecherweise unterstelle, dass DU es nicht weißt.

dann weiss ich's spätestens jetzt, brauche ja nur die verlinkten seiten zu lesen.

DrGreenthumb schrieb:

Schonmal versucht static oder volatile wegzucasten? Die Eigenschaften sind überhaupt nicht mit const vergleichbar.

naja, zumindest 'volatile' ist ein qualifizierer ähnlich wie 'const', da könnte doch auch jemand auf idee kommen, 'volatile-correctness' zu erfinden.

[DrGreenthumb]

Nexus schrieb:

DrGreenthumb schrieb:

Schonmal versucht static oder volatile wegzucasten? Die Eigenschaften sind überhaupt nicht mit const vergleichbar.

Ach nein? Dann ist es also Zufall, dass man von CV-Qualifizierern spricht, wenn man const und volatile meint?

static ist hingegen eine Speicherklasse und hat wirklich nichts damit zu tun.

ja stimmt. volatile hatte ich im Nachhinein auch anders eingestuft. Aber scheiss auf "volatile-correctness". Das ist nur eine manchmal wichtige Anweisung an den Compiler. Benutzt man vielleicht 1x in 5 Jahren.

[DrGreenthumb]

;fricky schrieb:

DrGreenthumb schrieb:

du hast noch nie im team programmiert oder sonst großartig mit fremdcode zu tun gehabt, oder?

doch, beides.

wie kannst du dann ernsthaft const in Frage stellen??

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?

Gerade in C wurde const doch auch nachträglich eingeführt, weil es wohl Sinnvoll ist.

[;fricky]

hustbaer schrieb:

...weil volatile einfach keine sinnvolle Anwendung hat.

*heul*
ich dachte, das hattest du mittlerweile verstanden: http://www.embedded.com/story/OEG20010615S0107

[;fricky]

DrGreenthumb schrieb:

Aber scheiss auf "volatile-correctness". Das ist nur eine manchmal wichtige Anweisung an den Compiler.

'const' ist auch eine wichtige anweisung an den compiler, aber nicht nur.

DrGreenthumb schrieb:

wie kannst du dann ernsthaft const in Frage stellen??

tue ich ja nicht wirklich. ich halte nur 'const-correctness' für übertrieben und wenig hilfreich.

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.

[hustbaer]

;fricky schrieb:

hustbaer schrieb:

...weil volatile einfach keine sinnvolle Anwendung hat.

*heul*
ich dachte, das hattest du mittlerweile verstanden: http://www.embedded.com/story/OEG20010615S0107

fricky,

ich hoffe du weisst dass ich genau weiss was volatile macht, und wo es sinn macht und wo nicht.
aber vielleicht könntest du mal über den tellerrand gucken, zu den programmierern unter uns, die nicht jeden tag low-level zeugs für diverse embedded systeme stricken.

volatile macht sinn, wenn ich ne threading-library schreibe, und es mit memory-barriers kombiniere. volatile macht sinn, wenn ich interrupt-code schreiben will. wenn ich register beschreiben will, die in den normalen speicher-adressraum gemappt sind. etc. bloss WER TUT DAS???

"volatile hat keine sinnvolle anwendung" ist eine vereinfachung bzw. übertreibung, ok. aber eine die für 95% aller programmierer zutrifft.

[hustbaer]

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

sorry, aber das ist IMO total praxisfremd. würde ich immer und überall nachprüfen, ob irgendwas modifiziert wird, was ich an eine funktion als "const" übergebe, dann würde meine produktivität vermutlich auf 1-5% sinken.
in grossen projekten ist das einfach komplett undurchführbar.
wenn noch funktoren/templates/callbacks etc. dazukommen ist endgültig alles aus.

wenn man dagegen zwei einfach regeln in die coding-guidelines aufnimmt, kann man wunderbar mit const arbeiten:

1) const_cast ist genehmigungspflichtig
2) C-style casts sind ein entlassungsgrund

-> problem gelöst

p.S.: ich weiss nicht was du unter gross verstehst. ich verstehe unter gross etwas ab vielleicht 50 KLOC

[DrGreenthumb]

;fricky schrieb:

DrGreenthumb schrieb:

wie kannst du dann ernsthaft const in Frage stellen??

tue ich ja nicht wirklich. ich halte nur 'const-correctness' für übertrieben und wenig hilfreich.

"const-correctness" ergibt sich aber gezwungenermaßen sobald man irgendwo const schreibt. Also was nu? const gut oder schlecht?

Ich fluche jedes mal über c++-const-correctness wenn ich mal wieder eine Funktion doppelt überladen muss. Aber viel heftiger wird geflucht, wenn die get_name-Funktion den Namen mal eben um ein Komma erweitert

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.

und wie? Da gibt es nur die zwei Wege die ich vorgeschlagen habe. Beide scheisse!

ein 'const' im funktionskopf ist schon mal ein guter hinweis, aber keine garantie.

Sollte es aber sein. Sonst bringt natürlich das ganze nichts.

[;fricky]

hustbaer schrieb:

volatile macht sinn, wenn ich ne threading-library schreibe, und es mit memory-barriers kombiniere. volatile macht sinn, wenn ich interrupt-code schreiben will. wenn ich register beschreiben will, die in den normalen speicher-adressraum gemappt sind. etc. bloss WER TUT DAS???

eigentlich alle, die eine low-level bzw. maschinennahe programmiersprache benutzen, die dieses keyword kennt, weil diese sprache für maschinennahe programmierung entwickelt wurde und daher auch dafür verwendet wird. wer nicht maschinennah programmiert muss sich natürlich nicht mit 'volatile' auseinandersetzen.
ausnahme: Java kennt auch 'volatile' (als eine art non-blocking 'synchronized'), aber da hab' ich wirklich noch nie erlebt, dass es einer benutzt hat.

[hustbaer]

EDIT: arr, einen satz überlesen, und schon die ganze antwort sinnlos
also nochmal:

eigentlich alle, die eine low-level bzw. maschinennahe programmiersprache benutzen, die dieses keyword kennt, weil diese sprache für maschinennahe programmierung entwickelt wurde und daher auch dafür verwendet wird.

dieser satz enthält schlüsse, die ich so nicht anerkenne.

1. dass eine sprache das keyword volatile kennt, bedeutet nicht dass sie für maschinnennahe programmierung entwickelt wurde (das Beispiel Java hast du ja selbst schon gebracht. C++ sehe ich selbst auch in dieser kategorie)
2. dass jmd. eine sprache einsetzt, die für maschinnennahe programmierung gemacht wurde, bedeutet nicht, dass er selbst maschinnennah programmiert

angenommen ne firma macht ein mittleres bis grösseres projekt in C. ohne grosses mächtiges OS daruner. wieviel code schätzt du wird bzw. sollte deiner meinung nach davon "maschinnennah" sein?

ich sage: so wenig wie möglich. d.h. es werden auch wenig entwickler daran arbeiten. der grossteil wird einfach nur deren library/schicht/funktionen einsetzen. und genau dieser grossteil braucht volatile genauso wenig, wie ein python programmierer.

wer nicht maschinennah programmiert muss sich natürlich nicht mit 'volatile' auseinandersetzen.

hm. was inetwa dem gleichkommt, was ich geschrieben habe, oder?

nur dass ich den schluss "lowlevel geeignete sprache == alles nur lowlevel code" nicht akzeptiere.

[;fricky]

hustbaer schrieb:

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

sorry, aber das ist IMO total praxisfremd. würde ich immer und überall nachprüfen, ob irgendwas modifiziert wird, was ich an eine funktion als "const" übergebe, dann würde meine produktivität vermutlich auf 1-5% sinken.
in grossen projekten ist das einfach komplett undurchführbar.

naja, dann hab' ich wohl glück, dass keiner meine produktivität an der menge des codes bemessen kann, den ich schreibe, sondern eher an dingen, die funktionieren, also was am ende dabei rumkommt. dazu gehört z.b. dass man sich mit tools und libraries und deren bugs intensiv auseinandersetzt, um nicht hinterher wie der 'ochs vorm berge' zu stehen. langfristig lohnt es sich, je mehr man von dem zeug versteht, dass man verwendet, als es einfach nur blind anzuwenden. aber das weisst du sicher selbst.

hustbaer schrieb:

wenn man dagegen zwei einfach regeln in die coding-guidelines aufnimmt, kann man wunderbar mit const arbeiten:

1) const_cast ist genehmigungspflichtig
2) C-style casts sind ein entlassungsgrund

nö, das mögen vielleicht c++ mässige code monkey regeln sein. besser sind solche:
1. du kennst das ziel, du weisst was du tust, ich vertraue dir.
2. mangelhafte kreativität ist ein entlassungsgrund.

hustbaer schrieb:

ich weiss nicht was du unter gross verstehst. ich verstehe unter gross etwas ab vielleicht 50 KLOC

das grösste projekt an dem ich manchmal arbeite hat etwa 140.000 LOC. sonst sinds eher kleinere.

DrGreenthumb schrieb:

"const-correctness" ergibt sich aber gezwungenermaßen sobald man irgendwo const schreibt.

nein, du kannst jederzeit gefahrlos zwischen const und nicht-const wechseln, sofern du damit kein undefiniertes verhalten provozierst.

DrGreenthumb schrieb:

Also was nu? const gut oder schlecht?

kommt drauf an, es hat vor- und nachteile. so genau kann man das nicht sagen.

DrGreenthumb schrieb:

Ich fluche jedes mal über c++-const-correctness wenn ich mal wieder eine Funktion doppelt überladen muss.

code-duplizierung ist mist. in dem fall ist 'const' von nachteil.

hustbaer schrieb:

1. dass eine sprache das keyword volatile kennt, bedeutet nicht dass sie für maschinnennahe programmierung entwickelt wurde (das Beispiel Java hast du ja selbst schon gebracht. C++ sehe ich selbst auch in dieser kategorie)

in Java hat 'volatile' eine andere bedeutung als in C. c++ hat volatile einfach von C übernommen (wie ich glaube). der grund ist wohl, damit man möglichst einfach bestehenden C code mit einem C++ compiler übersetzen kann.

hustbaer schrieb:

2. dass jmd. eine sprache einsetzt, die für maschinnennahe programmierung gemacht wurde, bedeutet nicht, dass er selbst maschinnennah programmiert

dann hat er vielleicht die falsche sprache gewählt.

hustbaer schrieb:

angenommen ne firma macht ein mittleres bis grösseres projekt in C. ohne grosses mächtiges OS daruner. wieviel code schätzt du wird bzw. sollte deiner meinung nach davon "maschinnennah" sein?

ziemlich viel, denn es fängt bei maschinennahen datentypen wie 'int' an und hört irgendwo beim benutzen von systemspezifischen APIs auf. dazwischen kann man natürlich 'relativ plattformunabhängig' programmieren, aber man erreicht nie den grad der plattformunabhängigkeit wie z.b. bei einer VM- oder skriptsprache.

[hustbaer]

ok, fricky, sorry. mein fehler.
kreativen const-schummel code zu schreiben ist natürlich produktiver als sauber zu programmieren. wie konnte ich nur was anderes glauben.