mikrocontroller.net

Forum: Compiler & IDEs C++ Klassenbibliothek für AVR


Autor: Daniel Widmann (danielwidmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
kennt jemand eine Klassenbibliothek, die den Zugriff auf die Hardware 
von AVRs über Objekte ermöglicht?

Gruss Daniel Widmann

Autor: incunabulum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frage: Warum willst du dies machen?

Ich verwende zwar auch Klassen für Ringbuffer etc, aber die AVR Hardware 
wird ganz klassisch in C geschrieben, da ich hier von Vererbung, 
Mehrfachinstanzen etc. keine Vorteile habe, imho. Vom erhöhten 
Speicherplatzbedarf und der zur Zeit noch vorhandenen Problematik, dass 
immer alle (!) Methoden einer verwendeten Klasse - ob nun genutzt oder 
nicht - gelinkt werden, zu schweigen.

cu, mz

Autor: Frank Jonischkies (frajo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieh mal bei qfix nach.
http://qfix-shop.de/cgi/websale6.cgi?Ctx=%7bver%2f...
Im downloadbereich gibt es deren Software. Das ist eine ältere WinAVR 
mit eigenen C++ Programmen für deren Hardware. Ist vielleicht eine 
Anregung für den eigenen HAL in C++.

Autor: Daniel Widmann (danielwidmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@frajo:
Danke für den link

@incunabulum:
Ich denke auch ohne Mehrfachinstanzen, dynamisch erzeugte Objekte, etc. 
lässt sich c++ Sinnvoll einsetzen. Das mit dem erhöhten Speicherbedarf 
ist meiner Meinung nach Irrglaube. Wenn man dynamisch Objekte erzeugt 
oder Polymorphie verwendet, wird sicherlich sehr viel Speicher benötigt. 
Aber man kann ja z.B. staische Funktion verwenden, da muss man keine 
Instanzen erzeugen. Oder mit Hilfe von inline Funktionen kann man 
verhindern, dass nicht benötigte Methoden gelinkt werden.
Wie Frank das richtig erkannt hat, suche ich einen HAL für den AVR. Ein 
HAL wäre der erste Schritt um von den Vorteilen der Objekt-Orientierten 
Programmierung profietieren zu können. Besonders der die 
wiederverwendbarkeit von Code wird dadurch vereinfacht.

Gruss Daniel

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erfahrungsgemäss ist die einzige gut und einfach verwendbare C++ 
Classlib die selbst geschriebene. Jede andere nervt durch Bugs und 
fehlende oder irreführende Doku.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> da ich hier von Vererbung, Mehrfachinstanzen etc. keine Vorteile habe,

Es gibt auch andere nützliche C++-Features. Man muß nicht gleich alles 
nutzen, was die Sprache hergibt, um sie sinnvoll einsetzen zu können. 
Vererbung kann allerdings meiner Meinung nach schon ab und zu sinnvoll 
sein. Leider ist das mit g++ auf AVR aber alles andere als optimal 
implementiert, da die vtables immer im RAM gespeichert werden, was 
eigentlich unnötig ist.
Mal abgesehen davon:  Vor allem mit Templates und Operatorüberladung 
läßt sich schon sehr viel Nützliches machen, z.B. eine Art Smartpointer 
auf Flash, der beim Dereferenzieren automatisch pgm_read_* aufruft, eine 
Festkomma-Klasse, die sich fast wie ein eingebauter Datentyp verhält 
oder ein I/O-Bit-Typ, der ein einzelnes Bit in einem I/O-Register 
bedient und der zuweisungskompatibel zu bool ist.

> imho. Vom erhöhten Speicherplatzbedarf und der zur Zeit noch

Der Speicherbedarf ist nur dann höher, wenn man nicht aufpaßt. Er kann 
sogar niedriger sein.

> vorhandenen Problematik, dass immer alle (!) Methoden einer verwendeten
> Klasse - ob nun genutzt oder nicht - gelinkt werden, zu schweigen.

Sicher? Der Linker hat eigentlich keine Ahnung, ob der Code C oder C++ 
ist und sollte sich dementsprechend genauso verhalten wie bei C. Dort 
entscheidet er es auf Basis von Objektdateien und nicht von einzelnen 
Funktionen. Wenn du also die Memberfunktionen alle in eigene 
Implementationsfiles steckst, sollte das genauso funktionieren, wie in 
C.
C++ kann da auch sparsamer sein als C:
Eine Klasse, die sich so ähnlich benutzen läßt wie die I/O-Streams aus 
Standard-C++, aber auf das Wesentliche reduziert, kann z.B. kleiner sein 
als printf, weil bei printf immer alle unterstützten Konvertierungen 
gelinkt werden müssen, wogegen beim iostream für jede Konvertierung eine 
eigene Funktion existiert, die nur aufgerufen wird, wenn die 
Konvertierung auch tatsächlich irgendwo verwendet wird. Sehr einfache 
Konvertierungen können auch gleich inline erledigt werden.

Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus wrote:

>> vorhandenen Problematik, dass immer alle (!) Methoden einer verwendeten
>> Klasse - ob nun genutzt oder nicht - gelinkt werden, zu schweigen.
>
> Sicher? Der Linker hat eigentlich keine Ahnung, ob der Code C oder C++
> ist und sollte sich dementsprechend genauso verhalten wie bei C. Dort
> entscheidet er es auf Basis von Objektdateien und nicht von einzelnen
> Funktionen. Wenn du also die Memberfunktionen alle in eigene
> Implementationsfiles steckst, sollte das genauso funktionieren, wie in
> C.

Also meiner Erfahrung nach schon.... gab auch mal eine schöne Diskussion 
bei der "Konkurenz" (darf ich auf diese Verlinken?)

Zumindest bei Verwendung der Option qc-sections im Linker und 
function-sections im gcc werden Funktionen ohne Klasse nur gelinkt, wenn 
diese verwendet werden. Bei Klassen werden nach meinem Sym-File alle 
Methoden der Klasse gelinkt, unabhängig davon, ob ich diese Verwende 
oder nicht.

Zur Diskussion Klassenframework als HAL:
Also ich hatte mir damals auch so etwas entworfen und zum Teil 
implementiert. Aber wenn insbesondere bei der Hardware alle Methoden 
sowieso Static sein werden, dann hatte ich zumindest in meinem Fall 
keinerlei Vorteile aber einen höheren Speicherverbrauch (vtable im Ram) 
YMMV though :-)

Namespaces, Templates etc. verwende ich aber dennoch gerne. Klassen 
auch, wenn diese Sinn machen. Ringbuffer, Fifo, Stack etc.

@Magnus: Willst du ein Beispiel eines solchen Flash-Smartpointers online 
stellen? Klingt interessant, wobei mir da aber zum eigenständigen 
Umsetzen das Wissen wohl nocht fehlt.

cu, mz

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> sowieso Static sein werden, dann hatte ich zumindest in meinem Fall
> keinerlei Vorteile aber einen höheren Speicherverbrauch (vtable im Ram)
> YMMV though :-)

Gibt es ohne virtual member functions überhaupt eine vtable?

> Namespaces, Templates etc. verwende ich aber dennoch gerne. Klassen
> auch, wenn diese Sinn machen. Ringbuffer, Fifo, Stack etc.

Ebenso. Auch critical sections sind in C++ ganz praktisch, mit allem 
Code im constructor/destructor. Kann man nicht versehentlich hängen 
lassen.

Sehr nützlich: buffer template, beispielsweise für Puffer von UARTs und 
anderen Kommunikationsschnittstellen.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> sowieso Static sein werden, dann hatte ich zumindest in meinem Fall
>> keinerlei Vorteile aber einen höheren Speicherverbrauch (vtable im
>> Ram) YMMV though :-)
>
> Gibt es ohne virtual member functions überhaupt eine vtable?

