Ada oder MISRA-C, aktuell und in Zukunft

MISRA-C finde ich eine gelungene Bezeichnung. Es erinnert sofort an das 
Wort
MISSRA-TEN

Mit zugedrütem Hühnerauge könnte man sagen dass wenn man die MISRA-C 
Regeln in einen Compilerfrontend packt und dann die Syntax so ändert 
dass eine nicht unerhebliche Menge an Fehler bereits beim hinschreiben 
von Code verhindert wird, bei diese wie Ada ankommt.

Programmiersprachentheaterintendant schrieb:
> Mit zugedrütem Hühnerauge könnte man sagen dass wenn man die MISRA-C
> Regeln in einen Compilerfrontend packt und dann die Syntax so ändert
> dass eine nicht unerhebliche Menge an Fehler bereits beim hinschreiben
> von Code verhindert wird, bei diese wie Ada ankommt.

Warum gelingt es dir nicht, einen Gedanken klar zu formulieren und in 
einen Text umzusetzen?

Wird Ada eigentlich überhaupt in Deutschland komerziell eingesetzt?
Die meisten Embedded-Sachen laufen ja entweder mit C oder C++.

Bei Ada hat man halt einen großen Overhead was die Laufzeit betrifft … 
meine Ada Erfahrung ist mini. Wenn dann wieder Klimmzüge gemacht 
werden, weil Sicherheitszeiten in der Ausführung nicht mehr eingehalten 
werden können -> doof! Die statische Codeanalyse für C/C++ ist ja 
inzwischen auch recht weit.

Für "richtige" Ada Nutzung müssten wir unsere Architekten umerziehen 
bezüglich erreichbarer Intervalle und Feature Set bei gegebener 
Hardware.

MISRA Regeln können ja auch gebrochen werden. Das ist auch immer wieder 
sinnvoll. Leider machen die On/Off Sequenzen für den Checker den Code 
unleserlich.

MISRA ist vor allem für Einsteiger gut, denn es hatte ja schon jede 
Regel ihren Ursprung. Da können sich insbesondere Anfänger bewusst 
machen in was für "Fallen" man tappen kann und ihr Verständnis der 
Programmiersprache vervollständigen.

Die meisten Fehler Programmiertechnisch treten bei uns im Zusammenhang 
mit coolen generischen Sachen usw. auf. Die schleppen meistens 
Absolventen und noch viel Schlimmer externe "Experten" an. Hier hat noch 
nie einer der "Experten" wirklich etwas gebracht … vor allem wenn man 
die Zeit zum einlernen auf dem konkreten System und die Übergaben mit 
einrechnet. Das lernt so langsam zum Glück auch das Management -> aber 
anderes Thema.

Ich würde auch die Programmiersprache heute nicht mehr in den 
Vordergrund stellen wollen. Erfahrungsgemäß kommen die kritischen Fehler 
meist eher durch mangelndes Systemverständnis zustande, oder wurden 
direkt vom Architekten schön ins System geplant. Man sollte natürlich 
auch darauf achten, dass man nicht rückläufig in der Qualität wird was 
den Code betrifft.

Hier in der Firma haben die Safety Projekte den fast 10x Codeumfang wie 
noch vor 10 Jahren! Dennoch sind die Zahlen für echte Programmier-Fehler 
auch absolut rückläufig. Dafür sind stark ansteigende Fallzahlen von 
Konzeptfehlern heute ein Problem. Die bekommt man aber weder mit MISRA 
als auch Ada in den Griff. Hier scheitert dann oft auch das Unittesting 
und bei dem großen Funktionsumfang ist eine echte 100% Abdeckung im 
Systemtest sowas von Utopie!

Sprich das Testen über Simulationen wird immer wichtiger!!! Wenn man das 
Feature Set von vor 10 Jahren auf dem äquivalenten Anteil von heute 
abbildet, dann sind sogar dort die Fehlerzahlen rückläufig. Allerdings 
steigen die Problemeund Fehler insgesamt durch die großen 
Querbeeinflussungen durch die hohe Anzahl an Funktionen, welche man 
untergebracht hat.

Übrigens Ada wird heute immer noch in gewissem Umfang bei deutschen 
Banken eingesetzt. Vielleicht wechselt die Commerzbank ja gerade auf 
Java :D

Addada schrieb:
> Wird Ada eigentlich überhaupt in Deutschland komerziell eingesetzt

Natürlich

Softwareentwickler (m/w/d) ADA / JAVA Bahntechnik
ALTEN GmbH - Stuttgart 20.06.2019 mehr...
Softwarentwickler/-in ADA (w/m)
Airbus Group SE - Ulm 06.06.2019 mehr...
Hardwarenaher Softwareentwickler (m/w/d) mit Ada-Kenntnissen 
(Softwareentwickler/in)
Computer Futures - München, Deutschland, Bayern, Ingolstadt 12.03.2019

Dussel schrieb:
> Die beiden großen
> Kandidaten für sowas sind wohl Ada und MISRA-C(++).

Wobei ich MISRA-C noch um Lint und weitere Analysetools erweitern würde. 
C ist einfach die am Besten erforschte Programmiersprache, so dass es 
dazu das größte Biotop gibt.

Ich meine, mal gelesen zu haben, dass die NASA auf die Frage, welche 
statische Analysetools, die Antwort fand: Alle (bzw. alle relevanten). 
Warum auf Lint beschränken, wenn andere Tools andere Fehler finden.

Uns hilft PC-Lint sehr, da es relativ flexibel an alle 
Programmierparadigmen angepasst werden kann und z.B. MISRA-Richtlinie am 
umfangreichsten prüft.

Fand gerade diese Publikation über Sicherheit Relevantes SW Design:

https://standards.nasa.gov/file/2617/download?token=NIWUBzS6

Da sind ja doch schon einige gute Antworten zusammengekommen.
Der Hintergrund der Frage war, dass ich überlege, in die Richtung mehr 
zu lernen. Schwere Schäden durch Softwarefehler gab es immer wieder. Da 
war halt die Frage, ob es sich lohnt, sich auf Ada zu konzentrieren oder 
ob das in nächster Zeit durch andere Techniken (MISRA, Codeanalyse) 
ersetzt wird.
In dem Fall wäre es wahrscheinlich besser, sicheres C und den Umgang mit 
Analysewerkzeugen zu lernen.

Simulation und ausführliche Tests kann man sowieso nicht ersetzen. Aber 
man kann eventuell durch die richtige Herangehensweise Fehler vermeiden 
und die Fehlersuche verkürzen. Und mit mühsamer Fehlersuche in C(++) 
habe ich doch schon unschöne Erfahrung gemacht.

