kann man einen ATMEL Controller auch mit C++ ansprechen bzw gibts es compiller die aus C++ dann die hex Datei erzeugen?
Guckst du GCC links
Gast
#1100390
Ja, macht aber keinen Sinn.
Sven Pauli wrote:
> Ja, macht aber keinen Sinn.
wieso?
Weil der GCC kein C++ Compiler ist.
Gast
#1100405
>Ja, macht aber keinen Sinn.
Doch, macht Unsinn ;-)
Gast
#1100410
Weil die wesentlichen Vorzüge von C++ ggü. C zuviel Overhead für einen kleinen Prozessor mit wenig RAM mitbringen.
Gast
#1100412
Simon K. wrote:
> Weil der GCC kein C++ Compiler ist.
Der GCC ist überhaupt kein Compiler...
Ob das Sinn macht muss jeder IMHO selbst beurteilen. Du kannst die "Sprache" C++ an sich verwenden, nur die Standardbibliothek von C++ eher nicht. Aber die Vorteile von C++ an sich, also z.B. Objektorientierung, kann man auch auf einem AVR nutzen.
Sven Pauli wrote: > Simon K. wrote: >> Weil der GCC kein C++ Compiler ist. > > Der GCC ist überhaupt kein Compiler... Stimmt. Genau genommen ist "das Gleiche" auch nicht das gleiche wie "das Selbe", trotzdem wirds durcheinander geworfen. Macht aber hier jetzt auch keinen Unterschied. Nicht genau genommen steht sogar in der mikrocontroller.net-Wiki: > AVR-GCC ist ein kostenloser C-Cross-Compiler für AVR-Mikrocontroller. Jedenfalls beinhaltet die AVR-GCC kein C++ Compiler-Frontend. EDIT: Das stimmt natürlich nicht. AVR-GCC enthält ein C++ Frontend.
Also lieber C nehmen... Schade
Gast
#1100436
Natuerlich ergibt das einen Sinn - abhaengig vom zu loesenden Problem. Man muss nur ein paar Dinge beachten: Da auch bei grossen AVR sehr wenig Speicher und keine MMU vorhanden ist, sollte man auf dynamische Speicherverwaltung verzichten. Das ist aber unabhaengig davon, ob man C oder C++ verwendet. Ehrlich gesagt weiss ich gar nicht, ob new & delete mit dem avr-gcc funktionieren, da ich es nie versucht habe. Virtuelle Methoden funktionieren nicht. Zumindest mit dem avr-gcc 4.1.2 den ich hier habe. Das schraenkt natuerlich mitunter ein wenig ein, da Funktionspointer doch deutlich aufwendiger zu handhaben sind. Tatsaechlich fuehrt objektorientierte Programmierung (egal ob in C oder C++) schnell zu groesserem Code. Das liegt aber nicht daran, dass der Compiler ploetzlich irgendwelchen Zusatzcode produziert, sondern schlicht am anderen Stil. Im Allgemeinen bekommt man fuer Abstraktion und strikte Trennung von Komponenten aber auch etwas: Bessere Wartbarkeit.
Zu der Sinnfrage von C++ gab es übrigens schon teilweise große Diskussionen in dem GCC Forum. Such einfach mal. Das Ganze endete darin, dass C++ nette Features bietet, die man benutzen könnte (Automatische Smart Pointer ins Flash/RAM usw.). Aber hier hat bisher noch niemand was eingereicht für die AVR-GCC Maintainer, was man dem nächsten Release beipacken könnte. Übrigens muss C++ nicht notwendigerweise mehr Overhead als Plain-C haben. Aber wie gesagt, das hatten wir alles schon öfters hier.
Peter Stegemann wrote: > Da auch bei grossen AVR sehr wenig Speicher und keine MMU vorhanden ist, > sollte man auf dynamische Speicherverwaltung verzichten. Das ist aber > unabhaengig davon, ob man C oder C++ verwendet. Ehrlich gesagt weiss ich > gar nicht, ob new & delete mit dem avr-gcc funktionieren, da ich es nie > versucht habe. Genau. new und delete sind standardmäßig nicht vorhanden, wenn ich mich recht erinnere. > Tatsaechlich fuehrt objektorientierte Programmierung (egal ob in C oder > C++) schnell zu groesserem Code. Das liegt aber nicht daran, dass der > Compiler ploetzlich irgendwelchen Zusatzcode produziert, sondern > schlicht am anderen Stil. Im Allgemeinen bekommt man fuer Abstraktion > und strikte Trennung von Komponenten aber auch etwas: Bessere > Wartbarkeit. Ja, das mag gut sein. Aber man muss nicht unbedingt objektorientiert programmieren, wenn man C++ benutzt. Man kann auch einfach die Zusatz-Features benutzen gegenüber C. Nur, dass das klar ist.
Gast
#1100461
Simon K. wrote: > Ja, das mag gut sein. Aber man muss nicht unbedingt objektorientiert > programmieren, wenn man C++ benutzt. Man kann auch einfach die > Zusatz-Features benutzen gegenüber C. Nur, dass das klar ist. Voellig richtig. Und auch andersrum: Man kann auch in C objektorientiert programmieren (und in Java funktional, etc,..).