Nein. Eine vtable wird für eine Klasse nur angelegt, wenn sie virtuelle 
Funktionen enthält oder von einer solchen Klasse abgeleitet ist.

> @Magnus:

Das ist mein Nachname.

> Willst du ein Beispiel eines solchen Flash-Smartpointers online
> stellen? Klingt interessant, wobei mir da aber zum eigenständigen
> Umsetzen das Wissen wohl nocht fehlt.

Ich habe so eine Klasse schon vor einer Weile mal geschrieben, und 
dasselbe auch für EEPROM. Leider gibt es ein Problem, das die 
Verwendbarkeit meines Erachtens doch ziemlich einschränkt. Der operator 
-> funtkioniert mit der Klasse nicht, da der sich in C++ nicht so 
überladen läßt, wie ich das bräuchte.

> Ebenso. Auch critical sections sind in C++ ganz praktisch, mit allem
> Code im constructor/destructor.

Stimmt. Ich benutze da gerne eine einfacher interrupt-lock-Klasse, deren 
Destruktor automatisch die Interrupts freigibt.

> Sehr nützlich: buffer template, beispielsweise für Puffer von UARTs und
> anderen Kommunikationsschnittstellen.

Ja.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Gibt es ohne virtual member functions überhaupt eine vtable?
>
> Nein. Eine vtable wird für eine Klasse nur angelegt, wenn sie virtuelle
> Funktionen enthält oder von einer solchen Klasse abgeleitet ist.

