string-Objekte auf dem Heap

[Verbatim (Gast)]

Guten Tag,

ich setze hier einen MSP430 ein und arbeite mit string-Objekten. Bevor 
das "warum" kommt:

1.) Gibt der Controller/die Anwendung das her
2.) Muss ich wirklich viel mit Dateien und Verzeichnissen arbeiten, da 
ist die string-Klasse eine Erleichterung.

Jetzt das Problem:
------------------

Heap hatte ich auf 512 Bytes eingestellt.

Der Ablauf ist folgender: Ich baue mir aus der aktuellen Uhrzeit/dem 
aktuellen Datum jeweils den aktuellen Pfad zu den Dateien&Verzeichnissen 
zusammen und verwende dafür ein string-Objekt 'pathToFile'. Nach einer 
Weile hängt sich mein Programm auf. Und zwar genau wenn die nachfolgende 
erste Zeile mit dem "if" ins Spiel kommt:

if (pathToFile!= file.getPathToFile()) {
    /* Hier ist alles auskommentiert, theoretisch würde jetzt aber die alte Datei geschlossen und eine neue geöffnet werden. */
}

// Das macht 'getPathToFile'
const string& getPathToFile() const {
  return m_pathToFile;
}

Kommentiere ich diese if-Bedingung aus, dann läuft das Programm, ist der 
Abgleich drinne knallt es nach ein paar Sekunden.

Erhöhe ich jetzt den Heap von 512 auf 768 Bytes, dann scheint die 
Anwendung korrekt zu laufen. Hier verstehe ich den Hintergrund nicht. 
Meine Vermutung war das der Destruktor des strings zwar Heap-Speicher 
freigibt, dieser aber fragmentiert wird und es deswegen igendwann 
knallt.

Dagegen spricht, dass es mit 768 Bytes endlos läuft. Dagegen spricht 
auch, das das Programm nicht abstürzt, wenn die if-Bedingung nicht 
ausgeführt wird, obwohl hier laufend string-Objekte angelegt und 
zerstört werden.

Was kann das sein?

[Karl H. (kbuchegg)]

Verbatim schrieb:

> Meine Vermutung war das der Destruktor des strings zwar Heap-Speicher
> freigibt, dieser aber fragmentiert wird und es deswegen igendwann
> knallt.

Klingt als Hypothese nicht schlecht

> Dagegen spricht, dass es mit 768 Bytes endlos läuft.

Wieso soll das dagegen sprechen?
Wenn immer wieder sich Lücken auftun, die groß genug sind, dann kann das 
ewig so weiter gehen.
Das Problem bei Fragmentierung ist, dass man sehr genau analysieren 
müsste, wann welcher Speicher belegt und wann welcher Speicher frei 
gegeben wird und wann kleinere nebeneinander liegende freie 
Speicherbereiche wieder zu einem größeren zusammengefügt werden.

[Holger S. (holger_s30)]

http://www.cplusplus.com/reference/string/string/compare/

[Verbatim (Gast)]

Aber spricht nicht gegen die Hypothese, dass das Programm nur dann 
abstürzt, wenn diese Zeile enthalten ist:

if (pathToFile!= file.getPathToFile())

? Oder wird hier tatsächlich auch Speicher angefordert, das ist doch ein 
simpler Vergleich?


Gibt es Faustregeln wie groß der Heap sein sollte, oder ist das eine 
Gefühlssache? Ich meine wie kann ich jetzt davon ausgehen, dass es ewig 
mit 768 Bytes korrekt läuft?

[Verbatim (Gast)]

Holger S. schrieb:
> http://www.cplusplus.com/reference/string/string/compare/

Inwiefern hilft das? Ist die interne Implementierung von compare anders 
als der != operator?

[Mark B. (markbrandis)]

Holger S. schrieb:
> http://www.cplusplus.com/reference/string/string/compare/

Eben, seit wann vergleicht man Strings mit == und != ?

Ah so,  mit C++ verwechselt. Wenn == und != korrekt überladen sind, dann 
geht das so.

[Verbatim (Gast)]

Mark Brandis schrieb:
> Holger S. schrieb:
>> http://www.cplusplus.com/reference/string/string/compare/
>
> Eben, seit wann vergleicht man Strings mit == und != ?


Wollt ihr mich auf den Arm nehmen? Erstens ist '==' der gängige Weg und 
zweitens habe ich nachgeschaut wie das bei meiner Bibliothek gemacht 
wird:

inline bool operator==(const string& _Left, const string& _Right)
{       // test for string equality
  return (_Left.compare(_Right) == 0);
}

