Buch: Realtime C++

[IJustWannaKnow (Gast)]

Kennt jemand diese Werk, ist es empfehlenswert? Ich habs geschenkt 
bekommen. MFG.

[Walter T. (nicolas)]

IJustWannaKnow schrieb:
> Ich habs geschenkt
> bekommen. MFG.

Dann kannst Du Dir ja selbst eine Meinung bilden.

[Cyblord -. (cyblord)]

Walter T. schrieb:
> IJustWannaKnow schrieb:
>> Ich habs geschenkt
>> bekommen. MFG.
>
> Dann kannst Du Dir ja selbst eine Meinung bilden.

Dann müsste er es ja lesen. Heute sitzt man vor einem Buch, geht dann 
aber ins Netz und fragt wie dieses Buch so ist. Irre!

[Yalu X. (yalu) (Moderator)]

Es könnte ja sein, dass beim Öffnen des Buchs eine aggressive Giftspinne
herausspringt. Da fragt man besser diejenigen, die das vielleicht schon
erlebt haben ;-)

[esd-impuls (Gast)]

Achtung, Bücher mache Geräusche beim zuschlagen. Nicht erschrecken :D

[IJustWannaKnow (Gast)]

Ich mag euch. Ich musste schmunzeln...

ne ernsthaft. meine Erfahrung in dem Gebiet reicht nicht aus um zu 
beurteilen ob das Buch gut ist.

[Yalu X. (yalu) (Moderator)]

IJustWannaKnow schrieb:
> ne ernsthaft. meine Erfahrung in dem Gebiet reicht nicht aus um zu
> beurteilen ob das Buch gut ist.

Einer, der schon alles zum Thema weiß, wird vermutlich dieses Buch nicht
mehr lesen und kann deswegen ebenfalls kein Urteil darüber abgeben.

Während du das  Buch liest, wirst du spüren, ob dein Wissen zunimmt oder
nicht. Sollte das während der ersten 20% nicht der Fall sein, kannst das
Buch ja jederzeit wieder weglegen.

[void (Gast)]

Es ist schon etwas her, dass ich das Buch gelesen habe. Aber ich 
versuche es trotzdem mal.

Der Autor Christopher Kormanyos erschien mir recht praxisnah zu sein und 
seine Strukturierung des Buches fand ich gut. Zum einen erklärt er vom 
Einstieg her gut worauf es bei der Verwendung von C++ auf µC ankommt und 
baut dann schrittweise auf dem Wissen auf. Er verwendet zwar einen 
bestimmten µC Typen in dem Buch, erklärt aber wie es generisch für 
verschiedene µC gemacht werden kann/soll und vor allem verfängt sich 
nicht in "bei diesem µC Typen muss man jetzt so uns so in dieser und 
genau dieser IDE des Herstellers klicken" wie es gerne bei verschiedenen 
Büchern im Arduino/RPi Kontext passiert.
Sehr gut finde ich auch, dass alle Code-Beispiele auch für mehr 
µC-Targets auf seinem github-Konto zu finden sind.
https://github.com/ckormanyos/real-time-cpp

Zum C++. Die Sprachkonstrukte von C++ welche kleinen, hardwarenahen Code 
ermöglichen stellt Christopher klar da und auch die verschieden Vorteile 
von C++ gegenüber reinem C.
In meiner Praxiserfahrung jedoch kann C++ diesen Vorteil nicht 
ausspielen, da in der Entwicklung von low-level Treibern, HAL u.ä. eher 
hardware-orientierte Personen arbeiten welche sich eben nicht in die 
Tiefe mit den Besonderheiten von neuen C++ Sprachkonstrukten auskennen 
und daher eher C verwenden.

Beispiel: Mit C++ zur Kompile-Zeit Dinge prüfen zu können was mit C so 
nicht geht ist ein klarer Vorteil. Aber eben diese Möglichkeit bringt 
auch Komplexität mit sich, welche a) man kennen und beherrschen und b) 
am Ende wieder in irgendeinem Headerfile verstecken möchte wie man es 
bei C schon mit endlosen #define-Orgien gemacht hat...

// C
#include <mcu_registers.h>
(...)
  // Enable the timer0 compare match a interrupt.
  TIMSK0 = 0x02;

// C++
#include <mcu_registers_cpp.h>

template<typename addr_type,
         typename reg_type>
struct reg_access_dynamic final
{
(...)
  static void reg_set(const addr_type address, const reg_type value) { *reinterpret_cast<volatile reg_type*>(address)  = value; }
(...)
};

const std::uintptr_t address =
  reinterpret_cast<std::uintptr_t>(&register_timsk0);
(...)
  // Enable the timer0 compare match a interrupt.
  reg_access_dynamic<std::uintptr_t,
                     std::uint8_t>::reg_set(address, UINT8_C(0x02));

Yalu X. schrieb:
> Einer, der schon alles zum Thema weiß, wird vermutlich dieses Buch nicht
> mehr lesen und kann deswegen ebenfalls kein Urteil darüber abgeben.

Dann oute ich mich hiermit mal als jemand, der nicht schon alles zum 
Thema wusste. ;-)

[So so... (Gast)]

Bitte mal fuer nicht-C++ler: Soll das das Aequivalent sein?

[mh (Gast)]

So so... schrieb:
> Bitte mal fuer nicht-C++ler: Soll das das Aequivalent sein?

Wenn das sein C++ Äquivalent sein soll, macht er etwas falsch.

[void (Gast)]

mh schrieb:
> Wenn das sein C++ Äquivalent sein soll, macht er etwas falsch.

Im MCAL der Register-Zugriffs-Abstraktion sieht das schon so aus.
Auf Applikations-Seite natürlich schön aufgeräumt.
https://github.com/ckormanyos/real-time-cpp/blob/master/examples/chapter06_14/src/app/led/app_led.cpp

Und wenn du es besser kannst, schreib halt selber ein Buch oder höre auf 
zu meckern.

[mh (Gast)]

void schrieb:
> mh schrieb:
>> Wenn das sein C++ Äquivalent sein soll, macht er etwas falsch.
>
> Im MCAL der Register-Zugriffs-Abstraktion sieht das schon so aus.
> Auf Applikations-Seite natürlich schön aufgeräumt.
> 
https://github.com/ckormanyos/real-time-cpp/blob/master/examples/chapter06_14/src/app/led/app_led.cpp
>
> Und wenn du es besser kannst, schreib halt selber ein Buch oder höre auf
> zu meckern.

Kannst du mir in ein paar Worten erklären was da abstrahiert wird bzw. 
was genau der Vorteil dieser MCAL ist?

Soweit ich das in den Beispielen sehen kann, wird da "toggle eine LED" 
auf 20 Dateien augeteilt und hinter einem Haufen Templates versteckt.

(Ich habe aufgehört in dem repo rumzustöbern, als ich eine Datei 
"cstdint" gefunden habe. Die Datei enthält, was man erwartet und sorgt 
danut für undefined behavior.)

[void (Gast)]

mh schrieb:
> Soweit ich das in den Beispielen sehen kann, wird da "toggle eine LED"
> auf 20 Dateien augeteilt und hinter einem Haufen Templates versteckt.

Genau. Und in klassischem C hättest du ein Haufen von #defines in header 
files versteckt. ;-)


> Kannst du mir in ein paar Worten erklären was da abstrahiert wird bzw.
> was genau der Vorteil dieser MCAL ist?

Der MCAL (oder auch HAL) abstrahiert erstmal nur die Hardware-Zugriffe. 
Soweit kein Unterschied zu einem MCAL in C.
Im Buch wird dann aber auf die spezifischen Vorteile eingegangen, welche 
die Implementierung eines MCAL in C++ bringen kann. Die da z.B. wären 
zur Kompile-zeit Berechnungen ausführen zu lassen und stringente 
Typ-Prüfung.

  // C
  static RCC_OscInitTypeDef RCC_OscInitStruct;
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEFreq = 16000000; // 16MHz Quarz am externen Oszillator 'HSE'
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLFreqOut = 960000000; // 96MHz PLL out fuer CPU-Takt

  if(HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    /* Initialization Error */
    Error_Handler();
  }

Mit ein bischen wenig Glück erzeugt der C-Kompiler hier kein Fehler beim 
kompilieren und der Code läuft. Es wird zur Laufzeit im RAM die Struktur 
RCC_OscInitStruct angelegt, belegt Speicher und Pointer darauf werden 
hin und her übergeben beim Funktionsaufruf. (naja, noch schlimmer wäre 
wenn alle Parameter einzelnd übergebenen würden.)
Und später fällt dir noch auf, dass die CPU mit 16MHz und nicht wie 
gedacht mit 96MHz läuft.

  // C++
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEFreq = 16000000; // 16MHz Quarz am externen Oszillator 'HSE'
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLFreqOut = 960000000; // 96MHz PLL out fuer CPU-Takt

  mcal::RCC::Osc.config(&RCC_OscInitStruct);

Der C++-Kompiler wirft den Fehler "reg_set REG_PLL_MULT out of bound", 
weil er für die PLL-Multiplier-Bits den Wert 60 ermittelt hat jedoch der 
von dir oben so verschmähte reg_set() wusste, dass nur 4bit für die 
PLL-Multiplier-Bits vorgesehen sind.
Ist nicht schlimm, Benutzter Fehler halt 960MHz anstatt 96MHz 
geschrieben. Es war eine Null zuviel der Kompiler hat es gemerkt. Nach 
der Korrektur beim zweiten Kompilieren errechnet der C++-Kompiler den 
Wert für den die PLL-Multiplier-Bits passen zur kompile-Zeit aus (6) und 
schreibt am Ende nur den/die Register-Zugriff(e) in das Executable. Kein 
belegter RAM, keine Pointer-Übergabe, kein Funktionsaufruf.

Das Buch erklärt jetzt wie man dies in C++ hinbekommt.
Nicht erwähnt ist aber natürlich, dass Personen benötigen werden die 
diese C++ Eigenheiten kennen und auch nutzten können und wollen.

[mh (Gast)]

void schrieb:
> Der C++-Kompiler wirft den Fehler "reg_set REG_PLL_MULT out of bound",
> weil er für die PLL-Multiplier-Bits den Wert 60 ermittelt hat jedoch der
> von dir oben so verschmähte reg_set() wusste, dass nur 4bit für die
> PLL-Multiplier-Bits vorgesehen sind.

Dann erklär mal, wie das mit dem von dir "gezeigten"

static void reg_set(const addr_type address, const reg_type value);

gehen soll.

[Erich H. (Gast)]

void schrieb:
> Es wird zur Laufzeit im RAM die Struktur RCC_OscInitStruct angelegt,
> belegt Speicher und Pointer darauf werden hin und her übergeben beim
> Funktionsaufruf.

..bei ausgeschalteter (globaler) Optimierung?

[fltr (Gast)]

Man sollte auch erwähnen, dass der Autor auf die Unterschiede ASM/C/C++ 
eingeht und auch Disassmblies vergleicht. Und schneidet C++ oft 
mindestens so gut ab wie ASM eines erfahrenen Entwicklers.

[P. S. (namnyef)]

Ich weiß nicht was euer Problem ist. Das ist kein Roman, der einem 
gefällt oder eben nicht. Das ist ein Sachbuch. Und da kann man sich ja 
ruhig mal umhören, ob es etwas taugt. Es sollte doch wohl auf der Hand 
liegen, dass man diese Einschätzung möglicherweise nur eingeschränkt 
selbst vornehmen kann. Schließlich liest man ein Sachbuch in der Regel 
um etwas dazu zu lernen und hat auf dem jeweiligen Gebiet unter 
Umständen eher weniger Erfahrung.

[void (Gast)]

mh schrieb:
> Dann erklär mal

Nein. Entweder du ließt das Sachbuch, oder eben nicht. Ich erkläre es 
dir nicht.

Erich H. schrieb:
> ..bei ausgeschalteter (globaler) Optimierung?
 Ich habe nicht behauptet, dass ein C-Kompiler da gar nichts machen kann 
(Ja natürlich kannst du z.B. ihn bitten mal inlining zu verwenden). Aber 
eben kann ein C++-Kompiler mehr. Das erklärt dieses Buch.

P. S. schrieb:
> Ich weiß nicht was euer Problem ist.

Das Problem von manchen Leuten hier im Forum ist, dass Sie ewig gestrige 
Nörgler sind. Hätte ich vorher wissen sollen, dass etwas zu dem Buch zu 
sagen hier total vergebene Zeitverschwendung war. Damit bin ich dann 
Mal raus.

[Paul Peter Schm. (Gast)]

