C++ Mc gcc Object löschen

>Anders geht es nicht, auch wenn du vermutlich was anderes hören
>wolltest.

Gibt's da keine Problem mit der Garbage Collection?
Gibt es ein Delete auf einem STM32?

chris schrieb:
> Gibt's da keine Problem mit der Garbage Collection?

Welche Implementation benutzt du, welche Garbage Collection bietet? 
Keine mir bekannte C++ Implementation für Mikrocontroller macht das.

chris schrieb:
> Gibt es ein Delete auf einem STM32

Wenn es new gibt, ja. Ob das ganze sinnvoll ist ist eine andere Frage.

> Welche Implementation benutzt du, welche Garbage Collection bietet?
Weiß ich nicht.
Hier der nicht funktionierende Versuch auf einem ESP32:

1

class Test

2

{

3

  public:

4

    int id;

5

    Test(int identifier)

6

    {

7

      id=identifier;

8

    }

9

10

    void show()

11

    {

12

      Serial.print("Test ID: ");

13

      Serial.println(id);

14

    }

15

};

16

17

std::vector<Test> Tests;

18

19

void setup()

20

{

21

  Serial.begin(115200);

22

23

}

24

25

#define ANZAHL 4

26

27

void loop()

28

{

29

  for(int n=0;n<ANZAHL;n++)

30

  {

31

    Test t=new Test(n);

32

    Tests.push_back(t);

33

  }

34

35

  // hier alle löschen ....

36

37

  delay(3000);

38

}

Und dann gehst du halt hin und machst eine schleife in der du durch den 
Vector iterierst, delete auf die objekte aufrufst und danch clearst du 
den vector.

chris schrieb:
> Hier der nicht funktionierende Versuch auf einem ESP32

Was bedeutet nicht funktionierend?

M.K. B. schrieb:
> oder dies erst mit einer Garbage Collection erfolgt ist

C/C++ haben keine Garbage Collection.

leo

M.K. B. schrieb:
> sondern kann dies auch erst bei einer
> Garbagecollection tun.

Was verstehst du hier nicht: C/C++ haben keine Garbage Collection.

leo

leo schrieb:
> M.K. B. schrieb:
>> sondern kann dies auch erst bei einer
>> Garbagecollection tun.
>
> Was verstehst du hier nicht: C/C++ haben keine Garbage Collection.
>
> leo

Aber C und C++ könnten einen GC in der Implementation von malloc nutzen 
und das ist es was M.K. B. geschrieben hat.

mh schrieb:
> Aber C und C++ könnten einen GC in der Implementation von malloc nutzen

Aha. Beispiel bitte.

leo

leo schrieb:
> Aha. Beispiel bitte.

Ich mache es nochmal deutlicher: KÖNNTE

mh schrieb:
> leo schrieb:
>> Aha. Beispiel bitte.
>
> Ich mache es nochmal deutlicher: KÖNNTE

Nein.
[ ] Du weisst, wie ein GC funktioniert?

leo

M.K. B. schrieb:
> GC bei der Speicherverwaltung durch den Heap.

Gibt es nicht.

leo

M.K. B. schrieb:
> GC bei der Speicherverwaltung durch den Heap.

Welches OS macht denn sowas? Eine MMU kann Speicherseiten ein- bzw. 
ausblenden. Dass ist aber kein GC.

leo schrieb:
> Aha. Beispiel bitte.

https://www.hboehm.info/gc/

Der C++ Standard erlaubt definitiv ein "normales"  GC in der Sprache, 
ähnlich wie Java. Das benutzt nur keiner. Daher der verbreitete 
Irrglaube, C++ würde prinzipiell kein GC unterstützen.

chris schrieb:
> Hier der nicht funktionierende Versuch auf einem ESP32:

Das ist vorne und hinten falsch. Lies erstmal ein C++ Buch. C++ ist eine 
komplexe Sprache, die lernt man nicht mal eben mit ein paar Tutorials. 
Und überlege, ob du wirklich dynamische Speicherverwaltung brauchst. Die 
macht nämlich nur Sinn, wenn man Speicher zu verschiedenen Zeitpunkten 
unterschiedlich nutzen will, also z.B. mal 100 Test Objekte anlegen, 
dann wieder freigeben, dann 100 Test2 Objekte. Wenn eine solche 
abwechselnde Nutzung nicht gegeben ist, wird nach der Freigabe der 
Speicher gar nicht benutzt, wofür es kein Geld zurück gibt. Daher ist es 
oft besser, einfach fixe Arrays (keine Vektoren) der benötigten Größe 
anzulegen und nie was freizugeben.

