Operator [] für konstante Objekte

Ich weis nicht was du meinst. Mir geht es nicht um den Proxy an sichm warum der den generekk verwendet das weis, wusst auch bevor ich das gelesen habe. MIr gehts nur um die const-Variante. UNd wie gesagt, ich dachte im Stroustroup wird da auch an dieser Stelle keine Porxyklasse genommen

7H3 N4C3R

Ich habe More Effective C++ gerade nicht zur Hand, von daher kann ich nichts über Meyers Absichten an der Stelle sagen. Das einzige Problem, dass ich aber an dieser Stelle sehe, ist dass man ohne Proxy ein änderbares Handle auf interne Daten rausgibt (die kanonische Form des []-Operators gibt übrigens immer eine (Const-)Referenz zurück).

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.

Pellaeon

Also der const in "meiner Fassung" oben gibt ja keine Referenz zurück, sondern den char by value, also eine Gefahr des Überschreibens besteht nicht. Und sowas

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

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

7H3 N4C3R

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

7H3 N4C3R schrieb:

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

Also gut ich zitiere mal für dich

[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]

--Oh nen kleinen Tippfehler gehabt, hier in der korrigierten Version:

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)*.

Pellaeon

Neeeeeeeeeeeeeeeeeeeein @ lesen, nimms nicht persönlich, aber du solltest lesen lernen^^

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

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.Ü.)

Pellaeon

Lesen schrieb:

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