Hallo zusammen,
nachdem ich in der Ankündigung des AVR Studio 6 die vollmundige Aussage
vorfand, dass dieses nun C++ Programmierung unterstütze, habe ich es mir
heruntergeladen und ausprobiert.
Es war mir leider nicht möglich, auch nur eine einzige Mickymaus-C++
Klasse zu deklarieren. Es kommen die unmöglichsten Fehlermeldungen dabei
raus, und auf Anfrage (Ticket) gab es lediglich die Antwort, dass
"stdlib" nicht unterstützt werde (???).
Leider war auch nach mehrmaliger Anfrage überhaupt nichts zu diesem
Thema zu erfahren, daher nun meine Frage an das Forum:
Unterstützt jetzt das AVR Studio objektorientierte Programmierung mit
C++ oder nicht ? Und wenn ja, gibt es da irgendwelche Besonderheiten,
die man beachten muß, wenn man Klassen deklarieren möchte ?
Dieses Problem brennt mir auf den Nägeln; ich bin für jeden Hinweis sehr
dankbar.
Das AVR Studio basiert auf dem Visual Studio, und es wird in der
Toolchain der gcc Compiler benutzt. Beide sind problemlos in der Lage,
objektorientiert zu arbeiten; also verstehe ich eigentlich nicht, warum
es da Probleme geben soll.
Und bitte: Keine Vorschläge, das doch mit C zu machen.
C++ ist die schnellste und effektivste Programmiersprache unserer Zeit,
und objektorientierte Programme sind sicherer, besser und effektiver als
C oder Assembler Code.
Vielen Dank im Voraus !
Gerhard Biebl schrieb:> C++ ist die schnellste und effektivste Programmiersprache unserer Zeit,> und objektorientierte Programme sind sicherer, besser und effektiver als> C oder Assembler Code.
aber leider nicht geeignet für kleine µC.
Templates kannst du vergessen, diese werden auf jeden Fall nicht
unterstützt. Auch Dynamische speicherverwaltung (new/delete) ist nicht
sinnvoll, aber möglich.
Die könntest ja auch mal den output von deinem Build vorgang posten,
dann erkennt man eventuell was schief geht. Bitte auch gleich den
Quelltext du du versucht hast.
Du solltest mal ein paar mehr Informationen rausrücken. Z.B. welcher AVR
und wie sieht die Fehlermeldung aus? Ein Codebeispiel wäre auch nicht
schlecht.
Ansonsten kannst du ja mal hier im Forum suchen. Es gibt reichlich
Threads über AVR-GCC und C++.
Z.B.:
Beitrag "C++ in AVR Studio verwenden-> Funktioniert nicht!"> C++ ist die schnellste und effektivste Programmiersprache unserer Zeit,> und objektorientierte Programme sind sicherer, besser und effektiver als> C oder Assembler Code.
Das halte ich für ein Gerücht ;).
Gerhard Biebl schrieb:> Es war mir leider nicht möglich, auch nur eine einzige Mickymaus-C++> Klasse zu deklarieren. Es kommen die unmöglichsten Fehlermeldungen dabei> raus, und auf Anfrage (Ticket) gab es lediglich die Antwort, dass> "stdlib" nicht unterstützt werde (???).
Eigentlich heißt sie libstdc++. Es ist die GCC-Implementierung der
C++-Standardbibliothek. Die gibt es nicht für AVR. Das wäre auch nur für
einen recht kleinen Anteil der Bibliothek sinnvoll, denn die meisten
Klassen setzen dynamischen Speicher im großen Stil ein, was bei so
kleinen µCs in der Regel überhaupt nicht sinnvoll ist.
> Unterstützt jetzt das AVR Studio objektorientierte Programmierung mit> C++ oder nicht ?
Ja, aber mit Einschränkungen. Das liegt aber am avr-g++.
> Und wenn ja, gibt es da irgendwelche Besonderheiten, die man beachten muß,> wenn man Klassen deklarieren möchte ?
Keine Exceptions, keine Standardklassen, und soweit es geht auf
dynamischen Speicher verzichten.
> Das AVR Studio basiert auf dem Visual Studio,
Echt?
> C++ ist die schnellste und effektivste Programmiersprache unserer Zeit,> und objektorientierte Programme sind sicherer, besser und effektiver als> C oder Assembler Code.
Wenn man genau weiß, was man tut und was der Compiler draus macht, kann
man die auch auf AVRs nutzbringend einsetzen. Aber das ist
Grundvoraussetzung, um effiziente Programm dort schreiben zu können.
Peter II schrieb:> Templates kannst du vergessen, diese werden auf jeden Fall nicht> unterstützt.
Unsinn. Templates funktionieren wunderbar und können auch, wenn man
weiß, was man tut, sehr sinnvoll sein, auch auf einem AVR.
> Auch Dynamische speicherverwaltung (new/delete) ist nicht> sinnvoll, aber möglich.
Allerdings nicht out-of-the-box. Man muß sich die Operatoren selbst
definieren.
> Die könntest ja auch mal den output von deinem Build vorgang posten,> dann erkennt man eventuell was schief geht. Bitte auch gleich den> Quelltext du du versucht hast.
Das wäre auf jeden Fall sinnvoll.
Gerhard Biebl schrieb:> Vielen Dank im Voraus !
Wie immer: Fehlermeldungen zeigen, Code zeigen, dazu die Kommandozeilen
beim Kompilieren und linken.
Ansonsten hat schon das alte Studio 4 "C++ unterstützt" - was auch immer
das heissen mag.
Oliver
Peter II schrieb:> Marwin schrieb:>> Es gibt sehr viele Mikrocontroller abseits der AtTiny-Reihe.> ist ja schön, und wie viel werden davon im AVR Studio 6 Programmiert?
Was fuer eine Frage - meinst du es gibt eine Statistik von Atmel
darueber, welche Controller wie oft von welcher Version des AVR Studio
programmiert werden?!?
Peter II schrieb:> Marwin schrieb:>> Es gibt sehr viele Mikrocontroller abseits der AtTiny-Reihe.>> ist ja schön, und wie viel werden davon im AVR Studio 6 Programmiert?
Es heißt jetzt Atmel Studio und nicht mehr AVR Studio. Und wenn Du
unbedingt C++ machen willst, ist ein ARM besser geeignet. Auch den
kannst Du von Atmel kaufen und im Atmel Studio 6 mit dem dazu passenden
JTAG-Interface programmieren.
fchk
ja, wenn man dem gcc (auch so aufgerufen) eine *.cpp vorwirft, wird er
die als C++ übersetzen.
Der Unterschied ist nur, daß bei einem Aufruf als g++ auch die
Std-C++-Libs mit gelinkt werden - was bei AVR also nichts bewirken
sollte.
Sobald ein 'new' im Code vorkommt, gibts die meldung:
"undefined reference to 'operator new(unsigned int)'"
Hab gelesem das man sich new/delete selbst schreiben muss.
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=59453
Ob C++ nun schneller als C oder Asm ist, hängt davon ab was der Compiler
drauß macht. Und ob es ein ARM, ATmega oder ATtiny ist, ist völlig
Stulle. Wenn der Compiler mist macht, ist der ARM auch nicht besser als
ein 68000.
>Wenn der Compiler mist macht, ist der ARM auch nicht besser als>ein 68000.
Der Compiler macht keinen Mist, eher der Programmierer;)
Ein schlechter Assembler Programmierer erzeugt auch keinen
besseren Code als ein C Compiler. Hier werden immer wieder
Äpfel mit Birnen verglichen.
Natürlich ist es ein "zusammenspiel" von Programmierer und Compiler.
Aber du kannst noch so gut programmieren, wenn der Compiler den Code
nicht vernünftig umsetzten kann (einfach weil der compiler schlecht
ist), dann helfen auch die besten Programmierkünste nichts ;)
> Ob C++ nun schneller als C oder Asm ist, hängt davon ab was der Compiler> drauß macht. Und ob es ein ARM, ATmega oder ATtiny ist, ist völlig> Stulle. Wenn der Compiler mist macht, ist der ARM auch nicht besser als> ein 68000.
Ist was Wahres dran, man kann auch mit C schlechten und ineffizienten
Code schreiben. Dennoch wird ein C Compiler fast immer besseren Code
liefern als ein C++ Compiler. Das liegt schon alleine am reduzierten
Sprachumfang, wodurch sehr effizient in den jeweilige ASM-Code der
Zielarchitektur übersetzt werden kann.
Wenn man mal überlegt, was bei einer einfachen Vererbung mit einer
Überschreibung einer Methode für Aufwand zur Verwaltung notwendig ist:
Namemangling der Symbole, Auflösung der Vtable und die ganzen Kon- und
Destruktoraufrufe... Und wie bereits oben erwähnt wurde: kommen
Container bzw STL ins Spiel, kann's was den Speicherbedarf sehr eklig
werden. Jeder, der mal STL-Container über DLL-Grenzen weg exportieren
musste, kann ein Lied davon singen, wie unschön die STL sein kann.