>Die macht nämlich nur Sinn, wenn man Speicher zu
> verschiedenen Zeitpunkten unterschiedlich nutzen will,
> also z.B. mal 100 Test Objekte anlegen,
>dann wieder freigeben, dann 100 Test2 Objekte.

Das Programm soll folgendes tun:
1. es werden N-Testobjekte angelegt ( z.B. N=100 )
2. Die Testobjekte werden ein Zeit lang benutzt und eine Test.execute() 
Methode aufgerufen.
3. Der Speicher, den die Testobjekte belegen, muss wieder frei gegeben 
werden.
4. Goto 1.

Ich vermute, dass im Framework des ESP32 keine Garbage Collection 
implementiert ist. In C wäre das Ganze extrem einfach zu lösen.

1. man reserviert Speicher für die Objekte und merkt sich den Speicher 
Anfang
2. man legt Objekte an ( Strukturen )
3. wie oben ( 1-3)
4. Man setzt den Objektpointer zurück
5. Goto 1.

Aufwand, die Objekte zu löschen: Null

chris schrieb:
> 3. Der Speicher, den die Testobjekte belegen, muss wieder frei gegeben
> werden.

Warum muss? Wofür wird der Speicher danach gebraucht?

chris schrieb:
> 4. Man setzt den Objektpointer zurück
>
> Aufwand, die Objekte zu löschen: Null

Haha, weil du sie gar nicht löschst! Wenn du nur den Pointer auf Null 
setzt, ist der Speicher noch belegt, und du kannst ihn nie wieder 
freigeben - ein Speicherleck. Wenn du den Speicher tatsächlich 
freigibst, über die free() Funktion, ist der Aufwand natürlich nicht 
null, denn die Funktion kann ggf. nicht trivial sein.

chris schrieb:
> In C wäre das Ganze extrem einfach zu lösen.

In C++ sogar noch einfacher dank unique_ptr. Allerdings muss man dazu 
schon ein bisschen wissen was man tut und nicht einfach irgendwas 
zusammen stoppen.

Bevor man anfängt drauf los zu coden, sollte man sich erst mal 
überlegen:
- Haben alle Objekte den gleichen Typ, oder sollen auch abgeleitete 
Typen möglich sein (Polymorphie)? Sollen sogar komplett unterschiedliche 
Typen ohne gemeinsame Basisklasse möglich sein?
- Wird die Größe des Containers initial festgelegt, oder sollen Elemente 
einzeln hinzugefügt und einzeln gelöscht werden können? Wenn ja, wie 
oft? Wenn nein, steht die Größe beim Kompilieren schon fest oder erst 
zur Laufzeit?
- Wenn die Elemente gelöscht wurden, wofür wird der Speicher dann 
gebraucht? Nur wieder für das erneute Befüllen des selben Containers?
- Soll der Container nur von Anfang bis Ende durchgegangen werden, oder 
auch wahlfreier Zugriff per Index möglich sein?
- Soll eine Assoziation/Mapping erfolgen, d.h. Elemente z.B. anhand 
eines Namens o.ä. suchen, und nicht nur nach Index?
- Spielt die Reihenfolge eine Rolle?
- Müssen die Elemente alle direkt im Speicher hintereinander stehen 
(z.B. für DMA) oder können sie verteilt sein?
- Sind die Elemente simple Datenobjekte oder haben sie virtuelle 
Funktionen?

Siehe auch: https://stackoverflow.com/q/471432

Rolf Magnus
>Muss dafür wirklich jedes dieser Objekte einzeln dynamisch angelegt
>werden? Woraus besteht so ein Objekt? Wäre es ein Problem, wenn das
>Objekt kopiert werden müsste? Wird Polymorphie benötigt?

Die Testobjekte sind von einem gemeinsamen Objekt abgeleitet, aber ihr 
Speicherverbrauch ist unterschiedlich groß.