Oha na sie mal an, ist ja dasselbe. Vielleicht habe ich auch nur die 
Ironie nicht verstanden.

[Holger S. (holger_s30)]

Ruhig Blut. Erstmal solltest du vielleicht überlegen ob dein 
"Dateiansatz" auf einem MSP430 wirklich gebräuchlich ist.

Vielleicht erhälst du bei Einblick in den Assembler-Code einen Wink auf 
das Bottle-Neck.

[Mark B. (markbrandis)]

Was passiert wenn man testweise den String mal nicht auf dem Heap, 
sondern:
-auf dem Stack anlegt (sofern aufgrund des Scopes möglich)?
-als globale Variable (evtl. globales char-Array mit fester Länge) 
anlegt?

[Verbatim (Gast)]

Mark Brandis schrieb:
> Was passiert wenn man testweise den String mal nicht auf dem Heap,
> sondern:
> -auf dem Stack anlegt (sofern aufgrund des Scopes möglich)?
> -als globale Variable (globales char-Array mit fester Länge) anlegt?


Der string sorgt ja intern dafür, dass Speicher angefordert wird, ich 
selber lege den string ja auf dem stack an (also kein new).

Die globale Variable mit char-Array wäre meine Notfalllösung, falls das 
mit den strings zu unvorherseh bist.

Daher meine Frage: Wie bestimmte ich den Heapspeicher für eine 
Anwendung? Gibt es da Richtlinien? Ich habe schon recherchiert, aber der 
einzige Ansatz den ich gefunden habe besteht darin, experimentell 
herauszufinden, wann der Heap & Stack groß genug ist

[Verbatim (Gast)]

Um mich mal selber zu zitieren:

Verbatim schrieb:
> Daher meine Frage: Wie bestimmte ich den Heapspeicher für eine
> Anwendung? Gibt es da Richtlinien? Ich habe schon recherchiert, aber der
> einzige Ansatz den ich gefunden habe besteht darin, experimentell
> herauszufinden, wann der Heap & Stack groß genug ist

Ich habe da soeben von IAR eine sehr gute Präsentation gefunden:

The first question to be answered when considering an application
using dynamic memory is how much heap do I need?

- This is really more of an estimate than a
determination

und

It is difficult to estimate how much heap space you will need
without some sort of tool to help analyze your dynamic
memory needs.

- There exist such tools for desktop Java (HAT, Heap Analysis Tool)

- No such tool as yet for Embedded C/C++

Aus: 
http://www.iar.com/Global/Resources/Seminars/Working_with_the_Stack_and_Heap.pdf


Ist wohl tatsächlich eine Schätzung.

[Andreas B. (andreasb)]

Verbatim schrieb:
> Mark Brandis schrieb:
> Die globale Variable mit char-Array wäre meine Notfalllösung, falls das
> mit den strings zu unvorherseh bist.
>
> Daher meine Frage: Wie bestimmte ich den Heapspeicher für eine
> Anwendung? Gibt es da Richtlinien? Ich habe schon recherchiert, aber der
> einzige Ansatz den ich gefunden habe besteht darin, experimentell
> herauszufinden, wann der Heap & Stack groß genug ist

Wenn deine Applikation genug klein ist kannst du den Speicherverbrauch 
berechnen, also wenn du weisst du hast max. 3 Strings der länge X, Y und 
Z, dann speicher für Daten und Speicher für String Objekt berechnen.
(C++ compiler kann dir ggf. noch mit sizeof(string) etwas weiterhelfen)

Ich würde schätzen bevorzugen;-)

Es gibt aber noch eine andere Möglichkeit, ich weiss aber nicht ob das 
auf deinem µC umsetzbar ist, habe sowas noch nie im Mikrocontroller 
bereich gemacht.

new und delete überladen, bzw schauen ob du dich irgendwie reinhängen 
kannst. Dann kannst du feststellen wie viel Speicher das gebraucht wird, 
und ggf. wie gross die Blöcke sind.

Aber auch da bist du nur dann sicher wenn du immer die gleichen Daten 
zum verarbeiten hast, also wenn z.B. plötzlich doppelt so lange Strings 
von irgendwoher gelesen werden wird natürlich auch meh Speicher 
gebraucht, du müsstest also mit dem worst-case testen.


mfg Andreas

[Markus M. (mark_m)]

Beim Datentype String musst Du aufpassen. Ist ein String einmal 
angelegt, ist dieser nicht mehr änderbar. Jede Änderung erzeugt eine 
Kopie des String auf dem Heap. Da kann der schnell mal überlaufen. Auf 
dem PC ist das, bis auf die Performance, kein Problem. Auf dem 
Controller schon.

Grüsse