Eben. Ist also auch zunächst kein Problem.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Zumindest bei Verwendung der Option qc-sections im Linker und
> function-sections im gcc werden Funktionen ohne Klasse nur gelinkt,
> wenn diese verwendet werden. Bei Klassen werden nach meinem Sym-File
> alle Methoden der Klasse gelinkt, unabhängig davon, ob ich diese
> Verwende oder nicht.

Bei mir (gcc 4.2.1, binutils 2.18) funktioniert das tadellos, sowohl
mit normalen als auch mit Klassenmethoden. Beim Compiler gebe ich
-ffunction-sections, beim Linker --gq-sections an. Die Methoden stehen
alle in der gleichen Quelldatei, werden aber - wie gewünscht - nur bei
Verwendung gelinkt.

Ich programmiere zwar bisher meine AVRs ausschließlich in C, aber
vielleicht stellt sich am Ende dieses Threads heraus, dass C++ doch
die bessere Sprache ist ;-)

Ich bin auf jeden Fall auf weitere Für- und Gegenargumente gespannt.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus wrote:

> Ich habe so eine Klasse schon vor einer Weile mal geschrieben, und
> dasselbe auch für EEPROM. Leider gibt es ein Problem, das die
> Verwendbarkeit meines Erachtens doch ziemlich einschränkt. Der operator
> -> funtkioniert mit der Klasse nicht, da der sich in C++ nicht so
> überladen läßt, wie ich das bräuchte.

Ich nehme an, du sprichst auf den Zugriff innerhalb von struct
an. Das glaub ich dann schon, das das knifflig bis unmöglich
wird (soll ja auch effizient sein)

Für einen einfach Bytepointer sollte aber sowas ausreichen
(nur um Michael mal in die Richtung zu bringen)
Das ganze beruht auf operator overloading

class FlashPtr
{
  public:
    FlashPtr()            :  m_pPtr( 0 )   {}
    FlashPtr( void* Ptr ) :  m_pPtr( Ptr ) {}
    FlashPtr( int Ptr )   :  m_pPtr( (unsigned char*)Ptr )  {}
    FlashPtr( const FlashPtr& arg ) : m_pPtr( arg.m_pPtr ) {}

    unsigned char operator* () const
      { return pgm_read_byte( m_pPtr ); }

  private:
    unsigned char* m_pPtr;
}

int main()
{
  FlashPtr a = 0x123;
  unsigned char b;

  b = *a;
}

Das ganze wird man sinnvollerweise noch in ein Template umwandeln,
wobei man für das Template Spezialisierungen für Byte und Word
macht, da dort ja mit pgm_read_byte, bzw pgm_read_word gearbeitet
werden kann, während im allgmeinen Fall, ja mit Speicherblöcken
gearbeitet werden muss (pgm_read_block, bzw. das Äquivalent mit
einer Schleife und pgm_read_byte).