>> 2. Die Testobjekte werden ein Zeit lang benutzt und eine Test.execute()
>> Methode aufgerufen.
>> 3. Der Speicher, den die Testobjekte belegen, muss wieder frei gegeben
>> werden.

>Muss jedes Objekt einzeln wieder freigegeben werden, oder reicht es,
>wenn nach den 100 Tests alle am Stück gelöscht werden?

Die gesamte Testliste wird durch eine neue mit einer anderen Anzahl von 
Objekte ersetzt. Die alten werden nicht mehr gebraucht, die ganze Liste 
kann also in einem Stück gelöscht werden.

chris schrieb:
> aber ihr
> Speicherverbrauch ist unterschiedlich groß.

chris schrieb:
> In C wäre das Ganze extrem einfach zu lösen.

Jetzt bin ich gespannt, wie das "extrem einfach" in C geht. Viele 
unterschiedliche structs mit malloc() anlegen, Pointer darauf in ein 
Array, und danach alle structs und das Array mit free() freigeben? Dann 
stimmt aber

chris schrieb:
> Aufwand, die Objekte zu löschen: Null

nicht.

Um das jetzt mal etwas abzukürzen, hier ein komplettes Beispiel mit 
einer Basis-Klasse "Test" und 2 davon abgeleiteten, welche in einem 
vector abgelegt werden:

1

#include <iostream>

2

#include <memory>

3

#include <vector>

4

5

class Test {

6

  public:

7

    virtual ~Test() {}

8

    virtual void show () = 0;

9

};

10

11

class Test1 : public Test {

12

  public:

13

    Test1 (int i) : id (i) {}

14

    virtual void show () { std::cout << id << std::endl; }

15

  private:

16

    int id;

17

};

18

19

class Test2 : public Test {

20

  public:

21

    Test2 (float f) : id (f) {}

22

    virtual void show () { std::cout << id << std::endl; }

23

  private:

24

    float id;

25

};

26

27

28

constexpr std::size_t ANZAHL = 4;

29

30

31

int main () {

32

  std::vector<std::unique_ptr<Test>> Tests;

33

  // Speicher für alle Zeiger auf einmal anlegen

34

  Tests.reserve (ANZAHL);

35

36

  // Objekte einfügen

37

  for (std::size_t i = 0; i < ANZAHL/2; ++i)

38

    Tests.push_back(std::make_unique<Test1> (i));

39

40

  for (std::size_t i = ANZAHL/2; i < ANZAHL; ++i)

41

    Tests.push_back(std::make_unique<Test2> (i+0.3f));

42

43

  // Ausgeben

44

  for (auto& t : Tests)

45

    t->show ();

46

47

  // Alle löschen

48

  Tests.clear ();

49

50

  // Eins einfügen

51

  Tests.push_back (std::make_unique<Test1> (42));

52

53

  // Ausgeben (diesmal leer)

54

  for (auto& t : Tests)

55

    t->show ();

56

57

  // Bei Rückkehr der Funktion wird "Tests" und alle Inhalte automatisch gelöscht

58

}

vector und unique_ptr sorgen dafür dass alles gelöscht wird.

PS: Für Konstanten sollte man "constexpr" und kein "#define" nutzen. In 
C++ gibt es kaum einen Grund für #define, und #define kann diverse 
Probleme machen.

Dr. Sommer schrieb:
> leo schrieb:
>> Aha. Beispiel bitte.
>
> https://www.hboehm.info/gc/

Was genau hat eine externe Bibliothek mit den GC-Eigenschaften der 
Sprache zu tun?

leo

leo schrieb:
> Was genau hat eine externe Bibliothek mit den GC-Eigenschaften der
> Sprache zu tun?

Ist nur ein Beispiel. Der Standard vermerkt an verschiedenen Stellen 
etwas zur Garbage Collection, er ist praktisch aufwärtskompatibel, denn 
es ist nicht vollständig spezifiziert. Es wird aber in der Praxis nicht 
genutzt. Ist auch egal, denn der GCC für ESP kann das bestimmt nicht.

Dr.Sommer
>Um das jetzt mal etwas abzukürzen, hier ein komplettes Beispiel

