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

[abc.w]

Mir hilft es auch. Es hilft wesentlich gegen mich Damit weiss ich, was in der Funktion "input" ist und was man nicht verändern sollte.

hustbaer schrieb:

...Da gab es Dinge die kann man sich kaum vorstellen. So ala OpenFile(path); , und 5-10 Call-Stack Ebenen tiefer kommt man drauf, dass dieser Aufruf path modifiziert...

Ups, das mit path und mit modifizieren könnte gut ich gewesen sein...

[Shade Of Mine]

DEvent schrieb:

Shade Of Mine schrieb:

Dieses Problem hat man in allen Sprachen wo es referenzen gibt.

Interesanterweise gibt es das Kozept des const-correctness nur in C++. Alle anderen Sprachen kommen sehr gut ohne sowas aus.

Lies meine Posts bitte.

Ich habe gesagt const correctness ist in C++ genauso wichtig oder unwichtig wie in Java. Es ist ein Tool, mehr nicht.

Stellt sich die Frage, ob man es wirklich braucht und ob es wirklich dem Programmierer hilft. Const ist wohl das neue Goto, man kann alles machen ohne es, aber es gibt jede Menge Programmierer, die auf Goto/Const schwoeren.

Es gibt ja genug stimmen die auch ein const in Java fordern. Java hat zB das Konzept der immutable Klassen und final für primitive Typen. Statt T const& macht man in Java dann halt defensive Kopien.

Wie du siehst hast du in Java und allen anderen Sprachen mit Referenzen das exakt selbe Problem. Ob const jetzt die beste Lösung ist sei mal dahingestellt - aber es ist eine gute Lösung.

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