try {
                            Lines.back().reset(temp); // Hier stürzt es ab.
                        }
                        catch(std::bad_alloc) {
                            MessageBox(0, "std::bad_alloc", "", 0); // Wird nie ausgeführt.
                        }

std::vector<boost::shared_array<char> > Lines;

char* temp = new char[ZeichenAnzahl + 1];

Wie kann die boost::shared_array<T>::reset() Funktion abstürzen, wenn nich durch eine exception?!?

mfg.

naja du fängst ja nicht jede exception nur bad_alloc, es gibt ja noch mehr

Auf der boost seite stand, dass dies die einzige exception ist. Und

catch(...)

hab ich auch schon probiert, hat aber auch nichts aufgefangen

mfg.

was ist mit Lines? ist das evtl. leer? reset könnte nur eine exceptions werfen wenn der destruktor der elemente wirft, das trifft hier auf keinen fall zu. std::bad_alloc könnte beim new geworfen werden, das sich nicht im gezeigten try block befindet...

Also lines ist nicht leer, ich kann mir sogar den Inhalt vorher mit Lines.back().get() anzeigen lassen.
Also ich bin mir zeimlich sicher, dass der Fehler bei dieser Zeile auftritt, weil ich davor eine und dahinter eine MessageBox ausgebe.
Das Problem tritt auf, wenn die stelle schon mehrmals durchgelaufen ist. Könnte es sein das shard_array eine Begrenzung hat?

mfg.

std::vector<std::string>

ich hab schon meinen grund warum ich ein array von chars nehme und nicht einen string.
Aber du hast schon recht, wenn alles nicht mehr funktioniert, werde ich versuchen es auf std::string umzuschreiben.

Funktioniert std::string::c_str() eigentlich immer? Weil dazu müssten die Daten ja alle hintereinander im Speicher legen.

mfg.

ch hab schon meinen grund warum ich ein array von chars nehme und nicht einen string.

Weil du ein Frickler bist?

ch hab schon meinen grund warum ich ein array von chars nehme und nicht einen string.

Weil du ein Frickler bist?

nein

Funktioniert std::string::c_str() eigentlich immer? Weil dazu müssten die Daten ja alle hintereinander im Speicher legen.

Ja, tut sie - und der Inhalt des string's steht hintereinander im Speicher.

@joomoo:
nur mal so als Anmerkung: boost::shared_array gibt dir eine performancegarantie, die du mit std::string nur implementationsspezifisch bekommst.

Was für einen Fehler bekommst du denn? Notfalls mal debugger anwerfen - estartu hat ein schönes tutorial geschrieben...

Gar keine, das Programm stürzt einfach ab. Die einzige rückmeldung ist der return wert von int main 1.

Was kann ich mit dem Debugger herrausfinden? Ich dachte da kann man das Programm anbestimmten stellen anhalten? Aber ich weiß schon, dass es an dieser Zeile liegt.

mfg.

Aber bei STL-Containern ist das schon recht schwierig...

Ich denke nicht, daß de Fehler an dieser Stelle liegt.

catch fängt nur C++ exceptions, zumindest soll es nur das. Harte Fehler (z.B. Schutzverletzung) fängst du damit nicht (VC6 hat das mal gemacht, das war aber nicht so geplant..).

Verwendest du einen debug build? Welche Entwicklungsumgebung? (Davon hängt halt ab, wie bestimmte Fehler aussehen)

vor dem Aufruf einfach mal lines durchgehen und auf die console rausgeben, ebenso temp.
wenn das geht, sollte auch deine Zeile gehen

P.S. daa @joomoo sollte eigentlich ein "@window" werden

Wie kann die boost::shared_array<T>::reset() Funktion abstürzen, wenn nich durch eine exception?!?

Wenn es vorher schon auf was zeigte, dann wird das ja freigegeben. Wenn das aber schon freigegeben wurde, dann schmiert er an der Stelle ab. Zeig doch mal, wie Du die Daten erstellst und in den vector reinfüllst. Vielleicht hast Du da irgendwo ne Temporäre Variable gebaut, die das Ding unabsichtlich freigibt.

joomoo schrieb:

Funktioniert std::string::c_str() eigentlich immer? Weil dazu müssten die Daten ja alle hintereinander im Speicher legen.

Ja, tut sie - und der Inhalt des string's steht hintereinander im Speicher.

Im Ergebnis von c_str() stehen die Zeichen (logischerweise) direkt hintereinander. Aber c_str() darf konvertieren, die interne std::string-Darstellung muss also nicht der C-String-Darstellung entsprechen. Insbesondere muss die interne std::string-Darstellung weder nullterminiert noch zusammenhängend sein (z.B. [1]).
Würde die interne Darstellung auf reine Nullterminierung bauen, könnte std::string gar keine Nullzeichen enthalten.