__blackjack__ hat geschrieben: ↑Dienstag 25. Mai 2021, 20:29
@LukeNukem: Die C-Standardbibliothek in der C++-Standardbibliothek ist teilweise überflüssig, ja. Nämlich da wo die C++ als Sprache oder die C++-Standardbibliothek eigenes hat was das gleiche macht.
Das ist zweifellos nicht ganz flashc, man hätte einige der alten Zöpfe abschneiden können. Allerdings war die Abwärtskompatibilität zu C eines der wesentlichen Designziele von C++ und ist bis heute zweifellos einer der wichtigsten Gründe, warum C++ so erfolgreich ist. Und dann...
__blackjack__ hat geschrieben: ↑Dienstag 25. Mai 2021, 20:29
Du hast ja beispielsweise bei der Ausgabe auch den C++-Weg gewählt statt `printf()` zu verwenden.
Ja, weil mein Beispielcode auf einem fetten Eisen läuft. Denn auch mit Optimierung mit -Os und strip(1) ist das C++-Binary laut size(1) wesentlich größer, das C-Binary ist hier "a" und das C++-Binary "b":
Code: Alles auswählen
text data bss total filename
621 1803 8 2432 a
1533 3795 280 5608 b
Nun, die Dateigrößen unterscheiden sich nicht wesentlich, aber die Größen der einzelnen Segmente sehr wohl. Wie gesagt, auf einer richtigen Maschine spielt das keine Rolle, aber in meiner Freizeit spiele ich manchmal auch gerne mit kleinen 8-Bit-SOC wie den Atmel (jetzt Microchip) AVRs, zum Beispiel dem AtTiny13. Der hat maximal 20 MHz Taktfrequenz, gerade mal ein Kilobyte Flash-Speicher für den Code und nur jeweils 64 Bytes RAM und EEPROM. Du kannst Dir sicherlich vorstellen, daß auf so einem winzigen SOC die Größe der Codesegmente eine wichtige Rolle spielt, weswegen man auf etliche schicke Features von C++ leider verzichten und bei anderen sehr genau darauf achten muß, was und wie man es nutzt. Templates gehen ziemlich gut, aber schon die Vererbung krankt bei zeitkritischen Dingen daran, daß sie für Methodenaufrufe auf die interne Virtual Method Table zugreifen muß, was zwar nicht viele, dennoch aber Prozessortakte kostet. Dynamische Sachen wie Exceptions und die STL kannst Du auf so kleinen Dingern natürlich auch knicken... aber wenn man sich auf die "guten Features" beschränkt, ist der optimierte C++-Code nicht größer als ein äquivalenter C-Code. Diese Umstände sind übrigens der Grund dafür, warum es im Forum von Mikrocontroller.net immer noch häufig zu echauffierten Diskussionen zwischen den Verfechtern von Assembler, C und C++ kommt und der Sinn der Objektorientierung oft immer noch ganz grundsätzlich in Frage gestellt und zum Teil sogar rundheraus abgelehnt wird. Daß es in den Neunzigern einige... Scharlatane gegeben hat, die ihrem alten C-Code lediglich ein paar Klassen spendiert und wie die Maikäfer alles vererbt haben, was nicht schnell genug weglaufen konnte, hat allerdings auch nicht unbedingt zur Popularität oder gar Beliebtheit der OOP in diesen Kreisen beigetragen...
Übrigens, für den Fall, daß jemand von Euch sich mal in dem anderen Forum umsehen möchte: Python ist dort von der Moderation und vielen Anwendern zwar wohlgelitten und oft auch gerne gesehen, allerdings gibt es dort noch eine sehr hartnäckige Fraktion, für die Python pures Teufelszeug ist. Die Syntax mit dem Whitespace, das ist ja wie Fortran77, und überhaupt ist Python viel zu langsam und zu bloaty und zu unverstanden und alle, die Python mögen, sind irgendwelche pickeligen Skriptkiddies, die es nicht besser können und ihren Code sowieso nur zusammenkopieren, ohne ihn zu verstehen. Okay, das wird dort auch gerne über Arduino und Co. gesagt, und, ach ja: Micropython ist natürlich eine Ausgeburt der Hölle! Nur daß Ihr Bescheid wißt, nicht daß es hinterher heißt, ich hätte Euch nicht gewarnt.
__blackjack__ hat geschrieben: ↑Dienstag 25. Mai 2021, 20:29
Was wäre denn für Dich ein Grund `malloc()` in C++ zu verwenden?
Hier? Weil ich's kann -- und weil ich etwas zeigen wollte, nämlich die Idee hinter der Objektorientierung. Da wollte ich nicht, daß der Code
zu weit von einander abweicht, um halbwegs vergleichbar zu bleiben. Auf einem AtTiny gehen natürlich auch Funktionen wie (s)printf() nicht so wirklich, das Parsen des Formatstrings und die Verarbeitung von varargs sind viel zu teuer -- deswegen muß man auf größeren AVRs dann auch derlei Funktionen mit eigenen Compilerschaltern ausdrücklich aktivieren. Ähnliches gilt für malloc()... bei 64 Byte (nicht KByte, Byte!) RAM kannst Du dynamische Speicherallokation und Ähnliches gepflegt knicken, und auch auf größeren AVRs ist das eine ziemlich riskante Nummer. Nicht selten steht der Entwickler in solchen Fällen dann vor der Aufgabe, externen Arbeitsspeicher anzubinden und bestimmte Codesegmente mit eigenen Linkerskripten in diesen externen Speicher zu verschieben, siehe dazu beispielsweise auch:
https://www.nongnu.org/avr-libc/user-manual/malloc.html -- HF!