A. S. schrieb:
> Dussel schrieb:
>> Die beiden großen
>> Kandidaten für sowas sind wohl Ada und MISRA-C(++).
>
> Wobei ich MISRA-C noch um Lint und weitere Analysetools erweitern würde.

Dann sollt man auch Ada-SPARK vergessen:

https://www.golem.de/news/ada-und-spark-mehr-sicherheit-durch-bessere-programmiersprachen-1906-141211.html

Markus K. schrieb:
> Sichere Softwareentwicklung ist aber ziemlich teuer. Deswegen will das
> niemand.
In dem Bereich, an den ich bei dem Thema vorzugsweise denke, geht es um 
ein paar Millionen Euro…

Markus K. schrieb:
> Ich kenne Misra C aus der
> Automobilbranche, aber weiter oben wurden ja ein paar Stellenanzeigen
> für Ada genannt und da ging es um Bahntechnik und Flugzeuge.
Also scheint beides verbreitet zu sein und wie VHDL und Verilog je nach 
Branche oder Land bevorzugt zu werden.

Martin S. schrieb:
> sich bei guten alten Konzepten aus der Raumfahrt bedienen
An die denke ich. :-) Wobei bei der Raumfahrt wahrscheinlich noch andere 
Anforderungen dazukommen.

Dann werde ich mal sehen. Sich in Konzepte zum sicheren Programmieren 
einzuarbeiten ist sicher nicht verkehrt. Bei Gelegenheit kommt dann noch 
Ada dazu.

sparky schrieb:
> A. S. schrieb:
>> Dussel schrieb:
>>> Die beiden großen
>>> Kandidaten für sowas sind wohl Ada und MISRA-C(++).
>>
>> Wobei ich MISRA-C noch um Lint und weitere Analysetools erweitern würde.
>
> Dann sollt man auch Ada-SPARK vergessen:
>
> 
https://www.golem.de/news/ada-und-spark-mehr-sicherheit-durch-bessere-programmiersprachen-1906-141211.html

Denke, du meintest wohl „nicht vergessen“. :)

ADA mit SPARK gibt nicht nur sicheren Code, sondern auch verifizierten 
Code. In manchen Branchen eine conditio sine qua non. Leute, die das 
können, sind gefragt und gut bezahlt.

Gruß
Herby

Markus K. schrieb:
> Wobei ein paar Millionen Euro für die meisten größeren Firmen nicht so
> übermäßig viel Geld ist.
Das war ein bisschen vorschnell. Curiosity hat laut Wikipedia wohl ein 
paar (über zwei) Milliarden Dollar gekostet.
Bei der NASA werde ich wohl auch in Zukunft nicht arbeiten, aber 
vielleicht in Bereichen, in denen die Schäden sehr hoch werden könnten. 
Außerdem gibt es ja auch andere Bereiche für sichere Programmierung.

Markus K. schrieb:
> Das Programmieren (also das Code schreiben) ist dabei aber nur ein
> kleiner Teil. Es fängt vorne an (Anforderungen systematisch
> aufschreiben) und hinterher systematisch auf allen Ebenen testen.
Ich weiß. Das wurde ja oben schon geschrieben. Aber sowas macht man ja 
nicht alleine. Softwareentwickler sind für die Sicherheit der Software 
zuständig und müssen sich wohl eher weniger um die Hardware kümmern und 
umgekehrt.
Hier ging es mir nur um die Programmierung.

Mark B. schrieb:
> Ada wird durchaus eingesetzt, allerdings nahezu ausschließlich in der
> Luft- und Raumfahrt. In anderen Branchen scheint es sehr wenig vertreten
> zu sein.
Vielleicht wirklich aus Kostengründen. In Luft- und Raumfahrt ist man 
bereit, die spezialisierten Ada-Programmierer zu bezahlen, während die 
anderen Bereiche eher kostenkritischer sind und man C-Programmierer 
nimmt und die durch MISRA und andere Werkzeuge sicher macht. (Nichts 
gegen C-Programmierer, ich bin ja selber einer.)

Christopher J. schrieb:
> Ich würde noch Rust als Alternative zu Misra-C oder Ada ins Spiel
> bringen. Obwohl es (leider) nicht primär für Embedded-Applikationen
> gedacht war, tut sich in diesem Bereich schon jetzt sehr viel, so gibt
> es etwa schon einen - nicht perfekten aber sehr brauchbaren -
> Stackanalyzer:

Wie sieht es mit valgrind aus, kann man das (mit Debug-Symbolen) schon 
sinnvoll verwenden? Und wie gehn coverage-Tests (gcov?) von der Hand?

Christopher J. schrieb:
> Ob es sinnvoll ist einen OS-Kernel in Rust und die eigentliche Anwendung
> in C zu schreiben sei jetzt mal dahingestellt. Ich persönlich würde es
> wohl eher andersherum machen. Rust ist aber grundsätzlich sehr
> kompatibel zu C.

Das ist ein interessanter Punkt, der auch gelegentlich bei der Frage C 
vs. C++ aufflackert. Beispiel: Ich habe hier ein Kernel, was ohne 
malloc() arbeiten muss, aber eine gewisse (begrenzte) Anzahl von vielen 
Objekten alloziert und immer wieder freigibt, d.h. es läuft intern auf 
verlinkte Listen raus.
In C ist das nervige Schreibarbeit mit Iteratoren-Makros, in C++ wär's 
schöner, aber gibt ein paar Showstopper für diese Architektur (u.A. 
stack unwinding/Exceptions). Habe schon gesehen, dass man in Rust 
relativ elegant Allokatoren definieren kann. Wie sieht das in der Praxis 
aus, macht das engineering-mässig Sinn, ein Mikro-Kernel in C zu 
schreiben und einen Applikations-Layer in Rust drüberzukleben? D.h. wie 
einfach ist es, ein Objekt mit einem Listen-Kopf (C-Struct mit .next, 
.prev, .children und einer Objekt-Nutzlast) zu wrappen? Und: es darf 
keine Template-Orgie a la  C++ werden, da Mikrocontroller...

> Das Problem mit neuen Sprachen besteht darin, dass viele Codegeneratoren
> und Bibliotheken auf C/C++ ausgerichtet sind.

