Forum: Compiler & IDEs C++ auf dem ATmega


von Chris (Gast)


Lesenswert?

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?

von Chris (Gast)


Lesenswert?

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. :)

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Steffen (Gast)


Lesenswert?

warum nicht gleich UML ( Unified Modelling Language ) benutzen. Das ist
das absolute Muss für 8Bit Controller.

von Chris (Gast)


Lesenswert?

> 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.

von Matthias Friedrich (Gast)


Lesenswert?

Ü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.

von Klaus Hummel (Gast)


Lesenswert?

> 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

von Jörg Wunsch (Gast)


Lesenswert?

> 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.

von Matthias (Gast)


Lesenswert?

Hi

Gerade templates sollten keinen Einfluß auf die Performance haben.
Warum auch. Die werden doch zur Compilezeit komplett aufgelößt.

Matthias

von Klaus Hummel (Gast)


Lesenswert?

> 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.

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Chris (Gast)


Lesenswert?

> 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.

von Klaus Hummel (Gast)


Lesenswert?

> 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).

von Jörg Wunsch (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.