Danke für's konkret werden. Das nenne ich vorbildlich.

Hier das ganze getestet für's Arduino Framework des ESP32:

1

#include <iostream>

2

#include <memory>

3

#include <vector>

4

5

class Test {

6

  public:

7

    virtual ~Test() {}

8

    virtual void show () = 0;

9

};

10

11

class Test1 : public Test {

12

  public:

13

    Test1 (int i) : id (i) {}

14

    virtual void show () { Serial.print("test1 int:");Serial.println(id); }

15

  private:

16

    int id;

17

};

18

19

class Test2 : public Test {

20

  public:

21

    Test2 (float f) : id (f) {}

22

    virtual void show () { Serial.print("test2 float:");Serial.println(id); }

23

  private:

24

    float id;

25

};

26

27

28

constexpr std::size_t ANZAHL = 4;

29

30

//make_unique is an upcoming C++14 feature and thus might not be available on your compiler,

31

//even if it is C++11 compliant.

32

//https://stackoverflow.com/questions/24609271/errormake-unique-is-not-a-member-of-std

33

template<typename T, typename... Args>

34

std::unique_ptr<T> make_unique(Args&&... args) {

35

    return std::unique_ptr<T>(new T(std::forward<Args>(args)...));

36

}

37

38

39

void setup()

40

{

41

  Serial.begin(115200);

42

}

43

44

void loop()

45

{

46

  std::vector<std::unique_ptr<Test>> Tests;

47

  // Speicher für alle Zeiger auf einmal anlegen

48

  Tests.reserve (ANZAHL);

49

50

  // Objekte einfügen

51

  for (std::size_t i = 0; i < ANZAHL/2; ++i)

52

    Tests.push_back(make_unique<Test1> (i));

53

54

  for (std::size_t i = ANZAHL/2; i < ANZAHL; ++i)

55

    Tests.push_back(make_unique<Test2> (i+0.3f));

56

57

  Serial.print("FreeHeap mit Objekten:");

58

  Serial.println(ESP.getFreeHeap());  

59

  // Ausgeben

60

  for (auto& t : Tests)

61

    t->show ();

62

63

  // Alle löschen

64

  Tests.clear ();

65

66

  Serial.print("FreeHeap Objekte gelöscht:");

67

  Serial.println(ESP.getFreeHeap());  

68

69

  // Eins einfügen

70

  Tests.push_back (make_unique<Test1> (42));

71

72

  // Ausgeben (diesmal leer)

73

  for (auto& t : Tests)

74

    t->show ();

75

76

  delay(3000);

77

}

Jetzt bin ich mal gespannt, wie sich das ganze laufzeitmässig mit C 
schlägt.
Die Test sollen nämlich im Mikrosekundenbereich und so schnell wie 
möglich laufen ( keine prints )

chris schrieb:
> //make_unique is an upcoming C++14 feature

"Upcoming"...

chris schrieb:
> Jetzt bin ich mal gespannt, wie sich das ganze laufzeitmässig mit C
> schlägt.

Vermutlich etwas langsamer.

chris schrieb:
> Die Test sollen nämlich im Mikrosekundenbereich und so schnell wie
> möglich laufen ( keine prints )

Du bist lustig! new/malloc und delete/free sind natürlich eher langsam. 
Für  Echtzeit ist das natürlich vollkommen ungeeignet. Was machst du 
wenn kein Speicher mehr da ist? Einfach abstürzen lassen?

Dr.Sommer
>Du bist lustig! new/malloc und delete/free sind natürlich eher langsam.
>Für  Echtzeit ist das natürlich vollkommen ungeeignet.

Es geht natürlich um die noch zu erschaffende "execute" Methode der 
Testklassen und nicht die Instantiierung der Objekte.

chris schrieb:
> Es geht natürlich um die noch zu erschaffende "execute" Methode der
> Testklassen und nicht die Instantiierung der Objekte.

Dann ist die Laufzeit des bisher diskutierten Codes also irrelevant und 
somit C vs. C++ auch nicht von Bedeutung?

Um mal konkret zu werden ;-)

1

#include <iostream>

2

#include <memory>

3

#include <vector>

4

5

class Test {

6

  public:

7

    virtual ~Test() {}

8