Ach, da koennen einem noch weitere Probleme einfallen. Zum Beispiel 
Compiler die bestimmte Zertifizierungen aufweisen. (SIL) Oder auch 
schlicht die Tatsache das jeder der im Embedded Bereich antritt perfekte 
C Kenntnisse haben muss weil ja der Source der letzten 20Jahre in C 
geschrieben wurde und den muss er immer noch warten, gelegentlich von 
Fehler befreien oder erweitern und in neuen Anwendungen weiter verwenden 
koennen. Wenn er also schon mal diese Kenntnisse aufweisst, warum sollte 
er sich dann noch eine zusaetliche Sprache antun? Und zwar fuer 
mindestens 10Jahre, in der Industrie gelten andere Zyklen als bei 
Endkundenware.

Das Problem mit C ist halt einfach das die Sprache da ist. Es weiss auch 
jeder das Microsoft oder Word schlecht ist, aber auch das ersetzt man 
nicht mal eben so.

Ausserdem hat C den grossen Vorteil einfach zu funktionieren, mit der 
Betonung auf "einfach". Bei vielen neuen Modesprachen hab ich den 
Eindruck als wenn sich da irgendwelche jugendlichen Informatikjuenger 
vor allem einen drauf abrubbeln wollen und es weniger auf 
Funktionalitaet ankommt.

Olaf

Strubi schrieb:
> Wie sieht das in der Praxis aus, macht das engineering-mässig Sinn, ein
> Mikro-Kernel in C zu schreiben und einen Applikations-Layer in Rust
> drüberzukleben

Warum nicht den Kernel auch in Rust?

Strubi schrieb:
> Und: es darf keine Template-Orgie a la  C++ werden, da
> Mikrocontroller...

Wieso? Ob man den Boilerplate-Code fehleranfällig und unwartbar von Hand 
schreibt oder automatisch per Templates generieren lässt, das Ergebnis 
in Form von Maschinencode sieht gleich aus. Templates haben an sich 
keinerlei Overhead! Templates sind gerade für Mikrocontroller gut, wo 
man teure Laufzeit-flexibilität durch Compiletime-Konfigurierbarkeit 
abwägen muss.

Olaf schrieb:
> Ausserdem hat C den grossen Vorteil einfach zu funktionieren, mit der
> Betonung auf "einfach". Bei vielen neuen Modesprachen hab ich den
> Eindruck als wenn sich da irgendwelche jugendlichen Informatikjuenger
> vor allem einen drauf abrubbeln wollen

Und hier ist es wieder, das Informatiker Bashing. Wie macht man denn 
z.B. in C "einfach" String-Verarbeitung, so einfach wie in der 
Modesprache Java? Oder typsichere Container (Gut für verlässliche 
Software!)? Oder strikte Kapselung? Hast du mal in einer der sogenannten 
Modesprachen gearbeitet und festgestellt wie schön es ist sich von den 
Restriktionen des uralten C lösen zu können und nicht zum 1000. Mal 
darüber nachzudenken wie man Strings konkateniert?

Von wegen "abrubbeln" - wer mit Leidenschaft dabei ist und gute Produkte 
abliefern möchte, freut sich über gute, wartbar, zuverlässige robuste 
Lösungen. Wie sie moderne Sprachen ermöglichen. Nicht jeder ist ein 
Konzernbeamter der mit seinen Kenntnissen von 1990 sein gesamtes 
Berufsleben bestreitet und mit Neuerungen bloß in Ruhe gelassen werden 
möchte.

> Nicht jeder ist ein Konzernbeamter der mit seinen Kenntnissen von 1990
> sein gesamtes Berufsleben bestreitet und mit Neuerungen bloß in Ruhe
> gelassen werden möchte.

Hihi, da bin ich ganz bei dir. :) Aber alle gesammelten Erkenntnisse 
seit 1990 werden immer noch verwendet und verkauft. Die kann man nicht 
ignorieren und einfach sagen wir machen etwas neu. Ich sehe die 
Nachteile von C durchaus. Aber der darin geschriebene Code muss weiter 
verwendbar bleiben. Du kannst nicht 20Jahre Entwicklung einfach in 
2Monaten neu schreiben.

Olaf

Olaf schrieb:
> Aber der darin geschriebene Code muss weiter
> verwendbar bleiben. Du kannst nicht 20Jahre Entwicklung einfach in
> 2Monaten neu schreiben.

Dagegen sagt ja auch keiner was. Aber es werden auch neue Projekte 
gestartet, und dafür kann man neue Technologien verwenden. Und nicht 
alles, was nach C erfunden wurde, ist eine Modeerscheinung. Tatsächlich 
ist eher C die Mode, weil so viel da irrational dran fest klammern!

Dr. Sommer schrieb:
> Wieso? Ob man den Boilerplate-Code fehleranfällig und unwartbar von Hand
> schreibt oder automatisch per Templates generieren lässt, das Ergebnis
> in Form von Maschinencode sieht gleich aus. Templates haben an sich
> keinerlei Overhead! Templates sind gerade für Mikrocontroller gut, wo
> man teure Laufzeit-flexibilität durch Compiletime-Konfigurierbarkeit
> abwägen muss.

Man kann Templates schon so schreiben, dass sie wenig Overhead 
generieren. Aber immer noch Overhead, gegenüber der handgestrickten 
Lösung. Alles schon durchgespielt.
C++ hat in einem robusten Kernel generell nichts zu suchen, den Fehler 
haben schon einige im näheren Umkreis gemacht. Hier gilt die Regel: 
schreibe expliziten Code nach einem vorgegebenen Schema. Das ist weder 
fehleranfällig noch unwartbar und schreit somit auch nicht nach 
Verbesserung. Je expliziter Code generiert wird, desto verifizierbarer 
ist er auch (Coverage-Tests).

C++ ist im 'Userspace' (auch auf dem uC) legitim und wird da auch 
gebraucht, man kann sich nur kräftig ins Knie schiessen. Wenn Rust 
gewisse Fehler/Sprachmissbrauch einfach nicht mehr erlaubt (dazu gehört 
auch das problematische Exception-Handling), wäre es ein besserer 
Kandidat als C++.
Ich bin generell der Meinung: Wenn eine Vielzahl von 
Programmier-Regeln/Guidelines einer klassischen Sprache einer Sprache 
gegenübersteht, die gewissen Unfug schon einfach nicht erlaubt, lerne 
ich lieber die neue Sprache, sofern das Framework nicht 'broken by 
design' ist. Der Rest sind Engineering-Details (API, 
Calling-Conventions) die einfach stimmen müssen. Bei C++ ist leider 
einiges broken by design, aber ich möchte diese Diskussion hier nicht 
(zum x-ten mal) führen..

Strubi schrieb:
> Man kann Templates schon so schreiben, dass sie wenig Overhead
> generieren. Aber immer noch Overhead, gegenüber der handgestrickten
> Lösung.

