pop_back()

Stromberg

Das hier:

#include <iostream>
#include <fstream>
#include <string>
#include <vector>
using namespace std;

int main()
{
    vector<int> test;
    test.push_back(10);
    test.push_back(50);
    test.push_back(30);
    test.pop_back(); //Feld [0] wird gelöscht 1 und 2 rücken nach auf 0 und 1
    cout << test[0] << "\n"; //Ausgabe 10! Warum?

	return 0;
}

Müsste doch die Ausgabe "50" erbringen? Bei mir is des aber immer noch "10" , obwohl ichs ja gelöscht habe.
Hab ich n Denkfehler?
MfG
Stromberg

Nanyuki

Stromberg schrieb:

Müsste doch die Ausgabe "50" erbringen? Bei mir is des aber immer noch "10" , obwohl ichs ja gelöscht habe.
Hab ich n Denkfehler?
MfG
Stromberg

Das letzte Element wird gelöscht (also Feld[2]), nicht das erste.

Bashar

Stromberg schrieb:

cout << test[2] << "\n"; //Müsste System Fehler auslösen? Weil ja nur noch 2 Felder da sind?

pop_back löscht, aber operator[] macht nicht unbedingt eine Fehlerprüfung..

Stromberg

Aso, jetzt hab ichs geckeckt, mit letztem ist das oberste gemeint. Dan wundert mich aber warum das hier geht:

#include <iostream>
#include <fstream>
#include <string>
#include <vector>
using namespace std;

int main()
{
    vector<int> test;
    test.push_back(10);
    test.push_back(50);
    test.push_back(30);
    test.pop_back();
    cout << test[2] << "\n"; // Ausgabe 30

	return 0;
}

MfG
Stromberg

Braunstein

pop_back entfernt das letzte Element aus der Liste, gibt aber dessen Speicher nicht frei. D.h. das interne Array ist noch genauso lang. Deswegen funktioniert der Zugriff noch. Das ist aber nicht garantiert.
Das Ganze ist wohl undefined behaviour.

LordJaxom

push_back - hinten draufschieben
pop_back - hinten wegholen

Deshalb die Wortverwandschaft - analog für *_front

In diesem Kontext ist front (vorne) üblicherweise bei 0 angesiedelt und back (hinten) beim letzten Element (size() - 1).

*D*Evil

Versuch mal per at() auf das Element zuzugreifen Das ist mit Fehlermeldung und du solltest eine Exception um die Ohren bekommen

Das ist auch das Problem bei den Vektoren. Aus Performancegründen findet keine automatische Bereichsüberprüfung statt, dafür muss man halt selber sorgen. Wie schon gesagt wurde, mit at() kannst du auch abfragen. Das gibt allerdings nur einen Fehler zur Laufzeit aus. Es ist also IMMER besser vor dem Zugriff eine Bereichsüberprüfung zu machen. Man könnte das in einer Klasse kapseln und bei jedem Zugriff kann man das auch 'cachen'. Bei großen Vektoren ist das sogar sinnvoll.

LordJaxom

vectorizer schrieb:

Das ist auch das Problem bei den Vektoren. Aus Performancegründen findet keine automatische Bereichsüberprüfung statt, dafür muss man halt selber sorgen. Wie schon gesagt wurde, mit at() kannst du auch abfragen. Das gibt allerdings nur einen Fehler zur Laufzeit aus. Es ist also IMMER besser vor dem Zugriff eine Bereichsüberprüfung zu machen. Man könnte das in einer Klasse kapseln und bei jedem Zugriff kann man das auch 'cachen'. Bei großen Vektoren ist das sogar sinnvoll.

1. Wann soll die Prüfung sonst stattfinden, wenn nicht zur Laufzeit?
2. Wie willst Du eine Abfrage (i < size()) bitte cachen?!
3. IMMER eine Bereichsprüfung zu machen ist quatsch, es gibt genug Situationen in denen ich weiß dass mein Index gültig ist (z.B. in einer Schleife von 0 bis size()-1).

BorisDieKlinge

nim iteratoren, wenn du die liste durchlaufen willst

//NEIN
for( int i= 0; i= mylist.size(); i++)
  .....= myList[i];
//JA
for (list<int>::iterator it= mylist.begin(); it != mylist.end(); it++)
  .....= (*it);

P.S: hab den code nich geteste ob fehler drin sind