PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : "new" klappt nicht



p_mork
28.03.2007, 12:31
Hallo,

weiß vllt jemand, wieso folgendes nicht klappt:


int main()
{
int* pi;
pi=new int;
*pi=10;
delete pi;
while(1);
return 0;
};


Auf dem PC klappts problemlos, wenn ich jedoch versuche das Programm mit dem GCC zu kompilieren kommt die Meldung cpp:13: undefined reference to `operator new(unsigned int)'" . Wo liegt da das Problem?

Danke

MfG Mark

SprinterSB
28.03.2007, 12:36
Du verwendest avr-g++ ?

ogni42
28.03.2007, 12:46
Weil es keine lipsup++ beim avr-gcc gibt. Sprich:

Es gibt kein new und delete. Die C++ Implementierung für den avr ist nicht vollständig. Gibt hier im Forum und bei mikrocontroller.net einige Threads dazu.

p_mork
28.03.2007, 14:17
Du verwendest avr-g++ ?
Ja.


Weil es keine lipsup++ beim avr-gcc gibt. Sprich:

Es gibt kein new und delete. Die C++ Implementierung für den avr ist nicht vollständig. Gibt hier im Forum und bei mikrocontroller.net einige Threads dazu.

Gibt es wirklich keine Versionen, die das unterstützen?

MfG Mark

ogni42
30.03.2007, 09:09
Du kannst Dir die globalen Operatoren ::new und ::delete ja selber schreiben. Für den avr-gcc (bzw. avr-g++) gibt es das nicht. Steht auch so in der FAQ der libc:
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus

p_mork
30.03.2007, 09:23
Danke für den Link, ich werd ihn mal genau anschauen.

MfG Mark

bluebrother
03.04.2007, 10:34
Mal unabhängig davon: dynamischer Speicher ist auf einem Mikrocontroller i.a. eine ziemlich schlechte Idee. Und gerade in deinem Beispiel gibts ja nun wirklich keinen Grund nicht alles statisch anzulegen ...

p_mork
03.04.2007, 11:39
Mal unabhängig davon: dynamischer Speicher ist auf einem Mikrocontroller i.a. eine ziemlich schlechte Idee. Und gerade in deinem Beispiel gibts ja nun wirklich keinen Grund nicht alles statisch anzulegen ...

Das oberige Beispiel ist nur eine Reduzierung meins Problems auf ein Minimum. Was ich wirklich mit new und delete anstellen möchte: Ich hab ein Farb-LCD(132x132 Pix). Auf diesem möchte ich sowohl Text als auch Grafik darstellen. Aber Text einfach nur darzustellen reicht mir nicht, ich möchte dass der uC auch weiss, was für Text sich auf dem LCD befindet, damit z.b. beim Löschen des Cursors nicht eine weisse Linie entsteht sondern wirklich der untere Teil des Buchstaben, der zuvor vom Cursor verdeckt wurde(Ich hasse Grafikfehler). Oder aber auch damit ich den Text scrollen kann usw.... Da ich aber wie gesagt auch Grafik darstellen will möche ich eine Funktion OpenConsoleWindow(x,y,Textbreite,Texthöhe) schreiben, die dem Text-Fenster nur soviel Speicherplatz reserviert, wie dieses benötigt. Damit will ich unnötigen Speicherverbrauch vermieden.

MfG Mark

ogni42
03.04.2007, 12:10
Warum nicht die Zeichen per XOR Darstellen? Dann brauchst Du keinen zusätzlichen Platz und kannst mit erneutem XOR den Hintergrund wiederherstellen.

p_mork
03.04.2007, 12:16
Dann muss ich aber wissen, welche Pixel gesetzt sind oder nicht, und bei 132x132=17424 Bytes(im 256-Farben-Modus) würde der RAM nicht reichen. Zudem möchte ich den Text ja wie gesagt scrollen können.

MfG Mark

SprinterSB
03.04.2007, 13:03
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
03.04.2007, 13:12
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
03.04.2007, 14:23
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
03.04.2007, 16:05
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
03.04.2007, 16:34
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.