Invalid Heap Pointer nach Aufruf von new char[]
-
std::string-Instanzen verwalten ihren Speicher übrigens üblicherweise Referenz-gezählt. Das kann dein char* nicht.
-
camper schrieb:
Das Problem ist, dass der eigentlich interessante (weil mutmaßlich fehlerhafte) Teil des Codes entfernt wurde. Damit ist die gestellte Frage nicht ohne großes Nachfragen beantwortbar. Das macht den ganzen Thread von vornherein uninteressant, jedenfalls ist es ein ist es ein KO-Kriterium, wenn ich mich entscheide, ob ich ich mich an der Diskussion beteilige oder nicht. Es ist auch nicht meine Aufgabe, einen wie-stelle-ich-Fragen-richtig-Link zu platzieren.
Das verstehe ich aber nicht. Der fehlerhafte Teil des Codes ist doch da! Ich habe das Problem doch erläutert. Bei dem ersten Durchlauf wird der Speicher zwar reserviert aber nicht befüllt. Beim nächsten wird strchr auf den nicht befüllten Speicher aufgerufen. Wobei es erst mal ungeklärt ist, warum dann ein Invalid Heap Pointer kommt, aber der Fehler ist im Code zu erkennen.
-
tntnet schrieb:
camper schrieb:
Das Problem ist, dass der eigentlich interessante (weil mutmaßlich fehlerhafte) Teil des Codes entfernt wurde. Damit ist die gestellte Frage nicht ohne großes Nachfragen beantwortbar. Das macht den ganzen Thread von vornherein uninteressant, jedenfalls ist es ein ist es ein KO-Kriterium, wenn ich mich entscheide, ob ich ich mich an der Diskussion beteilige oder nicht. Es ist auch nicht meine Aufgabe, einen wie-stelle-ich-Fragen-richtig-Link zu platzieren.
Das verstehe ich aber nicht. Der fehlerhafte Teil des Codes ist doch da! Ich habe das Problem doch erläutert. Bei dem ersten Durchlauf wird der Speicher zwar reserviert aber nicht befüllt. Beim nächsten wird strchr auf den nicht befüllten Speicher aufgerufen. Wobei es erst mal ungeklärt ist, warum dann ein Invalid Heap Pointer kommt, aber der Fehler ist im Code zu erkennen.
// Stringrekombination, mehrfacher aufruf von strcpy_ssuggeriert, dass da etwas mit dem Speicher angestellt wird. Falls doch nicht... dann ist der Kommentar erst recht fehl am Platz.
-
314159265358979 schrieb:
std::string-Instanzen verwalten ihren Speicher übrigens üblicherweise Referenz-gezählt. Das kann dein char* nicht.
Macht zumindestens die libstdc++. Zb der MSVC nutzt aber stattdessen Short String Optimization, alle Strings kleiner 16 Chars benötigen keine Allocation. Finde ich persönlich besser, der Nutzen von Copy-on-write ist oft eher gering ...
-
314159265358979 schrieb:
std::string-Instanzen verwalten ihren Speicher übrigens üblicherweise Referenz-gezählt. Das kann dein char* nicht.
Die gcc Version macht das so, ich meine aber, dass mindestens MSVC++ ein normales dynamisches array mit short string optimization (oder wie man sowas nennen will) verwendet.
EDIT: zu langsam
Dass man hier so sehr auf std::string pocht wundert mich aber. Ich finde das design von std::string nicht besonders gut. Eine Aufteilung in zwei ineinander konvertierbare Klassen std::string_buffer und std::immutable_string_reference (mit besseren Namen...) wäre meiner Ansicht nach klüger gewesen. substr würde nur dann kopieren, wenn es wirklich nötig ist. Eine immutable_string_reference als Funktionsparameter hätte den Vorteil, dass man ohne zu kopieren einen c string oder ein literal übergeben kann.
Natürlich könnte man sich ins Knie schießen, indem man den buffer einer reference ändert. Aber das sollte in c++ kein Problem sein, schließlich geht man davon aus, dass ein c++ Programmierer weiß, was er tut.
-
GorbGorb schrieb:
Dass man hier so sehr auf std::string pocht wundert mich aber. Ich finde das design von std::string nicht besonders gut.
Das std::string nicht unbedingt das beste Design hat, mag sein. C-Strings haben aber viele Fehlerquellen, die man mit dem std::string umschifft. Wenn man wirklich andere Funktionatlitäten braucht, muss man sich überlegen ob man die Gefahren den std::string-Design vorzieht (Oder die Gefahren zumindest hinter eine Schnittstelle kapselt die nach Möglichkeit die falsche Verwendung verhindert).
-
Wie soll ein String mit < 16 Zeichen keine Allokation benötigen?
-
314159265358979 schrieb:
Wie soll ein String mit < 16 Zeichen keine Allokation benötigen?
Der std::string von msvc++ hat halt intern ein
char buffer[16]. Erst wenn der voll ist wird der heap bemüht.
-
Was für ne Verschwendung oO
-
314159265358979 schrieb:
Was für ne Verschwendung oO
Du verstehst nicht. Das ist kein zusätzliches Array. Stell dir eine Art union vor. Wenn die Stringlänge kleiner ist als die internen Verwaltungsdaten des Strings, dann werden diese Daten wie ein char[] benutzt. Wird der String länger, schaltet er um auf Datenfeld im Heap.
-
Achso, okay. Das ist was anderes. Interessanter Trick.
-
SeppJ schrieb:
314159265358979 schrieb:
Was für ne Verschwendung oO
Du verstehst nicht. Das ist kein zusätzliches Array. Stell dir eine Art union vor. Wenn die Stringlänge kleiner ist als die internen Verwaltungsdaten des Strings, dann werden diese Daten wie ein char[] benutzt. Wird der String länger, schaltet er um auf Datenfeld im Heap.
Interessant. Ich war davon ausgegangen, dass sie mindestens den data_begin und data_end ptr auf jeden Fall auch bei kleinen strings behalten würden, um operator[], begin und end möglichst effizient zu halten. Weißt du was die intern genau machen? (habe den vc++ nicht mehr installiert)
-
GorbGorb schrieb:
Interessant. Ich war davon ausgegangen, dass sie mindestens den data_begin und data_end ptr auf jeden Fall auch bei kleinen strings behalten würden, um operator[], begin und end möglichst effizient zu halten. Weißt du was die intern genau machen? (habe den vc++ nicht mehr installiert)
Wie das nun haargenau ist, weiß ich nicht und ich kann's ebenfalls nicht nachschauen. Gut möglich, dass du Recht hast.
-
Zum Thema standard libraries würde ich noch anmerken, dass die nicht immer besonders effizient geschrieben sind. Mein MinGW mit gcc 4.6 macht zum Beispiel keine small object optimization bei std::function, obwohl sizeof( std::function<...> ) genauso groß ist wie bei boost::function. (das ist finde ich echt ein Ärgernis... die hätten doch einfach die Version von boost übernehmen können)
-
GorbGorb schrieb:
Zum Thema standard libraries würde ich noch anmerken, dass die nicht immer besonders effizient geschrieben sind. Mein MinGW mit gcc 4.6 macht zum Beispiel keine small object optimization bei std::function, obwohl sizeof( std::function<...> ) genauso groß ist wie bei boost::function. (das ist finde ich echt ein Ärgernis... die hätten doch einfach die Version von boost übernehmen können)
Wie sieht diese Optimierung denn aus?
-
TyRoXx schrieb:
Wie sieht diese Optimierung denn aus?
Das ist ziemlich genau das gleiche wie die oben beschriebene small string optimization.
