Druckbare Version
Hallo,
weiß vllt jemand, wieso folgendes nicht klappt:
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?Code:int main()
{
int* pi;
pi=new int;
*pi=10;
delete pi;
while(1);
return 0;
};
Danke
MfG Mark
Du verwendest avr-g++ ?
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.
Ja.Zitat:
Zitat von SprinterSB
Gibt es wirklich keine Versionen, die das unterstützen?Zitat:
Zitat von ogni42
MfG Mark
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-...#faq_cplusplus
Danke für den Link, ich werd ihn mal genau anschauen.
MfG Mark
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.Zitat:
Zitat von bluebrother
MfG Mark
Warum nicht die Zeichen per XOR Darstellen? Dann brauchst Du keinen zusätzlichen Platz und kannst mit erneutem XOR den Hintergrund wiederherstellen.
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
"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.Zitat:
Zitat von 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?Zitat:
Zitat von SprinterSB
MfG Mark
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
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
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...Zitat:
Zitat von p_mork
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.