    virtual void show () = 0;

9

    virtual void execute () = 0;

10

};

11

12

class Test1 : public Test {

13

  public:

14

    Test1 (int i) : id (i) {}

15

    virtual void show () { Serial.print("test1 int:");Serial.println(id); }

16

    virtual void execute () { id++; }

17

  private:

18

    int id;

19

};

20

21

class Test2 : public Test {

22

  public:

23

    Test2 (float f) : id (f) {}

24

    virtual void show () { Serial.print("test2 float:");Serial.println(id); }

25

    virtual void execute () { id*=3; }

26

  private:

27

    float id;

28

};

29

30

31

constexpr std::size_t ANZAHL = 4;

32

33

//make_unique is an upcoming C++14 feature and thus might not be available on your compiler,

34

//even if it is C++11 compliant.

35

//https://stackoverflow.com/questions/24609271/errormake-unique-is-not-a-member-of-std

36

template<typename T, typename... Args>

37

std::unique_ptr<T> make_unique(Args&&... args) {

38

    return std::unique_ptr<T>(new T(std::forward<Args>(args)...));

39

}

40

41

42

void setup()

43

{

44

  Serial.begin(115200);

45

}

46

47

48

49

void loop()

50

{

51

  std::vector<std::unique_ptr<Test>> Tests;

52

  // Speicher für alle Zeiger auf einmal anlegen

53

  Tests.reserve (ANZAHL);

54

55

  // Objekte einfügen

56

  for (std::size_t i = 0; i < ANZAHL/2; ++i)

57

    Tests.push_back(make_unique<Test1> (i));

58

59

  for (std::size_t i = ANZAHL/2; i < ANZAHL; ++i)

60

    Tests.push_back(make_unique<Test2> (i+0.3f));

61

62

  Serial.print("FreeHeap mit Objekten:");

63

  Serial.println(ESP.getFreeHeap());  

64

  // Ausgeben

65

  for (auto& t : Tests)

66

    t->show ();

67

68

  const uint32_t numListExecutions=100000;

69

  uint32_t startTime_us=micros();

70

  for(int n=0;n<numListExecutions;n++)

71

  {

72

    for (auto& t : Tests)

73

    t->execute ();

74

  }

75

  uint32_t stopTime_us=micros();

76

  Serial.print("average execution time per object: ");

77

  Serial.print((double)(stopTime_us-startTime_us)/numListExecutions/ANZAHL);Serial.println(" us");

78

79

80

  // Alle löschen

81

  Tests.clear ();

82

83

  Serial.print("FreeHeap Objekte gelöscht:");

84

  Serial.println(ESP.getFreeHeap());  

85

86

  // Eins einfügen

87

  Tests.push_back (make_unique<Test1> (42));

88

89

  // Ausgeben (diesmal leer)

90

  for (auto& t : Tests)

91

    t->show ();

92

93

  delay(3000);

94

}

FreeHeap mit Objekten:373504
test1 int:0
test1 int:1
test2 float:2.30
test2 float:3.30
average execution time per object: 0.14 us
FreeHeap Objekte gelöscht:373600
test1 int:42

Falls der ESP 1Befehl/Zyklus erlaubt wären das:

>> FCPU=240e6;
>> timePerObject=0.14e-6;
>> numberOfCpuCommandsPerObject=timePerObject*FCPU
numberOfCpuCommandsPerObject =  33.600

Und ein Objekt braucht 96Byte/4 = 24Byte Speicher.

chris schrieb:
> Das Programm soll folgendes tun:
> 1. es werden N-Testobjekte angelegt ( z.B. N=100 )
> 2. Die Testobjekte werden ein Zeit lang benutzt und eine Test.execute()
> Methode aufgerufen.
> 3. Der Speicher, den die Testobjekte belegen, muss wieder frei gegeben
> werden.
> 4. Goto 1.
>
> Ich vermute, dass im Framework des ESP32 keine Garbage Collection
> implementiert ist. In C wäre das Ganze extrem einfach zu lösen.
>
> 1. man reserviert Speicher für die Objekte und merkt sich den Speicher
> Anfang
> 2. man legt Objekte an ( Strukturen )
> 3. wie oben ( 1-3)
> 4. Man setzt den Objektpointer zurück
> 5. Goto 1.
>
> Aufwand, die Objekte zu löschen: Null

