std::vector<int>* vec = new vector<int>();
vec->push_back(42);
int i = vec[0]; // geht nicht
delete vec;

(wenn du unbedingt mit dem Zeiger arbeiten willst, mußt du ihn auch dereferenzieren, um die vector<>-Methoden nutzen zu können)

Warum machst du dir überhaupt die Mühe, den vector<> auf dem Heap anzulegen? Es reicht völlig, ihn als normale Variable anzulegen.

Weil es dem Fall alles verkomplizieren würde wenn ich ihn als Membervariable anlege.

CStoll schrieb:

(wenn du unbedingt mit dem Zeiger arbeiten willst, mußt du ihn auch dereferenzieren, um die vector<>-Methoden nutzen zu können)

Wie würde das denn aussehen? Weder

int i = &vec[0];

noch

int i = *vec[0];

funktioniert. Ich vermute mal der []-Operator geht in dem Fall nicht und ich muss die at-Methode verwenden?

Wieso ist die einzige Alternative zum Heap ne Membervariable? Wieso nicht scopelokal aufm Stack?

CStoll schrieb:

Warum machst du dir überhaupt die Mühe, den vector<> auf dem Heap anzulegen? Es reicht völlig, ihn als normale Variable anzulegen.

Weil es dem Fall alles verkomplizieren würde wenn ich ihn als Membervariable anlege.

Ich fürchte, du verkomplizierst hier wesentlich mehr, indem du den vector per new anlegst. Wir sind hier nicht bei Java oder C#, wo sowas üblich ist - in C++ ist die Speicheranforerung per new eher die Ausnahme als die Regel.
Was willst du eigentlich mit dieser Konstruktion bezwecken? Und wie lange soll der vector<> überhaupt überleben bzw. verwendet werden?

PS: Ich habe übrigens nicht von einer Membervariable gesprochen.

Weil es dem Fall alles verkomplizieren würde wenn ich ihn als Membervariable anlege.

Erklär uns doch einfach mal den 'Fall'.

std::vector<int>* vec = new vector<int>();
vec->push_back(42);
int i = vec[0]; // geht nicht
delete vec;

Ich gehe mal davon aus, dass das ein sehr künstliches Beispiel ist. Aus was für einem Grund auch immer (möglicherweise kein guter!) verwendest Du einen Zeiger auf einen Vektor; denn ein

T* ptr = new T(...);
...
delete ptr;

ist in 99% der Fälle einfach eine schlechte Version von

T obj (...);
...

und in den restlichen 1% (dann wenn T "zu groß" für den automatischen Speicher ist) hätte es

const auto_ptr<T> ptr (new T(...));
...

heißen müssen (bzw unique_ptr in der neuen C++ Version).

Spongebob schrieb:

CStoll schrieb:

(wenn du unbedingt mit dem Zeiger arbeiten willst, mußt du ihn auch dereferenzieren, um die vector<>-Methoden nutzen zu können)

Wie würde das denn aussehen? Weder

int i = &vec[0];

noch

int i = *vec[0];

funktioniert. Ich vermute mal der []-Operator geht in dem Fall nicht und ich muss die at-Methode verwenden?

Wenn Du C++ wie ein Ratespiel behandelst, wirst Du damit nicht weit kommen! Stichwort: Operatorpräzedenzen. Siehe Dobi's Antwort. Postifix-Operatoren binden immer stärker als Präfixoperatoren. *vec[0] ist also äquivalent zu *(vec[0]).

Wie sieht es denn mit dem Gültigkeitsbereich des Vektors aus?
Könnte das nicht ein Argument sein, was dafür spricht, ihn auf dem Heap anzulegen?

Bedingt, z.B. kann man Vektoren mit C++11-Movesemantik auch günstig von Funktionen zurückgeben.

Allerdings ist der Gültigkeitsbereich so oder so kein Argument dafür, den Speicher auch manuell zu verwalten. RAII und konkret Smart-Pointers helfen wieder mal. Wobei ich mich nicht erinnern mag, letztes Mal einen Container in einem Smart-Pointer gesteckt zu haben, wahrscheinlich wird es auch hier nicht benötigt.