[C/C++] const auf integrale typen in einer Funktion sinnvoll?
-
;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.
-
hustbaer schrieb:
...weil
volatileeinfach keine sinnvolle Anwendung hat.*heul*
ich dachte, das hattest du mittlerweile verstanden: http://www.embedded.com/story/OEG20010615S0107
-
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.
-
;fricky schrieb:
hustbaer schrieb:
...weil
volatileeinfach 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.
-
;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
-
;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.
-
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.
-
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.
- 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)
- 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.
-
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 entlassungsgrundnö, 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:
- 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:
- 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.
-
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.
-
hustbaer schrieb:
1) const_cast ist genehmigungspflichtig 2) C-style casts sind ein entlassungsgrundNoob.
-
volkard schrieb:
hustbaer schrieb:
1) const_cast ist genehmigungspflichtig 2) C-style casts sind ein entlassungsgrundNoob.
Träumer.
-
hustbaer schrieb:
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.wieso 'schummel'? schnittstellen müssen sowieso gut dokumentiert sein, wenn andere damit arbeiten sollen. 'const' hilft dabei nur bedingt.
aussagekräftiger als 'const' finde ich z.b. die info zur datenrichtung bei den prototypen in einigen windows-headern, die schreiben __in, __out und __inout vor ihre pointer (wahrscheinlich in anlehnung an VHDL, wo in,out,inout bzw 'buffer' als port-modes auch vom compiler gecheckt werden).
-
;fricky schrieb:
aussagekräftiger als 'const' finde ich z.b. die info zur datenrichtung bei den prototypen in einigen windows-headern, die schreiben __in, __out und __inout vor ihre pointer (wahrscheinlich in anlehnung an VHDL, wo in,out,inout bzw 'buffer' als port-modes auch vom compiler gecheckt werden).
Da ich zufällig in VHDL "programmieren" kann, würde ich sagen, es hat nichts mit VHDL zu tun. VHDL ist "zu anders" und man kann es weder mit C noch C++, noch mit Assembler vergleichen, denke ich, abgesehen von der Syntax vielleicht.
Interessant wäre, wie sind diese __in, __out und __inout definiert? __in bestimmt als const, oder?
-
abc.w schrieb:
Interessant wäre, wie sind diese __in, __out und __inout definiert? __in bestimmt als const, oder?
nö, ich glaube das sind einfach nur leere #defines, damit der benutzer am funktionskopf sehen kann, in welcher richtung die pointer arbeiten. 'const' könnte man ja für 'in' nehmen, 'ohne const' für 'inout', aber für eine reine 'out'-datenrichtung sieht C nix vor (sowas wie ein 'inverses const', das wäre ein pointer, über den man schreibzugriffe machen, aber nicht lesen darf).
-
abc.w schrieb:
Da ich zufällig in VHDL "programmieren" kann, würde ich sagen, es hat nichts mit VHDL zu tun. VHDL ist "zu anders" und man kann es weder mit C noch C++, noch mit Assembler vergleichen, denke ich, abgesehen von der Syntax vielleicht.
nachtrag: die syntax ist an ADA angeleht, aber dieses konzept der port-modi könnte man auch in 'normalen' programmiersprachen verwenden.
-
;fricky schrieb:
nö, ich glaube das sind einfach nur leere #defines, damit der benutzer am funktionskopf sehen kann, in welcher richtung die pointer arbeiten...
Oder hat Microsoft vielleicht eine "Spezialversion" ihres Compilers, der diese Schlüsselwörter kennt und vielleicht die eine oder andere Warnung ausgibt, wenn z.B. etwas als __in definiert wurde und in der Funktion doch geändert wird, oder etwas als __out nichts zugewiesen bekommt, sondern fälschlicherweise gelesen wird... Wäre denkbar?
-
abc.w schrieb:
;fricky schrieb:
nö, ich glaube das sind einfach nur leere #defines, damit der benutzer am funktionskopf sehen kann, in welcher richtung die pointer arbeiten...
Oder hat Microsoft vielleicht eine "Spezialversion" ihres Compilers, der diese Schlüsselwörter kennt und vielleicht die eine oder andere Warnung ausgibt, wenn z.B. etwas als __in definiert wurde und in der Funktion doch geändert wird, oder etwas als __out nichts zugewiesen bekommt, sondern fälschlicherweise gelesen wird... Wäre denkbar?
zuzutrauen ist es ihnen jedenfalls. kannst ja mal im winapi-forum fragen, da tummeln sich die m$-compiler freaks.
-
Einfach mit MSVC++ mit /analyze compilieren.
http://msdn.microsoft.com/en-us/library/ms173498.aspx
Bzw. früher hiess das Teil PREfast:
http://msdn.microsoft.com/en-us/library/ms933794.aspx
-
;fricky schrieb:
hustbaer schrieb:
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.wieso 'schummel'?
const wegcasten, und dann etwas modifizieren, ist schummeln. du behauptest ja hier, dass man sich nicht auf const verlassen kann. das impliziert, dass es OK ist, code zu schreiben, der genau das macht: const wegcasten, und dann modifizieren. und das halte ich nunmal für völlig daneben.
schnittstellen müssen sowieso gut dokumentiert sein, wenn andere damit arbeiten sollen. 'const' hilft dabei nur bedingt.
was heisst bedingt? bedingt wie "hilft viel, aber ist nicht 100% ausreichend"? oder bedingt wie "ist so-gut-wie egal"? sag mal konkret was du meinst.
aussagekräftiger als 'const' finde ich z.b. die info zur datenrichtung bei den prototypen in einigen windows-headern, die schreiben __in, __out und __inout vor ihre pointer (wahrscheinlich in anlehnung an VHDL, wo in,out,inout bzw 'buffer' als port-modes auch vom compiler gecheckt werden).
__in macht eigentlich nur sinn, wenn ein zeiger nicht const ist, der const sein sollte.
einzig die unterscheidung zwischen __inout und __out ist etwas, was sich über const nicht abbilden lässt. im idealfall impliziert der methodenname, der parametername oder einfach die semantik der schnittstelle was gemeint ist.bei einer funktion "apply" einer klasse "inplace_blur_filter" brauche ich nicht dazuschreiben dass es "in/out" ist, da es logisch ist.
sollte es nicht logisch sein, dann gehört es dokumentiert. habe nie was anderes behauptet.
ich behaupte nur, dass const einen nicht unwesentlichen teil dessen was dokumentiert gehört abdeckt, und dass der compiler die checks übernimmt, ob man sich auch an das hält, was man verspricht. genau das ist ja der grosse vorteil dabei.
eine doku die irgendwo steht, kann der compiler nicht checken. und dass doku sehr schnell veraltet, ist etwas was ich nicht nur glaube, sondern aus der praxis 100% bestätigen kann.