Ich glaube, du hast C/C++ so gar nicht verstanden.

Es gibt in C malloc und free, man braucht nur 1 Aufruf um ein ganzes 
Array im noch freien heap Speicher zu reservieren, und wieder 
freizugeben.
New und delete von C++ tun dasselbe, so lange in der Klassenstruktur nur 
einfache Variablen enthalten sind, keine weiteren Objekte (also structs 
mit ihrer eigenem Constructor und Destructor), und können auch ein 
ganzes Array auf einen Schlag behandeln.

Im einfachsten Fall macht malloc/new:

1

void *alloc(size_t bytes)

2

{

3

  // einfacher Fall, keine bzw. leere freelist

4

  heaptop-=bytes+sizeof(bytes);

5

  *(size_t *)heaptop=bytes;

6

  return heaptop+sizeof(bytes);

7

}

8

void free(void * ptr)

9

{

10

  if(ptr==heaptop+sizeof(size_t))

11

     heaptop+=*(size_t *)heaptop;

12

  else // aufwändiger

13

}

Rolf M. schrieb:
> Und wie allokierst du ein Array aus lauter unterschiedlich großen
> Elementen

Grundlagen der Programmierung: Ein Array besteht aus gleichartigen 
Elementen.

Bei unterschiedlich grossen kann man nicht berechnen, dass das dritte 
Element bei 2+sizeof(element) steht.

Man braucht Pointer, geht aber auch, gern gemacht um strings in Worte zu 
zerlegen oder so:

1

element ** mem=malloc(elementanzahl*sizeof(element *)+elementgesamtgrösse);

2

for(n=0,ptr=mem+elementanzahl;n<elementanzahl;n++)

3

{

4

   mem[n]=ptr; ptr+=elementgrösse(n);

5

}

Da reicht dann 1 free um alle loszuwerden.

Hier ein Versuch mit einer Objektliste fester Länge.

Meine Vermutung war, dass die "execute"-Schleife etwas schneller ist und 
das die verkehrte Reihenfolge beim Löschen der Objekte zu Problemen 
führt.
Aber scheinbar bleibt alles wie beim vorigen Beispiel. Die 
Ausführungszeit ist gleich und mit dem "delete" der Objekte scheint es 
wohl auch kein Problem zu geben.

1

#include <iostream>

2

#include <memory>

3

#include <vector>

4

5

class Test {

6

  public:

7

    Test () {}

8

    virtual ~Test() {}

9

    virtual void show () = 0;

10

    virtual void execute () = 0;

11

};

12

13

class Test1 : public Test {

14

  public:

15

    Test1 (int i) : id (i) {}

16

    virtual void show () {

17

      Serial.print("test1 int:");

18

      Serial.println(id);

19

    }

20

    virtual void execute () {

21

      id++;

22

    }

23

  private:

24

    int id;

25

};

26

27

class Test2 : public Test {

28

  public:

29

    Test2 (float f) : id (f) {}

30

    virtual void show () {

31

      Serial.print("test2 float:");

32

      Serial.println(id);

33

    }

34

    virtual void execute () {

35

      id *= 3;

36

    }

37

  private:

38

    float id;

39

};

40

41

42

constexpr std::size_t ANZAHL = 4;

43

44

45

Test *Tests[ANZAHL];

46

47

void setup()

48

{

49

  Serial.begin(115200);

50

}

51

52

void loop()

53

{

54

  Serial.print("FreeHeap ohne Objekte:");

55

  Serial.println(ESP.getFreeHeap());

56

  // Objekte einfügen

57

  for (std::size_t i = 0; i < ANZAHL / 2; ++i)

58

    Tests[i] = new Test1(i);

59

60

  for (std::size_t i = ANZAHL / 2; i < ANZAHL; ++i)

61

    Tests[i] = new Test2(i);

62

63

  Serial.print("FreeHeap mit Objekten:");

64

  Serial.println(ESP.getFreeHeap());

65

  //Ausgeben

66

  for (auto& t : Tests)

67

    t->show ();

68

69

  const uint32_t numListExecutions = 100000;

70

  uint32_t startTime_us = micros();

71

  for (int n = 0; n < numListExecutions; n++)

72

  {

73

    for (auto& t : Tests)

74

      t->execute ();

75

  }

76

  uint32_t stopTime_us = micros();

77

  Serial.print("average execution time per object: ");

78

  Serial.print((double)(stopTime_us - startTime_us) / numListExecutions / ANZAHL); Serial.println(" us");

79

  delay(3000);

80

81

82

  for (auto& t : Tests)

83

    delete(t);

84

85

}