Interessant, hast du ein Beispiel? Das kann eigentlich nur sein, wenn 
die handgestrickte Lösung irgendwelche fall-spezifischen Optimierungen 
hat.

Strubi schrieb:
> C++ hat in einem robusten Kernel generell nichts zu suchen, den Fehler
> haben schon einige im näheren Umkreis gemacht.

Ich habe in C++ schon erfolgreich Kernel geschrieben und mich gefreut, 
wie schön man die Datenstrukturen in Klassen packen kann.

Strubi schrieb:
> Bei C++ ist leider
> einiges broken by design,

Ja, die Sachen die aus C übernommen wurden...

> Dagegen sagt ja auch keiner was. Aber es werden auch neue Projekte
> gestartet, und dafür kann man neue Technologien verwenden.

Natuerlich kommt das vor. Aber auch da hast du gerne mal 20-50% 
Weiterverwendung von altem Code. Und selbst wenn nicht, du hast dann 
immer noch 3-5 Ingenieure in deinem Team die 1990 angefangen haben und 
deine neue Modesprache nicht koennen. Aber die sind auch unverzichtbar 
weil sie die Erfahrung mitbringen die fuer ein Embedded-Projekt 
notwendig ist.
Und die lernst du auch nicht um weil Informatik-Gebabbel heute genauso 
verstaendlich ist wie eine Steuererklaerung. Was ich den Informatikern 
vorwerfe das sie in ihren Elfenbeintuermen bei Chips und Pizza hausen 
und sich eine neue coole Sprache nach der anderen ausdenken, aber dabei 
vergessen das draussen in der Welt damit normale Leute normale 
Anwendungen schreiben sollen. Leute mit Etechnik oder 
Maschinenbaustudium weil dieses Fachwissen der wichtige Teil der 
Anwendung ist und nicht die Geheimnisse der esoterischen Informatik.

> Tatsächlich ist eher C die Mode, weil so viel da irrational dran fest
> klammern!

Aehem..die Idee von Mode ist es eigentlich die Leuten zum kauf von neuen 
Klamotten anzuregen wenn das alte noch gut genug ist. .-)

BTW: Ich warte immer noch darauf das Smalltalk alle anderen Sprachen 
abloesst weil das jetzt die neue coole Sau im Dorf ist. Ich kann mich 
noch gut erinnern wie mir das um 2000 jeder erzaehlt hat.

Olaf

Olaf schrieb:
> Natuerlich kommt das vor. Aber auch da hast du gerne mal 20-50%
> Weiterverwendung von altem Code.

Tja, unter den JVM-basierten Modesprachen kann man alten Code super 
weiter verwenden, da binärkompatibel.

Olaf schrieb:
> Und die lernst du auch nicht um weil Informatik-Gebabbel heute genauso
> verstaendlich ist wie eine Steuererklaerung.

Im Gegenteil sind die Einführungen zu modernen Sprachen viel 
zugänglicher als C. Jeder Anfänger fragt sich was dieses kryptische 
"char* argv[]" heißen soll...

Olaf schrieb:
> Was ich den Informatikern
> vorwerfe das sie in ihren Elfenbeintuermen bei Chips und Pizza hausen
> und sich eine neue coole Sprache nach der anderen ausdenken, aber dabei
> vergessen das draussen in der Welt damit normale Leute normale
> Anwendungen schreiben sollen

Liest du nur TheoInf-Publikationen? z.B. die Sprache Kotlin ist so 
einfach, dass man sie "en passant" lernen kann. Mit Java-Kenntnissen 
versteht man sofort was passiert, und dank des großartigen automatischen 
Refactoring von z.B. Android Studio lernt man direkt wie man Kotlin 
effektiv nutzt. So kann man seine Codebasis easy Stück für Stück 
umstellen oder auch nur neue Module in Kotlin schreiben - ist ja alles 
kompatibel!
Es gibt heutzutage schicke Online-Tutorials welche die aktuellen 
Sprachen Stück für Stück erklären, sogar direkt mit Online-Kompilieren. 
Das hat nichts mit Elfenbeinturm zu tun.

Sprachen wie Python lernen sogar Kinder, weil sie so eingängig sind. 
Klar steckt im Parser eine Menge theoretische Informatik, aber das 
interessiert den Nutzer der Sprache nicht. Rate mal warum Python eine 
der bevorzugten Sprachen beim R-PI ist... Ok, Python ist nicht brandneu, 
aber definitiv aktuell.

Rust macht so vom schnellen ersten Überblick einen guten Eindruck.
Aber beruflich gesehen bleibt die Frage, ob es sinnvoll ist, das zu 
lernen. Wir wissen wahrscheinlich alle, dass die Industrie, gerade im 
sicherheitskritischen Bereich, oft sehr träge ist (bei einer Firma wurde 
vor Kurzem ein Prozessor von 1990 für neue Projekte ersetzt).
Da weiß man halt nicht, ob Rust eine Chance hat oder es aus praktischen 
Gründen doch bei MISRA-C oder Ada bleibt.

Andreas S. schrieb:
> Ich hatte einmal einen Kunden, der
> einen Diplom-Informatiker eingestellt hatte

Deppen gibt's überall... Ich kenne auch E-Techniker die für alles und 
jedes (billige China-) Arduinos verbauen um dann festzustellen dass das 
Konzept "einfacher Mikrocontroller plus alle Peripherie auf externen 
Modulen" auch nicht das Beste ist, vor allem wenn die dann nötigen 
Bibliotheken nicht gut sind.

Ein von uns beauftragtes Ing-Büro wollte das Problem, dass unser 
Embedded-Linux-System "versehentlich" über den USB-Port mit dem PC 
verbunden werden kann (was eigentlich nur für den Service vorgesehen 
ist) lösen, indem sie die Datenleitungen weglassen und so auch im 
Service das Flashen/Debuggen verhindern. Ich habe dann darauf 
hingewiesen dass man unter Linux einfach die USB-Treiber weglassen 
kann...

Andreas S. schrieb:
> Allerdings lief die Firmware nicht,
> und er zeigte mir ganz stolz sein riesiges objektorientiertes Framework.

Vielleicht habt ihr auch einfach jemanden mit dem falschen Fachgebiet 
eingestellt. Manche denken ja "Informatiker" heißt "kann alles was mit 
IT zu tun hat".

Dr. Sommer schrieb:
> Interessant, hast du ein Beispiel? Das kann eigentlich nur sein, wenn
> die handgestrickte Lösung irgendwelche fall-spezifischen Optimierungen
> hat.