Besonders interessant wird das Ganze natürlich, so man es sich
leisten kann, wenn man da Klassen für SRAM Pointer, Flash Pointer
und EEPROM Pointer hat, die alle von einer gemeinsamen Basisklasse
abgeleitet sind und virtuelle Operatoren erhalten. Dann kommt man
dem Traum ein Stückchen näher, dass sich eine Funktion die so
einen Pointer erhält, nicht mehr darum kümmern muss, wohin der
Pointer jetzt wirklich zeigt. Das Pointer Objekt weiss schon ganz
von alleine, was es mit der in ihm gespeicherten Adresse anfangen
muss. So gesehen realtiviert sich dann der verbrauchte Speicher
für die vtable wieder, da man keine unterschiedlichen verwendenden
Funktionen für SRAM, Flash bzw. EEPROM mehr braucht. Nur leider
liegt halt die vtable im SRAM und das tut weh.

Disclaimer: Schnell mal so hingeschrieben, da werden also noch
eine Menge Fehler drinnen sein.

Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yalu wrote:
> Bei mir (gcc 4.2.1, binutils 2.18) funktioniert das tadellos, sowohl
> mit normalen als auch mit Klassenmethoden. Beim Compiler gebe ich
> -ffunction-sections, beim Linker --gq-sections an. Die Methoden stehen
> alle in der gleichen Quelldatei, werden aber - wie gewünscht - nur bei
> Verwendung gelinkt.

Sieht so aus, als müsste ich in diesem Falle meine Toolchain updaten 
bzw. genauer suchen, warum dies bei mir nicht klappt. Danke für die 
Info!

Und danke für die Idee hinsichtlich eines Smart-Pointers. Als Fingerzeig 
zum selber denken wirklich das RIchtige! Bei C++ muss ich Python-Mensch 
noch viel lernen :-)

cu, mz

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich nehme an, du sprichst auf den Zugriff innerhalb von struct

Ja.

> Das glaub ich dann schon, das das knifflig bis unmöglich
> wird (soll ja auch effizient sein)

Der Operator-> müßte halt einen regulären Zeiger auf die Struktur 
zurückgeben und hat dann mit dem eigentlichen Zugriff nichts mehr zu 
tun. Ich weiß nicht mal, ob ein Lese- oder ein Schreibzugriff auf das 
Zielobjekt erfolgen, oder gar eine Memberfunktion davon aufgerufen 
werden soll. Auch gibt es keine Möglichkeit herauszufinden, auf welches 
Element.
Mir ist keine Möglichkeit eingefallen, das Problem zu umgehen. Wenn man 
eine Proxy-Klasse einführt, hat man wieder genau dasselbe Problem.

> Das ganze wird man sinnvollerweise noch in ein Template umwandeln,
> wobei man für das Template Spezialisierungen für Byte und Word
> macht, da dort ja mit pgm_read_byte, bzw pgm_read_word gearbeitet
> werden kann, während im allgmeinen Fall, ja mit Speicherblöcken
> gearbeitet werden muss (pgm_read_block, bzw. das Äquivalent mit
> einer Schleife und pgm_read_byte).

Genau so macht das meine Implementation. Die kann ich heute abend mal 
zusammen mit der fürs EEPROM posten,wenn ich dran denke.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich mir so die Nützlichkeit einiger Features anhöre, die man in C++ 
hätte, würde ich mir schon wünschen, dass es in ferner Zukunft mal sowas 
wie eine avr-libc++ gibt :-)

Aber, um Gottes Willen, Jörg Wunsch und David und wie sie nicht alle 
heißen: Halst euch nicht noch mehr Arbeit auf.

PS: Der FlashPtr-Klasse könnte man noch den operator++ bzw. operator-- 
hinzufügen ;)

Autor: Rolf Magnus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang mal meine bisherige Implementation eines Templates 
pgmspace_ptr mit Doxygen-Doku für deutsch und englisch, mit allen 
Operatoren und mit überladenen Wrappern für gängige 
Standard-C-Funktionen. Dasselbe habe ich auch noch für den EEPROM.
Bisher habe ich es allerdings noch nicht oft eingesetzt.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum ist es denn auf einmal so still hier? Hat mein Code euch die 
Sprache verschlagen? ;-)

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir warten darauf, dass jemand mit einer kompletten vollständigen 
ausdokumentierten C++ Library vorbeikommt. :-)

*wartet

