Arduino und struct gefallen sich nicht !

[Ralph S. (jjflash)]

Norbert schrieb:
> Es geht um die zusätzliche TCS Funktionalität mit ESC(0 und ESC(B (für
> Grafikzeichen), welche alle VT100 oder besser haben. Eben auch die
> richtigen Hardware-Dinger, falls man da mal dran möchte. Die können
> nämlich mit UTF-8 nicht wirklich etwas anfangen und der Bildschirm sieht
> dann aus wie ausgekotze Buchstabensuppe.

okay, das schaue ich mir einmal genauer an (weil ich das so nicht auf 
dem Schirm hatte) und danke für den Hinweis.

Arduino F. schrieb:
> Das fängt an bei den selbstgewählten Bezeichnern für alle möglichen
> Dinge.
> 1. Keine Unterstriche in Bezeichnern. (also kein xyz_t)
> 2. Datentypen beginnen mit einem Großbuchstaben (also kein xyz_t)
> 3. Andere, mit Kleinbuchstaben ( DatenType variable = 23;)
> 4. KamelHöckerSchreiweise
> 5. Kein typedef für Strukturen, eigentlich gar kein typedef mehr.
> "typedef" ist eine Sammlung unnützer Buchstaben.

puuuuh, das ist für mich natürlich "harter Tobak", weil das seit 40 
Jahren meine Sache so ist. Werde ich mir mal gucken ob ich mich 
"überwinden" kann, weil es genau diese Schreibweise ist, die ich 
"eigentlich" nicht sonderlich mag.

Aaaaber: das kann man ja ändern.

Arduino F. schrieb:
> Die Aufteilung in *.h und *.cpp vermeiden.
> Warum?
>
> Methoden in *.h only sind per default inline.
>
> Man hat nur eine Datei zu pflegen und nicht zwei.

Für so etwas wurde mir vor Jahren "der xyz" vesohlt, weil ich nur eine 
Datei hatte und habe mir das nun nach *.h / *.c ... oder *.h / *.cpp 
angewöhnt.
Eigentlich unfassbar, dass Konventionen nicht mehr gültig sind, wenn sie 
in die Jahre kommen.

Hmmmm. ich war gerade dabei, das HardwareSerial (CH32V003) zu patchen 
und muß das an mehreren Dateien gleichzeitig machen, besonders der 
Ringbuffer beim Lesen, interruptgesteuert ist etwas "eklig" zu 
realisieren und ich glaube ich lass das dann doch lieber, weil ich 
niemandem erklären kann oder will, wie ich das dann gemacht habe.

Hier gehe ich dann glaube ich doch eher den Weg, dass es eine zweite 
Library geben wird, die dieselben Klassen und Objekte wie extendedSerial 
hat, aber in einer Library namens v003extendedSerial vorhanden ist.

Einziger Unterschied wird dann sein, dass das #include anderst heißt und 
die Objektinstanziierung.... Rest wird gleich bleiben.

Vielen Dank, dass du dir das angesehen hast

[Ralph S. (jjflash)]

Norbert schrieb:
> Ach um die Programmiersprache geht's doch gar nicht. Auch nicht um die
> Farbe. ;-) Py war nur gerade zur Hand, bequem und schnell.
>
> Es geht um die zusätzliche TCS Funktionalität mit ESC(0 und ESC(B (für
> Grafikzeichen), welche alle VT100 oder besser haben. Eben auch die
> richtigen Hardware-Dinger, falls man da mal dran möchte. Die können
> nämlich mit UTF-8 nicht wirklich etwas anfangen und der Bildschirm sieht
> dann aus wie ausgekotze Buchstabensuppe.
>
> Für eine (ausschließliche) Emulation braucht man das natürlich nicht.
> Die halten sich sowieso kaum an Standards.

jetzt hast du mich echt "angetriggert" mit deiner "Idee" und den alten 
7-Bit DEC Standard hatte ich nicht mehr auf dem Schirm... weil ich jetzt 
meinen letzten Urlaubstag hier auf Gran Canaria habe... aber das Wetter 
eine Woche schlecht war (und heute auch), werde ich mich doch 
tatsächlich diesem mal widmen und sehen, wie sich das bei mir 
präsentiert, wenn ich TCS noch in die AnsiOut-Klasse implementiere....

Hrmpf, man hat ja in einem südlichen Land mit Barbetrieb, Pool und 
Strand ja nix anderes zu tun, als Elektronik zu machen...

[Arduino F. (Firma: Gast) (arduinof)]

Ralph S. schrieb:
> Für so etwas wurde mir vor Jahren "der xyz" vesohlt, weil ich nur eine
> Datei hatte und habe mir das nun nach *.h / *.c ... oder *.h / *.cpp
> angewöhnt.
> Eigentlich unfassbar, dass Konventionen nicht mehr gültig sind, wenn sie
> in die Jahre kommen.

Ja.
Das wird sich auch wieder ändern!
z.B. mit den modules von C++23 braucht es keine *.h mehr.
Also dann nur *.cpp
Funktioniert bei mir schon, auch für AVR.
Aber der Arduino Builder spielt da noch so richtig mit.
Tuts, aber hakelt.

[Ralph S. (jjflash)]

Arduino F. schrieb:
> Ja.
> Das wird sich auch wieder ändern!
> z.B. mit den modules von C++23 braucht es keine *.h mehr.
> Also dann nur *.cpp
> Funktioniert bei mir schon, auch für AVR.
> Aber der Arduino Builder spielt da noch so richtig mit.
> Tuts, aber hakelt.

:-) ich glaube ich sollte anfangen, das was ich habe (eben für V003) mal 
alles zusammenfassen und so lassen wie es ist, denn es ist eine Menge 
schon an Code und dann nur "punktuell" ändern: Wie du vor längeren Posts 
gesagt hast: die Arduino-User sind nicht dumm und diejenigen, die dann 
wirklich den Billigst 32-Bit Chip nutzen wollen (unter Arduino) werden 
dann auch mit dem zurechtkommen, wie es ist. Soooooo viel anderst ist es 
dann auch nicht!

[Oliver S. (oliverso)]

Ralph S. schrieb:
> puuuuh, das ist für mich natürlich "harter Tobak", weil das seit 40
> Jahren meine Sache so ist. Werde ich mir mal gucken ob ich mich
> "überwinden" kann, weil es genau diese Schreibweise ist, die ich
> "eigentlich" nicht sonderlich mag.

Erste Grundregel zu Styles in Programmiersprachen: es gibt nur genau 
einen einzigen richtigen: den, den man selber benutzt. Alle anderen sind 
grundlegend und komplett falsch…
>
> Aaaaber: das kann man ja ändern.

Muß man aber nicht, erst recht nicht bei Code, den außer eine, selber 
niemand jemals zu Gesicht bekommt.

> Arduino F. schrieb:
>> Die Aufteilung in *.h und *.cpp vermeiden.

Wenn die Modules in C++ irgendwann mal sinnvoll bzw. überhaupt 
funktionieren, kann man da eventuell drüber nachdenken. Das wird aber 
noch eine ganze Weile dauern, bis das soweit ist. Bis dahin wird es in 
C/C++ selbstverständlich weiterhin Header- und sourcedateien geben. Es 
geht gar nicht ohne.

Oliver