1

average execution time per object: 0.14 us

2

FreeHeap ohne Objekte:373616

3

FreeHeap mit Objekten:373520

4

test1 int:0

5

test1 int:1

6

test2 float:2.00

7

test2 float:3.00

8

average execution time per object: 0.14 us

9

FreeHeap ohne Objekte:373616

10

FreeHeap mit Objekten:373520

11

test1 int:0

12

test1 int:1

13

test2 float:2.00

14

test2 float:3.00

Super Sache: Man kann den Compiler-Explorer verwenden, um den 
Assemblercode für verschiedene MCUs zu analysieren:

https://godbolt.org/

Tschuldigung ... die Dateiendung für das Bild fehlt.

chris schrieb:
> Man kann den Compiler-Explorer verwenden, um den Assemblercode für
> verschiedene MCUs zu analysieren:

Mit objdump geht das auch lokal. Schalte mal die Optimierungen ein!

Hier im Netz gibt es einen schönen Artikel zu malloc und 
Heap-Fragmentierung:
https://www.mikrocontroller.net/articles/Heap-Fragmentierung

Wird "malloc" bei C++ noch verwendet?
Ich suche nach einer Möglichkeit, in einem Objekt beim Instantiieren 
eine variable Speichergröße anzulegen und später das Objekt mitsamt 
Speicher wieder zu löschen.

chris schrieb:
> Wird "malloc" bei C++ noch verwendet?

Ja, "new" ruft das auf.

chris schrieb:
> Ich suche nach einer Möglichkeit, in einem Objekt beim Instantiieren
> eine variable Speichergröße anzulegen und später das Objekt mitsamt
> Speicher wieder zu löschen.

Also ein vector, genau wie gezeigt...

chris schrieb:
> Hier im Netz gibt es einen schönen Artikel zu malloc und
> Heap-Fragmentierung:

Das ist halt das Problem bei dynamischer Speicherverwaltung. Zum Glück 
braucht man die bei Embedded Systems auch fast nie...

Dr. Sommer
>Also ein vector, genau wie gezeigt...

Ist der geeignet, um in den verschiedenen Objekten ein "uin16_t" Array 
mit 10-4000 Werten anzulegen ( je nach geforderter Größe bei der 
Instantiierung )? Wird in einem Vector nicht eine "linked list" 
angelegt, die 3x soviel Speicher braucht?

chris schrieb:
> Ist der geeignet, um in den verschiedenen Objekten ein "uin16_t" Array
> mit 10-4000 Werten anzulegen

Ja natürlich.

chris schrieb:
> Wird in einem Vector nicht eine "linked list" angelegt, die 3x soviel
> Speicher braucht?

Nein, das macht std::list. vector legt ein Array aus zusammenhängendem 
Speicher an.

chris schrieb:
> Wird in einem Vector nicht eine "linked list"
> angelegt, die 3x soviel Speicher braucht?

Wie kommt man auf so eine Idee?

Autor: mh (Gast)
>Wie kommt man auf so eine Idee?
Von hier:
https://de.cppreference.com/w/cpp/container/vector
"Der Speicherplatz des Vektors wird automatisch angepasst, er wird je 
nach Bedarf erweitert und verkleinert. Vektoren belegen in der Regel 
mehr Platz als statische Arrays, weil mehr Speicher zugewiesen wird um 
zukünftiges Wachstum zu behandeln."

Zugegeben, das mit der "linked list" war eine Vermutung. Aber zumindest 
hat "vector" einen Overhead. Die Frage ist, wie groß?

chris schrieb:
> Aber zumindest hat "vector" einen Overhead. Die Frage ist, wie groß?

Ca 16 Bytes (einmalig). Siehe auch die Funktion std::vector::reserve...