Autor: Michael Z (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rolf,

ich bin noch dabei, deine pgmspace-Classe zu verstehen. Sind auf jeden 
Fall gute Anregungen dabei. Danke dir!

Desweiteren experimentiere ich ein bisschen hinsichtlich der weiteren 
Verwendung von Klassen, also wo sind die Grenzen der (für mich) 
sinnvollen Einsetzbarkeit. Was macht z, B. hinsichtlich Speichergröße, 
Komfort und Flexibilät mehr Sinn: 1) Einer I2C-Funktione jedesmal die 
Adresse übergeben, 2) diese per #define in einem config-File zu 
definieren oder 3) diese beim init() der Klasse zu übergeben und dann 
als private Variable zu speichern.

Warum sollte ich ganz low Level Klassen verwenden? Was kann mir 
Vererbung hier bringen? Meiner Meinung nach wenig.

Fragen, das sich mir hierbei stellen:
1) Kann ich eine Methode einer Klasse aus einer ISR aufrufen, wenn ich 
diese volatile deklariert habe? (noch nicht getestet)

2) Für Ausgabe etc. arbeite ich viel mit Funktoren, d. h. eine 
Handler-Funktion z. B. für writeChar(char c) wird für die Ausgabe zur 
Laufzeit registriert. Über diese werden dann alle Ausgaben 
weitergeleitet.

Wie kann ich über Funktoren Methoden eines Klassenobjektes registrieren? 
Geht bei mir (noch) nicht....


cu, mz

cu, mz (Auch die RAM-Frage, s.o. will noch untersucht werden )

