int& CFolge::operator[](int x)
	{

		if (x<maxlen && x>=0)
        {
        return *(pFolge+x); 
         }

		return fehler; 

    }

int& CFolge::operator[](unsigned int x)
{
  assert ( x < maxlen );

  return *(pFolge+x);
}

Dann brauchst du auch kein dummy Objekt.

Ich verweise einfach mal auf std::vector, da ich das Gefühl habe, dass du das Rad neu erfindest.

ähnlich wie bei std::vector:

std::vector<int> vi;
/*...*/
vi[13] = 425;

Wenn hier keine Referenz zurückgegeben würde, dann würde stattdessen eine Kopie des Wertes von vi[13] zurückgegeben und der Wert würde durch die Zuweisung nicht geändert.

Sonst wäre also die Zuweisung nicht möglich. Was das assert anbelangt,
dachte ich das wäre nur zum debuggen da und in der Release Version
gar nicht mehr enthalten ?

danke.

Sonst wäre also die Zuweisung nicht möglich. Was das assert anbelangt,
dachte ich das wäre nur zum debuggen da und in der Release Version
gar nicht mehr enthalten ?

Ja. Und? Ist das nicht genau das, was du willst?

Was das assert anbelangt, dachte ich das wäre nur zum debuggen da und in der Release Version gar nicht mehr enthalten ?

Das ist korrekt und womöglich auch erwünscht. std::vector bietet auch zwei unterschiedliche Zugriffe: std::vector::operator[] und std::vector::at .

Über den Operator bekommt man schnellen ungeprüften Zugang. Da ist allerhöchstens eben auch ein assert dahinter. Die Methode at dagegen prüft jedesmal, ob der Index korrekt ist und wenn nicht, wird eine out_of_range Exception geworfen. Doch so eine Überprüfung kostet zusätzliche Zeit, obwohl es zum Teil nicht mal nötig ist.

int arr[] = { 234, 223, 22, 12 };
std::vector<int> vec(arr, arr + 4);

for(int i = 0; i < vec.size(); ++i)
{
  vec[i] *= i;
  // Eine zusätzliche Überprüfung ist unnötig, wir wissen, dass der index
  // immer korrekt sein wird.
}

Grüssli

Über den Operator bekommt man schnellen ungeprüften Zugang. Da ist allerhöchstens eben auch ein assert dahinter.

Sag mir wenn ich falsch liege, aber auch wenn die Methode at bei einem Indexzugriff mit einer Exception reagieren muss, darf dies auch der Indexoperator (Auch wenn ich letzteres in der Praxis noch nicht beobachtet habe).

Noch eine Frage. Warum muss der operator= eine Memberfunktion sein und
kann nicht als friend deklariert werden.

Sag mir wenn ich falsch liege, aber auch wenn die Methode at bei einem Indexzugriff mit einer Exception reagieren muss, darf dies auch der Indexoperator (Auch wenn ich letzteres in der Praxis noch nicht beobachtet habe).

Also der Standard macht diesbezüglich, glaub ich, keine Vorschrift. Also der operator[] dürfte auch eine Exception werfen. Allerding wird zum Beispiel in "Die C++ Programmiersprache" von Bjarne Stroustrup erwähnt, dass at im Gegensatz zu operator[] eine Indexüberprüfung hat. Wodurch eigentlich gefolgert werden könnte, dass operator[] keine Indexüberprüfung hat oder halt vielleicht keine garantierte, wie mans nimmt.

Womöglich hat man es offen gelassen, falls auf einer Plattform standardmässig automatisch Überprüfungen gemacht werden. Keine Ahnung.

Grüssli

IIRC gibts beim MSVC unter bestimmten Umständen (d.h. bestimmte Compilerflags nicht abgeschaltet) noch Überprüfungen, irgendwas mit STL_SECURE_ITERATOR oder son Käse Also der op[] darf alles mögliche machen, solang er bei gültigem Index den richtigen Wert zurückgibt. Der unterschied zwischen at() und op[]() liegt beim Aufruf mit ungültigem Index, und zwar exception vs. undefiniertes Verhalten, was sehr wohl auch eine Exception sein darf - ist eben nicht definiert.

das makro hieß zwar anders, aber imho hat das nur was damit zu tun, dass übergebene ranges und iteratoren gecheckt werden - wird aber nicht im op[] verwendet... da ists imho auch nur ein simples assert()

bb

Aber at() habe ich bisher noch nie wirklich benötigt. Wenn ich Random-Access brauche, stimmt der Index.