Frage zu Überladung

pumuckl

Damit du das, was hinter dem Pointer "pFolge+x" zu finden ist, auch ändern kannst.

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

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 ?

SeppJ

blurry12345 schrieb:

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?

Dravere

blurry12345 schrieb:

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

asc

Dravere schrieb:

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

eigentlich schon. Ist nur zu übungszwecken.

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

l'abra d'or

http://www.c-plusplus.net/forum/viewtopic-var-t-is-232010.html
Weil es vorgschrieben ist. Punkt.
Ein operator= braucht Zugriff auf private Member, da musst du ihn immer als friend deklarieren, was doch Käse ist...

Dravere

asc schrieb:

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

pumuckl

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.

unskilled

pumuckl schrieb:

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

Nexus

Wenn ihr _SECURE_SCL meint, ist das ein Makro für Checked-Iterators.

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