Autor: Daniel Widmann (danielwidmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rolf,
die Klasse sieht echt interressant aus. Das ist ein gutes Beispeil 
dafür, wie man Klassen sehr komfortabel einsetzen kann, ohne das es viel 
mehr Speicher braucht als das Gleiche in C (Falls es überhaupt mehr 
Speicher benötigt).

Traumhaft wäre wum Beispiel auch eine EEPROM-Zeiger-Klasse, die den 
Zugriff auf einen externen EEPROM-Baustein genau so ermöglich, wie auf 
das interne EEPROM. Als Programmierer wäre man dann deutlich Flexiebler.
Ich denke es gibt auch noch eine ganze Menge von Dingen die Sich 
besonders elagant mit Klassen beschreiben lassen.

Aber zurück auf den Boden der Tatsachen, es gibt leider (noch) keine 
avr-libc++. Aber warum eigentlich? Aus technischer Sicht gibt es 
eigentlich keine größeren Problem. Durch den gcc hat praktisch jeder 
schon einen c++ Compiler installiert. Auch der in C++ geschriebene Code 
benötigt im Vergleich zu C ähnlich viel Speicher (falls sauber 
programmiert wird). Trotzdem fürht c++ bei Mikrocontrollern eher ein 
Nischendasein. Vieleicht, weil es keine KLassenbibiothek giebt (--> ein 
Teufelskreis g)

Da sich ein Klassenbibiothek nicht einfach aus dem Ärmel schütteln 
lässt, wäre es zumindest ein Anfang, wenn man die Klassen von 
verschiedenen Leuten sammelt. Vieleicht gibt es noch mehr Leute wie 
Rolf, die schon das ein oder andere Programmiert haben.

Auch wäre es sicher hilfreich, wenn man ein paar Relgen hätte, was man 
auf Mikrocontrollern machten sollte und was besser nicht. Denn das 
Meiste, was man zu C++ findet, bezieht sich auf PCs.


Gruss Daniel

Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Widmann wrote:

> Vieleicht gibt es noch mehr Leute wie
> Rolf, die schon das ein oder andere Programmiert haben.

Mal 2 kleine template basierte Buffer-Klassen:

Ringbuffer: http://mz.incunabulum.de/avr/RBuffer.h
FiFo: http://mz.incunabulum.de/avr/Fifo.h

Erstere stammt aus einem Forum und wurde leicht modifiziert, letztere 
dann durch mich daraus abgeleitet.

cu, mz

Autor: Jorge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin eigentlich C++-Fan. Argumente dagegen:

- es fragt sich jetzt warum das meiste an systemnahen Programmen unter 
Unix in "C" geschrieben ist

- auf eine fremdhergestellte C++-Klasse kann man sich nicht 100%ig 
verlassen ausser vielleicht wenn man sie selbst hergestellt hat und auch 
dann nicht

- objektorientiert konnte man in "C" und Assembler schon immer machen 
nur C++ hat den einen oder anderen erst dazu gebracht.

- man kann via C++ nicht über seinen Schatten springen muss also 
trotzdem Probleme systematisch angehen

- vmt im RAM geht halt nicht anders wegen der Architektur (oder doch?). 
Das heisst von 1kByte RAM bleiben 25 Bytes für Variablen, dann noch die 
32 Allzweckregister

- alles in C zu können ist die grössere Kunst

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> - es fragt sich jetzt warum das meiste an systemnahen Programmen unter
> Unix in "C" geschrieben ist

Weil es bisher noch keine brauchbaren Libs gibt und weil viele die 
Vorteile nicht kennen oder weil sie glauben, C++ bedeute einen riesigen 
Overhead.

> - auf eine fremdhergestellte C++-Klasse kann man sich nicht 100%ig
> verlassen ausser vielleicht wenn man sie selbst hergestellt hat und
> auch dann nicht

Warum spricht das gegen C++? Das ist doch bei C genauso.

> - objektorientiert konnte man in "C" und Assembler schon immer machen
> nur C++ hat den einen oder anderen erst dazu gebracht.

Vor allem ist es in C++ schon eingebaut, wodurch es sich viel eleganter 
formulieren läßt. Hast du schon mal versucht, in C wirklich 
objektorientiert zu programmieren? Das wird schnell ziemlich häßlich.

> - man kann via C++ nicht über seinen Schatten springen muss also
> trotzdem Probleme systematisch angehen

Auch hier sehe ich nicht, warum das gegen C++ sprechen sollte. Klar löst 
C++ meine Probleme nicht für mich, aber C tut das auch nicht.

> - vmt im RAM geht halt nicht anders wegen der Architektur (oder doch?).

Sicher ginge das. Nicht die Architektur, sondern der Compiler ist hier 
das Problem. gcc ist voll auf von-Neumann-Architekturen ausgerichtet. Er 
weiß nichts von verschiedenen Speichertypen. Deshalb gibt es ja den 
ganzen Umstand mit pgm_read_*. Die vtables werden intern einfach als 
Variablen angelegt. Wenn man direkt auf eine Variable zugreift, muß die 
aber zwingend im RAM stehen, und irgendwo mitten in C++-Compiler kann 
man eben nicht einfach so ein pgm_read_word einpflanzen.

> Das heisst von 1kByte RAM bleiben 25 Bytes für Variablen, dann noch die
> 32 Allzweckregister

Hm? Die vtable braucht pro virtueller Funktion und Klasse einen Zeiger.

> - alles in C zu können ist die grössere Kunst

Du denkst also, daß es in C schwieriger ist, spricht gegen C++?

Autor: Joachim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wäre schön, wenn das hier nicht in eine Diskussion darüber ausartet,
ob C++ nun gut oder schlecht oder besser als C ist.
Es gibt wie so oft auf beiden Seiten Vor- und Nachteile und C++
ist sicher nicht kompromisslos auf Mikrocontrollern einzusetzen.
Manchmal nimmt man aber ja vielleicht auch die Nachteile einer
Seite in Kauf da man sich dadurch auch anderswo Vorteile schafft.

Darum fände ich es schön, wenn hier Code oder Beiträge erscheinen,
die C++ auf Mikrocontrollern in einem sinnvollen Rahmen erlauben
oder einem wirklich auf Grund der Objektorientierung "das Leben
leichter machen". Das Ganze hat natürlich auch "Gummibandgrenzen" :-)
Ich lerne nämlich gerne dazu :-)

@Rolf:
Den Beitrag von Jorge hatte ich nicht gegen C+++ verstanden, sondern
ich verstand es als "Bremse" gegen den doch sehr verbreiteten Hype
um C++ (die Lösung und alle ist toll und rosa).  gähn
Deine Argumente stimmen schon zu großen Teil, aber es ist nichts
wirkliches dafür oder dagegen, eher philosophisch.