Lol, wie immer selten dämliche Kommentare hier.
Ich denke er er hat Kommentare erwartet wie, es ist gut geschrieben, die 
beispiele sind brauchbar und haben hand und Fuß..
Ich WETTE!!! wenn er geschrieben hätte, er leist gerade Buch XYZ und er 
fidnet es total gut.
, DANN!!! kämen kritiken wie
Die verwendeten Beispiele im Buch sind einfach nur schlecht.
Es enthält irre viele FEhler
Stattdessen würde ich lieber Buch `XYZ lesen.



Merke..in diesem Forum gibt es IMMeR NUR DUMME und NEGATIVE Kommentare, 
und auch die Moderatoren machen dabei mit!!


Wenn man also eine brauchbare Antwort auch eine Frage bekommen will, 
muss sie so formuliert werden, das mit dummen Antworten brauchbare 
Antworten erzielt werden


Am besten noch mit ein paar Beleidigungen gespickt und mit den Hinweisen 
das er offenbar die Deutsche Rechtschreibung nicht beherrscht

[Paul Peter Schm. (Gast)]

"Das Problem von manchen Leuten hier im Forum ist, dass Sie ewig 
gestrige
Nörgler sind. Hätte ich vorher wissen sollen, dass etwas zu dem Buch zu
sagen hier total vergebene Zeitverschwendung war. Damit bin ich dann
Mal raus."



HHAHAH, ich hatte nur die eesten zwei Kommentare gelesen als ich meinen 
TExt verfasst hatte und eben erst den letzten:-)
ICh sehe wir sind der gleichen Meinung hehe

Getroffen und versenkt:-)

[Marcel (Gast)]

Hmm, das Buch klinkt eigentlich sehr interessant.

Lohnt es sich das jetzt noch zu erwerben oder wird vieles durch 
C++17/C++20 obsolet/kürzer und einfacher schreibbar. Kann das jemand 
einschätzen?

[Marcel (Gast)]

Ahh, ich fand einen Download. Ich werde es mir mal zu Gemüte führen!

[mh (Gast)]

void schrieb:
> mh schrieb:
>> Dann erklär mal
>
> Nein. Entweder du ließt das Sachbuch, oder eben nicht. Ich erkläre es
> dir nicht.

Ich brauch das Buch nicht lesen. Es ist technisch unmöglich, das von dir 
angepriesene Verhalten mit dieser Funktionssignatur umzusetzen.

void schrieb:
> Das Problem von manchen Leuten hier im Forum ist, dass Sie ewig gestrige
> Nörgler sind.

Auf wen genau beziehst du dich und wo wird Genörgelt?

[Flick12 (Gast)]

Marcel schrieb:
> Ahh, ich fand einen Download. Ich werde es mir mal zu Gemüte
> führen!

Wo und mit welchem Suchbergriff(en)?

[Lutz (Gast)]

Nach illegalen Downloads wirst du wohl schon selber suchen müssen.

Mich würde aber auch interessieren, ob es ein relativ aktuelles und 
empfehlenswertes, deutschsprachiges Buch speziell zum Thema C++ auf 
Mikrocontrollern gibt. Der Winter kommt...

[Marcel (Gast)]

Flick12 schrieb:
> Marcel schrieb:
>> Ahh, ich fand einen Download. Ich werde es mir mal zu Gemüte
>> führen!
>
> Wo und mit welchem Suchbergriff(en)?

Ich suchte einfach nur Realtime C++ auf Google und fand dann auf der 
erste Seite: 
https://www.academia.edu/37116671/Real-Time_C_Efficient_Object-Oriented_and_Template_Microcontroller_Programming_Second_Edition

Das Angebot erscheint mir nicht illegal. Ich las aber auch nicht die 
AGBs sondern meldete mich mit einem Íst mir egal Google Account bei 
denen an und bekam den Download.

Sollte das doch kein Seriöser Anbieter sein, diesen Post bitte Löschen!

[Paul Peter Schm. (Gast)]

warum war jetzt eigentlich der ASM Kommentar so schlimm.
Warum wird nicht gleich der zweite dämliche  Beitrag von Walter 
gelöscht?
Cyblord etc..
alles dumme Kommentare die gleich weitere Idioten anziehen

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Paul Peter Schm. schrieb:
> warum war jetzt eigentlich der ASM Kommentar so schlimm.

moby hat hier Hausverbot.
Beim zweiten Teil deines Post geb ich dir zu 100% recht.

[Gustl B. (gustl_b)]

Paul Peter Schm. schrieb:
> alles dumme Kommentare die gleich weitere Idioten anziehen

Wie kann ich helfen?

Echtzeitanwendungen gehören ausschließlich in Hardware. Vielleicht noch 
in ein FPGA, aber niemals als Software in eine CPU.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Gustl B. schrieb:
> Echtzeitanwendungen

Echtzeit heist nicht, dass es sofort passieren muss.
Sondern, dass es garantiert innerhalb eines gesteckten Zeitraumes 
passieren muss.
Sowas wie die Regulierungsstäbe müssen innerhalb von 1min voll in den 
Reaktor fahren, sonst Feuerwerk ;)
Oder von Erkennung Überdruck bis Ventilöffnung dürfen max 10ms vergehen.
Sonst brauchsten neuen Kessel.

[Slickflick (Gast)]

Kann es sein das Technik komplett gegen die Natur des Menschen ist? 
Meiner Erfahrung nach sind gerade Infos oder andere "Nerdwesen" 
unglaublich oft unsozial und frustriert.

Was hier im Forum extrem zur Geltung kommt. Was so eine lockere 
Buch-Frage hier ausgelöst hat, unfassbar.

[Carl D. (jcw2)]

Mw E. schrieb:
> Gustl B. schrieb:
>> Echtzeitanwendungen
>
> Echtzeit heist nicht, dass es sofort passieren muss.
> Sondern, dass es garantiert innerhalb eines gesteckten Zeitraumes
> passieren muss.
> Sowas wie die Regulierungsstäbe müssen innerhalb von 1min voll in den
> Reaktor fahren, sonst Feuerwerk ;)
> Oder von Erkennung Überdruck bis Ventilöffnung dürfen max 10ms vergehen.
> Sonst brauchsten neuen Kessel.

Viele verstehen unter Echtzeit eben
  "so schnell wie möglich"
Richtiger ist aber
  "so schnell wie nötig "

[Slickflick (Gast)]

Carl D. schrieb:
> Mw E. schrieb:
> Gustl B. schrieb:
> Echtzeitanwendungen
>
> Echtzeit heist nicht, dass es sofort passieren muss.
> Sondern, dass es garantiert innerhalb eines gesteckten Zeitraumes
> passieren muss.
> Sowas wie die Regulierungsstäbe müssen innerhalb von 1min voll in den
> Reaktor fahren, sonst Feuerwerk ;)
> Oder von Erkennung Überdruck bis Ventilöffnung dürfen max 10ms vergehen.
> Sonst brauchsten neuen Kessel.
>
> Viele verstehen unter Echtzeit eben  "so schnell wie möglich"
> Richtiger ist aber  "so schnell wie nötig "

Es heißt ja auch Echtzeit... Und nicht Schnellzeit. Die deutsche Sprache 
ist da schon sehr genau.

[Carl D. (jcw2)]

Slickflick schrieb:
> Carl D. schrieb:
>> Viele verstehen unter Echtzeit eben  "so schnell wie möglich"
>> Richtiger ist aber  "so schnell wie nötig "
>
> Es heißt ja auch Echtzeit... Und nicht Schnellzeit. Die deutsche Sprache
> ist da schon sehr genau.

Wer versteht schon Worte ;-)

[Johannes S. (Gast)]

habe mal gelesen das auch eine IBM AS400 echtzeitfähig ist. Solange die 
Lohnabrechnung rechtzeitig am Monatsende fertig ist.

[Carl D. (jcw2)]

Johannes S. schrieb:
> habe mal gelesen das auch eine IBM AS400 echtzeitfähig ist. Solange die
> Lohnabrechnung rechtzeitig am Monatsende fertig ist.

Echtzeit hängt immer vom Problem ab.

[Gustl B. (gustl_b)]

Gustl B. schrieb:
> Paul Peter Schm. schrieb:
>> alles dumme Kommentare die gleich weitere Idioten anziehen
>
> Wie kann ich helfen?

Ich dachte das sei Hinweis genug. War es leider nicht. Ich werde in 
Zukunft die passenden Tags verwenden. [/troll]

[Walter T. (nicolas)]

Nebenbei: Das Buch ist über Springerlink verfügbar. Wer also eine 
Bibliothekskarte einer teilnehmenden Hochschule hat, kann sich die 
Meinung zum Buch kostenlos bilden.

Ich nehme auch an, dass das "geschenkt" des TO genau daher kommt.

[Einer K. (Gast)]

Kann bitte irgendwer mal dem Mobber erklären, dass das hier ein C++ Buch 
Thread ist?
Und dass sich hier wohl niemand für sein ASM Gedöns interessiert.
Es fehl am Platze ist!

Zumindest mir geht es so.
Mich interessiert C++ auf µC schon.

Ja, mich stört der Störenfried.
Und meine Zuneigung zu ASM schrumpft dadurch auch.
Ich muss mir nur vorstellen, dass man so bekloppt werden kann, wenn man 
sich auf ASM fixiert.

Ist es so, dass einen ASM so bekloppt macht, so nervig?

[M.A. S. (mse2)]

Arduino Fanboy D. schrieb:
> Ist es so, dass einen ASM so bekloppt macht, so nervig?
Es hat den Anschein.  :)

[Einer K. (Gast)]

Dann will ich nix von dem Zeugs...
Da ist so manche Crackhure vernünftiger.

Außerdem hilft mir der ASM Turn, in meiner kleinen Arduino Welt, nicht 
wirklich weiter. Da bin ich lieber voll auf dem C++ Puder.
AVR, SAM, ESP, STM32, um nur die üblichsten zu nennen, mit denen ich es 
da zu tun habe

Dann auch noch den "Kendryte K210".
Dessen Flash mit ASM voll zu bekommen, ist ein 10 Jahres Projekt.

Bitte falsch verstehen!
Ich habe nix gegen Assembler.
Selber schon ordentlich den Rüssel rein gehalten.

[Robert K. (Firma: Zombieland) (rko)]

void schrieb:
> Genau. Und in klassischem C hättest du ein Haufen von #defines in header
> files versteckt. ;-)
darum geht es aber nicht, sondern einzig und allein um die 
Ausführungsgeschwindigkeit und da ist C gegenüber C++ in der Regel 
besser.
Weiterhin ist #define eine von vielen Möglichkeiten; viele Wege führen 
nach Rom.

void schrieb:
> Zum C++. Die Sprachkonstrukte von C++ welche kleinen, hardwarenahen Code
> ermöglichen stellt Christopher klar da und auch die verschieden Vorteile
> von C++ gegenüber reinem C.
ja schön, C++ mag Vorteile in der Syntax haben, aber so gesehen könntest 
Du auch gleich zu 'hardwarenahen):' Java übergehen - das wäre dann 
wenigstens plattform unabhängig und auch Deine Kaffeemaschine wäre dann 
realtime-fähig :-)

> In meiner Praxiserfahrung jedoch kann C++ diesen Vorteil nicht
> ausspielen, da in der Entwicklung von low-level Treibern, HAL u.ä. eher
> hardware-orientierte Personen arbeiten welche sich eben nicht in die
> Tiefe mit den Besonderheiten von neuen C++ Sprachkonstrukten auskennen
> und daher eher C verwenden.
LOL, wenn C++ in Bezug auf Realtime wirklich was bringen würde, könnte 
man die lowlevel Treiber, etc. ja jetzt ganz locker auch in C++ umsetzen 
... macht man aber nicht, weil C eben doch die bessere Wahl dafür ist.
Noch besser als C in Bezug auf Realtime ist dann Assembler - nur das 
kann ja keiner mehr und will aufgrund der Komplexität auch niemand mehr.
C++ realtime ist einzig und allein dem Umstand geschuldet, daß man 
aufgrund der Speicherresourcen keinerlei Einschränkungen mehr hat wie 
das früher der Fall war.
C++ ist eine nette Sprache, aber man muß sie nicht überall und für alles 
zwanghaft anwenden.

@ TO
Viel Spaß beim Buchverkauf

[Robert K. (Firma: Zombieland) (rko)]

Arduino Fanboy D. schrieb:
> Es fehl am Platze ist!
>
> Zumindest mir geht es so.
> Mich interessiert C++ auf µC schon.
>
> Ja, mich stört der Störenfried.
> Und meine Zuneigung zu ASM schrumpft dadurch auch.
> Ich muss mir nur vorstellen, dass man so bekloppt werden kann, wenn man
> sich auf ASM fixiert.

das paßt total in die heutige Zeit - mit Kanonen auf Spatzen schießen 
geht natürlich auch und scheint wohl auch voll in zu sein :-)) LOL

[Einer K. (Gast)]

Robert K. schrieb:
> sondern einzig und allein um die
> Ausführungsgeschwindigkeit und da ist C gegenüber C++ in der Regel
> besser.
Das ist doch nur eine Durchhalteparole für C++ Verweigerer.
Gerade was das Register und Portgefummel angeht, liegen beide gleich 
auf. Selbst mit Assembler, und das auch noch Typesicher und ohne Makros.

Klar auf den kleinen µC fehlen viele gehobene C++ Features, wie 
Container und das ganze RuntimeTypeHandling. Schicksal.

Sicherlich kann man sich auch blöd anstellen, denn auch in C++ kann man 
Mist bauen. Bietet sogar mehr Möglichkeiten, sowohl im positiven, als 
auch im negativen.
Aber davon abgesehen bietet C keine nennenswerten Vorteile.

Robert K. schrieb:
> C++ ist eine nette Sprache, aber man muß sie nicht überall und für alles
> zwanghaft anwenden.
Was postulierst du da einen Zwang hin?
Auch ist sie nicht "nett", es dürfte die schwierigste Sprache für µC 
sein. Zumindest ich kenne keine komplexere.
Es ist einfach die mächtigere Sprache!
Unterstützt viel mehr Paradigmen.
Wenn man nur die Sicherheit von Referenzen gegenüber Zeigern betrachtet, 
hat man schon genügend Vorteil für eine Entscheidung.

OK, wenn man damit nicht klar kommt, oder dazu neigt Mist zu bauen, dann 
sollte man vielleicht die Finger von C++ lassen und sich mit C oder ASM 
beschäftigen.

Und sowieso...
Soll doch jeder seine Lieblingssprache nutzen, wenn er/sie/es die Wahl 
hat.
Da muss man keine verdrehten Argumente an den Haaren herbeizerren um 
anderen die Arbeit madig zu machen.
Schon gar nicht den Priester raus kehren!
Die ganzen Priester, egal, welchen Verein sie vertreten, sind angefüllt 
mit "Glaubenssätzen" die man bitte ja nicht auf Wahrheitsgehalt 
überprüfen darf.
Nicht immer, aber so häufig, dass man eine Regel draus ableiten kann.


Auch:
Das ist gar nicht die Frage in diesem Thread.
Sondern im Buch dreht es sich darum WIE man C++ auf µC RICHTIG nutzt.

[Robert K. (Firma: Zombieland) (rko)]

Arduino Fanboy D. schrieb:
> Das ist doch nur eine Durchhalteparole für C++ Verweigerer.
> Gerade was das Register und Portgefummel angeht, liegen beide gleich
> auf. Selbst mit Assembler, und das auch noch Typesicher und ohne Makros.
>
> Klar auf den kleinen µC fehlen viele gehobene C++ Features, wie
> Container und das ganze RuntimeTypeHandling. Schicksal.
nix Schicksal, da kann man dann C anwenden (wenn man es überhaupt kann) 
und es wird ja auch immer noch gemacht.
Was meinst Du denn weshalb die ganzen Treiber und andere 
Echtzeitanwendungen in C programmiert wurden?

Arduino Fanboy D. schrieb:
> Sicherlich kann man sich auch blöd anstellen, denn auch in C++ kann man
> Mist bauen. Bietet sogar mehr Möglichkeiten, sowohl im positiven, als
> auch im negativen.
> Aber davon abgesehen bietet C keine nennenswerten Vorteile.
Der Vorteil von C ist, daß ich eben nicht Microcontroller benötige, die 
noch Anforderungen an Speicher, etc. stellen ... und genau da müßte 
Deine Argumentation ansetzen.
Wir sind eine Wegwerfgesellschaft und die paar Euro mehr für 'bessere' 
Hardware spielt überhaupt keine Rolle mehr - und genau deswegen gibt es 
C++

Arduino Fanboy D. schrieb:
> Was postulierst du da einen Zwang hin?
Das ist der Zwang sich mit C++ befassen zu müssen ...

Arduino Fanboy D. schrieb:
> Auch ist sie nicht "nett", es dürfte die schwierigste Sprache für µC
> sein. Zumindest ich kenne keine komplexere.
> Es ist einfach die mächtigere Sprache!
Die Sprache ist einfacher in der Syntax als C und viele Konzepte wie 
Fenster lassen sich mit C++ einfacher umsetzen (dafür gibt es in C dann 
GTK+ etc. und das hat es dann in sich).
Aus Marketinggründen wird komischerweise C++ dann als Wunderwaffe für 
alles und nichts angepriesen.
Es gibt noch 1000 andere Sprachen und auch die haben eine Berechtigung.

Arduino Fanboy D. schrieb:
> Wenn man nur die Sicherheit von Referenzen gegenüber Zeigern betrachtet,
> hat man schon genügend Vorteil für eine Entscheidung.
Sorry, aber wenn es um Sicherheit geht, dann ist ADA die erste Wahl - 
diese Sprache wird immer noch im militärischen Bereich angewandt und das 
sagt dann wohl alles ?!

Arduino Fanboy D. schrieb:
> OK, wenn man damit nicht klar kommt, oder dazu neigt Mist zu bauen, dann
> sollte man vielleicht die Finger von C++ lassen und sich mit C oder ASM
> beschäftigen.
Alle Sprachen kannst Du sowieso nicht beherrschen - solche Leute können 
von allen ein bißchen und sind mit Vorsicht zu genießen.
Ein guter C Programmierer wird niemals ein guter C++ Programmierer und 
umgekehrt auch nicht - Du ruinierst Dir Dein Sprachwissen, wenn Du 
ähnliche Sprachen machst.
Richtig, bleib bei C++ aber versuche nicht C++ in den Himmel zu loben 
... auch andere Sprachen haben Ihre Berechtigung.

Arduino Fanboy D. schrieb:
> Soll doch jeder seine Lieblingssprache nutzen, wenn er/sie/es die Wahl
> hat.
> Da muss man keine verdrehten Argumente an den Haaren herbeizerren um
> anderen die Arbeit madig zu machen.
> Schon gar nicht den Priester raus kehren!
Den Priester kehrst Du raus, indem Du weiter oben davon sprichst, daß es 
bei C keine Vorteile gegenüber C++ gibt - das ist schlicht falsch.

Arduino Fanboy D. schrieb:
> Die ganzen Priester, egal, welchen Verein sie vertreten, sind angefüllt
> mit "Glaubenssätzen" die man bitte ja nicht auf Wahrheitsgehalt
> überprüfen darf.
genau und deshalb solltest Du solche Aussagen ebenfalls unterlassen 
sonst bist Du selbst ein Priester für C++
Bleib bei C++ und gut ist es.

Arduino Fanboy D. schrieb:
> Das ist gar nicht die Frage in diesem Thread.
> Sondern im Buch dreht es sich darum WIE man C++ auf µC RICHTIG nutzt.
Es geht um Realtime-Programmierung ... das muß nicht zwingend 
Microcontroller sein; wir wissen nicht was in dem Buch steht und selbst 
der TO hat es ja nicht gelesen.

[Einer K. (Gast)]

Robert K. schrieb:
> genau und deshalb solltest Du solche Aussagen ebenfalls unterlassen
> sonst bist Du selbst ein Priester für C++
> Bleib bei C++ und gut ist es.
Mein Sohn!
Natürlich darfst du meine Aussagen auf den Prüfstand stellen.
Aber nicht mir das Maul verbieten wollen.
Das ist arrogant und anmaßend.

Und noch mal:
Dieses ist ein Thread über ein C++ Buch.
Irgendwelche C und ASM Prister, auch du, sind gegen C++ eingestellt. Und 
müssen ihre "Meinung" hier in die Öffentlichkeit herausblasen. Tun dabei 
aber gleichzeitig, wenn auch indirekt kund, dass sie keine Ahnung davon 
haben. Und es auch nicht nutzen wollen.

Wie nennt man das, wenn eine Meinung herausgeblasen wird, die einer 
sachlichen Überprüfung nicht standhält?
Ein Irrtum?
Und nach hinweis, auf den Irrtum?
Eine Lüge? Oder Dummheit?

Da ist der Haken wo deine Argumentation krakelt.
Keine Sachargumente.
Keine Überprüfbarkeit.
Reine Stimmungsmache ohne Fakten.



Robert K. schrieb:
> und genau da müßte
> Deine Argumentation ansetzen.
Nee...
Deine Argumentation müsste anders aussehen!
Ich liefere dir mal ein fundiertes Argument gegen C++.

Das Interface/API einer geschickt in C abgefassten Library ist 
problemlos in C++ nutzbar. Der umgekehrte Weg ist mit C++ Libraries/APIs 
nicht so ohne weiteres möglich.


-------

Robert K. schrieb:
> Sorry, aber wenn es um Sicherheit geht, dann ist ADA die erste Wahl -
Sorry, aber das ist eine Ebene der Kommunikation, welche offensichtlich 
macht, dass du an einem Dialog nicht wirklich interessiert bist, sondern 
den Disput möchtest.
Du selber hast den Vergleich C zu C++ hier angestoßen.
Und ich sagte dir, dass alleine das Konzept der Referenzen schon genug 
Grund für einen Umstieg sein kann.
Anstatt das zugeben zu können, kommst du mit der Ablenkung ADA.

Nee...
So kommen wir nicht zusammen...

[Robert K. (Firma: Zombieland) (rko)]

Arduino Fanboy D. schrieb:
> Mein Sohn!
bin ich nicht - geht's auch sachlicher?

> Natürlich darfst du meine Aussagen auf den Prüfstand stellen.
> Aber nicht mir das Maul verbieten wollen.
> Das ist arrogant und anmaßend.
Quatschikowski!
Wenn Du hier postulierst, daß C keinerlei Vorteile gegenüber C++ hat und 
gleichzeitig auch noch herausstellt, daß jede Kritik an Deiner 
Lieblingssprache einer Verschwörung aka Priestertum gleichkommt, dann 
ist das eine Doppelmoral ... und die darf man sehr wohl auch als solche 
benennen, egal ob Dir das paßt oder nicht.

>
> Und noch mal:
> Dieses ist ein Thread über ein C++ Buch.
nein, es ist eine Frage zu einem C++ Buch ... einfach mal lesen!
Er fragt ob das Buch taugt, weil er sich das Lesen ersparen will, wenn 
es nicht taugt.
Nun ja, Lesen bildet war mal früher ):

> Irgendwelche C und ASM Prister, auch du, sind gegen C++ eingestellt.
Wieso das denn, ich habe nichts gegen C++
Ich finde lediglich die Kombination C++ und Realtime mehr als 
fragwürdig.
Dafür wurde diese Sprache nicht geschaffen und den Kreis muß man nicht 
zum Quadrat verbiegen.

> Und
> müssen ihre "Meinung" hier in die Öffentlichkeit herausblasen.
Ja allerdings, damit Personaler und andere Unwissende mal was dazu 
lernen.

> Tun dabei
> aber gleichzeitig, wenn auch indirekt kund, dass sie keine Ahnung davon
> haben. Und es auch nicht nutzen wollen.
Jo, das merkt man an Deinen Aussagen.

> Wie nennt man das, wenn eine Meinung herausgeblasen wird, die einer
> sachlichen Überprüfung nicht standhält?
> Ein Irrtum?
> Und nach hinweis, auf den Irrtum?
> Eine Lüge? Oder Dummheit?
Meine Behauptungen halten sachlich stand!
Du kannst jeden Treiber, der in C geschrieben wurde auch in C++ oder 
auch in Java, usw., usw. umprogrammieren - das steht Dir frei!
Es gibt Gründe warum man das nicht macht.
Die Ausführungsgeschwindigkeit wird in Abhängigkeit von der Hardware 
langsamer, bei guter Hardware merkst Du das nicht.
In Bezug auf Realtime ist gute Hardware aber nicht das 
Totschlag-Argument.

>
> Da ist der Haken wo deine Argumentation krakelt.
> Keine Sachargumente.
> Keine Überprüfbarkeit.
> Reine Stimmungsmache ohne Fakten.
die hast Du NICHT gelesen, ebenfalls hast Du nicht gelesen, daß der TO 
eine Frage gestellt hat.
Nichts gelesen, nichts begriffen, Hauptsache DAGEGEN


>
> Das Interface/API einer geschickt in C abgefassten Library ist
> problemlos in C++ nutzbar. Der umgekehrte Weg ist mit C++ Libraries/APIs
> nicht so ohne weiteres möglich.
nochmal bei Realtime geht es um Millisekunden in der 
Ausführungsgeschwindigkeit der Anwendung und nicht um die 
Programmiersprache und der Konvertierungsmöglichkeiten.
Auf mein Treiber in C Argument gehst Du natürlich nicht ein, schon klar.

> Du selber hast den Vergleich C zu C++ hier angestoßen.
Wer hat denn angefangen?
C hat gegenüber C++ keinerlei Vorteile - das war Deine Aussage ganz weit 
oben nachzulesen.

> Und ich sagte dir, dass alleine das Konzept der Referenzen schon genug
> Grund für einen Umstieg sein kann.
aber eben nicht in Bezug auf Realtime.

> Anstatt das zugeben zu können, kommst du mit der Ablenkung ADA.
weil es Fakt ist.
ADA wird im Sicherheitsbereich immer noch eingesetzt, obwohl es C++ 
gibt.
Auch C++ hat eben Schwächen - das heißt nicht, daß C++ deswegen generell 
schlecht ist ... es kommt eben auf die Anwendung an.

>
> Nee...
> So kommen wir nicht zusammen...
Wenn man nur von einer Sprache überzeugt ist so wie Du, dann ist das 
wohl so.

[Hans-Georg L. (h-g-l)]

Ich dachte in diesem Thread geht es um eine Buchbesprechung ...
OK, die Frage des TE "Ich habe ein Buch, wer liest es für mich ?" war 
wirklich blöd und die Kommentare dazu hat er damit auch verdient.

Aber es gibt hier wirklich keinen Thread über Embedded C++ wo keine 
Nebenkriegsschauplätze eröffnet werden.
C++ ist in den letzten Jahren dynamischer geworden und die verschiedenen 
Versionen machen das Lesen und Lernen aus Büchern und Beispielen auch 
nicht leichter. Aber es lohnt sich meiner Meinung nach auch dieses Buch 
zu lesen.

Mehr zur Performance von C++ gibt es hier :
http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf

[Einer K. (Gast)]

Robert K. schrieb:
> Wer hat denn angefangen?
Du natürlich.

Falls du das schon vergessen haben solltest, hier der Einsatz eines C 
Pristers:
Beitrag "Re: Buch: Realtime C++"

Robert K. schrieb:
> weil es Fakt ist.
Es gibt noch mehr Fakten!
z.B. "Oben ist nicht da wo unten ist!"
Hat das was mit C oder C++ zu tun?
Nee, ne?

Zeiger sind ein steter Quell von Ungemach in der C Welt, und nicht nur 
dort. Wenigstens das sollte einem jeden C Priester klar sein.
Ob es ADA gibt, oder wie verbreitet es ist, hat damit nichts zu tun.
Es ist einfach nur eine Nebelkerze.

[Johannes S. (Gast)]

Robert K. schrieb:
> Wieso das denn, ich habe nichts gegen C++
> Ich finde lediglich die Kombination C++ und Realtime mehr als
> fragwürdig.
> Dafür wurde diese Sprache nicht geschaffen und den Kreis muß man nicht
> zum Quadrat verbiegen.

Die Meinung kann man haben, das zeigt aber nur das du dich damit nicht 
richtig beschäfftigt hast. Vielleicht erstmal das Buch um das es hier 
geht leen?

[void (Gast)]

Robert K. schrieb im 
Beitrag "Re: Buch: Realtime C++"
> nein, es ist eine Frage zu einem C++ Buch ... einfach mal lesen!

Schon eine gewagte Aussage von jemandem der selbst behauptet es nicht 
gelesen zu haben.

> wir wissen nicht was in dem Buch steht
>  und selbst der TO hat es ja nicht gelesen. (..)
>
> Nichts gelesen, nichts begriffen


Da der einigste der das Buch gelesen hat wohl ich bin,
möchte ich mich noch bei Hans-Georg für die Weiterführende 
Literatur-Empfehlung bedanken.

Hans-Georg L. schrieb im 
Beitrag "Re: Buch: Realtime C++"
> Aber es lohnt sich meiner Meinung nach auch dieses Buch zu lesen.
> Mehr zur Performance von C++ gibt es hier:
> http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf

[Einer K. (Gast)]

Robert K. schrieb:
> Auf mein Treiber in C Argument gehst Du natürlich nicht ein, schon klar.
Doch doch!
Nur hast du es offensichtlich nicht als solches wahrgenommen...

Aber hier gerne nochmal:
Arduino Fanboy D. schrieb:
> Das Interface/API einer geschickt in C abgefassten Library ist
> problemlos in C++ nutzbar. Der umgekehrte Weg ist mit C++ Libraries/APIs
> nicht so ohne weiteres möglich.
Wenn eine API/Library in C genutzt werden soll, macht es Sinn diese in C 
statt in C++ zu schreiben.

Robert K. schrieb:
> nochmal bei Realtime geht es um Millisekunden in der
> Ausführungsgeschwindigkeit der Anwendung und nicht ....
Es geht auch um Speicherplatz auf µC.

Mir scheint, dass diese "Laufzeitnachteile" nur in deinem Kopf 
existieren. Einen Bezug zur Realität hat das eher nicht.
Vielleicht wäre es mal angesagt, dass du dafür ein belastbares Beispiel 
zeigst. So eine Art Diskussionsgrundlage.
Alternativ könnte ich dir auch ein Beispiel aus meiner Welt zeigen, wo 
du dir in C einen Ast abbrichst, um das so effizient hin zu bekommen.
So eine Art Schwanzvergleich.

[Robert K. (Firma: Zombieland) (rko)]

Arduino Fanboy D. schrieb:
> Du natürlich.
>
> Falls du das schon vergessen haben solltest
richtig, kam zwar nicht von Dir, aber ich mich darauf bezogen und dem 
Post stimmst Du ja zu:
> void schrieb:
>> Zum C++. Die Sprachkonstrukte von C++ welche kleinen, hardwarenahen Code
>> ermöglichen stellt Christopher klar da und auch die verschieden Vorteile
>> von C++ gegenüber reinem C.
denn, Deine Aussage:
Arduino Fanboy D. schrieb:
> Dann will ich nix von dem Zeugs...
> Da ist so manche Crackhure vernünftiger.
bezeugt ja, daß es nix besseres als C++ gibt - egal was, universelle 
Programmiersprache für alles ... also bitte, was willst Du denn 
überhaupt ?!

Arduino Fanboy D. schrieb:
> Mir scheint, dass diese "Laufzeitnachteile" nur in deinem Kopf
> existieren. Einen Bezug zur Realität hat das eher nicht.
> Vielleicht wäre es mal angesagt, dass du dafür ein belastbares Beispiel
> zeigst. So eine Art Diskussionsgrundlage.
Ich glaube Beispiele würden bei C++ Jüngern nix bringen.
Du kannst das u.a. unter Linux nachprüfen, wenn der KDE Desktop startet 
(in C++ programmiert) oder alternativ ein anderer Desktop, der in C 
programmiert wurde - insbesondere bei alten Rechner wird der Unterschied 
deutlich.
Aber ist klar, daß es jetzt 1000 Gegenargumente gibt.
Fakt ist und bleibt, daß z.B. Treiberprogramme nicht umgeschrieben 
werden in C++ entweder weil es von der Hardware gar nicht geht oder weil 
es u.a. Laufzeitprobleme gibt.

Arduino Fanboy D. schrieb:
> Alternativ könnte ich dir auch ein Beispiel aus meiner Welt zeigen, wo
> du dir in C einen Ast abbrichst, um das so effizient hin zu bekommen.
das ist richtig! Aber das ist deswegen kein Argument gegen C als 
Sprache.
Assembler würde ja auch noch gehen und das wäre dann noch besser ... nur 
eben eine Mammutaufgabe mit Assembler Inline Code.

[Robert K. (Firma: Zombieland) (rko)]

void schrieb:
> Schon eine gewagte Aussage von jemandem der selbst behauptet es nicht
> gelesen zu haben.
na ja und, was rätst Du jetzt dem TO ?
Ich würde ihm raten das Buch zu verkaufen, weil es bei dem Buch um kein 
Anfänger-Buch handelt und der TO ist Anfänger ... davon darf man 
ausgehen allein schon aufgrund der Fragestellung!

void schrieb:
> Da der einigste der das Buch gelesen hat wohl ich bin,
> möchte ich mich noch bei Hans-Georg für die Weiterführende
> Literatur-Empfehlung bedanken.
ja toll, C++ ler unter sich - aber irgendwann habt Ihr auch mal 
angefangen und bestimmt nicht mit Literatur für Fortgeschrittene in 
dieser Sprache bzw. Highend-Entwickler.
Deswegen Verkauf solange man noch Geld dafür bekommen kann.

[Einer K. (Gast)]

Robert K. schrieb:
> Ich glaube Beispiele würden bei C++ Jüngern nix bringen.
Ja, der Glaube, das ist der wahre Kern des Priesters.

Ja, mir scheint, es macht wirklich keinen Sinn....
Es ist schon ok, dass du dich dem nicht stellen möchtest.
Total menschlich, vielleicht etwas feige, aber doch menschlich.

[Robert K. (Firma: Zombieland) (rko)]

Arduino Fanboy D. schrieb:
> Ja, mir scheint, es macht wirklich keinen Sinn....
nö kann man nichts machen, gegen Argumente gibt's nur das übliche 
Gelaber

Arduino Fanboy D. schrieb:
> Total menschlich, vielleicht etwas feige, aber doch menschlich.
weiter oben habe ich die Gründe genannt - wer jede Programmiersprache 
beherrscht ist ein Hochstapler ... das geht nämlich nicht.

Fazit/Ratschlag für den TO:
Das ist kein Anfängerbuch ... so kann man sich als Anfänger am besten 
die Freude am programmieren zerstören.

[Hans-Georg L. (h-g-l)]

void schrieb:
> Da der einigste der das Buch gelesen hat wohl ich bin,
> möchte ich mich noch bei Hans-Georg für die Weiterführende
> Literatur-Empfehlung bedanken.

keine Sorge ich hab es auch gelesen ;-)

Auch sehr zu empfehlen:
Scott Meyers Effective C++ in an Embedded Environment

[Einer K. (Gast)]

Robert K. schrieb:
> weiter oben habe ich die Gründe genannt
Nein!
Du hast mehrfach behauptet, dass C++ langsamer in der Ausführung ist, 
als C.

Und jetzt bist du nicht bereit diese Behauptung durch ein 
praxisrelevantes Beispiel zu bestätigen.
Das ist das, was ich feige nenne.
Kneifen.
Behauptungen aufstellen, aber nicht bereit, den Nachweis zu führen.

[Robert K. (Firma: Zombieland) (rko)]

Hans-Georg L. schrieb:
> Auch sehr zu empfehlen:
> Scott Meyers Effective C++ in an Embedded Environment

Das kannst Du auch in C haben und wozu kaufen, wenn es als pdf 
preiswerter geht,
Free PDF Download ... so sieht es aus mit Büchern:
https://barrgroup.com/embedded-systems/books/embedded-c-coding-standard

[Robert K. (Firma: Zombieland) (rko)]

Arduino Fanboy D. schrieb:
> Nein!
> Du hast mehrfach behauptet, dass C++ langsamer in der Ausführung ist,
> als C.
und das stimmt ja auch ... nur merkst Du das je nach Anwendung und je 
nach Hardware überhaupt nicht mehr - genau dieses Argument pro C++ 
müßtest Du eigentlich bringen! Machst Du aber nicht, das muß ich machen 
):
Aus diesem Grund programmiert auch kein normaler Mensch mehr in 
Assembler selbst wenn es um hardwarenahe Anwendungen geht.

Arduino Fanboy D. schrieb:
> Und jetzt bist du nicht bereit diese Behauptung durch ein
> praxisrelevantes Beispiel zu bestätigen.
siehe oben, Linux und die verschiedenen Desktops - daran ist mir das 
aufgefallen und ein anderer Fakt ist, daß zumindest in der Anfangszeit 
von C++ erst einmal intern vom C++ Compiler als Zwischenschritt 
unsichtbar in C umcompiliert wurde, weil C++ eben eine Obermenge von C 
ist ... falls Dir Mengenlehre überhaupt was sagt.
Ich behaupte nicht, daß C++ schlecht ist, sondern daß je nach Anwendung 
auch andere Sprachen viel sinnvoller sein können ... was Du ja partout 
nicht einsiehst!
Im Realtime Bereich wäre für mich C++ nicht unbedingt die erste Wahl - 
aber hängt auch von ganz anderen Faktoren ab. Wenn z.B. Deine Firma, 
etc. das unbedingt so will, ist ja alles gut.

[Robert K. (Firma: Zombieland) (rko)]

Geil, meine Beiträge (z.B. auch Buchempfehlung mit Link) werden generell 
negativ bewertet nur weil sie von mir kommen ... wie dumm muß man hier 
eigentlich sein :-)

[Cyblord -. (cyblord)]

Robert K. schrieb:
> Geil, meine Beiträge (z.B. auch Buchempfehlung mit Link) werden generell
> negativ bewertet nur weil sie von mir kommen ... wie dumm muß man hier
> eigentlich sein :-)

Hier werden keine Beiträge bewertet, sondern Autoren.

[Johannes S. (Gast)]

Robert K. schrieb:
> und ein anderer Fakt ist, daß zumindest in der Anfangszeit
> von C++ erst einmal intern vom C++ Compiler als Zwischenschritt
> unsichtbar in C umcompiliert wurde, weil C++ eben eine Obermenge von C
> ist ...

Das hat der Bjarne mal 1985 gemacht weil er keinen C++ Compiler aus dem 
Hut zaubern konnte, aber mit deinen Vorurteilen bist du scheinbar auf 
diesem Stand stehen geblieben.

[Hans-Georg L. (h-g-l)]

Robert K. schrieb:
> Geil, meine Beiträge (z.B. auch Buchempfehlung mit Link) werden generell
> negativ bewertet nur weil sie von mir kommen ... wie dumm muß man hier
> eigentlich sein :-)

Das Thema hier ist ein Buch über Embedded C++ und du beantwortest eine 
Empfehlung für ein dazu passendes Buch  mit etwas völlig anderem. Da 
hättest du genauso gut einen Link auf ein Kochbuch posten können.

Kapere keine Threads, mache einen eigenen für deine Ergüsse auf.
PS die Bewertung war nicht von mir, kann sie aber verstehen.

[Einer K. (Gast)]

Robert K. schrieb:
> und das stimmt ja auch ..
Nachweis?

Robert K. schrieb:
> Linux und die verschiedenen Desktops
Das ist eine an den Haaren herbei gezerrte Nebelkerze.
Wir reden hier über µC, Echtzeit und C++.
Und du behauptest, dass C da besser da steht.
Lieferst aber keinen Nachweis.

Robert K. schrieb:
> daß zumindest in der Anfangszeit
> von C++ erst einmal intern vom C++ Compiler als Zwischenschritt
> unsichtbar in C umcompiliert wurde,
Ja und...
Damals war alles besser?
Oder, was soll das jetzt zum Thema beitragen.

Robert K. schrieb:
> weil C++ eben eine Obermenge von C
> ist ... falls Dir Mengenlehre überhaupt was sagt.
Offensichtlich sagt dir Mengenlehre weniger als mir.
Denn es gibt eine Schnittmenge, aber C ist keine Teilmenge.
Vor 30 Jahren mag das so gewesen ein.
Der Drops ist aber schon längst gelutscht.

Robert K. schrieb:
> Im Realtime Bereich wäre für mich C++ nicht unbedingt die erste Wahl -
Das sei dir ungenommen!
Deine persönliche Entscheidung macht aber nicht automatisch C für die 
bessere Sprache auf µC.

[Hans-Georg L. (h-g-l)]

Ich habe auch wieder den Link auf Scott Meyers Schulungsunterlagen zum 
Thema gefunden.

https://aristeia.com/TalkNotes/C++_Embedded_Deutsch.pdf

[Hans-Georg L. (h-g-l)]

Cyblord -. schrieb:
> Robert K. schrieb:
>> Geil, meine Beiträge (z.B. auch Buchempfehlung mit Link) werden generell
>> negativ bewertet nur weil sie von mir kommen ... wie dumm muß man hier
>> eigentlich sein :-)
>
> Hier werden keine Beiträge bewertet, sondern Autoren.

Das mag vielleicht daran liegen, das manche Autoren immer das gleiche 
egal zu welchem Thema schreiben. Das muss man nicht unbedingt jedesmal 
lesen sondern kann der Einfachheit halber gleich den Autor bewerten.

[Robert K. (Firma: Zombieland) (rko)]

Cyblord -. schrieb:
> Hier werden keine Beiträge bewertet, sondern Autoren.
aha; für jeden Post eine erneute Einzelbewertung des Autors, LOL.



Hans-Georg L. schrieb:
> Das Thema hier ist ein Buch über Embedded C++
nein, das Thema ist Realtime C++, kennt jemand diese Werk, ist es 
empfehlenswert?

> und du beantwortest eine
> Empfehlung für ein dazu passendes Buch  mit etwas völlig anderem.
nein, ich habe dem TO die Empfehlung gegeben das Buch zu verkaufen!
Die Link-Empfehlung habe ich deshalb gemacht, weil hier so getan wird 
als ob nur C++ für embedded geeignet ist - ist es nicht, es gibt genug 
Alternativen.
Das obige Buch befaßt sich mit Realtime C++ und embedded ist dann eben 
nur ein Teilauschnitt.

Hans-Georg L. schrieb:
> Da hättest du genauso gut einen Link auf ein Kochbuch posten können.
machen die anderen hier ja auch, nur da ist es ein C++ Kochbuch?
Das ist dann besser, weil C++
Merkst Du langsam wie lächerlich es hier wird ):

Hans-Georg L. schrieb:
> Kapere keine Threads, mache einen eigenen für deine Ergüsse auf.
Jawohl, mein ... - spare Dir doch einfach Deine Rechten Ratschläge;
Dein Tonfall ist echt für die Tonne!

[Robert K. (Firma: Zombieland) (rko)]

Arduino Fanboy D. schrieb:
> Nachweis?
u.a. auch c't
siehe:
http://www.wikiservice.at/dse/wiki.cgi?ProgrammierSpracheUndLaufzeit
natürlich darf C++ keinerlei Nachteile haben - ist schon klar.

Arduino Fanboy D. schrieb:
> Ja und...
> Damals war alles besser?
> Oder, was soll das jetzt zum Thema beitragen.
d.h. der TO als Anfänger muß die Entscheidung treffen und ihm dann noch 
sowas spezielles als Buch zu empfehlen sagt ja schon einiges aus )):

Arduino Fanboy D. schrieb:
> Denn es gibt eine Schnittmenge, aber C ist keine Teilmenge.
Aha, was geht denn in C, was ich in C++ nicht nachbilden kann?
Glaubst Du doch selber nicht was Du da redest.
Genau deswegen gab es doch C++, weil bestimmte Programmierkonzepte in 
C++ wesentlich einfacher gehen ):
Aber nö, C ist eine Schnittmenge - bei einer Schnittmenge würde einiges 
was mit C funktioniert unter C++ gar nicht funktionieren ... und diese 
Aussage ist falsch.

[Einer K. (Gast)]

Robert K. schrieb:
> Aber nö, C ist eine Schnittmenge - bei einer Schnittmenge würde einiges
> was mit C funktioniert unter C++ gar nicht funktionieren ... und diese
> Aussage ist falsch.
Damit hast du dich und deine Aussagen endgültig disqualifiziert.

Siehe, z.B. die Struktur Initialisierung.

struct person 
{
  char name[50];
  int alter;
} ;

struct person kurt = {.name = "Maier", .alter = 42};

Damit ist der Beweis gegen "Teilmenge" geführt.


Interessanter Effekt:
Jetzt zeigt sich, dass ich nicht nur in C++ sattelfester bin, sondern 
auch in C.
Was für eine Überraschung...

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Was in cpp auc nicht geht ab in C:

enum kekse {
  butter = 0x01,
  schoko = 0x02,
  supercookie = 0x03,
};

enum kekse variable = butter | schoko;

if (supercookie == variable) {
  printf("zombieland nervt!");
}

Das fliegt dir in cpp knallhart um die Ohren, weil da ein enum eine 
Klasse ist und vor allem typsicher und kein verdeckter int mehr.
Also troll dich zurück in deine Zombiehöhle!

(Sowas hab ich mal bei nem WLAN Treiber gesehen und das wollt in cpp 
nicht compilen)

[Robert K. (Firma: Zombieland) (rko)]

Arduino Fanboy D. schrieb:
> Damit ist der Beweis gegen "Teilmenge" geführt.
in C++ sind das dann wohl Klassen und damit ist Deine Teilmenge wieder 
hinfällig, siehe auch
https://www.learn-c.org/de/Structures
Soweit ich mich grob erinnere ist 'struct' auch schon C11 und taucht im 
ursprünglichen Ansi C nicht auf.
Ich gebe auch freimütig zu, super duper Programmierer bin ich nicht und 
brauche ich auch nicht mehr zu sein.

Arduino Fanboy D. schrieb:
> Jetzt zeigt sich, dass ich nicht nur in C++ sattelfester bin, sondern
> auch in C.
> Was für eine Überraschung...
ich sag mal so: wer glaubt beides gleich gut zu beherrschen, der irrt 
sich.
Spätestens bei GTK+ bist Du jedenfalls nicht mehr dabei, weil Du dann 
sowieso C++ wählen wirst, oder ?!

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Hier noch der Compilererror:

main.c: In function 'int main()':
main.c:68:30: error: invalid conversion from 'int' to 'kekse' [-fpermissive]
   68 | enum kekse variable = butter | schoko;
      |                       ~~~~~~~^~~~~~~~
      |                              |
      |                              int

[Robert K. (Firma: Zombieland) (rko)]

Mw E. schrieb:
> (Sowas hab ich mal bei nem WLAN Treiber gesehen und das wollt in cpp
> nicht compilen)
Auch in c++ gibt es wie bei c den c99, c11, usw. Standard - vielleicht 
hattest Du bei cpp einfach den falschen Compiler erwischt :-)

[Robert K. (Firma: Zombieland) (rko)]

Du machst eben Fehler in den Optionen des C++ Compilers.
Du kannst mit dem C++ Compiler auch C Programme compilieren, womit 
wiederum der irrsinnige Aspekt Schnittmenge vom Tisch ist.
Umgekehrt C++ Programme mit C Compiler compilieren geht nicht!

[Einer K. (Gast)]

Robert K. schrieb:
> in C++ sind das dann wohl Klassen und damit ist Deine Teilmenge wieder
> hinfällig, siehe auch
> https://www.learn-c.org/de/Structures
> Soweit ich mich grob erinnere ist 'struct' auch schon C11 und taucht im
> ursprünglichen Ansi C nicht auf.
struct gibt es in beiden Sprachen.
Allerdings die von mir gezeigte Initialisierung nicht.
Damit ist die "Teilmenge" hinfällig.
Egal, ob du das einsehen möchtest, oder auch nicht.
Der Fakt ist völlig unabhängig von deinen Meinungen oder 
Glaubensbekenntnissen.


Robert K. schrieb:
> ich sag mal so: wer glaubt beides gleich gut zu beherrschen, der irrt
> sich.
Ach, das mag ja sein....
Aber unter dem Lichte betrachte, dürfte ich über die Jahre in C mehr 
Erfahrungen als in C++ gemacht haben. Ja, in Sachen C++ gibts für mich 
noch einiges zu lernen. Darum ist das eingangs genannte Buch auch in 
meinem Interessenbereich.

Und genau im gleichen Lichte dieser Erfahrung möchte ich behaupten:
Bitte erst C++ lernen!
Dann fällt dir C viel leichter, als umgekehrt.

[Robert K. (Firma: Zombieland) (rko)]

Arduino Fanboy D. schrieb:
> Ja, in Sachen C++ gibts für mich
> noch einiges zu lernen. Darum ist das eingangs genannte Buch auch in
> meinem Interessenbereich.
vielleicht kannst Du dem TO das Buch ja preiswert abkaufen :-)
Ich sage ja nicht, daß es schlecht ist - nur für den TO wohl nicht so 
geeignet da viel zu speziell.

Arduino Fanboy D. schrieb:
> Und genau im gleichen Lichte dieser Erfahrung möchte ich behaupten:
> Bitte erst C++ lernen!
> Dann fällt dir C viel leichter, als umgekehrt.
würde ich nicht machen, weil Du Dir dann C garantiert vergraulst.
Im Prinzip die bewährte Reihenfolge:
Basic, Assembler, Pascal oder gleich C und dann C++ oder Java ... das 
reicht dann auch um einen Favoriten zu finden.

[Einer K. (Gast)]

Robert K. schrieb:
> vergraulst
Vergraulen...
Darum dreht sichs doch gar nicht.
Außerdem scheint es mir, als hätte deine C Ausbildung dir das C++ 
vergrault.
Schade eigentlich...

Übrigens, eben ist wieder ein Thread hoch gehüpft, wo ich zeige, wie man 
in C++ zur Kompilezeit 2 Arrays miteinander zu einem dritten verknüpft, 
und der Kompiler das zu quasi Nichts zusammenschrumpft. 0 RAM Verbrauch, 
minimaler Code.
Ich behaupte: Das bekommt kein Assembler und kein C Programmierer 
innerhalb seiner Sprache hin. Und wenn doch, würde ich mich über eine 
gelungene Vorführung sehr freuen.
Beitrag "Re: Makro Funktionen avr-gcc"

Ob das ein schönes Beispiel ist, ka, aber es ist so Laufzeiteffizient, 
wie es nicht besser geht, mit keinem Mittel.
Es zeigt schön die Macht des C++, welche sich zur Kompilezeit zur 
Nutzung anbietet, zumindest einen Aspekt davon.

[Yalu X. (yalu) (Moderator)]

Arduino Fanboy D. schrieb:
> Ich behaupte: Das bekommt kein Assembler und kein C Programmierer
> innerhalb seiner Sprache hin. Und wenn doch, würde ich mich über eine
> gelungene Vorführung sehr freuen.

Bitte sehr:

Dein Programm 1:1 nach C übersetzt:

#define arraySize 3

typedef int MeinArray[arraySize];

static MeinArray a = {1,2,3};
static MeinArray b = {4,5,6};

typedef struct
{
  MeinArray array;
} MeinContainer;

static MeinContainer fillContainer()
{
  MeinContainer c = {0};
  for(unsigned i = 0; i < arraySize; i++)
  {
    c.array[i] = a[i] + b[i] + i;
  }
  return c;
}

void setup(void) 
{
  MeinContainer c = fillContainer();

  for(unsigned i = 0; i < arraySize; i++)
  {
    PORTB = c.array[i];
  }
}

Erzeugter Assemblercode:

setup:
  ldi r24,lo8(5)
  out 0x18,r24
  ldi r24,lo8(8)
  out 0x18,r24
  ldi r24,lo8(11)
  out 0x18,r24
  ret

[Einer K. (Gast)]

OK!
Danke!
Ja, geprüft und ist identisch.
Dann nehme ich meine Behauptung zurück.

Ein Fall mehr, wo beide gleichauf liegen.

[Robert K. (Firma: Zombieland) (rko)]

Arduino Fanboy D. schrieb:
> Außerdem scheint es mir, als hätte deine C Ausbildung dir das C++
> vergrault.
> Schade eigentlich...
das kann gut sein ... und jetzt wäre sowieso C# angesagt; 
Programmiersprachen haben einen fließenden Übergang.
Ich bin da mittlerweile auch raus.

Arduino Fanboy D. schrieb:
> Ein Fall mehr, wo beide gleichauf liegen.
Mittlerweile hat sich ja auch bei C++ viel getan; in der Anfangszeit 
fand ich C++ nicht so berauschend und hab dann auch abgeblockt bzw. 
deswegen wohl auch die Vorurteile.
Insofern würde ich an Deiner Stelle versuchen dem TO das Buch 
abzukaufen; Dir könnte es sicher noch was nützen.

[Günter N. (gnatz)]

void schrieb:
> Das Problem von manchen Leuten hier im Forum ist, dass Sie ewig gestrige
> Nörgler sind. Hätte ich vorher wissen sollen, dass etwas zu dem Buch zu
> sagen hier total vergebene Zeitverschwendung war. Damit bin ich dann
> Mal raus.

Es ist leider so, dass es immer einige Leute gibt, die in fundierte 
Diskussionen unqualifizierte Bemerkungen einstreuen. Ich jedenfalls habe 
die Erläuterungen von void interessiert gelesen. Somit war das Erstellen 
jedenfalls keine Zeitverschwendung. Wer etwas - wie in diesem Fall void 
- zum Thema beitragen kann, sollte das auch tun und sich nicht durch 
Störmeldungen davon abhalten lassen.

[Robert K. (Firma: Zombieland) (rko)]

Günter N. schrieb:
> Es ist leider so, dass es immer einige Leute gibt, die in fundierte
> Diskussionen unqualifizierte Bemerkungen einstreuen. Ich jedenfalls habe
> die Erläuterungen von void interessiert gelesen. Somit war das Erstellen
> jedenfalls keine Zeitverschwendung. Wer etwas - wie in diesem Fall void
> - zum Thema beitragen kann, sollte das auch tun und sich nicht durch
> Störmeldungen davon abhalten lassen.
merkst Du eigentlich wie armseelig dieser Post von Dir ist ?
Wahrscheinlich nicht ... RIP

[Robert K. (Firma: Zombieland) (rko)]

Günter N. schrieb:
> Somit war das Erstellen
> jedenfalls keine Zeitverschwendung. Wer etwas - wie in diesem Fall void
> - zum Thema beitragen kann, sollte das auch tun und sich nicht durch
> Störmeldungen davon abhalten lassen.
für mich war der Thread sehr inspirativ - hab was im Web gefunden (hätte 
ich anfangs gar nicht gedacht das überhaupt zu finden) ... werde ich 
hier aber ganz bewußt nicht teilen, können ja die ganz schlauen Poster 
wie void machen - das überlasse ich dann dem großen void :-))
Bei Arduino Fanboy mache ich vielleicht eine Ausnahme, wenn es denn 
interessiert? Gute Enzyklopädie zu C++ :-)

[Uwe D. (monkye)]

Cyblord -. schrieb:
> Walter T. schrieb:
>> IJustWannaKnow schrieb:
>>> Ich habs geschenkt
>>> bekommen. MFG.
>>
>> Dann kannst Du Dir ja selbst eine Meinung bilden.
>
> Dann müsste er es ja lesen. Heute sitzt man vor einem Buch, geht dann
> aber ins Netz und fragt wie dieses Buch so ist. Irre!

Ja, es ist eine Dienstleistung mit der sich Geld verdienen lässt. Seid 
langer Zeit, damals nicht mit einer App oder Online Rezension. Tja, die 
Bücher Top-10 bei Spiegel und Co. ist auch nix anderes...

[Wilhelm M. (wimalopaan)]

Yalu X. schrieb:
> Arduino Fanboy D. schrieb:
>> Ich behaupte: Das bekommt kein Assembler und kein C Programmierer
>> innerhalb seiner Sprache hin. Und wenn doch, würde ich mich über eine
>> gelungene Vorführung sehr freuen.
>
> Bitte sehr:
>
> Dein Programm 1:1 nach C übersetzt:
>
>
>

> #define arraySize 3
> 
> typedef int MeinArray[arraySize];
> 
> static MeinArray a = {1,2,3};
> static MeinArray b = {4,5,6};
> 
> typedef struct
> {
>   MeinArray array;
> } MeinContainer;
> 
> static MeinContainer fillContainer()
> {
>   MeinContainer c = {0};
>   for(unsigned i = 0; i < arraySize; i++)
>   {
>     c.array[i] = a[i] + b[i] + i;
>   }
>   return c;
> }
> 
> void setup(void)
> {
>   MeinContainer c = fillContainer();
> 
>   for(unsigned i = 0; i < arraySize; i++)
>   {
>     PORTB = c.array[i];
>   }
> }
>

>
> Erzeugter Assemblercode:
>
>
>

> setup:
>   ldi r24,lo8(5)
>   out 0x18,r24
>   ldi r24,lo8(8)
>   out 0x18,r24
>   ldi r24,lo8(11)
>   out 0x18,r24
>   ret
>

Einen Vorteil sieht man nur, wenn die Arraygröße eine bestimmte Schwelle 
überschreitet. bm09a.c und bm09b.cc wie oben:

Arraygröße 3:

text    data     bss     dec     hex filename
152       0       0     152      98 bm09a.elf
152       0       0     152      98 bm09b.elf

Arraygröße 20:

324      80       0     404     194 bm09a.elf
238      40       0     278     116 bm09b.elf

[Einer K. (Gast)]

Wilhelm M. schrieb:
> wenn die Arraygröße eine bestimmte Schwelle
> überschreitet.
Ja, das war klar mein Fehler!
Mein ursprüngliches Beispiel zeigt leider nicht die Wirkung des 
constexpr, sondern ehr die der "for loop unrolling" Optimierung.
Und da kann C natürlich prächtig mithalten.
Zudem ist es eine Eigenschaft des Compilers, und nicht der Sprache.

Meine Ergebnisse mit 20 Arrayelementen sehen leicht anders aus
> C++: 266 Bytes Flash - 40 Bytes RAM
> C  : 376 Bytes Flash - 80 Bytes RAM
Beides mit der Arduino IDE und Gcc 9.2


Interessant finde ich, dass kompetente Leute in der Lage und auch 
Willens sind, Annahmen und Behauptungen zu überprüfen, und dann auch die 
Ergebnisse wertfrei präsentieren.
Ich schätze mal, das ist DIE wirksame Möglichkeit, Dialoge C vs. C++ 
zu führen, ohne dass es in Grabenkämpfe ausartet.

Meinen herzlichen Dank, für diese Vorführung!

[Wilhelm M. (wimalopaan)]

Arduino Fanboy D. schrieb:
> Wilhelm M. schrieb:
>> wenn die Arraygröße eine bestimmte Schwelle
>> überschreitet.
> Ja, das war klar mein Fehler!
> Mein ursprüngliches Beispiel zeigt leider nicht die Wirkung des
> constexpr, sondern ehr die der "for loop unrolling" Optimierung.
> Und da kann C natürlich prächtig mithalten.
> Zudem ist es eine Eigenschaft des Compilers, und nicht der Sprache.
>
> Meine Ergebnisse mit 20 Arrayelementen sehen leicht anders aus
>> C++: 266 Bytes Flash - 40 Bytes RAM
>> C  : 376 Bytes Flash - 80 Bytes RAM
> Beides mit der Arduino IDE und Gcc 9.2
>
>
> Interessant finde ich, dass kompetente Leute in der Lage und auch
> Willens sind, Annahmen und Behauptungen zu überprüfen, und dann auch die
> Ergebnisse wertfrei präsentieren.
> Ich schätze mal, das ist DIE wirksame Möglichkeit, Dialoge C vs. C++
> zu führen, ohne dass es in Grabenkämpfe ausartet.
>
> Meinen herzlichen Dank, für diese Vorführung!

Etwas idiomatischer sähe es dann so aus (mit denselben Ergebnissen 
hinsichtlich Code):

#include <avr/io.h>
#include <cstdint>
#include <array>

using MeinArray = std::array<uint16_t, 20>;

constexpr auto a = []{
    MeinArray data;
    for(uint8_t v = 0; auto& d : data) {
        d = ++v;
    }
    return data;
}();

constexpr auto b = []{
    MeinArray data;
    for(uint8_t v = 0; auto& d : data) {
        d = ++v + 10;
    }
    return data;
}();

using MeinContainer = MeinArray;

void setup() {
    constexpr auto c = []{
        MeinContainer data;
        for(MeinArray::size_type i{0}; i < std::size(data); ++i) {
            data[i] = a[i] + b[i] + i;
        }
        return data;
    }();
    
    for(const auto& item : c) {
        PORTB = item; // Ausgabe
    }
}

int main() {}

[Wilhelm M. (wimalopaan)]

Für die Freunde des Loop-Unrolling könnte man die letzte Schleife auch 
folgendermaßen schreiben:

    [&]<auto... II>(std::index_sequence<II...>) {
        ((PORTB = c[II]), ...);
    }(std::make_index_sequence<std::size(c)>{});

(Und ja, ich weiß: die Schönheit des template-code liegt im Auge des 
Betrachters)

[Einer K. (Gast)]

Wilhelm M. schrieb:
> (Und ja, ich weiß: die Schönheit des template-code liegt im Auge des
> Betrachters)

Wenn es men nur das wäre......

Hier fängt es ja schon zu krankeln an:
> fatal error: cstdint: No such file or directory

[Carl D. (jcw2)]

Arduino Fanboy D. schrieb:
> Wilhelm M. schrieb:
>> (Und ja, ich weiß: die Schönheit des template-code liegt im Auge des
>> Betrachters)
>
> Wenn es men nur das wäre......
>
> Hier fängt es ja schon zu krankeln an:
>> fatal error: cstdint: No such file or directory

Nimm stattdessen

#include <inttypes.c>

oder

#include <stdint.c>

das ist beim Avr-GCC mit dabei.

avr-GCC hat keine c++ Lib, deshalb auch keine c<irgendwas> includes, 
aber auch kein <array>. Eventuell erzählt uns Wilhelm wo er das her hat.

Wobei, so kompliziert ist std:::array auch nicht.

[Einer K. (Gast)]

Carl D. schrieb:
> Eventuell erzählt uns Wilhelm wo er das her hat.
Weiß nicht....
Die Indizienlage sagt was anderes.

[Wilhelm M. (wimalopaan)]

Carl D. schrieb:
> Nimm stattdessen#include <inttypes.c>oder#include <stdint.c>das ist beim
> Avr-GCC mit dabei.

Nein.
Steht doch alles in der Doku:

https://en.cppreference.com/w/cpp/header/cstdint

std::array<> sollte doch als Fingerübung kein Problem sein. Wer das 
nicht will, schaut halt mal in der OSS-Version der stdlibc++ oder 
benutzt seine eigenen Programmierkentnisse.

[Carl D. (jcw2)]

Wilhelm M. schrieb:
> Carl D. schrieb:
>> Nimm stattdessen#include <inttypes.c>oder#include <stdint.c>das ist beim
>> Avr-GCC mit dabei.
>
> Nein.
> Steht doch alles in der Doku:
>
> https://en.cppreference.com/w/cpp/header/cstdint
>
> std::array<> sollte doch als Fingerübung kein Problem sein. Wer das
> nicht will, schaut halt mal in der OSS-Version der stdlibc++ oder
> benutzt seine eigenen Programmierkentnisse.

Ich hab die Fingerübung längst gemacht. Ob aber jeder, der deinen Code 
ausprobieren will, das vorher auch machen will, bezweifle ich.

[Einer K. (Gast)]

Wilhelm M. schrieb:
> Für die Freunde des Loop-Unrolling könnte man die letzte Schleife auch
> folgendermaßen schreiben:
>     [&]<auto... II>(std::index_sequence<II...>) {
>         ((PORTB = c[II]), ...);
>     }(std::make_index_sequence<std::size(c)>{});

Das ist ja nun auch nur die halbe Miete.
Ja, es rollt die Schleife aus, aber das Array wird dennoch im RAM 
angelegt.

Flash 326 Bytes
Ram 40 Bytes

// schnipp
        ((PORTB = c[II]), ...);
  b8:  8c e0         ldi  r24, 0x0C  ; 12
  ba:  85 b9         out  0x05, r24  ; 5
  bc:  8b 81         ldd  r24, Y+3  ; 0x03
  be:  85 b9         out  0x05, r24  ; 5
  c0:  8d 81         ldd  r24, Y+5  ; 0x05
  c2:  85 b9         out  0x05, r24  ; 5
  c4:  8f 81         ldd  r24, Y+7  ; 0x07
  c6:  85 b9         out  0x05, r24  ; 5
  c8:  89 85         ldd  r24, Y+9  ; 0x09
  ca:  85 b9         out  0x05, r24  ; 5
  cc:  8b 85         ldd  r24, Y+11  ; 0x0b
  ce:  85 b9         out  0x05, r24  ; 5
  d0:  8d 85         ldd  r24, Y+13  ; 0x0d
  d2:  85 b9         out  0x05, r24  ; 5

// schnapp

[Wilhelm M. (wimalopaan)]

Arduino Fanboy D. schrieb:
> Das ist ja nun auch nur die halbe Miete.
> Ja, es rollt die Schleife aus, aber das Array wird dennoch im RAM
> angelegt.

Ja, klar.

Dann müssen wir uns etwas von diesem Arduino-Style wegbewegen:

using MeinArray = std::array<uint16_t, 20>;
class Setup {
    static inline constexpr auto a = []{
        MeinArray data;
        for(uint8_t v = 0; auto& d : data) {
            d = ++v;
        }
        return data;
    }();
    
    static inline constexpr auto b = []{
        MeinArray data;
        for(uint8_t v = 0; auto& d : data) {
            d = ++v + 10;
        }
        return data;
    }();
    
    using MeinContainer = MeinArray;
    
    static inline constexpr auto c = []{
        MeinContainer data;
        for(MeinArray::size_type i{0}; i < std::size(data); ++i) {
            data[i] = a[i] + b[i] + i;
        }
        return data;
    }();
public:
    static inline void init() {
        [&]<auto... II>(std::index_sequence<II...>) {
            ((PORTB = c[II]), ...);
        }(std::make_index_sequence<std::size(c)>{});
        
    }
};

int main() {
    Setup::init();
}

ergibt:

text    data     bss     dec     hex filename
324      80       0     404     194 bm09a.elf
218       0       0     220      dc bm09b.elf

[Oliver S. (oliverso)]

Eigentlich müsste jetzt mal neben dem obfuscates c Contest noch ein 
Wettbewerb kommen, für den längsten C++- Code, den der Compiler in 
maximal zwei Assembleranweisungen übersetzt.

Oliver

[Wilhelm M. (wimalopaan)]

Oliver S. schrieb:
> Eigentlich müsste jetzt mal neben dem obfuscates c Contest noch ein
> Wettbewerb kommen, für den längsten C++- Code, den der Compiler in
> maximal zwei Assembleranweisungen übersetzt.

In verschiedenen Programmiersprachen gibt es unterschiedliche Idiome, 
und in verschiedenen Programmierparadigmen gibt es unterschiedliche 
Muster (Pattern). Wer diese kennt, versteht den Code wesentlich 
schneller und sicherer.

Im Umkehrschluss gilt jedoch auch, dass manche Muster und Idiome durch 
ihre Universalität nicht immer trivial sind. Das bedeutet, dass es für 
die Unkundigen oft schwierig ist, die Bedeutung eines Musters zu 
verstehen.

[Hans-Georg L. (h-g-l)]

Wilhelm M. schrieb:
> In verschiedenen Programmiersprachen gibt es unterschiedliche Idiome,
> und in verschiedenen Programmierparadigmen gibt es unterschiedliche
> Muster (Pattern). Wer diese kennt, versteht den Code wesentlich
> schneller und sicherer.
>
> Im Umkehrschluss gilt jedoch auch, dass manche Muster und Idiome durch
> ihre Universalität nicht immer trivial sind. Das bedeutet, dass es für
> die Unkundigen oft schwierig ist, die Bedeutung eines Musters zu
> verstehen.

Du gehst davon aus, das immer nur Spezialisten deinen Code lesen.
Ich habe die letzten 20 Jahre meines Berufslebens im regulierten Umfeld 
verbracht und dabei unzählige Code-Reviews, interne und externe Audits 
mit gemacht. Das sitzen dann Physiker, Chemiker, Biologen usw. und alle 
wollen von dir den Nachweis haben das du Ihre Vorgaben vollständig und 
richtig umgesetzt hast. Die müssen dafür unterschreiben.
Da brauchst du verständlichen Code fürs Volk. Sonst hast du das gleiche 
Problem wie hier - ellenlange Diskussionen die nicht weiter führen.
Von daher finde ich den "Arduino Style" nicht mal so schlecht.

[void (Gast)]

Wilhelm M. schrieb in 
Beitrag "Re: Buch: Realtime C++"
> (...) Wer diese kennt, versteht den Code wesentlich schneller und sicherer.
> (..) Das bedeutet, dass es für die Unkundigen oft schwierig ist, die Bedeutung
> eines Musters zu verstehen.

Hans-Georg L. schrie in 
Beitrag "Re: Buch: Realtime C++"
> Du gehst davon aus, das immer nur Spezialisten deinen Code lesen.
> Ich habe die letzten 20 Jahre meines Berufslebens im regulierten Umfeld
> verbracht und dabei unzählige Code-Reviews, interne und externe Audits
> mit gemacht. (...)
> Sonst hast du das gleiche Problem wie hier - ellenlange Diskussionen die nicht 
weiter führen.

Danke Wilhelm, Hans-Georg. Das sind genau die Erfahrungen die ich auch 
gemacht habe und eingangs schon beschrieb.
Zum einen sollte man die unterschiedlichen Paradigmen kennen, denn nur 
so kann man bewerten welche Programmiersprache für einen bestimmten 
Zweck gerade mehr oder weniger geeignet ist.
Zum andren sollte man ein Gefühl dafür haben in wie weit der Code für 
andere mit dir zusammen arbeitenden Personen verständlich 
nachvollziehbar ist.
Das ist was ein Fortgeschrittener Programmierer / "Highend-Entwickler" 
zu leisten hat und eben nicht was ein Anfänger schon kann. Der 
Unterschied zwischen Beiden sind übrigens gelesene Bücher und 
Programmieren.

Von daher mein Abschliessender Rat an den TO:
Lies ein Sachbuch und dann noch eins. Du musst nicht unbedingt mit 
"Realtime C++" anfangen. Und selber programmieren nicht vergessen...

Abschliessend zum Thema Programmiersprache:
Selbst eingesetzt habe ich meistens C, manchmal C++ und selten ASM auf 
Mikrocontrollern.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Auch für klein moby gilt: Ab zum Arzt!

[Wilhelm M. (wimalopaan)]

Hans-Georg L. schrieb:
> Da brauchst du verständlichen Code fürs Volk. Sonst hast du das gleiche
> Problem wie hier - ellenlange Diskussionen die nicht weiter führen.
> Von daher finde ich den "Arduino Style" nicht mal so schlecht.

Oh, der Kunde entwickelt mit - das ist bestimmt spannend ;-)

[Wilhelm M. (wimalopaan)]

Zu dem Thema Idiome (in C++) gehört natürlich auch, dass man möglicht 
die Algorithmen (und Container) der Standard-Bibliothek verwenden 
sollte. Und wer die IIFE nicht mag, kann natürlich für diese "statische" 
Loop einen Algorithmus schreiben. Und ja: natürlich gehört dann 
'StaticFor' in eine eigene Header-Datei (Module) und zählt somit nicht 
zum Umfang des Beispiels. Und: natürlich ist der Maschinencode derselbe 
wie oben.

template<size_t N>
using Iterations = std::integral_constant<size_t, N>;

template<typename> struct StaticFor;

template<size_t N>
struct StaticFor<std::integral_constant<size_t, N>> {
    static inline constexpr void call(const auto f) {
        call_impl(std::make_index_sequence<N>{}, f);
    }
private:
    template<size_t... II>
    static inline constexpr void call_impl(std::index_sequence<II...>, const auto f) {
        (f(II), ...);
    }
};

template<size_t N = 20>
class Setup {
    using MeinArray = std::array<uint16_t, N>;
    using MeinContainer = MeinArray;
    static inline constexpr auto a = []{
        MeinArray data;
        std::iota(std::begin(data), std::end(data), 0, 1);
        return data;
    }();
    static inline constexpr auto b = []{
        MeinArray data;
        std::iota(std::begin(data), std::end(data), 0, 10);
        return data;
    }();
    static inline constexpr auto c = []{
        MeinContainer data;
        std::transform(std::begin(a), std::end(a), std::begin(b), std::begin(data), 
                       [](const auto ai, const auto bi){return ai + bi;});
        return data;
    }();
public:
    static inline void init() {
        StaticFor<Iterations<20>>::call([](const auto i){
            PORTB = c[i];
        });
//        [&]<auto... II>(std::index_sequence<II...>) {
//            ((PORTB = c[II]), ...);
//        }(std::make_index_sequence<std::size(c)>{});
    }
};

int main() {
    Setup<>::init();
}

[A. B. (Gast)]

Wilhelm M. schrieb:
> Zu dem Thema Idiome (in C++) gehört natürlich auch, dass man möglicht
> die Algorithmen (und Container) der Standard-Bibliothek verwenden
> sollte.

Unter welcher Umgebung compilierst du das?

Das Beispiel verwendet #include <avr/io.h> und PORTB und damit ist das 
Beispiel für die Allgemeinheit unter avr-gcc-9.3.0-mingw64 so nicht 
kompilierbar. Der oben zitierte Satz ist eine nicht erreichbare 
Wunschvorstllung.

Alexandra

[Hans-Georg L. (h-g-l)]

Wilhelm M. schrieb:
> Hans-Georg L. schrieb:
>> Da brauchst du verständlichen Code fürs Volk. Sonst hast du das gleiche
>> Problem wie hier - ellenlange Diskussionen die nicht weiter führen.
>> Von daher finde ich den "Arduino Style" nicht mal so schlecht.
>
> Oh, der Kunde entwickelt mit - das ist bestimmt spannend ;-)

Nicht der Endkunde aber das Entwicklungsteam und der Gesetzgeber ...
Die Software ist nur ein Teil des Produktes.

Wenn du mal in der in der Notfallabteilung einer Klinik landest möchtest 
du bestimmt auch gerne haben, das die Laborwerte schnell und sicher sind 
die der Arzt als Grundlage für deine Behandlung nimmt.
Wenn dir aber wichtiger ist das die Software im Messgerät im schönen C++ 
geschrieben ist kannst die Behandlung ja verweigern;-).

[Wilhelm M. (wimalopaan)]

Hans-Georg L. schrieb:
> Wenn du mal in der in der Notfallabteilung einer Klinik landest möchtest
> du bestimmt auch gerne haben, das die Laborwerte schnell und sicher sind
> die der Arzt als Grundlage für deine Behandlung nimmt.
> Wenn dir aber wichtiger ist das die Software im Messgerät im schönen C++
> geschrieben ist kannst die Behandlung ja verweigern;-).

Du meinst also, die Korrektheit eines Programms und "Schönheit" 
schließen sich aus? Was ist denn das für ein Quatsch?

[Hans-Georg L. (h-g-l)]

Zurück zum Thema und dem Buch.

Reviews zu dem Buch:

https://www.rangakrish.com/index.php/2018/12/23/book-review-real-time-c/

https://www.reddit.com/r/cpp/comments/awfv5v/stefan_petersen_book_review_realtime_c_second/
https://atadiat.com/en/e-embedded-c-developers-hate-or-love-cpp/

Und unter den 62 Best C++ Books of All Time rangiert es auf Platz 27
https://bookauthority.org/books/best-c-plus-plus-books


Und hier noch der Code zum Buch:

https://github.com/ckormanyos/real-time-cpp

[Walter T. (nicolas)]

Hans-Georg L. schrieb:
> Zurück zum Thema und dem Buch.

Danke für den Beitrag.

Wie ich oben schon schrieb, ist es über Springerlink verfügbar und ich 
habe es angefangen und dann weggelegt. Zielgruppe scheint "Kenne C++, 
will Embedded" zu sein. Es ist meiner Meinung nach nicht geeignet für 
jemanden, der C auf Embedded Systemen kennt und in C++ einsteigen will.

[Hans-Georg L. (h-g-l)]

Wilhelm M. schrieb:
> Hans-Georg L. schrieb:
>> Wenn du mal in der in der Notfallabteilung einer Klinik landest möchtest
>> du bestimmt auch gerne haben, das die Laborwerte schnell und sicher sind
>> die der Arzt als Grundlage für deine Behandlung nimmt.
>> Wenn dir aber wichtiger ist das die Software im Messgerät im schönen C++
>> geschrieben ist kannst die Behandlung ja verweigern;-).
>
> Du meinst also, die Korrektheit eines Programms und "Schönheit"
> schließen sich aus? Was ist denn das für ein Quatsch?

Wie kommst du darauf ? Natürlich nicht !

[Hans-Georg L. (h-g-l)]

Walter T. schrieb:
> Hans-Georg L. schrieb:
>> Zurück zum Thema und dem Buch.
>
> Danke für den Beitrag.
>
> Wie ich oben schon schrieb, ist es über Springerlink verfügbar und ich
> habe es angefangen und dann weggelegt. Zielgruppe scheint "Kenne C++,
> will Embedded" zu sein. Es ist meiner Meinung nach nicht geeignet für
> jemanden, der C auf Embedded Systemen kennt und in C++ einsteigen will.

Da bin ich völlig deiner Meinung, das sind fast alle solche Bücher.
Wer wenig Ahnung von C++ hat und höchstens die klassische Vererbung 
kennt wird sich nach dem Durcharbeiten fragen. Alles schön und gut, die 
LED blinkt, aber wie setze ich es gewinnbringend in meiner täglichen 
Arbeit ein ?

[Einer K. (Gast)]

Hans-Georg L. schrieb im Beitrag #6437524:
> Wenn du das Rad und für jeden Datentyp täglich neu erfinden willst magst
> du recht haben ;-)
Nööö.....
Mobby war damals schon von der C Datentyp Systematik überfordert.
Jetzt macht ihm nur noch ASM, ohne alle Datentypen.
Auch damit zusammenhängende Warnungen/Errors haben ihn fürchterlich 
genervt, werden darum als gängeln empfunden und somit als überflüssig 
deklariert.

Irgendwann hat er sich den Irrtum eingefangen, dass es an den Sprachen 
C und C++ liegt, und nicht an seiner überzogenen Erwartungshaltung, in 
seine begrenzten Kognitiven Fähigkeiten, dass er so unglücklich ist.

Jetzt endlich hat er/sie/es sein Glück in seiner kleinen AVR ASM Welt 
gefunden, und möchte auch dich damit überschütten.

Sei dankbar!

-----------

A. B. schrieb:
> Unter welcher Umgebung compilierst du das?
In dem Punkt ist Wilhelm steif.
Von seinem Elfenbeintürmchen aus, interessiert ihn das Fußvolk schlicht 
nicht.

Meine Einschätzung:
Nachfragen, wie deine, betonen die Distanz und damit auch seine 
Erhabenheit.

Aber, wie sagte schon Johann Heinrich Pestalozzi:
> Wohltätigkeit ist das Ersaufen des Rechts im Mistloch der Gnade

Somit ... alles im gesellschaftlich übliche Rahmen.

[Wilhelm M. (wimalopaan)]

Hans-Georg L. schrieb:
> Wilhelm M. schrieb:
>> Hans-Georg L. schrieb:
>>> Wenn du mal in der in der Notfallabteilung einer Klinik landest möchtest
>>> du bestimmt auch gerne haben, das die Laborwerte schnell und sicher sind
>>> die der Arzt als Grundlage für deine Behandlung nimmt.
>>> Wenn dir aber wichtiger ist das die Software im Messgerät im schönen C++
>>> geschrieben ist kannst die Behandlung ja verweigern;-).
v>>
>> Du meinst also, die Korrektheit eines Programms und "Schönheit"
>> schließen sich aus? Was ist denn das für ein Quatsch?
>
> Wie kommst du darauf ? Natürlich nicht !

Das beruhigt mich. Dann habe ich wohl

>>> Wenn dir aber wichtiger ist das die Software im Messgerät im schönen C++
>>> geschrieben ist kannst die Behandlung ja verweigern;-).

falsch verstanden.

[Wilhelm M. (wimalopaan)]

Arduino Fanboy D. schrieb:
> A. B. schrieb:
>> Unter welcher Umgebung compilierst du das?
> In dem Punkt ist Wilhelm steif.
> Von seinem Elfenbeintürmchen aus, interessiert ihn das Fußvolk schlicht
> nicht.

Für etwa die AVRs mit:

avr-gcc (GCC) 11.0.0 20200818 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Allerdings gehört da natürlich eine libstdc++ dazu. Diese existiert 
nicht, und ich kann die Sourcen zu meiner Implementierung nicht 
öffentlich machen.

Soweit, so schlecht.
Doch, Leute, worum geht es hier? Erstmal um std::array<>. Dafür finden 
sich zahlreiche Implementierungen im Netz oder man schaut einfach in die 
libstdc++ des gcc.
Und so ist das mit den anderen Sachen auch. Da wäre meine 
Implementierung auch nicht mehr von Hilfe.

Allerdings lernt man doch generische Programmierung, Erstellen von 
templates und TMP nicht auf einem Arduino! Das macht man ganz normal auf 
dem PC.

Daher:

gcc (GCC) 11.0.0 20201009 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.

Und mit etwas Kreativität kann man das obige Beispiel einfach auf dem PC 
oder im Godbolt-CE laufen lassen:

#include <cstdint>
#include <array>
#include <algorithm>
#include <numeric>

namespace UC {
    volatile uint8_t portb;
}

#define PORTB UC::portb

template<size_t N>
using Iterations = std::integral_constant<size_t, N>;

template<typename> struct StaticFor;

template<size_t N>
struct StaticFor<std::integral_constant<size_t, N>> {
    static inline constexpr void call(const auto f) {
        call_impl(std::make_index_sequence<N>{}, f);
    }
private:
    template<size_t... II>
    static inline constexpr void call_impl(std::index_sequence<II...>, const auto f) {
        (f(II), ...);
    }
};

template<size_t N = 20>
class Setup {
    using MeinArray = std::array<uint16_t, N>;
    using MeinContainer = MeinArray;
    static inline constexpr auto a = []{
        MeinArray data;
        std::iota(std::begin(data), std::end(data), 0);
        return data;
    }();
    static inline constexpr auto b = []{
        MeinArray data;
        std::iota(std::begin(data), std::end(data), 0);
        return data;
    }();
    static inline constexpr auto c = []{
        MeinContainer data;
        std::transform(std::begin(a), std::end(a), std::begin(b), std::begin(data), 
                       [](const auto ai, const auto bi){return ai + bi;});
        return data;
    }();
public:
    static inline void init() {
        StaticFor<Iterations<20>>::call([](const auto i){
            PORTB = c[i];
        });
//        [&]<auto... II>(std::index_sequence<II...>) {
//            ((PORTB = c[II]), ...);
//        }(std::make_index_sequence<std::size(c)>{});
    }
};

int main() {
    Setup<>::init();
}

[Einer K. (Gast)]

Wilhelm M. schrieb:
> Allerdings lernt man doch generische Programmierung, Erstellen von
> templates und TMP nicht auf einem Arduino!

Ich danke Euch auch für diese Herabwürdigung.
Sowie auch für alle weiteren....
Möge sie der Stabilisierung, seiner Erhabenheit, dienlich sein.

[Wilhelm M. (wimalopaan)]

Arduino Fanboy D. schrieb:
> Ich danke Euch auch für diese Herabwürdigung.

Das ist doch keine Herabwürdigung von Dir. Es ist lediglich die Aussage, 
dass man das nicht auf einem Arduino richtig lernen kann. Abgesehen von 
der fehlenden libstdc++ ist es doch viel zu umständlich und völlig 
spaßbefreit.

[Hans-Georg L. (h-g-l)]

Wilhelm M. schrieb:
....
> Das beruhigt mich. Dann habe ich wohl
> falsch verstanden.

Du musst nur das ganze lesen...

[Hans-Georg L. (h-g-l)]

Wilhelm M. schrieb:
...
> Für etwa die AVRs mit:
> avr-gcc (GCC) 11.0.0 20200818 (experimental)
...
> Allerdings gehört da natürlich eine libstdc++ dazu.

Es macht nicht viel Sinn einen Compiler Version zu verwenden die 
"realer" kein AVR Entwickler benutzt.
...

> Allerdings lernt man doch generische Programmierung, Erstellen von
> templates und TMP nicht auf einem Arduino! Das macht man ganz normal auf
> dem PC.

Aber nicht den "embedded" Teil und auch nicht was du auf einem 
"schwachbrüstigen" MC gefälligst unterlassen solltest

...
> namespace UC {
>     volatile uint8_t portb;
> }
>
> #define PORTB UC::portb
...
>//            ((PORTB = c[II]), ...);

Das ist "embedded" an dem ganzen ...
Der Rest ist doch nur Verwirrspiel und du überzeugst keinen damit ;-)

[Einer K. (Gast)]

Wilhelm M. schrieb:
> Das ist doch keine Herabwürdigung von Dir. Es ist lediglich die Aussage,
> dass man das nicht auf einem Arduino richtig lernen kann. Abgesehen von
> der fehlenden libstdc++ ist es doch viel zu umständlich und völlig
> spaßbefreit.

Ohne diese Ansage wüsste ich nicht, wann, wo und wie ich Spass haben 
kann.
Auch dafür danke ich Euch, wie für jeden anderen Krumen, welcher von 
eurem hochgelobten Tische herab fällt.

Im Ernst:
Einen AVR-GCC 10.1 baue ich mir ja noch und integriere diesen in die 
Arduino IDE,  um deiner Brotkrumenspur zu folgen...
Aber "experimental"?
Das hat dann keine Praxisrelevanz mehr.
Hier endet es!

Wilhelm M. schrieb:
> Allerdings gehört da natürlich eine libstdc++ dazu. Diese existiert
> nicht, und ich kann die Sourcen zu meiner Implementierung nicht
> öffentlich machen.
Was ich davon halte, .... das sage ich lieber nicht.

[Wilhelm M. (wimalopaan)]

Arduino Fanboy D. schrieb:
> Einen AVR-GCC 10.1 baue ich mir ja noch und integriere diesen in die
> Arduino IDE,  um deiner Brotkrumenspur zu folgen...
> Aber "experimental"?
> Das hat dann keine Praxisrelevanz mehr.
> Hier endet es!

Du kannst dafür genauso gut einen 10.1 nehmen. Es war die Frage, was ich 
verwende, und nicht, was man mindestens nehmen muss. Ein Blick in die 
Feature-List von cppreference lohnt sich.

[Einer K. (Gast)]

Auf die Gefahr hin, mich endlos wiederholen zu müssen, auch für diese 
weitere Demütigung:
Meinen Dank!

[Wilhelm M. (wimalopaan)]

Hans-Georg L. schrieb:
> Es macht nicht viel Sinn einen Compiler Version zu verwenden die
> "realer" kein AVR Entwickler benutzt.

Das ist ein Scheinargument, denn es geht ja auch mit älteren Versionen 
vom g++.

Hans-Georg L. schrieb:
> Aber nicht den "embedded" Teil und auch nicht was du auf einem
> "schwachbrüstigen" MC gefälligst unterlassen solltest

Auch das ist hier kein Argument, denn es geht um ein konkretes Beispiel. 
Und all das kann man am PC oder im GB-CE sehr schön nachvollziehen. 
Warum sollte das nur für einen AVR möglich sein?

[Wilhelm M. (wimalopaan)]

Das Buch ist m.E. gar nicht schlecht, weist es doch in die richtige 
Richtung: compile-computation, type-reflection, meta-functions, ...

Der Nachteil des Buches liegt m.E. darin, das es zu früh erschienen ist. 
Denn ein ganz wichtiger Baustein darin fehlt, und dass sind "concepts". 
Die sind als "concepts-ts" zwar schon eine ganze Weile im g++ enthalten, 
jedoch in einer Form, die vor der Einbringung in C++20 nochmal verändert 
wurde (keine function-style concepts mehr, einige Erweiterungen). Dies 
ist zwar nicht besonders kritisch, weil es zwar die Syntax und wenige 
features betrifft, aber nicht das Grundkonzept fallen lässt. Und 
concepts sind ein wesentlicher Bestandteil der statischen Polymorphie. 
M.E. hätte der Autor darauf hinweisen müssen, denn bekannt und verfügbar 
waren concepts schon lange vor Erscheinen des Buches. Vielleicht kommt 
ja eine neue Auflage ;-)

[Yalu X. (yalu) (Moderator)]

Wilhelm M. schrieb:
> Der Nachteil des Buches liegt m.E. darin, das es zu früh erschienen ist.

Das haben Bücher auch dem Computerbereich und anderen ständig
voranschreitenden Wissensgebieten so an sich. Wenn der Autor mit der
Veröffentlichung des Buchs auf den absolut finalen C++-Standard warten
würde, könnte er davon nur wenige Exemplare verkaufen, da zu diesem
Zeitpunkt kaum noch jemand C++ nutzen wird.

Wilhelm M. schrieb:
> M.E. hätte der Autor darauf hinweisen müssen, denn bekannt und verfügbar
> waren concepts schon lange vor Erscheinen des Buches.

Warum sollte der Autor seine Leser mit neuen Features belästigen, die
noch weit von der Verabschiedung durch das Normungsgremium entfernt sind
und damit noch auf recht wackeligen Beinen stehen? Die Concepts wurden
erstmalig im Juli 2017 in den C++20-Draft aufgenommen, da hat Kormanyos
sein Buch, das im Mai 2018 veröffentlicht wurde, vermutlich schon zu 98%
fertiggestellt. Technisch finalisiert wurde der C++20-Standard Anfang
dieses Jahres (das wäre IMHO der früheste Zeitpunkt gewesen, seine
Inhalte in Lehrbücher aufzunehmen). Offiziell veröffentlicht wird er
voraussichtlich erst Ende dieses Jahres.

Natürlich gibt es immer Leute (wie bspw. du), denen das alles nicht
schnell genug geht. Diese kaufen aber keine solchen Bücher, sondern
informieren sich in den Vorabveröffentlichungen des ISO-Gremiums.
Kormanyos wäre somit ziemlich dumm, wenn er sein Buch auf diese Leute
zuschneiden würde.

> Vielleicht kommt ja eine neue Auflage ;-)

Vielleicht. Aber auch diese wird für dich viel zu spät erscheinen, da
das ISO-Gremium schon längst an an C++23 arbeitet ;-)

[Einer K. (Gast)]

> Das größte Problem im Leben eines Menschen,
> ist die Wahl der richtigen Gedanken
Quelle: ?

[Joachim B. (jar)]

IJustWannaKnow schrieb:
> ne ernsthaft. meine Erfahrung in dem Gebiet reicht nicht aus um zu
> beurteilen ob das Buch gut ist.

wenn du es durch hast und keine Fragen offen sind war es gut, bis jetzt 
wurde ich aber oft enttäuscht hatte viel Geld versenkt in schlechte 
Bücher.
Das letzte C++ Buch noch nicht durchgearbeitet, ja in dem Wort steckt 
Arbeit!