Ist eine Weile her, den Code kann ich nicht ausgraben, aber so im 
Groben: Da anstatt echten Pointern für die Objekte Indices angelegt 
werden, wird entsprechend auch ein Iterator für den Smart Pointer 
generiert. Dafür wurde für jeden Iterator zum zugehörigen Objekttyp 
zusätzlicher Code erzeugt. Dasselbe Ding mit dynamischen Datentypen (vom 
Kernel bereitgestellt) macht in C weniger Overhead (Platz, 
Code-Effizienz nahezu gleichauf).
Es gab da auch Unterschied betr. CPU-Architektur, die nur in C-Stil 
wirklich portabel und explizit (ohne inline asm) umgesetzt werden 
können).
Da entscheide ich mich dann für das minimale Subset.

Dr. Sommer schrieb:
> Ich habe in C++ schon erfolgreich Kernel geschrieben und mich gefreut,
> wie schön man die Datenstrukturen in Klassen packen kann.

Ich meine einen kompakten OS-Kernel, verifizierbar. Was im Sinne von 
Linux, NuttX, FreeRTOS, usw. U.U. mit impliziter Haftung für fehlerfreie 
Ausführung.

Dr. Sommer schrieb:
> Ja, die Sachen die aus C übernommen wurden...

Haha. Schön wär's. Sicher gibt's Klimmzüge betr. C-Referenzen, aber es 
wurde eine Menge verschlimmbessert, die genau dazu führt, dass 
High-Level-Informatiker das Gefühl haben, C++-Code wäre mit seiner 
Implizitheit fehlerfrei zu schreiben und dann noch wunderschön 
abstrahiert. Genau das ist bei Safety fehl am Platz.

Dr. Sommer schrieb:
> Im Gegenteil sind die Einführungen zu modernen Sprachen viel
> zugänglicher als C. Jeder Anfänger fragt sich was dieses kryptische
> "char* argv[]" heißen soll...

Und genau da ist das Problem: Man muss mal den Prototyping-Charakter 
von C verstanden haben, sonst kapiert man nicht, was auf unterem Level 
bei C++ passiert, und kann es auch nicht debuggen. Da muss ein Anfänger 
durch.
Ich mache jetzt seit 20 Jahren Code-Analysen und muss leider sagen, dass 
im Gros der schlimmste unwartbare (aber natürich schöne!) Code in Form 
von C++ vorlag. Wegschmeissen, neu schreiben war jeweils billiger - 
schlussendlich zählt einfach die Hausnummer, und nicht der 
Wohlfühlfaktor. Da muss ich Olaf recht geben.

Olaf schrieb:
> Und selbst wenn nicht, du hast dann
> immer noch 3-5 Ingenieure in deinem Team die 1990 angefangen haben und
> deine neue Modesprache nicht koennen. Aber die sind auch unverzichtbar
> weil sie die Erfahrung mitbringen die fuer ein Embedded-Projekt
> notwendig ist.

Da kann man argumentieren, dass die ja die neue Modesprache schnell 
lernen könnte, wenn sie deutliche Vorteile aufweist. Der Punkt ist aber: 
die Fehlersuche (und ins-knie-schiessen) will man unbedingt gegenüber 
der herkömmlichen Methode minimiert sehen. Und es braucht mindestens 
einen teamfähigen Experten, der den anderen den Weg ebnet und sie 
anleiten kann.
Das ist bei Python eigentlich optimal, da ist immerhin das OO-Konzept 
wirklich logisch umgesetzt.

Insofern hat sich auch bisher keiner wirklich geweigert, gelieferte 
Python-Module und Scripte zu benutzen oder anzupassen.
Nur ist halt bei Python schwierig bis unmöglich, ein Compilat nach 
Safety-Kriterien zu verifizieren, ausser man macht gleich Hardware draus 
(MyHDL).

So wird hier Python also meistens nur als Prototyping-/Test-Umgebung 
genutzt und der Prototyp wieder in ein C-Modul verfrachtet, damit's auch 
auf dem uC läuft.

Ansonsten: Nix gegen C++ im Userspace, OO kann man auch sinnvoll 
betreiben. Nur manche Schmankerl der std:: sind auf gewissen Systemen 
pures implizites Gift und haben auch schon gehörigen Schaden 
angerichtet, weil die Programmierer nicht wussten, dass da irgendwo ein 
"realloc()" aufgerufen wird (und was es überhaupt macht).

Olaf schrieb:
> BTW: Ich warte immer noch darauf das Smalltalk alle anderen Sprachen
> abloesst weil das jetzt die neue coole Sau im Dorf ist. Ich kann mich
> noch gut erinnern wie mir das um 2000 jeder erzaehlt hat.

Irgendwie war's seiner Zeit auch voraus, aber jetzt haben wir ja Python.
Aber warum nicht, gerade für den IoT Hype liesse sich Smalltalk sicher 
aufwärmen. Forth schafft es ja auch immer mal wieder an die Oberfläche..

> Vielleicht habt ihr auch einfach jemanden mit dem falschen Fachgebiet
> eingestellt.

Ich habe eher den Eindruck als wenn die Komplexizitaet der Produkte 
heute so gross geworden ist das es selbst von sehr guten Teams wo alles 
perfekt laeuft nur noch in Ausnahmefaellen perfekt hinbekommen wird. Und 
sobald dann eine Kleinigkeit schief laeuft wird es dann sehr schnell 
sehr boese.

Und das ist natuerlich ein weitere Grund warum es neue Sprachen schwer 
haben. Wer will denn das Risiko eingehen das hinterher alle mit dem 
Finger auf einen zeigen wenn es schief geht.

Olaf

Strubi schrieb:
> Dafür wurde für jeden Iterator zum zugehörigen Objekttyp
> zusätzlicher Code erzeugt.

Wenn der Iterator jeweils unterschiedliche Dinge tut bleibt das nicht 
aus. Eine handgestrickte Lösung muss ja auch pro Typ was anderes tun. 
Wenn der erzeugte Code für die unterschiedlichen Iterator-Typen gleich 
ist, das template hier nur zwecks Typsicherheit benutzt wird (ähnlich 
Java Generics), dann ist wohl der Compiler zu alt/schlecht um dies zu 
bemerken. Man kann sich hier mit manueller Type Erasure behelfen, und 
das template nur als dünnen typisierten Wrapper um nicht-typisierten 
allgemeinen Code verwenden.

Strubi schrieb:
> Ich meine einen kompakten OS-Kernel
Ich auch.

Strubi schrieb:
> verifizierbar

Formale Verifikation a la L4? Ok, das gibt's für C++ nicht. Liegt aber 
nicht an C++ selbst, nur an fehlenden Tools.