Habt ein schönes Wochenende.
Joachim

Autor: sous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> - alles in C zu können ist die grössere Kunst

Ja eben: Kunst.
Besser als Kunst wäre jedoch Handwerk!

Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerade durch Zufall per RSS gefunden:

http://avr-cpp-lib.sourceforge.net/

Eine C++ Bibliothek für einige AVRs mit rudimentärem (?) New/Delete 
Support etc. Allerdings muss ich zugeben, dass ich die Details noch 
nicht so richtig begriffen habe...

cu, mz

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Weil es bisher noch keine brauchbaren Libs gibt und weil viele die
> Vorteile nicht kennen oder weil sie glauben, C++ bedeute einen riesigen
> Overhead.

Und weil die real existenten C++ Libs eine nicht unerhebliche Chance 
beinhalten, zuerst einmal diese Libs debuggen und fehlende oder falsche 
Dokumentation durch eingehendes Studium unlesbaren Quellcodes ersetzen 
zu müssen.

> Warum spricht das gegen C++? Das ist doch bei C genauso.

Nicht ganz. Die klassischen Systeminterfaces sind meist recht alt, 
relativ sauber definiert und stabil. Bei C++ Libs wird alle paar Jahre 
eine neue Sau durch's Dorf getrieben und du darfst von vorne anfangen.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Eine C++ Bibliothek für einige AVRs mit rudimentärem (?) New/Delete
> Support etc.

new und delete sind auch nicht weiter schwierig.

> Allerdings muss ich zugeben, dass ich die Details noch nicht so richtig
> begriffen habe...

Ist auch etwas schwierig, beim "User Guide in Estonian" ;-)
Im Ernst: Der Code sieht aus, als sei er von einem Java-Programmierer 
geschrieben, der mit C++ gerade erst angefangen hat. Er macht viele 
Dinge so, wie sie in Java Konvention oder gar vorgeschrieben sind, die 
aber überhaupt nicht denen der C++-Standardlib entsprechen und teilweise 
in C++ auch komplett falsch sind. Beispiel:
StaticArray()
{
    BaseArray<DataType, SizeType, DataType[array_capacity]>();
}

Hier wird im Konstruktor von StaticArray ein lokales BaseArray der 
gleichen Kapazität angelegt und gleich wieder zerstört. Wohl eher nicht 
das, was der Autor im Sinne hatte.

Und dann so seltsame Dinge wie ein operator() für std::string, der dann 
einen C-String zurückliefert. Dafür fehlt beim Array der eigentlich 
obligatorische operator[] ganz.

>> Warum spricht das gegen C++? Das ist doch bei C genauso.
>
> Nicht ganz. Die klassischen Systeminterfaces sind meist recht alt,
> relativ sauber definiert und stabil. Bei C++ Libs wird alle paar Jahre
> eine neue Sau durch's Dorf getrieben und du darfst von vorne anfangen.

Der Thread hier bezieht sich speziell auf AVR und darauf, eine eigene 
C++-Lib zu schreiben. Da gibt's keine alten "klassischen 
Systeminterfaces", und ob sich die C++-Libs ändern, hätte man dann 
selbst in der Hand.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So wie ich das als C++-Laie* sehe hat C++ das Problem dass es zu viele 
Möglichkeiten und zu wenig allgemein beachtete Konventionen gibt. Sicher 
kann man mit C++ schön sauberen Code schreiben, dummerweise hat jeder 
eine andere Vorstellung davon WIE sauberer C++-Code auszusehen hat, und 
durch die Flexibilität von C++ führt das dazu dass fast jedes Projekt 
völlig anders aussieht. Das fängt schon bei so elementaren Dingen wie 
Strings an: der eine verwendet MFC-Strings, der andere STL-Strings, der 
nächste QT-Strings, wieder ein anderer die klassischen C-Strings, und 
manch einem ist das nicht gut genug und er schreibt sich seine eigene 
String-Klasse. Ich will nicht in der Haut dessen stecken der diese 
Projekte kombinieren muss.

* kann C++ halbwegs lesen, hab aber nie Bedarf gesehen es anzuwenden

Autor: asdf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas:

100% ACK!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.