Hi, ich programmiere zur Zeit einen ATmega8 mit avr-g++ mit C++. Leider funktionieren pure virtual functions nicht. Sobald ich eine Funktion als rein virtuell deklariere, kommt beim Linken folgender Fehler: "undefined reference to `__cxa_pure_virtual'" Als Fehlerzeile ist die erste Zeile des Destruktors angegeben. Der Destruktor ist natürlich auch virtual, aber auch leer. Der Fehler tritt übrigens auf, egal ob die rein virtuelle Funktion einen Rumpf hat oder nicht. Liegt dieser Fehler an avr-g++ oder habe ich einfach etwas vergessen? p.s.: Programmiert überhaupt jemand einen ATmega mit C++ oder bin ich der einzige leichtsinnige?
Die Suchfunktion ist etwas tolles: http://www.avrfreaks.net/phpBB2/viewtopic.php?t=18187 (erste Antwort) Damit hätte sich meine erste Frage wohl erledigt. Meine zweite steht immer noch im Raum. :)
Wahrscheinlich werden es eher wenige Leute sein, die C++ benutzen wollen. Alle interessanten Features von C++ kosten entweder viel ROM und/oder viel Rechenzeit, beides ist auf Controllern knapp. ;-) Es sind bislang jedenfalls zu wenige, als daß es mal jemand geschafft hätte, sich die libsupc++ zur Aufgabe zu machen. Die bisherigen Mitglieder des avr-libc-Teams haben erstens dafür keine Zeitreserve mehr übrig und zweitens eher wenig Interesse an C++ insgesamt -- es müßte sich also einfach jemand finden, der diese beiden Voraussetzungen mitbringt und dort mitmachen will.
warum nicht gleich UML ( Unified Modelling Language ) benutzen. Das ist das absolute Muss für 8Bit Controller.
> warum nicht gleich UML [...] benutzen.
Weil UML nur eine Spezifikation, aber nicht die Implementierung einer
Software dargestellt?
Habe den Wink aber schon verstanden...
Ich finde, dass kompilierter C++-Code gar nicht so viel größer ist als
C-Code. Klassen existieren eh nur auf Quellcode-Ebene, Exception
funktionieren in absehbarer Zeit nicht.
Virtuelle Funktionen belegen natürlich etwas mehr Speicher. Aber wenn
man vergleichbare Funktionalität in C simulieren würde, würde man
mindestens genausoviel Speicher brauchen.
Ich habe aber mit Mikrocontrollern noch wenig Erfahrung, programmiere
sie erst seit relativ kurzer Zeit. Ich werd wohl mal versuchen, mit C++
weiterzukommen. Wenn ich damit wirklich auf Granit stoße, kann ich immer
noch zu C wechseln.
Auf jeden Fall mal danke für die Antworten.
Übrigens ist das mit UML nicht so abwegig. Viele Firmen nutzen jetzt schon UML oder andere CASE-Tools um Software zu modellieren und sich dann Code erzeugen zu lassen, auch auf µCs. Bei kommerziellen oder komplexeren Projekten stehen meistens andere Dinge im Vordergrund als das letzte Byte Code einzusparen.
> Wahrscheinlich werden es eher wenige Leute sein, die C++ benutzen > wollen. Alle interessanten Features von C++ kosten entweder > viel ROM und/oder viel Rechenzeit, beides ist auf Controllern > knapp. ;-) Dem muss ich (teilweise) widersprechen. Wenn man mit "interessanten Features" Templates, Exeptions u.ä. meint ist das wohl richtig. Aber C++ bietet viele Features die das Programmierleben einfacher machen und trotzdem kein Bit mehr ROM oder mehr Rechenzeit benötigen. Einige Beispiele: * inline Funktionen * Überladen von Funktionen: void Out (int x); void Out (char x); void Out (float x); * freie Platzierung von Deklarationen und nicht zuletzt "normale" Klassen und die Möglichkeit diese abzuleiten.... Ich habe 10Jahre Microcontroller in C programmiert. Seit 2 Jahren programmiere ich "gemischt" in C/C++. Die Vorteile möchte ich nicht mehr missen. Vor allem wenn mehr als ein Programmierer an diesem Code arbeitet... Klaus
> Wenn man mit "interessanten Features" Templates, Exeptions u.ä. > meint ist das wohl richtig. Diese meinte ich, ja. > * inline Funktionen > * Überladen von Funktionen: > void Out (int x); > void Out (char x); > void Out (float x); > * freie Platzierung von Deklarationen 1 und 3 hat C99 auch. ;-) Alles, was Du willst, funktioniert ja durchaus auch mit dem existierenden C++-Port von AVR-GCC. Auf der Liste der derzeit nicht unterstützten Features dürfte new/delete am weitesten oben stehen.
Hi Gerade templates sollten keinen Einfluß auf die Performance haben. Warum auch. Die werden doch zur Compilezeit komplett aufgelößt. Matthias
> inline Funktionen > freie Platzierung von Deklarationen > hat C99 auch. ;-) Ja Jörg, du hast natürlich Recht, mein Fehler. Aber es gibt noch einige C++Features, die einem beim Microcontroller Programmieren helfen. * Überladen von Funktionen (Ok, hatten wir schon, aber ist auch wirklich ein genjales Feature, warum muss ich mir gedanken machen ob ich OutInt32(x) oder OutFloat(x) schreiben muss, wenn mir's der Compiler abnimmt, sprich Out(x). ) * Referenzen * Konstruktor (Oh, habe eine komplexere Struktur nicht richtig initialisiert...) * Destruktor (Oh mal wieder free nach malloc vergessen., Schnittstelle nicht geschlossen...) * Überladen der des Array Operators [] (Scheisse, Programmabsturz, mal wieder über das Ende eines Arrays geschrieben....) Man kann ohne diese ganzen Features leben/programmieren. Natürlich kenn ich meinen Code, ich weiss, dass das Array Xyz nur 20 Elemente hat. Aber weiss ich das in einem halben Jahr auch noch...? C++ macht das codieren der eigentlichen Funktionalität nicht einfacher, aber die **Anwendung** meines Codes wird sicherer.
Jaja, aber s.o.: das wichtigste, was dafür wirklich fehlt ist, daß sich endlich mal jemand von denen, die an C++ auf dem AVR interessiert sind hinsetzt und die libsupc++ compilefähig macht. Das dürfte insbesondere new/delete bringen (und damit auch diese Varianten, bei denen new/delete implizit aufgerufen werden, Beispiele hast Du ja schon genannt), außerdem wahrscheinlich auch exceptions (wer's mag, kostet immens viel Code, hatte sie bei meinen ersten C++-Versuchen noch versehentlich eingeschaltet um dann feststellen zu müssen, daß sich das Zeug nicht linken läßt). Templates dürften ohnehin schon funktionieren, auch wenn sie im EC++ nicht vorgesehen sind. STL hat natürlich noch keiner ernsthaft versucht.
> STL hat natürlich noch keiner ernsthaft versucht. Ich möchte nicht direkt sagen "ernsthaft", aber versucht habe ich es. Und ich habe es geschafft einige STL-Klassen für den ATmega8 zu kompilieren (mit STLport). Getestet habe ich std::list und std::vector. Ich habe natürlich nicht jeden Aspekt getestet, aber das meiste was ich ausprobiert habe hat gut funktioniert. :) Manche Funktionen verursachen aber auch Compilezeit-Fehler, zum Beispiel "PORTB = *l.begin()", um das erste Element einer Liste zu bekommen. Seltsamerweise funktioniert das hier: PORTB = *static_cast<list<uint8_t>::const_iterator>(test.begin()); Allerdings spuckt der Compiler dann diese gefährliche Warnung aus: stl/_list.h:128: warning: returning reference to temporary Ohne den Cast auf const_iterator kommt dieser Fehler: stl/_list.h:128: error: cannot bind packed field `((std::_List_node<uint8_t>*)((const std::_List_iterator_base*)((const std::_List_iterator<uint8_t, std::_Nonconst_traits<uint8_t> >*)this))->std::_List_iterator_base::_M_node)->std::_List_node<uint8_t>: :_M_data' to `uint8_t&' Ich bin dem aber nicht näher nachgegangen, weil durch die STL-Klassen der entstehende Hex-Code doch ein (zu) gutes Stück zunimmt.
> Jaja, aber s.o.: das wichtigste, was dafür wirklich fehlt ist, daß > sich endlich mal jemand von denen, die an C++ auf dem AVR interessiert > sind hinsetzt und die libsupc++ compilefähig macht. Das dürfte > insbesondere new/delete bringen (und damit auch diese Varianten, bei > denen new/delete implizit aufgerufen werden, Beispiele hast Du ja > schon genannt) Man braucht die C++ Libraries nicht um obige Vorteile von C++ zu nutzen. Ich mache in "C" Embedded Systemem sowieso einen großen großen Bogen um dynamischen Speicher und deren Allokation mittels malloc (gebranntes Kind), ich versuche auch in "C++" Systemen so gut wie's geht dynamischen Speicher zu vermeiden. > das wichtigste, was dafür wirklich fehlt ist, daß > sich endlich mal jemand von denen, die an C++ auf dem AVR > interessiert sind hinsetzt und die libsupc++ compilefähig macht. Ich bin momentan beruflich noch ziemlich am Anschlag. Aber wenn's klappt mach ich Anfang nächsten Jahres ein Päuschen. (Bin zwar noch kein Experte in C++, aber den Versuch libsupc++ anzupassen reizt mich).
Melde Dich auf der avr-libc Mailingliste, wenn Du das ernsthaft angehen willst.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.