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

[Tyrdal]

Aus meiner Sicht falsch. Man kann ohne auskommen. Man kann auch ohne Strom und fließend Wasser auskommen. Bequemer ist aber mit (Gründe kamen schon im Thread). Andere Sprachen haben auch keine Destruktoren und es gibt etliche Stellen an den ich die vermisse wenn ich in den Sprachen arbeiten muß. Also nur weils die Mehrheit anders macht muß es nicht besser sein.

[hustbaer]

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. Stellt sich die Frage, ob man es wirklich braucht und ob es wirklich dem Programmierer hilft.

Es hilft.
Es hilft (begrenzt, aber nicht unwesentlich) gegen dumme Programmierer.
Gegen die Programmierer, die sich nichts dabei denken würden in einem Getter irgendwas zu modifizieren, wenn der Compiler dabei nicht schreit. Die aber doch (gottseidank) zu feige und/oder zu blöd sind, einen const_cast dafür zu verwenden, um den Fehler zu "umschiffen".

Ich habe schon in einigen Projekten Fehler gesucht. Das schlimmste war ein Projekt an dem > 5 Programmierer gearbeitet haben, wo keinerlei const verwendet wurde.
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.

Was andere Sparchen angeht: dort hilft man sich oft über "immutable" Klassen. An Stellen, wo diese total unnötig wären, wenn man const hätte.

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