Speichernutzungsverhalten von STL-Vector und Konsorten

[Daniel der Gast]

Destruktoren schreibe ich immer, selbst wenn sie leer sind. Mit denen hatte ich schon zu viel Ärger.

[Braunstein]

theta schrieb:

Für Windows gibts den Application Verifier.

Sofern man MS Visual Studio verwendet.

[The-Kenny]

Braunstein schrieb:

theta schrieb:

Für Windows gibts den Application Verifier.

Sofern man MS Visual Studio verwendet.

Die Alternative dazu wäre doch wohl MinGW, und für den gibts afaik auch valgrind.

[Braunstein]

The-Kenny schrieb:

Die Alternative dazu wäre doch wohl MinGW, und für den gibts afaik auch valgrind.

Aber nicht für Windows. Es gibt eine unter wine lauffähige Variante aber das wars auch schon.

[theta]

Braunstein schrieb:

theta schrieb:

Für Windows gibts den Application Verifier.

Sofern man MS Visual Studio verwendet.

Muss nicht sein, kann auch separat gestartet werden.
Simon

[asc]

Daniel der Gast schrieb:

...aber das wars scheinbar nicht (leider).

Das memcpy nicht unbedingt für Objekte geeignet ist, hast du aber auch verstanden? Und dabei ist es egal ob du auf C-Arrays oder std::vector setzt.

[Daniel der Gast]

Memcpy verwende ich nicht. Alles was void* returned ist eh potenziell pfui ^^

Ich _glaube_ übrigens ich hab den bug exterminiert, kann aber nicht mit Sicherheit sagen, was genau es war. Habe ein größeres refactoring der Methode gemacht, die den Fehler scheinbar verursacht hat, jetzt läufts (wohl).

[Daniel der Gast]

Übrigens bin ich nicht identisch mit dgrat (nur um Verwirrung vorzubeugen)

[dgrat]

asc schrieb:

dgrat schrieb:

das hat mich auch nicht sonderlich verwundert, da ich generell von std::vector nicht viel halte.

Wundert mich nicht, wenn jemand gegen die Implementierung statt gegen die Schnittstelle programmiert.

zynismus ist die sprache schwacher geister.. vermutlich weiste selbser bicht, warum der fehler auftritt.

aber volkard hat wieder recht, in meinem fall bewirkt vector<vector> eine speicherfragmentierung, weil die daten, die wichtig behandelt werden, leider nicht hintereinanderliegen...

[Nexus]

dgrat schrieb:

zynismus ist die sprache schwacher geister..

Naja, es ist ein wenig einfach, dem vector mal grundsätzlich die Schuld in die Schuhe zu schieben, weil man persönliche (wahrscheinlich noch unbegründete) Abneigungen besitzt.

dgrat schrieb:

aber volkard hat wieder recht, in meinem fall bewirkt vector<vector> eine speicherfragmentierung, weil die daten, die wichtig behandelt werden, leider nicht hintereinanderliegen...

Dann benutzt du eben nicht memcpy() . Sobald nämlich mehr als nur PODs vorliegen, erzielst du damit undefiniertes Verhalten.

Und dass ein verschachtelter std::vector nicht alle Elemente linear hintereinander im Speicher halten kann, dürfte zu erwarten sein. Entweder man kopiert die inneren Container einzeln oder benutzt einen anderen Aufbau der Datenstruktur (eindimensionaler std::vector ).

[asc]

dgrat schrieb:

vermutlich weiste selbser bicht, warum der fehler auftritt.

Mein Persönlicher Verdacht wurde bereits im 2ten Post geäußert, zudem habe ich schon selbst genügend Fehler in Programmen gebaut um auch das Verhalten durchaus zu kennen. Die Ablehnung wiederum vom std::vector, und das zurückgreifen wollen auf eine selbstgebaute Lösung die auf das gleiche hinausläuft ist mehr als Schwachsinn.

Die Macher der Standardbibliothek haben sich schon gute Gedanken gemacht (Und ich behaupte mal das man die Standardbibliothek, gerade bei aktuellen Compilern weitgehend Fehlerfrei bezeichnen kann - vermutlich besser getestet als du es jemals in eigenen Programmteilen hinbekommen wirst).

Es gibt sicherlich auch Punkte die man daran aussetzen kann, aber das was du mit memcpy betreibst funktioniert auch mit C-Arrays nicht (Zumindestens nicht mit vielen Objekttypen).

Und das du mein Abgewandeltes Zitat nicht kennst und darauf auf einen "schwachen Geist" schließt, zeigt mir nur das du nicht wirklich viele Fachbücher kennst, die sich auch mit OO und C++ auseinander setzen ("Programmiere gegen die Schnittstelle, und nicht gegen die Implementierung" ist nicht ohne Grund einer der häufigsten Zitate die ich aus Fachbüchern kenne).

cu André