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



  • volkard schrieb:

    Wenn ich mich recht erinnere, ist ein entconsten dann doch definiert, wenn das ursprüngliche objekt auch nicht const war.

    das klingt vernünftig, allerdings braucht man das ja nie, weil man sich auf ein nicht-const ursprungsobjekt auch immer einen nicht-const zeiger ohne cast machen kann.
    🙂



  • ;fricky schrieb:

    aber ich meine nicht, dass 'const' grundsätzlich sinnlos ist, denn es hilft dem compiler besser zu optimieren, so wie 'restrict' z.b.
    🙂

    Abgesehen von static const, ermöglich const genau garkeine Optimierungen, die so nicht möglich wären.



  • ;fricky schrieb:

    volkard schrieb:

    Wenn ich mich recht erinnere, ist ein entconsten dann doch definiert, wenn das ursprüngliche objekt auch nicht const war.

    das klingt vernünftig, allerdings braucht man das ja nie, weil man sich auf ein nicht-const ursprungsobjekt auch immer einen nicht-const zeiger ohne cast machen kann.
    🙂

    Nicht wenn man an einer bestimmten Stelle nur den const Zeiger zur Verfügung hat.



  • hustbaer schrieb:

    ;fricky schrieb:

    volkard schrieb:

    Wenn ich mich recht erinnere, ist ein entconsten dann doch definiert, wenn das ursprüngliche objekt auch nicht const war.

    das klingt vernünftig, allerdings braucht man das ja nie, weil man sich auf ein nicht-const ursprungsobjekt auch immer einen nicht-const zeiger ohne cast machen kann.
    🙂

    Nicht wenn man an einer bestimmten Stelle nur den const Zeiger zur Verfügung hat.

    dAS DÜRFTE NORMALERWEISE NUR IN fOLE EINES dENKFEHLERS 8MIST; CAPS-lOCK9 in der benutzten Bibliothek entstanden sein.
    Falls ich nur ordentliche libs benutze, sagen wie mal nur std::, brauche ich dann noch const_cast? Ich kann mich jetzt an keinen Fall erinnern.



  • hustbaer schrieb:

    ;fricky schrieb:

    aber ich meine nicht, dass 'const' grundsätzlich sinnlos ist, denn es hilft dem compiler besser zu optimieren, so wie 'restrict' z.b.
    🙂

    Abgesehen von static const, ermöglich const genau garkeine Optimierungen, die so nicht möglich wären.

    das würde ich nicht unterschreiben. 'const' könnte einen compiler z.b. dazu bewegen, sogenannte 'immediate' adressierung einzusetzen, also konstanten direkt in den maschinencode einzubauen, obwohl's im quelltext variablen sind. solche optimierungen fallen ihm ohne 'const' schwerer, weil er den quellcode analysieren müsste, um zu erkennen, dass keine schreibzugriffe stattfinden.
    🙂



  • ;fricky schrieb:

    hustbaer schrieb:

    ;fricky schrieb:

    aber ich meine nicht, dass 'const' grundsätzlich sinnlos ist, denn es hilft dem compiler besser zu optimieren, so wie 'restrict' z.b.
    🙂

    Abgesehen von static const, ermöglich const genau garkeine Optimierungen, die so nicht möglich wären.

    das würde ich nicht unterschreiben. 'const' könnte einen compiler z.b. dazu bewegen, sogenannte 'immediate' adressierung einzusetzen, also konstanten direkt in den maschinencode einzubauen, obwohl's im quelltext variablen sind. solche optimierungen fallen ihm ohne 'const' schwerer, weil er den quellcode analysieren müsste, um zu erkennen, dass keine schreibzugriffe stattfinden.
    🙂

    Oh Mann fricky, schalte mal dein Hirn ein. Er muss den Code sowieso analysieren, da const_cast ja schliesslich erlaubt ist. Nen? Eieieie...

    Ausgenommen sind da lediglich statische/globale Objekte/Variablen.



  • hustbaer schrieb:

    Er muss den Code sowieso analysieren, da const_cast ja schliesslich erlaubt ist.

    muss er, aber er wird anders reagieren, wenn er 'const', 'const-wegcast' oder nichts davon findet. willst du sagen, 'const' hätte keinen einfluss auf den erzeuigten code, sondern ist lediglich auf der logischen ebene vorhanden?
    🙂



  • ;fricky schrieb:

    hustbaer schrieb:

    Er muss den Code sowieso analysieren, da const_cast ja schliesslich erlaubt ist.

    muss er, aber er wird anders reagieren, wenn er 'const', 'const-wegcast' oder nichts davon findet. willst du sagen, 'const' hätte keinen einfluss auf den erzeuigten code, sondern ist lediglich auf der logischen ebene vorhanden?
    🙂

    ist mehr als nur logisch.

    int const size=100;
    char a[size];
    

    geht nicht ohne const.
    warum geht das eigentlich mit const? oder hat mich gcc nur zu sehr verwöhnt?

    double const PI=3.14;
    foo(PI);
    

    dringende empfehlung an den compiler, foo(3.14) zu schreiben und erlaubnis, keinen speicherplatz für PI anzulegen.



  • hustbaer schrieb:

    Er muss den Code sowieso analysieren, da const_cast ja schliesslich erlaubt ist. Nen? Eieieie...

    Der Compiler muss bei als const deklarierten Variablen nicht zwingend prüfen, ob jemals ein const_cast eingesetzt wird - deshalb ist das Verändern von Objekten, die ursprünglich const waren, ja auch undefiniert. Beispiel mit MSVC++:

    int main()
    {
    	const int a = 5;						// konstanter Ausdruck
    	const int b = (rand() >= 0) ? 5 : 1;	// kein konstanter Ausdruck
    
    	const_cast<int&>(a) = 42;
    	const_cast<int&>(b) = 42;
    
    	std::cout << a << std::endl;			// Ausgabe: 5
    	std::cout << b << std::endl;			// Ausgabe: 42
    }
    

    Ich bin auch nicht der Ansicht, dass nur static const -Member zur Optimierung beitragen können. Oder hab ich dich da völlig falsch verstanden?



  • Abgesehen von Semantik und Sicherheit: const braucht man (wie volkard angetönt hat) auch für konstante Ausdrücke, also Ausdrücke, deren Wert zur Kompilierzeit feststeht. Einige Sprachmittel in C++ erwarten integrale konstante Ausdrücke:

    const int ConstExpr = 3;
    
    // Enumeratoren
    enum Enum
    {
    	Enumerator = ConstExpr
    };
    
    // Bei der Definition initialisierte statische Konstanten
    class Class
    {
    	static const int Value = ConstExpr;
    };
    
    int main()
    {
    	// Template-Argumente
    	std::tr1::array<float, ConstExpr> a;
    
    	// Dimensionen von Arrays
    	int b[ConstExpr];
    
    	// Case-Konstanten
    	int c;
    	switch (c)
    	{
    		case ConstExpr: ;
    	}
    }
    


  • rüdiger schrieb:

    volkard schrieb:

    dort const halte ich für quatsch. ob ich später mal doch a ändern mag, ist mein geheimnis und hat in der schnittstelle nichts zu suchen.

    [...]
    Demnach kann man das Interface ohne const anbieten (da bringt das const ja nicht viel) und in der Implementierung dann const verwenden.

    hauptsache nicht im interface. Aus dem Grund nehme ich z.B. strings auch nur als const& und mache dann bei Bedarf selbst eine Kopie.

    Wer const als Schlüsselwort nicht verwenden will, schreibt es dann hoffentlich als Kommentar dazu. Ansonsten ist das nur nervig in einem großen Projekt, wo man mit viel Fremdcode zu tun hat.



  • OK, ihr habt Recht.
    Sorry.

    @Nexus: du hast mich richtig verstanden. Ich bin nur davon ausgegangen, dass die Compiler da viel konservativer sind. Also dass sie davon ausgehen, dass man auch const_cast auf (lokale) Variablen verwendet, die mit compile-time-konstanten Ausdrücken initialisiert wurden.

    Das von mir angenommen Kriterium "static const" ist also falsch. Vielmehr scheint es darum zu gehen, ob die Variable
    a) const ist und
    b) mit einem compile-time-konstanten Ausdruck initialisiert wird

    (In so einem Fall könnte man natürlich gleich auch static const schreiben, bloss es ist eben nicht - wie ich angenommen hatte - nötig, damit der Compiler "sich traut", mehr zu optimieren, als er sonst machen würde)

    @volkard:

    volkard schrieb:

    int const size=100;
    char a[size];
    

    geht nicht ohne const.
    warum geht das eigentlich mit const? oder hat mich gcc nur zu sehr verwöhnt?

    Wundert mich auch gerade dass das geht. VC9 frisst es aber auch.

    double const PI=3.14;
    foo(PI);
    

    dringende empfehlung an den compiler, foo(3.14) zu schreiben und erlaubnis, keinen speicherplatz für PI anzulegen.

    Das const in diesem speziellen Beispiel ist ziemlich* egal. Keiner zwingt den Compiler, Speicher für irgendwas anzufordern, solange das beobachtbare Verhalten stimmt. Und da zwischen der Definition von PI, und der Verwendung von PI nichts ist, was den Wert ändern könnte, kann der Compiler hier auch ohne const den Wert direkt ersetzen.

    *: "ziemlich" deswegen, weil ein guter Compiler hier auch ohne const "das richtige" macht. Natürlich kann es auch Compiler geben, die es ohne const nicht schnallen.



  • hustbaer schrieb:

    volkard schrieb:

    int const size=100;
    char a[size];
    

    geht nicht ohne const.
    warum geht das eigentlich mit const? oder hat mich gcc nur zu sehr verwöhnt?

    Wundert mich auch gerade dass das geht. VC9 frisst es aber auch.

    das liegt daran, dass in c++ ein 'const int size' einem '#define SIZE' sehr nahe kommt. in C89 geht sowas nicht, wohl aber in C99, wobei du da das 'const' sogar weglassen kannst.
    🙂



  • 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. Const ist wohl das neue Goto, man kann alles machen ohne es, aber es gibt jede Menge Programmierer, die auf Goto/Const schwoeren.



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



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



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



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



  • 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.
    🙂



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


Anmelden zum Antworten