Strubi schrieb:
> aber es
> wurde eine Menge verschlimmbessert, die genau dazu führt, dass
> High-Level-Informatiker das Gefühl haben, C++-Code wäre mit seiner
> Implizitheit fehlerfrei zu schreiben und dann noch wunderschön
> abstrahiert.

Was auch immer das heißen soll.

Strubi schrieb:
> Da muss ein Anfänger
> durch.

Ja, aber dann hat das noch mehr Elfenbein-Charakter als die 
Modesprachen.

Strubi schrieb:
> Ich mache jetzt seit 20 Jahren Code-Analysen und muss leider sagen, dass
> im Gros der schlimmste unwartbare (aber natürich schöne!) Code in Form
> von C++ vorlag.

Unwartbar durch Nicht-C++-Programmierer vielleicht... Ich habe auch 
schon sehr viel furchtbaren C-Code gesehen und mir gewünscht, dass die 
Leute vielleicht ein paar Paradigmen von den Modesprachen übernommen 
hätten.

Strubi schrieb:
> Nur manche Schmankerl der std:: sind auf gewissen Systemen
> pures implizites Gift

Manche Schmankerl aus stdlib.h auch. Bei C und C++ muss man wissen, 
welche Dinge man nicht nutzen sollte.

Strubi schrieb:
> weil die Programmierer nicht wussten, dass da irgendwo ein
> "realloc()" aufgerufen wird (und was es überhaupt macht).

Da gibt's ne ganz einfache Abhilfe: _sbrk nicht definieren, dann gibt's 
Linker-Fehler wenn man versehentlich malloc verwendet...

Strubi schrieb:
> Dr. Sommer schrieb:
>> Interessant, hast du ein Beispiel? Das kann eigentlich nur sein, wenn
>> die handgestrickte Lösung irgendwelche fall-spezifischen Optimierungen
>> hat.
>
> Ist eine Weile her, den Code kann ich nicht ausgraben, aber so im
> Groben: Da anstatt echten Pointern für die Objekte Indices angelegt
> werden,
Wer legt "Indices" statt "echten Pointer" an und was ist damit genau 
gemeint?
> wird entsprechend auch ein Iterator für den Smart Pointer
> generiert.
Jetzt gehts plötzlich um "Smart Pointer"? Wieso ein Iterator für Smart 
Pointer?
> Dafür wurde für jeden Iterator zum zugehörigen Objekttyp
> zusätzlicher Code erzeugt. Dasselbe Ding mit dynamischen Datentypen (vom
> Kernel bereitgestellt) macht in C weniger Overhead (Platz,
> Code-Effizienz nahezu gleichauf).
Was genau sind jetzt "dynamische Datentypen" die vom Kernel 
bereitgestellt werden?
> Es gab da auch Unterschied betr. CPU-Architektur, die nur in C-Stil
> wirklich portabel und explizit (ohne inline asm) umgesetzt werden
> können).
Was genau ist damit jetzt gemeint?
> Da entscheide ich mich dann für das minimale Subset.

Strubi schrieb:
> Prototyping-Charakter von C verstanden haben
Du meinst Variablendefinition oder -deklaration?

Nachdem ich deinen Beitrag mehrfach gelesen habe, gehe ich davon aus, 
dass du kein C++ kannst. Der Beitrag besteht aus einem Haufen 
zusammengewürfelter Schlagwörter, die zusammen keinen Sinn ergeben. Es 
gibt auch kein konkretes Beispiel oder sachliches Argument.

Dr. Sommer schrieb:
> Wenn der erzeugte Code für die unterschiedlichen Iterator-Typen gleich
> ist, das template hier nur zwecks Typsicherheit benutzt wird (ähnlich
> Java Generics), dann ist wohl der Compiler zu alt/schlecht um dies zu
> bemerken. Man kann sich hier mit manueller Type Erasure behelfen, und
> das template nur als dünnen typisierten Wrapper um nicht-typisierten
> allgemeinen Code verwenden.

Ein '*it' sollte nur aus einem 'Smart Pointer' (Pool-Nummer und 
Objekt-Index) einen Pointer machen. D.h. dieselbe Operation (ausg. Cast 
und sizeof(Objekt)) für alle Objekttypen.

Müsste eine gcc 3.x gewesen sein. Ich hätte auch erwartet, dass der 
Compiler erkennt, dass das mit genau einem Wrapper (index -> Pointer) 
abgehakt werden kann.

Nu, OO in C tut nicht so weh:

1

struct gna {

2

    LIST_HEADER

3

    Bla bla;

4

};

Und für die Iteratoren muss man halt Makros nehmen.

Dr. Sommer schrieb:
> Unwartbar durch Nicht-C++-Programmierer vielleicht...

Leider nein. Undebugbar durch C++-Programmierer. Sozusagen in letzter 
Instanz.

mh schrieb:
> Nachdem ich deinen Beitrag mehrfach gelesen habe

Dann liest du es eben noch ein paarmal durch, bis du es kapiert hast. 
Ein gewisses Bildungsniveau darf man erwarten, eine Antwort auf 
Trollgeunke nicht.

Strubi schrieb:
> Müsste eine gcc 3.x gewesen sein.

Also vor ewigen Zeiten...

Strubi schrieb:
> Ich hätte auch erwartet, dass der
> Compiler erkennt, dass das mit genau einem Wrapper (index -> Pointer)
> abgehakt werden kann.

Kann es eigentlich auch. Dann wurde irgendwas falsch gemacht.

Strubi schrieb:
> Nu, OO in C tut nicht so weh:

Und das dann für jeden Listen-Typ? Tut überhaupt nicht weh, nein...

Strubi schrieb:
> Leider nein. Undebugbar durch C++-Programmierer. Sozusagen in letzter
> Instanz.

Na, schlechten Code kann man in jeder Sprache produzieren. Ich habe 
meine C++-Fehler noch immer gefunden.

Dr. Sommer schrieb:
> Strubi schrieb:
>> Nu, OO in C tut nicht so weh:
>
> Und das dann für jeden Listen-Typ? Tut überhaupt nicht weh, nein...

Nutze selber gerne C++, aber wenn die Rahmenbedingungen C verlangen ist 
auch das OK. C11 _Generic hast du gesehen? Dazu ein mehrfach 
includierbares header file mit ein paar Macros fürs Tokenpasting. 
Fertig.
Ein template ist ja letztendlich auch nichts anderes.

Michael schrieb:
> Ein template ist ja letztendlich auch nichts anderes.

