Nach der Lektüre vieler Beiträge hier im Forum über den (Un)Sinn von C++ auf AVRs, versuche ich trotzdem mal positiv an diese Sache heranzugehen: Kann man eigentlich sowas wie
1 | |
für avr-c++ "nachbasteln"?
|
Anzeige
|
AVR und __propertyNach der Lektüre vieler Beiträge hier im Forum über den (Un)Sinn von C++ auf AVRs, versuche ich trotzdem mal positiv an diese Sache heranzugehen: Kann man eigentlich sowas wie
für avr-c++ "nachbasteln"? Ja, GCC ist Freie Software. Du kannst dir die Quellen nehmen, nach belieben verrenken und erweitern und dir dann deinen Compiler daraus erzeugen. Voilà.
Gast
#2932120
Das ist weniger ein AVR-Problem, eher ein Problem mit Spracherweiterungen außerhalb des C++ Standards.. Google findet einige Hinweise zu dem Thema. Oliver Johann L. schrieb: > Ja, GCC ist Freie Software. Du kannst dir die Quellen nehmen, nach > belieben verrenken und erweitern und dir dann deinen Compiler daraus > erzeugen. Voilà. Na, dann werde ich das mal so machen, Viola Mit "nachbasteln" meinte ich eher einen mehr oder weniger guten Würgeraund. Sonst hätte ich "reinbasteln" für "integrieren" geschrieben. Oliver schrieb: > Das ist weniger ein AVR-Problem, eher ein Problem mit > Spracherweiterungen außerhalb des C++ Standards. Hm, dacht' ich mir schon. War halt nur so 'ne Idee von mir. Ralf G. schrieb: > Mit "nachbasteln" meinte ich eher einen mehr oder weniger guten > Würgeraund. Durch einen Text-Prozessor? m4 oder was hausbackenes aus perl oder python oder awk oder... Johann L. schrieb: > oder...
Bis hierher habe ich mal was probiert. 'template' war eine Sackgasse. Angeregt duch diesen Thread: Beitrag "C++ für Embedded: ab welchen Prozessormerkmalen?" und nicht verschreckt durch Yalu X. ;-) Beitrag "Re: C++ für Embedded: ab welchen Prozessormerkmalen?" möchte ich mal das hier zur Diskussion stellen:
Gast
#2941225
Warum ist das weniger Sackgasse als ein Template? Weil man es "kunstvoll" per Macro nachbaut? Ich finde das ja immer ganz toll: "wenn ich die nicht für kleinen Speicher geeigneten Features von C++ verwende, dann geht's nicht. Also kann ich C++ nicht verwende!" Nein, falscher Schluß! Dann muß man das weglassen, was nicht geht! Was glaubt ihr denn, was von
übrig bleibt? 3 Befehle:
Obwohl da Templates, Overloading und ... benutzt werden. Die "property"'s von MSC ermöglichen es quasi Variablezugriffe zu überladen. Statt der Variablen prop, werden jeh nachdem ob lesender/schreibender Zugriff deren Setter/Getter-Methoden gerufen, die z.B. auch direkt die AVR Flash-/EEPROM-Zugriffsroutinen sein könnten. cplusplus schrieb: > Warum ist das weniger Sackgasse als ein Template? > Weil man es "kunstvoll" per Macro nachbaut? Kann schon sein... Nur: Ich kann die Operatoren in Templates für den entsprechenden Datentyp überladen. Variablen des selben Datentypes würden dann die gleichen Funtionen aufrufen. Deshalb von mir die Definition eines neuen Datentypes speziell für eine Variable. Ob das jetzt besser geht oder man es lassen sollte ... ich wollte einfach mal was probieren. > Was glaubt ihr denn, was von > Test.Wert=PORTB | (uint8_t)42; > übrig bleibt? 3 Befehle: > lds r16,PORTB > ori r16,0x2A ;42 > sts PORTB,r16 Eben nicht! Die Änderungsmethode soll ja noch mehr machen, als nur den Wert zuweisen. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|