Wieso "const" verwenden?
-
Blue-Tiger schrieb:
Ich bin sehr wohl der Meinung, dass const ueberall dort verwendet werden sollte, wo es verwendet werden kann (ohne dass dabei die Semantik veraendert wird).
I think it will be convenient to have special C++ compiler, where all variables, methods, etc. are const by default. And this compiler should have a special keyword "non_const" to explicity declare non-const objects
I have looked through some of my programs and firured out that they will became shorter with "non_const" keyword insteat of "const".
-
globals-freak schrieb:
Jester schrieb:
...also eigentlich nur bei globalen Konstanten.
das ist auch der einzige fall, bei dem ich 'const' verwende.
Naja und da ich mal annehem, dass du keine 100 MB an Speicher drinn hast, wird es kaum merkbar sein, dass da Speicher gespart wird.
-
SAn, there are languages that work like this, e.g. Nemerle which declares each object as immutable except for those that are explicitly marked 'mutable'.
In most functional programming languages 'const' is the only known behaviour. Binding a value to a name is permanent and this same name cannot be rebound in the same context.
-
Ich find ein const sieht einfach schööön aus
const int SIZE = 10; void func( const Muap& obj ); int getMem() const;
-
KasF schrieb:
Ich find ein const sieht einfach schööön aus
const int SIZE = 10; void func( const Muap& obj ); int getMem() const;
Und ich finde, es sieht noch schöner aus, wenn man die const-Position konsistent hält:
int const SIZE = 10; void func( Muap const& obj ); int getMem() const;
Gruß,
Simon2.
-
Welche Variante findet ihr 'stilistisch schöner':
1. Hier folge ich dem Ratschlag in meinem Buch, dass ich mit C++ keine #define Anweisungen verwenden darf (obwohl GANZ ohne #define klappt es nicht):
#ifndef FARBEN const short VII = 7; const short VIII = 8; const short IX = 9; const short X = 10; const short BUBE = 11; const short DAME = 12; const short KOENIG = 13; const short ASS = 15; const short JOKER = 23; const short ATOUTBONUS = 9; #define FARBEN
2. In guter alter C-Manier würde ich es so schreiben:
#define VII = 7; #define VIII = 8; #define IX = 9; #define X = 10; #define BUBE = 11; #define DAME = 12; #define KOENIG = 13; #define ASS = 15; #define JOKER = 23; #define ATOUTBONUS = 9;
... und auch in diesem Fall wäre der Header überall problemlos verwendbar.
Der Sinn und Zweck von Konstanten ist doch wohl nur, um den Quelltext etwas leserlicher zu gestalten. Wenn ich im Quelltext irgendwo '12' hinschreibe, dann sieht das sehr verdächtig aus. Wenn dort stattdessen 'DAME' steht, ist schon eher ersichtlich, dass es hier um einen Kartenrang geht -> ergo: der einzige Sinn und Zweck von Konstanten scheint zu sein, dass ein Quelltext für den Programmierer besser leserlich wird. Ob jetzt die Konstanten mittels const oder #define vereinbart werden, scheint eher nebensächlich zu sein. Vielmehr ärgerlich ist es bei den mittels 'const' vereinbarten Konstanten, dass geradezu ein Definitionszwang besteht, was gerne zu Compiler-Fehlern (Konstante mehrfach definiert etc.) führt, wenn die gleiche Header-Datei in mehreren Teilen einer Anwendung verwendet werden soll.Auch bei den enum{} - Konstanten gibt es öfter Ärger als Freude.
Jedenfalls meine Meinung zum Thema Konstanten, ich kann auch total daneben liegen
-
edit: die Semikola bei dem #define - Quelltext gehören dort natürlich nicht hin ... mfg
-
Weder noch. Dafür nimmt man enums.
/EDIT: Inwiefern soll es mit enums Ärger geben?
-
Konrad Rudolph schrieb:
Weder noch. Dafür nimmt man enums.
/EDIT: Inwiefern soll es mit enums Ärger geben?
Habe genau das auch gedacht. - Das Beispiel macht es einem ja soo einfach.
-
Konrad Rudolph schrieb:
Weder noch. Dafür nimmt man enums.
/EDIT: Inwiefern soll es mit enums Ärger geben?
Was nur geht wenn du konstanten auf reine Ganzzahlwerte beschränkst. Okay, im vorliegenden Fall hätte ich vermutlich auch ein enum genommen, aber das liegt am Beispiel.
-
The God is const, and our world is const in 4D (x,y,z,t) representation.
-
enums sind nicht gut geeignet, weil z.B. DAME + ATOUTBONUS den Wertebereich des Aufzählungstyps verlassen würde, überhaupt lässt sich mit enum-Konstanten nicht sonderlich gut rechnen.
enum Rang{VII =7, VIII = 8, IX = 9}; Rang meinRang = (Ergebnis irgend einer Berechnung); /* Fehler! Selbst wenn der Wert im zulaessigen Bereich liegen wuerde. */ Rang meinRang2 = meinRang + 2; /* Fehler! -> enum ist unbequem und unflexibel */
-> enum nur dann, wenn auch hundertprozentig niemals damit gerechnet wird. Das ist aber oft schwer vorherzusehen. Deshalb lieber #define oder const, damit lässt sich später bestimmt problemlos rechnen.
-
unerfahren3 schrieb:
enums sind nicht gut geeignet, weil z.B. DAME + ATOUTBONUS den Wertebereich des Aufzählungstyps verlassen würde
Nein, tut es nicht. Aber es stimmt, allgemein sind enums nicht für Addition o.ä. vorgesehen. In diesem Fall ist eine Addition aber eher nicht angebracht, es wäre wohl sinnvoller, Flags zu verwenden und diese zu verodern.
-
drakon schrieb:
globals-freak schrieb:
Jester schrieb:
...also eigentlich nur bei globalen Konstanten.
das ist auch der einzige fall, bei dem ich 'const' verwende.
Naja und da ich mal annehem, dass du keine 100 MB an Speicher drinn hast, wird es kaum merkbar sein, dass da Speicher gespart wird.
doch, letztens erst ein paar webseiten + code mussten in 256K flash passen. der RAM war nur 64K gross. da hat 'const' echt was geholfen. aber eigentlich ziehe ich #pragmas oder irgendwelche linkereinstellungen vor, um objekte an bestimmte speicherbereiche festzunageln.
-
webdesign-freak schrieb:
drakon schrieb:
globals-freak schrieb:
Jester schrieb:
...also eigentlich nur bei globalen Konstanten.
das ist auch der einzige fall, bei dem ich 'const' verwende.
Naja und da ich mal annehem, dass du keine 100 MB an Speicher drinn hast, wird es kaum merkbar sein, dass da Speicher gespart wird.
doch, letztens erst ein paar webseiten + code mussten in 256K flash passen. der RAM war nur 64K gross. da hat 'const' echt was geholfen. aber eigentlich ziehe ich #pragmas oder irgendwelche linkereinstellungen vor, um objekte an bestimmte speicherbereiche festzunageln.
Ok. Ich habe in "PC- Dimensionen" gedacht.
-
Simon2 schrieb:
KasF schrieb:
Ich find ein const sieht einfach schööön aus
const int SIZE = 10; void func( const Muap& obj ); int getMem() const;
Und ich finde, es sieht noch schöner aus, wenn man die const-Position konsistent hält:
int const SIZE = 10; void func( Muap const& obj ); int getMem() const;
Gruß,
Simon2.
ich finds eigentlich ganz praktisch, wenn man sofort das "const" sieht. Aber ich seh letztens oefters "Foo const& foo" anstatt "const Foo& foo"... wie kommts?
-
Blue-Tiger schrieb:
ich finds eigentlich ganz praktisch, wenn man sofort das "const" sieht. Aber ich seh letztens oefters "Foo const& foo" anstatt "const Foo& foo"... wie kommts?
Hat Simon doch geschrieben: Weil's so konsistent ist. Bei 'const'-Methoden ist das 'const' halt zwangsläufig postfix, daher bietet es sich an, dass es auch bei anderen Deklarationen postfix gestellt wird.
-
Konrad Rudolph schrieb:
Blue-Tiger schrieb:
ich finds eigentlich ganz praktisch, wenn man sofort das "const" sieht. Aber ich seh letztens oefters "Foo const& foo" anstatt "const Foo& foo"... wie kommts?
Hat Simon doch geschrieben: Weil's so konsistent ist. Bei 'const'-Methoden ist das 'const' halt zwangsläufig postfix, daher bietet es sich an, dass es auch bei anderen Deklarationen postfix gestellt wird.
es ist bei den const-Methoden ja eigentlich nur ein layouttechnischer "Hack", weil der this-Zeiger implizit uebergeben wird. Aus Konsitenzgruenden ueber all das const am Ende zu schreiben find ich da etwas merkwuerdig o_0 Ist das echt der einzige Grund?
-
Beim Programmieren ist vieles ein – wie nanntest Du's? – layouttechnischer Hack. Es geht schließlich darum, das ganze lesbar zu machen.
Da die beiden Varianten ansonsten gleichwertig sind, ist das u.a. für mich Grund genug.
-
pumuckl schrieb:
Bashar schrieb:
Nachteile von const:
http://c2.com/cgi/wiki?AvoidConstCompletelyWenn man sich das mal genauer anschaut kommen dort zu jedem Nachteil, den const angeblich hat (schwarze Punkte), mehrere Gegenargumente (weisse Punkte)...
Und wenn man es noch genauer anschaut, sieht man, dass das nicht so ist
Die weißen Punkte sind auch manchmal keine Gegenargumente, manchmal fehlen Gegenargumente oder beziehen sich nur auf eingeschränkte Aspekte. Wenn man const benutzt, muss man sich darüber im klaren sein, dass sich das durch das ganze Programm zieht (=> ConstIsAVirus), weil man auf einem const-Objekt nur const-Methoden aufrufen kann. Das führt dann irgendwann zu solchen Abscheulichkeiten wie const_iterator, also Codeduplikation. Wenn man da mal den Gewinn gegenrechnet, sieht das gar nicht mehr so gut aus für const.