geht es nur mir so oder könnte der const Qualifier ein paar mehr Features vertragen? Ich fände folgende Sachen sehr nützlich:

// Konstante freie Funktion, kann keine globalen Variablen verändern
void f() const;

struct Test 
{
    // Konstante statische Funktion, kann keine statische Member-Variablen verändern 
    static void f() const;
};

struct Test 
{
    // this_const ist "const" wenn Test objekt als const deklariert, sonst nichts
    int this_const &f() this_const;
};

Vor allem mit dem letzten könnte man sich doch viel doppelten Code sparen, wäre das nicht sinnvoll (mir ist allerdings kein besserer Name als "this_const" eingefallen^^)?

Ist vielleicht eins (oderer mehrere) dieser Features für die Zukunft geplant? Oder gibt es gute Gründe dagegen, weshalb das bis jetzt noch nicht zur Sprache hinzugefügt wurde?

<a href= schrieb:

GCC-Docs">Many functions do not examine any values except their arguments, and have no effects except the return value. Basically this is just slightly more strict class than the pure attribute below, since function is not allowed to read global memory.

Hier fallen statische Member Variablen in dieselbe Kategorie.

Deine dritte Idee sieht nicht sonderlich praktikabel aus. Wenn der Typ der Funktion vom Typ des Arguments abhängt, reden wir doch von Templates, oder nicht?

Ich fände folgende Sachen sehr nützlich:

// Konstante freie Funktion, kann keine globalen Variablen verändern
void f() const;

Ich würde const so nicht überladen wollen. Darf eine const-Member-funktion dann auch keine globalen Variablen mehr ändern? Oder doch? Wie unterscheidet man das? Will man nicht vielleicht beides separat kontrollieren können? Also const für this und was anderes für globale Variablen?

Zu Deiner Frage: Nein, das habe ich bisher nicht vermisst. Das mag daran liegen, dass ich so gut wie keine globalen veränderbaren Variablen benutze.

Ich würde const so nicht überladen wollen. Darf eine const-Member-funktion dann auch keine globalen Variablen mehr ändern? Oder doch? Wie unterscheidet man das? Will man nicht vielleicht beides separat kontrollieren können? Also const für this und was anderes für globale Variablen?

Naja, const bezieht sich ja immer auf das "umgebende" Objekt. Wenn man jetzt eine freie Funktion als member im "globalen Main-Objekt" ansieht würds wieder passen

krümelkacker schrieb:

Zu Deiner Frage: Nein, das habe ich bisher nicht vermisst. Das mag daran liegen, dass ich so gut wie keine globalen veränderbaren Variablen benutze.

Ich auch nicht, hatte das nur der Vollständigkeit halber dabei. Aber bei statischen Variablen fänd ich das schon teilweise gut.

Arcoth schrieb:

Deine dritte Idee sieht nicht sonderlich praktikabel aus. Wenn der Typ der Funktion vom Typ des Arguments abhängt, reden wir doch von Templates, oder nicht?

Ja, also mich nervt das halt vor allem bei Iteratoren. Da implementiert man letztendlich zweimal genau das gleiche Ding, nur dass man einmal überall const hinter die Funktion schreibt...

Oder von mir aus auch als Template:

auto const_it = my_vector.begin<const>();

Wär doch schön

Da implementiert man letztendlich zweimal genau das gleiche Ding, nur dass man einmal überall const hinter die Funktion schreibt...

Das kann man umgehen, indem die nicht-const Funktion die const Funktion mit entsprechenden casts aufruft.

Das kann man umgehen, indem die nicht-const Funktion die const Funktion mit entsprechenden casts aufruft.

Ja, aber deswegen muss man doch trotzdem den ganzen Code duplizieren, einmal für xyz::iterator und xyz::const_iterator ...

Ich fände folgende Sachen sehr nützlich:

Du befürchtest doch nur, daß jemand C++ schneller lernen kann als es verkompliziert wird.

Naja, const bezieht sich ja immer auf das "umgebende" Objekt. Wenn man jetzt eine freie Funktion als member im "globalen Main-Objekt" ansieht würds wieder passen

Das reicht doch nicht. Warum darf eine const Memberfunktion beliebig im globalen Scope rumpfuschen und eine freie Funktion nicht?

Du befürchtest doch nur, daß jemand C++ schneller lernen kann als es verkompliziert wird.

Naja, statische Funktionen const machen zu dürfen wäre jetzt glaub ich nicht der Komplexitäts-Overkill

Bei der globalen Funktion muss ich euch Recht geben, es wäre wohl logisch nicht vertretbar dass konstante Member Funktionen im globalen Scope Dinge ändern dürfen und konstante freie Funktionen nicht.