bisher habe ich, wenn ich den [] überladen habe für die konstante Variante sowas in der Art geschrieben:

char operator[](int) const;

Das ist aus einer Test-Stringklasse(Übung zum Stroustrup-Buch^^)
Für nichtkonstante Objekte muss man natürlich eine Proxyklasse benutzen.

So jetzt zur Frage: ich sitz grad vorm "Mehr Effektiv C++" und der gibt auch bei der konstanten Variante die Proxyklasse zurück(in const-Form)

ausm Buch:

const String::CharProxy String::operator[](int index) const
{
   ...
}

Was ist nun besser???
Ich würde ja zur ersten Variante neigen, weil dort kein Objekt erzeugt wird. Gibt es einen Nachteil der ersten Variante oder warum tut Meyers das was er da tut? ^^

Der Grund im const-Fall nun auch den Proxy zurückzugeben erscheint mir nicht ganz sinnig. Würde nur Sinn machen, wenn der Rückgabe-Wert mehrfach gelesen wird und sich zwischen den Aufrufen durch Nebeneffekte ändern kann (Beispiel: Strings mit Referenz-Zählung - der Proxy hätte dann eine poztenziell längere Lebensdauer als eine Referenz, die stillschweigend ungültig würde). Ich denke, mein Vorredner will dich auf irgendwas stoßen, was Meyers Absichten an der Stelle sind. Wie gesagt, ich habe das Buch leider nicht zur Hand und kann dir also nicht mehr als diesen Hinweis geben.

Edit: deutsche Sprache, schwere Sprache

Edit2: Auch in der STL wird keine Proxy-Klasse genommen - aus guten Gründen. Ein std::string soll sich anfühlen wie ein char-Array. D.h. insbesondere, dass der []-Operator eine char-Referenz zurückgibt (denn er speichert chars) und kein mysteriöses Proxy-Objekt. Allerdings hat man sich ziemlich verkrampft im Standard, um die Lebensdauer dieser Referenz festzulegen. Hängt alles damit zusammen, dass man eine Definition für strings haben wollte, die auch eine referenzgezählte Implementation zulässt.

const String test = "foo";
test[0] = 'm';

bringt bei beiden Varianten einen Compile-Fehler, wies ja auch sein soll.

...bringt bei beiden Varianten einen Compile-Fehler, wies ja auch sein soll.

Wenn das in der nicht-konstanten Variante einen Compile-Fehler bringt, würde ich dir das aber als Programmier-Fehler oder zumindest als äußert unübliches Verhalten "vorwerfen".

Pellaeon schrieb:

...bringt bei beiden Varianten einen Compile-Fehler, wies ja auch sein soll.

Wenn das in der nicht-konstanten Variante einen Compile-Fehler bringt, würde ich dir das aber als Programmier-Fehler oder zumindest als äußert unübliches Verhalten "vorwerfen".

mit beiden Varianten habe ich mich auf die beiden const-Varianten bezogen

[quote="Mehr Effektiv C++]
"Aber halt", sagen Sie, das brauchen wir doch nicht. Wir können operator[] doch anhand des Schlüsselwortes const überladen, und das gibt uns die Möglichkeit, Lesen und Schreiben zu unterscheiden." Mit anderen Worten schlagen Sie folgende Lösung vor:

class String{
public:
  char  operator[] (int index) const; //für Lesen
  char& operator[] (int index);       //für Schreiben
  ...
};

Leider funktioniert das nicht. Compiler wählen zwischen der konstanten und der nichtkonstanten Memberfunktion nur aus, indem sie nachsehen, ob das Objekt, das die Funktion aufruft, const ist oder nicht. Der Kontext, innerhalb dessen der Aufruf erfolgt, wird nicht beachtet*(Anmerkung von mir: Es ging hier um die Unterscheidung zwischen rvalue und lvalue, dies kann man nicht innerhalb von op[] unterscheiden)*.
[/quote]

Also gut ich zitiere mal für dich

Mehr Effektiv C++ schrieb:

"Aber halt", sagen Sie, das brauchen wir doch nicht. Wir können operator[] doch anhand des Schlüsselwortes const überladen, und das gibt uns die Möglichkeit, Lesen und Schreiben zu unterscheiden." Mit anderen Worten schlagen Sie folgende Lösung vor:

class String{
public:
  char  operator[] (int index) const; //für Lesen
  char& operator[] (int index);       //für Schreiben
  ...
};

Leider funktioniert das nicht. Compiler wählen zwischen der konstanten und der nichtkonstanten Memberfunktion nur aus, indem sie nachsehen, ob das Objekt, das die Funktion aufruft, const ist oder nicht. Der Kontext, innerhalb dessen der Aufruf erfolgt, wird nicht beachtet*(Anmerkung von mir: Es ging hier um die Unterscheidung zwischen rvalue und lvalue, dies kann man nicht innerhalb von op[] unterscheiden)*.

Es geht mir nicht um die Proxyklasse allgemein. Warum man die braucht weis ich, wusst ich auch schon bevor ich das im Meyers' gelesen habe
Es geht um diesen konkreten Fall

const String test = "foo";
test[0] = 'm'; //ergibt Fehler

Bei einem nichtkonstanten Objekt, klar da ist der Sinn der Proxyklasse ja logisch, das ist das worauf dein Zitat abzielt.
Aber bei einem konstanten Objket, welches die const-Variante aufruft, ist es halt nicht nötig.
Siehe @7H3 N4C3R Posts im Bezug zur STL
Darum geht es mir

Nun ich denke da kann ich dir helfen, bei meinem Buch steht da noch folgendes:

Mehr Effektiv C++ schrieb:

In den Errata weist Meyers darauf hin, dass die konstante Version von operator[] hier einfach const char& liefern kann. Das ist effektiver. Dann müssen auch einige folgende Methoden leicht modifiziert werden. (A.d.Ü.)

Achso jetzt verstehe ich was du meinst.

Nun ich denke da kann ich dir helfen, bei meinem Buch steht da noch folgendes:

Mehr Effektiv C++ schrieb:

In den Errata weist Meyers darauf hin, dass die konstante Version von operator[] hier einfach const char& liefern kann. Das ist effektiver. Dann müssen auch einige folgende Methoden leicht modifiziert werden. (A.d.Ü.)

T H X
Hab hier ne ältere Buch-Version(aus der Bibliothek), da stand das nicht dazu.
Das wollt ich wissen