Ein Template kann viel mehr als schnöde Textersetzung, wie durch 
Mehrfach-Include-Tricks.
_Generic ist nur ein Ersatz für Funktions Overloads, nicht für 
Templates ("Generics"). Der Name ist halt total dämlich gewählt. Das ist 
im Endeffekt manuelles Name Mangling.

Dr. Sommer schrieb:
> Michael schrieb:
>> Ein template ist ja letztendlich auch nichts anderes.
>
> Ein Template kann viel mehr als schnöde Textersetzung, wie durch
> Mehrfach-Include-Tricks.
> _Generic ist nur ein Ersatz für Funktions Overloads, nicht für
> Templates ("Generics").

Klar. (Partielle) Spezialisierung, SFINAE, ...

> Der Name ist halt total dämlich gewählt. Das ist
> im Endeffekt manuelles Name Mangling.

Schon klar, aber daher nannte ich ja auch macros und tokenpasting. Als 
Beispiel soll etwa so ein Ring-Buffer mit unterschiedlich breiten 
Indextypen ersetzt werden:

1

template<typename T>

2

class Ring

3

{

4

  public:

5

    Ring(ring_size_t cap);

6

    bool Enqueue(const uint8_t *src, ring_size_t len);

7

    // instead of return bool, maybe exception also possible

8

    // more methods

9

  private:

10

    T rd_back;

11

    T wr_front;

12

    T size;

13

    const T capacity;

14

    uint8_t data[];

15

};

ring.h:

1

#ifndef RING_H

2

#define RING_H

3

4

// Instantiate all functions for 8 bit and 16 bit sized counters/indices.

5

6

#define RING_WIDTH 8

7

# include "ring_impl.h"

8

#undef  RING_WIDTH

9

10

#define RING_WIDTH 16

11

# include "ring_impl.h"

12

#undef  RING_WIDTH

13

14

// We use C11's _Generic keyword to automagically resolve, for example,

15

// ring_enqueue() to ring8_enqueue() or ring16_enqueue(), depending on the

16

// type of the first parameter (ring8_t* or ring16_t*).

17

18

# define GENERIC_FUN(OPNAME, R, ...)  \

