dieser code crasht in ptr[ 0 ].push_back( 0.0f ). Allerdings nur im Release mode!

typedef std::vector< float > V;

V s;

V* ptr = NULL;

// 1st "push_back" on ptr

if ( V* tmp = (V*)realloc( ptr, sizeof( V ) ) )
{
    ptr = tmp;

    new ( ptr ) V( s );
}

// 2nd "push_back" on ptr

if ( V* tmp = (V*)realloc( ptr, sizeof( V ) * 2 ) )
{
    ptr = tmp;

    new ( ptr + 1 ) V( s );
}

ptr[ 0 ].push_back( 0.0f );

Ich hab mich schon dran tot debuggt... das zweite realloc scheint das
Problem zu sein. Hab mir also im VS 2008 memory viewer angesehen, ob
das realloc auch wirklich den alten memory block in den neuen kopiert
und ja das tut es. Verstehe also nicht, wieso es einen crash gibt
wenn ich auf das erste Feld im neu allokierten memory block zugreife?

Hat jemand eine Idee?

LG

Ungetestet, aber so ähnlich sollte es gehen

vector<vector<float> > vv;

?!

Was soll das denn? Also:
1.) mit ptr == 0 ist dein realloc das gleiche wie malloc
2.) bei C++ benutzt man new
3.) Speicherallokation von C++ nicht mit der von C wie malloc,realloc oder calloc mischen

1.) mit ptr == 0 ist dein realloc das gleiche wie malloc

Und mit size==0 ist es wie free... Es ist nicht ganz sinnlos, malloc/free nicht mit realloc zu vermischen. I.d.R. wird man in C++ allerdings keins von beiden verwenden wollen.

Es geht nur darum herauszufinden, wieso es crasht.

vector ist nicht trivial kopierbar, also kannst du nicht memcpy und Konsorten (realloc gehört auch dazu) dafür verwenden.

Warum nicht? std::vector enthält doch eigentlich nur...

pointer _Myfirst;
pointer _Mylast;
pointer _Myend;

...und sollte daher doch auch unproblematisch sein, wenn er während
eines reallocs kopiert wird?

Es geht nur darum herauszufinden, wieso es crasht.

Weil das Kopieren von nicht-POD-Typen mit memcpy und Konsorten schlicht und ergreifend undefiniert ist. Da nützt es nichts, zu diskutieren, warum denn oder dass es ja eigentlich egal sein sollte, es ist so. Sowas macht man nicht. Punkt.

camper schrieb:

vector ist nicht trivial kopierbar

Warum nicht? std::vector enthält doch eigentlich nur...

TriviallyCopyable

Mich interessiert trotzdem, was genau in diesem hier genannten Fall auf Speicherebene passiert bzw. schief läuft. Das ist auch der Grund,
warum ich so ein absolut minimalistisches Beispiel gepostet habe.

Ich hatte die Hoffung, dass jemand genau erklären kann, wieso das reine
Kopieren hier in diesem Fall nicht ausreicht. Warum genau crasht es,
was fehlt oder wurde nicht korrekt initialisiert oder zeigt auf irgendwas
ungültiges?

Ein mögliches Absturzszenario welches ich mir vorstellen könnte, wäre ein vector mit Optimierung für kleine Felder, der einen Teil seiner internen Verwaltungsdaten als Speicher benutzt und den Heap erst dann anpackt, wenn die Datenmenge zu groß wird. Hier wurde dann der Zeiger auf die Daten nach dem realloc auf die eventuell schon freigegebenen alten Daten zeigen.

Danke schon mal für die Vermutungen!

Es kann beispielsweise das Alignment nicht stimmen.

Das kann nicht passieren.

Um das herauszufinden, musst du dir die Implementation vom Vektor im MSVC genau anschauen.