"new" klappt nicht

[SprinterSB]

Damit will ich unnötigen Speicherverbrauch vermieden.

"Unnötigen Speicherverbrauch hast du eben mit new (bzw. malloc), weil die Speicherschnippsel in einer Liste verwaltet werden müssen. Das braucht Zeit, Code und RAM, das auf einem PC nicht schmerzt; auf einem kleinen µC aber wahrscheinlich merklich.

Zudem wird dadurch dein worst case nicht besser. Dein Grafik-Display wird also ein Singleton (hier also am besten ein globales oder statisches Objekt).

Über deine call-interfaces und deinen functions-frames und nicht alle möglichen C++-Konstrukte zu verwenden (VTABLE) kannst du deutlich an Code und Laufzeit sparen, und zwar was den worst case angeht.

[p_mork]

Zudem wird dadurch dein worst case nicht besser. Dein Grafik-Display wird also ein Singleton (hier also am besten ein globales oder statisches Objekt).

Über deine call-interfaces und deinen functions-frames und nicht alle möglichen C++-Konstrukte zu verwenden (VTABLE) kannst du deutlich an Code und Laufzeit sparen, und zwar was den worst case angeht.

Sorry falls es sich etwas dumm anhört, aber könntest Du das bitte so formulieren, dass es auch ein Anfänger wie ich verstehen kann?



MfG Mark

[SprinterSB]

In (objektorientiert) OO ist ein "Singleton" ein Design-Pattern und bezeichnet ein Objekt, das nur einmal angelegt wird und während der ganzen Programmdauer lebt. In einem kleinen AVR ist es jedoch günstiger nicht mit einem dogmatischen OO-Hammer drauf zu hauen, sondern einfach ne globale Variable dafür anzulegen.

"worst case" = im übelsten Falle

Das ist dann der Fall, wenn dein Fenster maximale Größe hat.

Neben dem statischen RAM-Verbrauch (globale + statische Variablen/Objekte) gibt es auch dynamischen RAM-Verbrauch:

-- Platz, wo lokale Variablen leben. wenn die Funktion nicht zu komplex ist braucht man keinen, weil GCC die Auto-Variablen in Regsitern halten kann
-- Platz, wo Variablen gesichert werden, während eine Funktion ausgeführt wird
-- Platz für Parameterübergabe an Funktionen, dito
-- Speichern der Return-Adresse (Funktionen + ISRs)
-- von malloc/new allokierter Platz
-- Overhead: Verwaultungsaufwand, zB von malloc/new

[p_mork]

Soll das heißen, dass ich einfach nur ein Array mit der maximalen Fanstergröße anlegen soll? Und dann einfach nur Teile davon verwenden, falls das Fenster kleiner wird?

MfG Mark

[bluebrother]

Soll das heißen, dass ich einfach nur ein Array mit der maximalen Fanstergröße anlegen soll? Und dann einfach nur Teile davon verwenden, falls das Fenster kleiner wird?

Im Prinzip ja -- dynamischer Speicher bringt einiges an Verwaltungsoverhead mit sich (ich konnte hier z.b. in einem (komplett anderen, auch andere Architektur, aber Mikrocontroller) Projekt problemlos über 10kiB Speicher freikriegen indem ich den ganzen dynamischen Krempel entsorgt und durch statische Arrays ersetzt hab. Wenn du malloc (bzw. new / free) benutzt musst du ja auch die entsprechenden Library-Routinen linken, und die brauchen ja auch Speicher...

In deinem Fall musst du dir halt überlegen wo dein Textfenster liegen kann und wie groß es ist -- u.U. ist es sinnvoll da ein paar Einschränkungen von vorne herein vorzusehen. Damit kannst du das ganze dann schon einiges kompakter machen.