Ich bin ja wirklich erstaunt, daß mein Frage ein recht reges Interesse geweckt hat.

Naja, ich werd wohl niemals die Zeit für die beiden Klammern benötigen, die aufgrund meiner Frage
hier deswegen verbraten wurde

Was hab ich für ein Problem mit "C" ?????

Angefangen hat alles mit Bits und Bytes.
"C" kennt aber gar kein Byte.
Das kann man sich dann selbst definieren, (unsigned char)
also eine Ableitung von einem "negativen Ascii-Character" ohne Vorzeichen.
Was für ein Scheiss ist das denn....

Bei Abfragen ob etwas gleich ist, muss man
nicht etwa "=" schreiben, das wär wohl zu "ungenau",
nein, man muss "==" schreiben, also "besonders gleich"

Vernünftige Compiler können Boolsche Ausdrücke von logischen Ausdrücken
selbst unterscheiden. Bei "C" geht das nicht. Und da es schon nicht geht,
können wir auch gleich noch entsprechende Sonderzeichen einführen,
dann merkt man das nicht sofort.
Aus XOR wird ^
aus AND wird &
Und auch hier heisst es wieder "besonders und" && oder
besonders oder "||" was generell mit Klammern umschrieben wird.
Naja wen wundert es da noch, daß man für "<>" kleiner größer auch gleich
was neues erfunden hat: != also "Achtung Nicht Gleich" ist gemeint.
Achja, habt Ihr schon mal versucht mit Strings zu arbeiten in "C"
Das war anscheinend nie vorgesehen und so hat man eine Bibliothek
namens "strings" rangebastelt.
Nun sollte man aber nicht glauben, daß man damit "vernünftig" arbeiten kann.
Wo ist denn die Funktion zum Einfügen eines Characters oder Strings in einen
Vorhandenen ??? "StrIns" oder so ähnlich....
Da ich schon beim Thema Strings bin, kann ich folgendes definieren in C
char name[]="Hallo";
wenn ich das im Programmcode versuche:
name = "Hallo"; geht es plötzlich nicht mehr.
Nun muss ich mit "strcpy" arbeiten. Also von Hinten Durch Die Brust Ins Auge....
Die Fehlerhäufigkeit in meiner Software ist exponentiell zum "verkürzten, kryptischen C Code"
angestiegen. Und Gott und die Welt programmiert nun mit dem Schei........
und leider hat mich meine Firma auch dazu verbannt.
Was solls, im nächsten Leben werd ich Gärtner........
Ich wünsche allen ein "absturzfreies" Wochenende.
Siro

So nun möche ich aber etwas positive ssagen:

Den letzten Artikel von "Besserwessi" finde ich sehr gut.
Die neueren Compiler zwingen einem schon eine gewisse Disziplin einzuhalten.
Das find ich auch gut so, lieber einen Warning mehr, der im Vorfeld schon auf Fehler
deuten kann. Auch meine negative Äußerung , was z.B die Stringverarbeitung angeht,
ist ja schon wesentlich besser gelöst worden in C++ Jave usw.
Hatte übrigens Pascal schon von Anfang an besser gelöst.
Nullterminierte Strings sind einfach "Grütze" darf ich das so sagen ???
Erstmal "durchhechten" wo denn die 0 zu finden ist. Wenns dann etliche Kilobyte sind
absolute Resourcenverschwendung.

Aber ein Thema habe ich bisher noch garnicht angesprochen:
Das betrifft vermutlich alle Hochsprachen. Für eine komplexe Software oder auch nur
zur Dokumentation hat man (hoffentlich) ein Flussdiagramm, Ablaufdiagramm Jordan oder
was auch immer. Durch die Optimierung eines Compilers, stimmt dieser Ablauf aber
unter Umständen garnicht mehr. Wenn ich im Diagramm festlege, daß bei
einem bestimmten Ereignis z.B eine Unterfunktion angesprungen wird und es auch so
programmiert habe, kann mir der Compiler einen Strich durch die Rechnung machen.
Je nach Einstellung macht er plötzlich keinen Unterprogrammaufruf sondern fügt den Code direkt
in das aufrufende Programm ein. Das spart Zeit, ist schlau und auch funktionell. Leider entspricht
es nicht meinem Flussdiagramm. Wenn ich z.B eine Stackbelastung vorausberechne liege ich dann
falsch, diesmal im positiven Sinne, weil weniger Stack benötigt wird. Es könnte aber auch sein,
daß ich mich darauf verlassen habe, daß mittels Assembler Code auf die Stackvariablen zugegriffen
wird. Das weis natürlich nicht der Compiler und es würde in die Hose gehen. Hier habe ich aber
schon aus diesem Forum erfahren, daß die meisten Compiler eine Schalter haben um diese Optimierung
abzuschalten. -noinline oder ähnliches.

Na wie dem auch sei. Einen wirklich "Eindeutigen" Code, unabhängig von irgend welchen Compiler
Einstellugnen, habe ich nur wenn ich in Assembler programmiere. Das hab ich auch die letzten 30
Jahre getan. Nun blick ich oftmals durch den erzeugten Code vom C-Compiler nicht mehr durch.
Ist schon "witzig" je nach Compiler Einstellung ist mein Code zur Zeit 14 KByte oder 8 KByte
groß. Wie soll man denn das dokumentieren ? zwecks ISO usw. ????
Was steht denn in den "verlorenen" 6 KByte ??? Für Sicherheitsrelevenate Anwendungen z.B.
in der Medizintechnik ist das für mich unverantwortlich, mal eben 6 KByte Code wegzulassen.
Wenns dann funktioniert okay....
In Assembler konnte ich bisher jedes Bit nachweisen, was es tut, warum, und zu welchem Zeitpunkt.
In C kann ich ja nichtmal die Laufzeit angeben für eine Funktion, da sie sich je nach Optimierung
ändert. InAssembler habe ich die Laufzeiten in Nano Sekunden dokumentieren können.
Bin ich ein "C"-Gegner ? Jaaaaaaaaa
Siro