19

   _Generic((R),                    \

20

        ring8_t*: ring8_##OPNAME,    \

21

        ring16_t*: ring16_##OPNAME)((R), ## __VA_ARGS__)

22

23

#define ring_dequeue(R, ...)   GENERIC_FUN(dequeue,R, ## __VA_ARGS__)

24

#define ring_empty(R, ...)     GENERIC_FUN(empty,  R, ## __VA_ARGS__)

25

#define ring_enqueue(R, ...)   GENERIC_FUN(enqueue,R, ## __VA_ARGS__)

26

#define ring_free(R, ...)      GENERIC_FUN(free,   R, ## __VA_ARGS__)

27

#define ring_init(R, ...)      GENERIC_FUN(init,   R, ## __VA_ARGS__)

28

#define ring_size(R, ...)      GENERIC_FUN(size,   R, ## __VA_ARGS__)

29

30

#endif //!RING_H

ring_impl.h:

1

#ifndef RING_H

2

# error "Never include this file directly; include ring.h instead."

3

#endif

4

5

#include <inttypes.h>

6

#include <stdbool.h>

7

8

#ifndef RING_WIDTH

9

# error "Missing #define RING_WIDTH to 8 bit or 16 bit."

10

#elif RING_WIDTH ==  8 || RING_WIDTH == 16

11

12

// We use token pasting to rename the functions/type aliases to their

13

// actual specified width (8 or 16 bit indices).

14

// Apart from the renaming, the code is the same for both.

15

16

# define TOKENPASTE(PREFIX, X, SUFFIX)      PREFIX##X##SUFFIX

17

# define TOKENPASTEWRAP(PREFIX, X, SUFFIX)  TOKENPASTE(PREFIX, X, SUFFIX)

18

// ...

19

# define ring_enqueue       TOKENPASTEWRAP(ring, RING_WIDTH, _enqueue)

20

# define ring_index_next    TOKENPASTEWRAP(ring, RING_WIDTH, _index_next)

21

# define ring_init          TOKENPASTEWRAP(ring, RING_WIDTH, _init)

22

# define ring_size_t        TOKENPASTEWRAP(uint, RING_WIDTH, _t)

23

# define ring_t             TOKENPASTEWRAP(ring, RING_WIDTH, _t)

24

25

#else

26

# error "Unsupported RING_WIDTH. Only 8 and 16 are allowed."

27

#endif

28

29

typedef struct {

30

    /// @brief Index of the next byte to read from #elem.

31

    ring_size_t rd_back;

32

    /// @brief Index where to write the next byte to in #elem.

33

    ring_size_t wr_front;

34

    /// @brief Number of allocated/used bytes.

35

    ring_size_t size;

36

    /// @brief Total size of the buffer in bytes.

37

    ring_size_t cap;

38

    /// @brief Flexible array member for the actual ring data.

39

    uint8_t elem[];

40

} ring_t;

41

42

/// @brief Reset a ring's indices for an empty ring.

43

/// @param[inout] r   the ring

44

/// @param[in]    cap the capacity the ring should be configured with

45

static inline void

46

ring_init(ring_t *const r, ring_size_t cap)

47

{

48

    if (!r || cap < 1)

49

        return;

50

51

    r->rd_back  = 0;

52

    r->wr_front = 0;

53

    r->size     = 0;

54

    r->cap      = cap;

55

    // no need to initialize elem[] buffer

56

}

57

58

/// @brief Increment an index with wrap around.

59

/// @param i   the index to increment

60

/// @param cap the capacity of the ring

61

/// @return incremented index with wrap around

62

static inline ring_size_t

63

ring_index_next(ring_size_t i, ring_size_t cap)

64

{

65

#if 0

66

    return ((ring_size_t)(i + 1)) % cap;

67

#else

68

    if (++i >= cap) {

69

        i = 0;  // wrap around

70

    }

71

    return i;

72

#endif

73

}

74

75

// ...

76

77

/// @brief Put elements into the queue.

78

/// @param[inout] r   the ring

79

/// @param[in]    src start of the block of data

80

/// @param[in]    len length in bytes of the source block

81

/// @return false if the ring is full, true on success

82

static inline bool

83

ring_enqueue(ring_t *const r, const uint8_t *src, ring_size_t len)

84

{

85

    if (!r || !src) {

86

        return false;   // invalid argument

87

    }

88

89

    if (ring_free(r) < len) {

90

        return false;   // not enough free space in ring

91

    }

92

    r->size += len;

93

94

    ring_size_t wr = r->wr_front;

95

    for (uint8_t i = 0; i < len; ++i) {

96

        r->elem[wr] = src[i];

97

        wr = ring_index_next(wr, r->cap);

98

    }

99

    r->wr_front = wr;

100

    return true;

101

}

102

103

#undef TOKENPASTE

104

#undef TOKENPASTEWRAP

105

// ... some skipped

106

#undef ring_enqueue

107

#undef ring_index_next

108

#undef ring_init

109

#undef ring_size_t

110

#undef ring_t

use_it.c

1

// ...

2

#include "ring.h"

3

// ...

4

#define BACKLOG_CAPACITY    120

5

6

static struct

7

{

8

#if BACKLOG_CAPACITY <= UINT8_MAX

9

    ring8_t ring;

10

#elif BACKLOG_CAPACITY <= UINT16_MAX

11

    ring16_t ring;

12

#else

13

# error "Backlog is too big. No suitable type to store it available."

14

#endif

15

    uint8_t data[BACKLOG_CAPACITY];

16

} backlog __attribute__((section(".noinit")));

17

18

static void

19

add_to_backlog(const uint8_t *src, uint8_t n)

20

{

21

    if (!ring_enqueue(&backlog.ring, src, n)) {

22

        // handle error: not enough free space in backlog

23

    }

24

}

Ist natürlich mehr Schreibaufwand als in C++, aber wenn der Rest alles C 
ist und ich nur den Ringbuffer benötige, werde ich nicht auf C++ 
umschwenken.

Michael schrieb:
> Ist natürlich mehr Schreibaufwand als in C++, aber wenn der Rest alles C
> ist und ich nur den Ringbuffer benötige, werde ich nicht auf C++
> umschwenken.

Warum nicht? Die _Generic Wrapper könnten ja den C++ Code aufrufen. Dann 
kann der restliche Code C bleiben.

Wer auf Biegen und Brechen C für Dinge nutzt, für die explizit C++ 
geschaffen wurde, bearbeitet auch Schrauben mit dem Hammer...

Dr. Sommer schrieb:
> Michael schrieb:
>> Ist natürlich mehr Schreibaufwand als in C++, aber wenn der Rest alles C
>> ist und ich nur den Ringbuffer benötige, werde ich nicht auf C++
>> umschwenken.
>
> Warum nicht? Die _Generic Wrapper könnten ja den C++ Code aufrufen. Dann
> kann der restliche Code C bleiben.
>
> Wer auf Biegen und Brechen C für Dinge nutzt, für die explizit C++
> geschaffen wurde, bearbeitet auch Schrauben mit dem Hammer...

Ich bin nur sehr vorsichtig, C und C++ zu mischen. Das ohne undefined 
behaviour hinzubekommen ist eine Kunst. Man denke z.B. an Exceptions, 
die zurück nach C geworfen werden. Ein einfaches "extern "C"" bzw. 
"extern "C++"" genuegt da nicht.

Michael schrieb:
> Man denke z.B. an Exceptions, die zurück nach C geworfen werden. Ein
> einfaches "extern "C"" bzw. "extern "C++"" genuegt da nicht.

Ja, da muss man Rückgabewerte verwenden. Immer noch besser als das 
Gewürge mit dem Präprozessor.

Dr. Sommer schrieb:
> Michael schrieb:
>> Man denke z.B. an Exceptions, die zurück nach C geworfen werden. Ein
>> einfaches "extern "C"" bzw. "extern "C++"" genuegt da nicht.
>
> Ja, da muss man Rückgabewerte verwenden. Immer noch besser als das
> Gewürge mit dem Präprozessor.

Man muss vor allem die Exceptions fangen bevor man sie auf einen 
Rückgabewert zurückführen kann.

Meine nur: C und C++ zu mischen ist extrem heikel. Sind halt komplett 
verschiedene Sprachen mit dem gleichen ersten Buchstaben, mehr nicht.
Es klappt eigentlich nur, weil GCC über die eigentlichen Sprachstandards 
hinaus gehende Garantien macht. Aber zwei durch unterschiedliche 
Compiler erstellte Kompilate kombinieren (z.B. Library + Programm) wird 
formell fast immer UB sein.
In der Praxis funktioniert das schon, aber wenn man den Standards folgt 
ist es quasi unmöglich.

Michael schrieb:
> Ich bin nur sehr vorsichtig, C und C++ zu mischen. Das ohne undefined
> behaviour hinzubekommen ist eine Kunst. Man denke z.B. an Exceptions,
> die zurück nach C geworfen werden. Ein einfaches "extern "C"" bzw.
> "extern "C++"" genuegt da nicht.

Das ist genau der Punkt, an dem Coverage-Tests (im Simulator) mit C++ 
versagen und der Compiler auch mal 'toten Code' generieren kann. Das ist 
dann auch extrem mühsam zu debuggen. Da habe ich lieber eine saubere 
Cleanup-Funktion die manuell explizit aufräumt (switch(state) { case: 
...} ). Da sieht man sofort, in welchem (Fehler-)Zustand das System ist, 
und kann nachweisen, dass zu allen Fehlerzuständen X die Aufräumprozedur 
ihren Job richtig macht. Manche Kunden erwarten das auch explizit so in 
der Code-Review.
Es ist schlussendlich das alte Lied: Wenn man alles an C++ abstellt, was 
problematisch ist, kann man auch C nehmen. Oder Ada. Das Mehr an 
Schreibarbeit zahlt sich spätestens beim expliziten Debuggen (was bei 
Templates a la Boost-Murks schon ein Albtraum werden kann) aus.

Michael schrieb:
> Meine nur: C und C++ zu mischen ist extrem heikel.

Dass C++ abwärtskompatibel zu C ist, ist ja eigentlich kein Zufall... 
Die Standard Bibliothek ist ja auch großteils C.

Strubi schrieb:
> Wenn man alles an C++ abstellt, was problematisch ist, kann man auch C
> nehmen

Also genau alles von C++ ist problematisch? Auch sowas wie richtige 
Konstanten statt Makros?

Strubi schrieb:
> Das Mehr an Schreibarbeit zahlt sich spätestens beim expliziten Debuggen
> (was bei Templates a la Boost-Murks schon ein Albtraum werden kann) aus.

Das ist ja genau der Witz. Weil der C++ Compiler strenger Typen prüfen 
und Fehler finden kann, muss man weniger Debuggen. Deswegen kommen C 
Programmierer mit C++ auch nicht klar - wenn der Compiler sich beschwert 
dass man einen int in einen std::vector<std::string> packen möchte, ist 
er sauer, weil er das Programm nicht übersetzen und starten kann... um 
genau diesen Fehler suchen zu können.