Forum: Compiler & IDEs Linux ist endlich vom C89 Standard weg


von Nano (Gast)


Lesenswert?

Rolf M. schrieb:
> Nano schrieb:
>> Wie schon gesagt, bei dem Fallthrough Problem wird genau das gemacht:
>> Siehe nochmal:
>> https://lwn.net/Articles/794944/
>>
>> Und das ist vor allem abwärtskompatibel und würde so noch mit C89
>> funktionieren. Es müsste nur der Compiler angepasst werden.
>
> Also Kompatibilität, indem man neue Syntax-Elemente einfach in die
> Kommentare verschiebt? Das halte ich für eine sehr schlechte Idee.

Bei Übergangslösungen bis es ein mut für mutable Keyword in der nächsten 
Standardversion gibt, ist das eine durchaus sinnvolle Lösung.
mut int 42: // durch das mut Keyword ist int explizit veränderlich
Zumal damit jeder Compiler umgehen kann, denn ein Compiler, diese 
Funktion nicht kann, ignoriert ja ohnehin das Kommentar.



> Nano schrieb:
>> Es geht also erst einmal darum, diese Möglichkeit überhaupt zu bieten.
>> Da so etwas noch nicht im Sprachstandard ist, geht das jetzt also nur so
>> wie bei dem fallthrough Teil auch nur über Kommentare oder
>> Compilerspezifische Attribute.
>
> Oder Makros.
>
1
> #if __STDC_VERSION__ < 202205L
2
> #define mut
3
> #endif
4
>

Willst du dann für jede Variablendefinition einen doppelten 
Codeabschnitt schreiben?
1
#if MUT
2
mut int 42;
3
#else
4
int 42;
5
#endif

6 Zeilen für eine einzige Variable?

Dann doch lieber im Kommentar:
/* mut */ int 42; // compiliert überall und bietet trotzdem das Feature 
bei fähigen compilern.

und später:
mut int 42; // ist dann nur noch für C2x Compiler.

von Rolf M. (rmagnus)


Lesenswert?

Wilhelm M. schrieb:
> Bei einer Schnittstelle wie
> namespace ProtocollA{
>  class Connection {
>      void shutdown();
>      template<size_t N>
>      bool sendTo(const Address&, const std::array<std::byte, N>&) const;
>  };
> }
>
> brauche ich keine Kommentare. Ggf. kann in der Realisierung auf noch
> eine Vorbedingung wie static_assert(N < 256) eingebaut werden.

Naja, was sagt der Return-Wert? Bedeutet true, dass es einen Fehler gab 
oder dass es keinen Fehler gab? Wie bekomme ich raus, welcher Fehler 
aufgetreten ist? Blockiert die Funktion beim Senden oder kehrt sie 
sofort zurück?  Gibt es irgendwelche Voraussetzungen, die die Adresse 
erfüllen muss? Was passiert, wenn sie die nicht erfüllt? Gibt es 
Voraussetzungen, die das Connection-Objekt erfüllen muss, um senden zu 
können? Was passiert, wenn die nicht erfüllt sind? Was wenn die Größe 
erst zur Laufzeit bekannt ist? Was passiert, wenn N 0 ist? Gibt es einen 
Puffer, der volllaufen kann? Gibt es irgendwelche anderen Gründe, 
weshalb das Senden fehlschlagen kann?

Nano schrieb:
> Und wenn aus Performancegründen Wertebereichprüfungen bewusst
> weggelassen werden, dann muss der gültige Wertebereich in einem
> Dokumentationskommentar definiert sein.

Das ist eigentlich völlig unabhängig davon, ob die Prüfung erfolgt oder 
nicht. Wenn der Wert nicht im gültigen Bereich ist, ist das ein Fehler, 
daher muss man dem Nutzer der Funktion mitteilen, was der gültige 
Bereich ist.

von Nano (Gast)


Lesenswert?

Roland F. schrieb:
> Hallo,
> Nano schrieb:
>> Weil man damit bestehenden Code verbessern könnte.
>
> Oder auch nicht.
> Wer weiß ob durch die "Sprachverbesserung" nicht Seiteneffekte
> entstehen, die an anderer Stelle ganz neue Probleme.

Das ist nicht möglich.
Als Kommentar wird das nämlich ignoriert und als C2x Keyword compiliert 
der Code auf alten Compilern nicht.

Und ansonsten ändert sich am Code ja nichts.
Bisher gilt alles, was kein const davor stehen hat, als veränderlich.
Das wäre dann immer noch so.
Der Compiler würde bei entsprechender Compileroption dann lediglich eine 
Warnung geben, dass nicht explizit der int Wert als veränderlich 
definiert ist.

Und wenn es davor steht, dann würde das bei einem Compiler, der das 
nicht kann, bei einem Kommentar keinen Unterschied machen und bei einem 
Compiler, der das kann, der würde dann explizit wissen, dass die 
Variable veränderlich sein soll und keine Warnung an der Stelle 
ausgeben.
Und so sollte es ja sein.

Damit umgeht man das Problem ohne die Sprache wesentlich zu verändern, 
dass man bei C vergessen hat, alle Variablen von Anfang an als implizit 
const zu definieren.
Und das ist doch schön.

In Zukunft wird es mit so einer Option, wenn es dann als keyword im C2x 
Standard ist dann halt lediglich etwas mehr Tipparbeit, wenn man immer 
auch noch ein mut vor den Typ setzen muss, wenn der Datentyp nicht 
konstant sein soll und der Compiler nicht meckern soll.

von Stefan F. (Gast)


Lesenswert?

Nano schrieb:
> Du bist dann doch gar nicht davon betroffen.
> Wenn du nicht damit rechnest, dann nutzt du die Compileroption ja nicht.

Doch schon, denn ich bin kein Einzelkämpfer. Ich arbeite in einem 
international verteiltem Team. Jeder kann etwas anderes besser.

von Nano (Gast)


Lesenswert?

MaWin schrieb:
> Nano schrieb:
>>> Ich finde es auch sehr blöd, wenn funktionale Anweisungen in Kommentaren
>>> verborgen werden. Damit rechnet man nicht, vor allem nicht, wenn man
>>> dieses oder jenes "neue" Feature dieser Art noch nicht kennt.
>>
>> Du bist dann doch gar nicht davon betroffen.
>> Wenn du nicht damit rechnest, dann nutzt du die Compileroption ja nicht.
>
> Wenn du ein solches Feature hinter einem Schalter verbirgst, dann kannst
> du es auch gleich vernünftig implementieren und ein neues keyword
> einführen oder ähnliches.

Genau das habe ich doch gesagt.

Es geht aber darum, dass auch für alten nicht C2x Code nutzen zu können. 
Und dann geht das nur mit einem Kommentar oder einem Attribut und beim 
Attribut hättest du das Problem, dass es halt nicht mehr überall 
compilieren würde, was man ja vermeiden will.

von Femto (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Stefan ⛄ F. schrieb:
>>> int<0, 99> p;
>>
>> Bei REST Interface geben wir tatsächlich den Wertebereich an, sofern er
>> für irgend etwas wichtig ist. Ich frage mich nur, was die
>> Programmiersprache mit so einer Angabe anfangen soll. Sie kann ja
>> schlecht bei jeder Zuweisung/Operation die Gültigkeit prüfen und ggf.
>> eine Exception auslösen. Erstens gibt es in C keine Exceptions und
>> zweitens würde das die Performance versauen.
>
> Natürlich eine Assertions-Verletzung feuern.
>
>> Das ist allerdings eine gute Stelle für Kommentare.
>>
>>> int p; // must be 0-99, requested in ticket 1234
>
> Nein, dann sollte man es so schreiben:
>
>
1
> const int p = calculate();
2
> assert((p >= 0) && (p <= 99));
3
>
>
> Assertionen sind auswertbare Kommentare!

Darf ich mich hier mal einklinken?

Hier steht zu assert folgendes:

https://www.c-plusplus.net/forum/topic/59867/was-ist-assert-und-was-macht-das/2

Zitat

"ASSERT wird nur im DEBUG ausgewertet.
Verwende VERIFY.

Verwendest du ASSERT und macht eine Bedingung davon abhängig dann wirst 
du dich im Release wundern das es nicht mehr funktioniert da alles im 
ASSERT im Release nicht ausgefügrt wird.

Ist ungefähr vergleichbar mit

#ifdef _DEBUG

wo dann nur ausgeführt wird wenn Debugmode."

??

von Nano (Gast)


Lesenswert?

Rolf M. schrieb:
> Nano schrieb:
>> Und wenn aus Performancegründen Wertebereichprüfungen bewusst
>> weggelassen werden, dann muss der gültige Wertebereich in einem
>> Dokumentationskommentar definiert sein.
>
> Das ist eigentlich völlig unabhängig davon, ob die Prüfung erfolgt oder
> nicht. Wenn der Wert nicht im gültigen Bereich ist, ist das ein Fehler,
> daher muss man dem Nutzer der Funktion mitteilen, was der gültige
> Bereich ist.

Wenn du das in deiner Schnittstelle überprüfst, was Performance kosten 
wird, dann kannst du auf den Fehler eingehen und den behandeln, sofern 
es behandelbar ist. Der Nutzer deiner Schnittstelle müsste sich dann 
nicht darum kümmern, da es ja deine Schnittstelle schon macht.

Nur dann, wenn der Fehler nicht innerhalb der Schnittstelle behandelbar 
ist, müsstest du den Nutzer deiner Schnittstelle darauf hinweisen.

Ebenso hat man das Problem, wenn du in deiner Schnittstelle keine 
Überprüfung und Fehlerbearbeitung drin hast, z.b. weil es keine 
Performance kosten soll. Erst dann muss der Nutzer deiner Schnittstelle 
wissen, mit welchen Daten er sie füttern darf.

Insofern ist das nicht unabhängig.

von Wilhelm M. (wimalopaan)


Lesenswert?

Nano schrieb:
>>
>> Oder Makros.
>>> #if _STDC_VERSION_ < 202205L
>> #define mut
>> #endif
>>
>
> Willst du dann für jede Variablendefinition einen doppelten
> Codeabschnitt schreiben?#if MUT
> mut int 42;
> #else
> int 42;
> #endif

Nein.
Man schreibt ein einfach
1
mut int a{42};

Das macht z.B. Qt mit verschiedenen Sachen so.

von Nano (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Nano schrieb:
>> Du bist dann doch gar nicht davon betroffen.
>> Wenn du nicht damit rechnest, dann nutzt du die Compileroption ja nicht.
>
> Doch schon, denn ich bin kein Einzelkämpfer. Ich arbeite in einem
> international verteiltem Team. Jeder kann etwas anderes besser.

Wenn du an dem Code mitarbeiten musst/möchtest, dann musst die dich 
natürlich den Bedingungen unterwerfen, unter dem der Code entwickelt 
wird.
Aber das machst du ja ohnehin schon so, du passt ja auch dein Coding 
Style daran an.
Also wirst du auch einen passenden fähigen Compiler einsetzen und das 
Kommentar somit immer richtig setzen, so dass dein Code, wenn du ihn 
commitest ohne Warnungen compiliert.

von Wilhelm M. (wimalopaan)


Lesenswert?

Femto schrieb:
>>>> int p; // must be 0-99, requested in ticket 1234
>>
>> Nein, dann sollte man es so schreiben:
>>
>>
1
>> const int p = calculate();
2
>> assert((p >= 0) && (p <= 99));
3
>>
>>
>> Assertionen sind auswertbare Kommentare!
>
> Hier steht zu assert folgendes:
>
> https://www.c-plusplus.net/forum/topic/59867/was-ist-assert-und-was-macht-das/2
>
> Zitat
>
> "ASSERT wird nur im DEBUG ausgewertet.
> Verwende VERIFY.

Was ist ASSERT?
Es ging um assert().

> Verwendest du ASSERT und macht eine Bedingung davon abhängig dann wirst
> du dich im Release wundern das es nicht mehr funktioniert da alles im
> ASSERT im Release nicht ausgefügrt wird.

Ja, assert() wird im Release-Build vom CPP entfernt.
assert() ist ein function-like CPP-macro, aber ohne allg. Rückgabewert 
(bspw. im debug-build nicht vorgechrieben), daher kannst Du es nicht in 
einem if-statement (oder #if-directive) verwenden, wenn Du das meinst.

Zusicherungen sind, wie ich oben schonmal geschrieben habe, dafür da, 
die interne Logik des Artefakts sicherzustellen. Dazu gehören Vor- und 
Nachbedingungen und bspw. alle Formen von Invarianten (oft 
Zustandsinvarianten von Objekten).

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Nano schrieb:
> Zumal damit jeder Compiler umgehen kann, denn ein Compiler, diese
> Funktion nicht kann, ignoriert ja ohnehin das Kommentar.

Ja. Aber nur die Versionen, bevor du Kommentare zu Syntax und Semantik 
gemacht hast.
Das ist ein one-shot. Danach ist die Annahme "ignoriert ja ohnehin das 
Kommentar" nicht mehr wahr.
Ab dem Zeitpunkt bekommst du nach und nach mit jedem neuen 
"Kommentarfeature" die gleichen Kompatibilitätsprobleme, wie außerhalb 
von Kommentaren auch.

von Nano (Gast)


Lesenswert?

MaWin schrieb:
> Nano schrieb:
>> Zumal damit jeder Compiler umgehen kann, denn ein Compiler, diese
>> Funktion nicht kann, ignoriert ja ohnehin das Kommentar.
>
> Ja. Aber nur die Versionen, bevor du Kommentare zu Syntax und Semantik
> gemacht hast.
> Das ist ein one-shot. Danach ist die Annahme "ignoriert ja ohnehin das
> Kommentar" nicht mehr wahr.

Doch und zwar genau dann, wenn du diese Compileroption nicht nutzt.
Es geht also auch mit einem neuen Compiler.

> Ab dem Zeitpunkt bekommst du nach und nach mit jedem neuen
> "Kommentarfeature" die gleichen Kompatibilitätsprobleme, wie außerhalb
> von Kommentaren auch.

Da das zuschaltbare Compileroptionen sind, sehe ich das nicht so. Die 
sind nämlich kein Sprachstandard, also kann man da auch wieder 
umdefinieren.
Aber wozu sollte das hier nötig sein?

von MaWin (Gast)


Lesenswert?

Nano schrieb:
> Da das zuschaltbare Compileroptionen sind, sehe ich das nicht so. Die
> sind nämlich kein Sprachstandard, also kann man da auch wieder
> umdefinieren.
> Aber wozu sollte das hier nötig sein?

Ab dem Zeitpunkt musst du dir Gedanken darüber machen, welche 
Schlüsselwort-Kommentare es bereits gab und wie es zu Uneindeutigkeiten 
und Inkompatibilitäten führen kann, wenn du wieder eins einführst. Wenn 
du jetzt ein weiteres Keyword wie /* immut */ einführst - warum auch 
immer - dann wechselwirkt das mit dem alten /* mut */ und allen anderen. 
Die Annahme, dass Kommentare neutral sind, ist ab dem Moment falsch, ab 
dem du sie zur Funktionalität erhoben hast.

Und nein, "es ist hinter einem Schalter, also ist es dein Problem" ist 
keine Lösung des Problems. Es wälzt die Lage lediglich auf den ohnehin 
schon durch 9000 Compilervarianten gestressten Programmierer ab.

von Wilhelm M. (wimalopaan)


Lesenswert?

Was soll das mit diesen Kommentaren für ein neues Schlüsselwort?

Mach doch einfach
1
#if defined(ENABLE_MUTABLE)
2
# define PRE_MUT mut
3
#else
4
# define PRE_MUT
5
#endif

Dann kannst Du das passende zu Deinem Compiler einschalten (oder 
ausschalten). Ok, es darf PRE_MUT nicht sonst im Code vorkommen. 
Deswegen ein gescheiter Präfix.

Einen alten Code musst Du auch bei der Kommentarlösung anfassen. Der 
Aufwand ist also gleich zu dieser Lösung.
Bei neuem Code baust Du das gleich ein, und kannst das feature 
entsprechend Deiner Compiler-Version benutzen. Nach 10 Jahren kannst Du 
es ja auch ganz raus werfen. Wie gesagt, das macht Qt schon immer recht 
erfolgreich.

von Rolf M. (rmagnus)


Lesenswert?

Nano schrieb:
>> Das ist eigentlich völlig unabhängig davon, ob die Prüfung erfolgt oder
>> nicht. Wenn der Wert nicht im gültigen Bereich ist, ist das ein Fehler,
>> daher muss man dem Nutzer der Funktion mitteilen, was der gültige
>> Bereich ist.
>
> Wenn du das in deiner Schnittstelle überprüfst, was Performance kosten
> wird, dann kannst du auf den Fehler eingehen und den behandeln, sofern
> es behandelbar ist.

Da es hier um einen programminternen logischen Fehler geht (z.B. deiner 
Variable, die im Bereich 0 bis 99 liegen muss, soll jetzt plötzlich 120 
zugewiesen werden), gibt es keinen sinnvollen Weg, das zu behandeln. Du 
hast eigentlich in dem Fall nur drei Möglichkeiten:
1. Geordneter Rückzug, also Programm beenden
2. Schreibzugriff unterdrücken - dann steht aber ein falscher Wert in 
der Variable
3. Schreibzugriff trotzdem durchführen - dann steht aber ein illegaler 
Wert in der Variable

> Der Nutzer deiner Schnittstelle müsste sich dann nicht darum kümmern, da
> es ja deine Schnittstelle schon macht.

Der Nutzer muss sich drum kümmern, sonst kann das Programm nicht 
funktionieren. Die Schnittstelle prüft lediglich, ob die Vorgaben auch 
wirklich eingehalten wurden (dann kann man den Fehler erkennen) oder 
eben nicht (dann passiert halt irgendwas).

> Nur dann, wenn der Fehler nicht innerhalb der Schnittstelle behandelbar
> ist, müsstest du den Nutzer deiner Schnittstelle darauf hinweisen.

Das ist aber nur bei Fehlern der Fall, die nicht intern in der 
Programmlogik liegen, sondern von außen kommen, z.B. der Versuch, eine 
Datei zu öffnen, die nicht existiert. Da gehört aber dann auch kein 
assert hin.

> Ebenso hat man das Problem, wenn du in deiner Schnittstelle keine
> Überprüfung und Fehlerbearbeitung drin hast, z.b. weil es keine
> Performance kosten soll. Erst dann muss der Nutzer deiner Schnittstelle
> wissen, mit welchen Daten er sie füttern darf.

Nein. Wenn er sie mit bestimmten Daten nicht füttern darf, dann ist das 
so. Soll der Programmierer etwa erst durch einen Assert-Fehler bemerken, 
dass 120 kein gültiger Wert für die Variable ist?

von W.S. (Gast)


Lesenswert?

Rolf M. schrieb:
> Der Quatsch schon wieder? Ja, wenn man selbst einen Header schreibt,
> gehört der im Gegensatz zu den Standard-Headern nicht zum Umfang des
> Standards. Was hat das jetzt mit stdint.h zu tun?

Ich habe das eben genau so mal formuliert, damit auch der Verbissenste 
mal kapieren muß, daß all das, wofür man eine Datei (für gewöhnlich 
Headerdatei genannt) braucht, eben prinzipiell NICHT zum Sprachumfang 
gehört. Ganz egal, ob so eine Datei nun vom Hersteller einer Toolchain 
oder von irgend einem anderen verfaßt wurde.

Besagte Datei muß zwangsweise vom Compiler verarbeitet werden und kann 
folglich nur bereits im Sprachumfang enthaltenes Zeug beinhalten, sonst 
ist sie fehlerhaft. Wer das nicht begreift, der ist schlichtweg dumm.

Fazit: Mawins Annahme, daß irgendein uint32_t o.ä. zum Sprachstandard 
gehört, ist eben falsch. Und durch gebetsmühlenartiges Wiederholen wird 
sie nicht wahrer.

Und was das mit dem Mantel zu tun hat? Nun, der kommt auch daher, wenn 
Mawin daher kommt, aber deswegen gehört der Mantel noch lange nicht zu 
Mawins Körperteilen. Genau so, wie all das Zeugs, was in einer mit der 
Toolchain dazu kommt, nicht zum Sprachstandard gehört.

Benutzt euren Kopf doch mal zum logischen Denken.

W.S.

von W.S. (Gast)


Lesenswert?

Rolf M. schrieb:
>> Programmiersprache schaffen und etablieren, die alles besser kann und
>> macht.
>
> Das haben schon so viele gemacht. Deshalb gibt es jetzt eine
> unüberschaubare Anzahl von Programmiersprachen. Die eine perfekte "one
> language to rule them all" ist dennoch nicht dabei.

Naja, das stimmt in der hier formulierten Allgemeinheit nicht.
Sondern:
Es hat schon viele Leute gegeben, denen C nicht gefällt oder zu wenig 
kann, weswegen einige davon sich Programmiersprachen ausgedacht hatten, 
die sie für besser hielten. Aber es ist jedesmal nur eine Art von 
durchgekautes C dabei herausgekommen und die Toolchain für solches Zeugs 
war zumeist nix als eine Art "Vorbrenner", der aus dem Quelltext einen 
C-Text gemacht hat.

Und dir ist das 'unüberschaubar' ? Naja, wenn man C verbessern will ohne 
es tatsächlich zu verbessern, dann ergibt das eine selbstgebaute 
Zwickmühle.

W.S.

von Nano (Gast)


Lesenswert?

Rolf M. schrieb:
> Nano schrieb:
>> Wenn du das in deiner Schnittstelle überprüfst, was Performance kosten
>> wird, dann kannst du auf den Fehler eingehen und den behandeln, sofern
>> es behandelbar ist.
>
> Da es hier um einen programminternen logischen Fehler geht (z.B. deiner
> Variable, die im Bereich 0 bis 99 liegen muss, soll jetzt plötzlich 120
> zugewiesen werden), gibt es keinen sinnvollen Weg, das zu behandeln. Du
> hast eigentlich in dem Fall nur drei Möglichkeiten:
> 1. Geordneter Rückzug, also Programm beenden
> 2. Schreibzugriff unterdrücken - dann steht aber ein falscher Wert in
> der Variable
> 3. Schreibzugriff trotzdem durchführen - dann steht aber ein illegaler
> Wert in der Variable

1-3 bedeutet behandeln. Was meinst du was das ist?

Mal angenommen du hast Höhendaten vom Satellit und willst das mit einer 
anderen Karte kombinieren. Dann ist ein Wolkenkratzer ein Spike, der da 
nicht in die Bodenleveldaten hingehört.
Also kannst du das behandeln und bspw. mit den umgebenden Daten 
nivellieren. Die Daten werden nicht perfekt sein, aber für einen 
Flugsimulator reicht's.

>> Der Nutzer deiner Schnittstelle müsste sich dann nicht darum kümmern, da
>> es ja deine Schnittstelle schon macht.
>
> Der Nutzer muss sich drum kümmern, sonst kann das Programm nicht
> funktionieren.

Wie schon gerade beschrieben, es kommt ganz darauf an.

>> Nur dann, wenn der Fehler nicht innerhalb der Schnittstelle behandelbar
>> ist, müsstest du den Nutzer deiner Schnittstelle darauf hinweisen.
>
> Das ist aber nur bei Fehlern der Fall, die nicht intern in der
> Programmlogik liegen, sondern von außen kommen, z.B. der Versuch, eine
> Datei zu öffnen, die nicht existiert. Da gehört aber dann auch kein
> assert hin.

Das ist bereits der Fall, wenn deine Routine schnell sein soll und mit 
den gleichen Daten häufig wiederholt aufgerufen wird.


>> Ebenso hat man das Problem, wenn du in deiner Schnittstelle keine
>> Überprüfung und Fehlerbearbeitung drin hast, z.b. weil es keine
>> Performance kosten soll. Erst dann muss der Nutzer deiner Schnittstelle
>> wissen, mit welchen Daten er sie füttern darf.
>
> Nein. Wenn er sie mit bestimmten Daten nicht füttern darf, dann ist das
> so. Soll der Programmierer etwa erst durch einen Assert-Fehler bemerken,
> dass 120 kein gültiger Wert für die Variable ist?

Siehe oben. Lies da nochmal.

von Wilhelm M. (wimalopaan)


Lesenswert?

W.S. schrieb:
> Ich habe das eben genau so mal formuliert, damit auch der Verbissenste
> mal kapieren muß, daß all das, wofür man eine Datei (für gewöhnlich
> Headerdatei genannt) braucht, eben prinzipiell NICHT zum Sprachumfang
> gehört. Ganz egal, ob so eine Datei nun vom Hersteller einer Toolchain
> oder von irgend einem anderen verfaßt wurde.
>
> Besagte Datei muß zwangsweise vom Compiler verarbeitet werden und kann
> folglich nur bereits im Sprachumfang enthaltenes Zeug beinhalten, sonst
> ist sie fehlerhaft. Wer das nicht begreift, der ist schlichtweg dumm.

Ihr schießt Euch hier regelmäßig selbst ins Knie. Haltet Euch doch mal 
an die Begriffsdefinition: im C-Standard ISO/IEC 9899 ist die 
Kern-Sprache (dort einfach nur Language genannt) wie auch die Header 
bzw. Standard-C-Lib beschrieben.

von Stefan F. (Gast)


Lesenswert?

Wenn man C nennenswert verbessert, kommt eine andere Sprache dabei 
heraus. Das ist bereits mehrfach passiert.

Ich programmiere µC trotzdem in C. Ich fahre auch gerne ein Auto dass 
ganz gewiss nicht das beste ist.

von Rolf M. (rmagnus)


Lesenswert?

W.S. schrieb:
> Ich habe das eben genau so mal formuliert, damit auch der Verbissenste
> mal kapieren muß, daß all das, wofür man eine Datei (für gewöhnlich
> Headerdatei genannt) braucht, eben prinzipiell NICHT zum Sprachumfang
> gehört. Ganz egal, ob so eine Datei nun vom Hersteller einer Toolchain
> oder von irgend einem anderen verfaßt wurde.

Es gehört nicht zum Sprachkern, aber zum Umfang des Standards, und das 
ist es, worauf es ankommt. Es ist ein Standardheader, der mit jedem 
standardkonformen Compiler mitgeliefert wird - in einer natürlich zu 
genau diesen Compiler passenden Variante.

> Besagte Datei muß zwangsweise vom Compiler verarbeitet werden und kann
> folglich nur bereits im Sprachumfang enthaltenes Zeug beinhalten, sonst
> ist sie fehlerhaft.

Das ist grundlegend falsch. Da ein Standardheader zum Compiler gehört, 
kann er intern auch beliebig auf compilerspezifische Dinge 
zurückgreifen, und davon wird in der Praxis auch Gebrauch gemacht. 
Tatsächlich muss es nicht mal zwingend eine Datei sein. Der Compiler 
kann sich auch entscheiden, #include <stdint.h> einfach als Trigger zu 
verwenden, um eine entsprechende, bereits im Compiler eingebaute 
Funktionalität zu aktivieren, ohne dass überhaupt irgendeine Datei dafür 
existieren müsste.

> Wer das nicht begreift, der ist schlichtweg dumm.

Nur weil du nicht begreifen kannst oder willst, dass Standardheader 
nicht das gleiche sind wie Header, die man als Programmierer selbst für 
sein Programm schreibst, sind andere also dumm…
Was du bisher nicht plausibel erklären konntest ist, warum es überhaupt 
eine Rolle spielt, ob uint32_t nun im Sprachkern oder einem 
Standardheader umgesetzt ist.

> Fazit: Mawins Annahme, daß irgendein uint32_t o.ä. zum Sprachstandard
> gehört, ist eben falsch. Und durch gebetsmühlenartiges Wiederholen wird
> sie nicht wahrer.

Selbstverständlich gehört es zum Standard. Du kannst das gerne im 
Standard nachlesen, da ist das alles spezifiziert.

von Wilhelm M. (wimalopaan)


Lesenswert?

Nano schrieb:
>> Da es hier um einen programminternen logischen Fehler geht (z.B. deiner
>> Variable, die im Bereich 0 bis 99 liegen muss, soll jetzt plötzlich 120
>> zugewiesen werden), gibt es keinen sinnvollen Weg, das zu behandeln. Du
>> hast eigentlich in dem Fall nur drei Möglichkeiten:
>> 1. Geordneter Rückzug, also Programm beenden
>> 2. Schreibzugriff unterdrücken - dann steht aber ein falscher Wert in
>> der Variable
>> 3. Schreibzugriff trotzdem durchführen - dann steht aber ein illegaler
>> Wert in der Variable
>
> 1-3 bedeutet behandeln. Was meinst du was das ist?

Nein, man hat nur eine Möglichkeit, und das ist 1.: Abbruch.
Denn das Programm ist damit nachgewiesenermaßen falsch. Punkt, Ende, 
Aus.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Rolf M. schrieb:
> In einem mathematischen Gleichungssystem können sich die Werte von
> Variablen auch nicht ändern, da es...

Ist dir eigentlich jemals der fundamentale Unterschied zwischen 
Gleichungen und Ergibtanweisungen bewußt geworden?

W.S.

von Wilhelm M. (wimalopaan)


Lesenswert?

Zum Feierabend haue ich jetzt - nach dem Einschränken des Wertebereiches 
(s.o. int<0,99>) - noch einen Spruch raus: die fundamentalen Datentypen 
sind dazu da, das man sie im wesentlichen nicht direkt benutzt: es sind 
nur Grundbausteine, um sich domänenspezifische Datentypen zu erstellen. 
Also statt double etwa Distance<Km>, was man dann durch Duration teilen 
kann, und dann kommt Velocity dabei heraus, und eben nicht ein 
semantikfreier double-Wert. Dieser Ansatz lässt sich auf alle benötigten 
Objekte und ihre Typen ausdehnen, eben je nach Problem-Domäne.

von MaWin (Gast)


Lesenswert?

W.S. schrieb:
> daß all das, wofür man eine Datei (für gewöhnlich
> Headerdatei genannt) braucht, eben prinzipiell NICHT zum Sprachumfang
> gehört. Ganz egal, ob so eine Datei nun vom Hersteller einer Toolchain
> oder von irgend einem anderen verfaßt wurde.
>
> Besagte Datei muß zwangsweise vom Compiler verarbeitet werden und kann
> folglich nur bereits im Sprachumfang enthaltenes Zeug beinhalten, sonst
> ist sie fehlerhaft.

https://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

> 7.1.2 Standard headers
> The standard headers are ... <stdint.h> ...

Du liegst falsch. Ganz einfach.

> Wer das nicht begreift, der ist schlichtweg dumm.

Wer im Glashaus sitzt.

von Stefan F. (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Nein, man hat nur eine Möglichkeit, und das ist 1.: Abbruch.

Denke mal ein bisschen über deinen Tellerand hinaus. Zum Beispiel an 
eine Datenbank für einen Online Shop. Bloss weil irgendwo eine ungültige 
Zahl aufgetaucht ist, soll ganz sicher die die DB ausfallen und damit 
der ganze Online Shop.

Ähnlich ist es bei Maschinen. Bloß weil z.B. der Beschleunigungssensor 
in der Stoßstange ungültige Werte liefert, sollte das Auto auf keinen 
Fall mitten auf der Autobahn abschalten.

Oder wenn im Elektroherd eine Kochstelle ausgefallen ist, soll deswegen 
nicht der ganze Herd unbrauchbar werden.

Deswegen eignet sich assert meiner Meinung nach in vielen Fällen nicht. 
Fehler müssen oft behandelt werden. Ein Totalausfall des Programms ist 
oft nicht akzeptabel.

von W.S. (Gast)


Lesenswert?

Rolf M. schrieb:
> Was du bisher nicht plausibel erklären konntest ist, warum es überhaupt
> eine Rolle spielt, ob uint32_t nun im Sprachkern oder einem
> Standardheader umgesetzt ist.

Dann erkläre ich es dir: jeder könnte sich eine Headerdatei schreiben 
und sich Namen nach eigenem Gusto für die im Sprachstandard enthaltenen 
Variablentypen selber machen. In der Vergangenheit wurde das ja auch 
sehr häufig gemacht. Sowas wie uint32_t ist genauso gut oder schlecht 
wie U32 oder DWORD und da das alles auf 'int' mit diversen Prädikaten 
(long, signed usw.) zurückgeführt wird, wozu eben zumeist besagte 
Headerdateien dienen, ist so etwas nicht zum Sprachstandard gehörig.

Man könnte es auch grob so sagen: was nicht der Compiler von sich aus 
versteht, das gehört auch nicht zum Sprachumfang. Grob ist das aus 2 
Gründen: zum einen mag es Compiler geben, die manche Datenformate wie 
z.B. float nicht unterstützen (Tiny C oder so) und zum anderen gibt es 
öfters plattform- oder tool-spezifische Dinge (siehe _irq), die 
Erweiterungen von bestimmten Compilern sind und nicht zum Sprachumfang 
gehören.

W.S.

von W.S. (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Mit ^ dahinter hätte man das Problem nicht mit der Multiplikation
> gehabt, dafür aber mit XOR ^ - das gibts in Pascal ja nicht. Also
> gleiches Problem, irgendwo hätte es ein anderes Symbol gebraucht.

Irrtum.
In Pascal gibt es AND, OR, XOR, NOT und noch einiges mehr. Da braucht 
man keine Sondertasten dafür. Hast du bloß nicht gewußt oder grad mal 
vergessen.

W.S.

von Stefan F. (Gast)


Lesenswert?

W.S. schrieb:
> Man könnte es auch grob so sagen: was nicht der Compiler von sich aus
> versteht, das gehört auch nicht zum Sprachumfang.

Wir haben dich schon verstanden. Deine Meinung bleibt jedoch Quatsch.

Es gibt eine Spezifikation, die fest legt, was zur Sprache gehört und 
was nicht.

von MaWin (Gast)


Lesenswert?

W.S. schrieb:
> Dann erkläre ich es dir: jeder könnte sich eine Headerdatei schreiben
> und sich Namen nach eigenem Gusto für die im Sprachstandard enthaltenen
> Variablentypen selber machen.

Ja, und? Es geht hier um stdint.h und nicht um irgendeine selbst 
geschriebene Datei. stdint.h gehört eben zum Standard.

Ich verstehe überhaupt nicht, was dich antreibt.
Es wurde bewiesen, dass du falsch liegst.
Trotzdem behauptest du weiterhin steif und fest richtig zu liegen.

Schaue vielleicht einfach mal in den C-Standard rein. Wäre das eine 
Idee? Du hast es offensichtlich noch nie getan.

von (prx) A. K. (prx)


Lesenswert?

W.S. schrieb:
> Hast du bloß nicht gewußt oder grad mal vergessen.

Es ging in meinem Beitrag um das ^ Symbol, das in Pascal für 
Dereferenzierung genutzt wird, aber in C aufgrund des Operators für 
exklusives Oder das gleiche Problem hätte wie *. Hast du bloss nicht 
verstanden.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

W.S. schrieb:
> Man könnte es auch grob so sagen: was nicht der Compiler von sich aus
> versteht, das gehört auch nicht zum Sprachumfang.

Zum Sprachumfang zählt alles, was der Sprachstandard definiert.

von Zombie (Gast)


Lesenswert?

Rolf M. schrieb:
> Da es hier um einen programminternen logischen Fehler geht (z.B. deiner
> Variable, die im Bereich 0 bis 99 liegen muss, soll jetzt plötzlich 120
> zugewiesen werden), gibt es keinen sinnvollen Weg, das zu behandeln. Du
> hast eigentlich in dem Fall nur drei Möglichkeiten:
> 1. Geordneter Rückzug, also Programm beenden
> 2. Schreibzugriff unterdrücken - dann steht aber ein falscher Wert in
> der Variable
> 3. Schreibzugriff trotzdem durchführen - dann steht aber ein illegaler
> Wert in der Variable

Was passiert bei?
1
char a = 1234;
-> undefined behavior
das würde ich auch für
1
int<-128,127> a = 1234;
erwarten. das sagt dem Compiler lediglich, dass er platz für Ganzzahlen 
zwischen -128 und 127 bereitstellen soll. Diesen Bereich nicht zu 
verlassen liegt dann in der Verantwortung des Programmierers.

von MaWin (Gast)


Lesenswert?

Zombie schrieb:
> Was passiert bei?
> char a = 1234;
> -> undefined behavior

Ja, genau. Es mangelt in C an UB. Deshalb müssen wir unbedingt auch bei 
trivialsten Zuweisungen noch die Möglichkeit für UB hinzufügen.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Wilhelm M. schrieb:
> Zum Feierabend haue ich jetzt - nach dem Einschränken des Wertebereiches
> (s.o. int<0,99>) - noch einen Spruch raus: die fundamentalen Datentypen
> sind dazu da, das man sie im wesentlichen nicht direkt benutzt: es sind
> nur Grundbausteine, um sich domänenspezifische Datentypen zu erstellen.
> Also statt double etwa Distance<Km>, was man dann durch Duration teilen
> kann, und dann kommt Velocity dabei heraus, und eben nicht ein
> semantikfreier double-Wert.

Dann haue ich jetzt auch noch einen Spruch raus:

Keine zwei Variablen sollten vom selben Typ sein, d.h. für jede Variable
wird ihr eigener Typ definiert. Für Funktionsargumente hast du diese
Vorgehensweise ja schon propagiert, aber sie sollte konsequenterweise
auf alle Variablen ausgedehnt werden.

Damit gehören fehlerträchtige Konstrukte wie bspw.
1
a = b;

endlich der Vergangenheit an. Da a und b für völlig verschiedene Dinge
stehen (sonst hätten sie nicht verschiedene Namen), ist eine Zuweisung
von b nach a grundsätzlich falsch. Wegen der unterschiedlichen
Datentypen von a und b ist nun auch der Compiler in der Lage, den Fehler
aufzudecken.

Ein weiterer Vorteil: Die eineindeutige Zuordnung zwischen Datentypen
und Variablen ermöglicht es, Variablen nach ihrem Typ zu benennen, also
bspw.
1
class DrehzahlLinkesVorderrad {
2
  ...
3
};
4
5
class DrehzahlRechtesVorderrad {
6
  ...
7
};
8
9
DrehzahlLinkesVorderrad DrehzahlLinkesVorderrad;
10
DrehzahlRechtesVorderrad DrehzahlRechtesVorderrad;

Somit geht aus dem Variablennamen nicht nur die Bedeutung des Inhalts,
sondern auch direkt der Datentyp hervor. Außerdem entfallen jegliche
Gründe für hässliche Suffixe an den Typnamen (bspw. "_t"), wie sie heute
noch von vielen verwendet werden.

Wer sich konsequent an diese und Wilhelms Regeln hält, wird automatisch
nur noch fehlerfreien Qualitätscode schreiben. Der Preis, den man dafür
zahlen muss, sind halt kilometerlange Header mit Klassendeklarationen,
was aber angesichts der immensen Vorteile verschmerzbar sein sollte.

von Nano (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Nein, man hat nur eine Möglichkeit, und das ist 1.: Abbruch.
> Denn das Programm ist damit nachgewiesenermaßen falsch. Punkt, Ende,
> Aus.

Du brichst beim Wolkenkratzer ab, mein Programm funktioniert weiter.

von Nano (Gast)


Lesenswert?

Yalu X. schrieb:>
> Dann haue ich jetzt auch noch einen Spruch raus:
>
> Keine zwei Variablen sollten vom selben Typ sein, d.h. für jede Variable
> wird ihr eigener Typ definiert. Für Funktionsargumente hast du diese
> Vorgehensweise ja schon propagiert, aber sie sollte konsequenterweise
> auf alle Variablen ausgedehnt werden.
>....
>
> Wer sich konsequent an diese und Wilhelms Regeln hält, wird automatisch
> nur noch fehlerfreien Qualitätscode schreiben. Der Preis, den man dafür
> zahlen muss, sind halt kilometerlange Header mit Klassendeklarationen,
> was aber angesichts der immensen Vorteile verschmerzbar sein sollte.

Als Geschenk zwei Tags:
[ironie]
[/ironie]

Die habe ich nämlich gesucht, kann dich aber verstehen.

von Jemand (Gast)


Lesenswert?

Nano schrieb:
> Mal angenommen du hast Höhendaten vom Satellit und willst das mit einer
> anderen Karte kombinieren. Dann ist ein Wolkenkratzer ein Spike, der da
> nicht in die Bodenleveldaten hingehört.
> Also kannst du das behandeln und bspw. mit den umgebenden Daten
> nivellieren. Die Daten werden nicht perfekt sein, aber für einen
> Flugsimulator reicht's.

Vielleicht magst du noch einmal erläutern, welche Verwendung ein hart im 
Wertebereich eingeschränkter Typ für erwartbar abweichende Daten hat. 
Die Unterstellung, dass Wilhelm in diesem Fall einen solchen Typ 
verwenden würde, halte ich doch für ziemlich abwegig.

von Wilhelm M. (wimalopaan)


Lesenswert?

Stefan ⛄ F. schrieb:
> Wilhelm M. schrieb:
>> Nein, man hat nur eine Möglichkeit, und das ist 1.: Abbruch.
>
> Denke mal ein bisschen über deinen Tellerand hinaus. Zum Beispiel an
> eine Datenbank für einen Online Shop. Bloss weil irgendwo eine ungültige
> Zahl aufgetaucht ist, soll ganz sicher die die DB ausfallen und damit
> der ganze Online Shop.
>
> Ähnlich ist es bei Maschinen. Bloß weil z.B. der Beschleunigungssensor
> in der Stoßstange ungültige Werte liefert, sollte das Auto auf keinen
> Fall mitten auf der Autobahn abschalten.
>
> Oder wenn im Elektroherd eine Kochstelle ausgefallen ist, soll deswegen
> nicht der ganze Herd unbrauchbar werden.
>
> Deswegen eignet sich assert meiner Meinung nach in vielen Fällen nicht.
> Fehler müssen oft behandelt werden. Ein Totalausfall des Programms ist
> oft nicht akzeptabel.


Mit Zusicherungen (wird derzeit in C / C++ durch assert() realisiert,
in Zukunft ggf. anders) wird NIEMALS eine Behandlung von externen 
Fehlern
durchgeführt: externe Fehler sind bspw. fehlerhaften Daten in einer 
Datei oder
DB, falsche Benutzereingaben, Netzwerkabbruch, ... Wenn Du möchtest 
kannst Du
diese externen Fehler noch in erwartbare und nicht-erwartbare 
unterteilen, und
anhand dieser Unterschiedung kannst Du ggf. die Art der Fehlerbehandlung
unterscheiden: etwa Exceptions für nicht-erwartbare Fehler und 
Rückgabewert
mit additiven Datentypen wie etwa std::optional<> für erwartbare Fehler.

Fehler in externen Daten sind ganz normaler Input für ein Programm und 
die
Verarbeitung dieser (fehlerhaften) Daten ist ganz normaler 
Programmablauf.

Aber die obige Unterscheidung spielt hier jetzt keine Rolle.
Das hat ja nichts mit Zusicherungen zu tun.
Zusicherungen stellen sicher, dass der  die Programmierer keine  
weniger
logische interne Fehler in die SW einbaut. Das Aufrufen einer Funktion 
mit
den richtigen Parametern ist Verantwortung der Aufrufers (Caller), die 
aufgerufene
Funktion (Callee) überprüft trotzdem in Form von sog. Vorbedingungen 
(einer der
verschiedenen Einsatzzwecke von assert()) diese Vorbedingungen. Stell 
Dir das so vor,
dass Programmierer A den Caller schreibt und Programmierer B den Callee. 
Beide
gehen einen Vertrag dabei ein über die Argumente / Parameter. Gewisse 
Dinge
kann der Compiler statisch prüfen z.B. die Signatur oder zur 
Compile-Zeit
bekannte Werte. Alles andere kann erst zur Laufzeit geprüft werden. Es 
ist aber
genauso schlimm: die SW hat einen fundamentalen Fehler! Diese Fehler 
wird leider
erst zur Laufzeit aufgedeckt, aber da das Programm hier nun 
nachgewiesenermaßen
inkorrekt in sich selbst ist, muss es abgebrochen werden. Es ist 
gewissermaßen ein Fehler, der eigentlich zur Compilezeit aufgedeckt 
werden sollte, aber bei der heutigen Technik erst zur Laufzeit 
aufgedeckt wird. Daher ist die einzig sinnvolle Maßnahme hier ein 
Programmabbruch.
In der Produktionsversion der SW werden die assert()-Anweisungen sowieso 
durch den CPP entfernt. Dort werden also gar keine Zusicherungen 
geprüft, und können demzufolge das Programm nicht abbrechen. Damit 
verschwindet die Vorbedingung natürlich nicht aus dem Code, sie ist 
immer noch vorhanden, aber sie hat andere Konsequenzen (ob dann ein 
Abbruch erfolgt oder ein falsches Ergebnis berechnet
wird, hängt von der Art des Fehlers ab. Bricht das Programm ab, ist das 
gut, läuft es mit dem unentdeckten Fehler weiter (etwa: falscher Preis 
für ein Produkt) ist das schlecht).

Konstruiertes Beispiel:
1
const UserData* data = processUserInput(...);
2
const Result result = evaluateData(data);

Die erste Funktion liest die Daten (User-Input, Netzwerkdaten, 
Messwerte, ...) und
bringt sie von der externen in eine interne Form (DT UserData), sofern 
sie das kann.
Falsche externe Daten führen hier als erwartbarer Fehler zu einem 
nullptr-Rückgabewert.

Leider ist der Vertrag zwischen den Funktionen verletzt:
1
Result evaluateData(const UserData* const data) {
2
   Result result;
3
   assert(data);
4
   for(UserData* it = data; *data; ++data)
5
       result.featureA(computeA(*data));
6
   }
7
   return result;
8
}

Dummerweise verlangt evaluateData() einen Zeigerwert != nullptr, d.h. 
hier gehört nullptr
nicht zum Wertebereich des Parameters data. Denn die Dereferenzierung im 
Kopf des for()-stmts
führt zu einem Abbruch. D.h. der Code IN der Funktion verlangt ab einem 
gewissen Punkt
(direkt vor der Schleife) dass data != nullptr ist. Diese Bedingung muss 
immer gelten (daher
nennt man das Invariante). Diese Invariante ist hier (in diesem 
Beispiel) identisch mit
der Vorbedingung bzgl. des Paranmeterwertes data.
BTW: dies ist natürlich letztlich ein Designfehler: anstatt eine 
nullable-Referenz nämlich
einen Zeiger zu nehmen, wäre hier einen non-nullable-Referenz nämlich 
eine C++-Referenz
richtig gewesen. Aber manchmal muss man ja nehmen, was man vorfindet ;-)

Der interne Fehler ist in der Verantwortung des Callers, der umgebenden 
Funktion, die beide
Operationen verkettet. Hier hätte die Behandlung des externen Fehlers 
stattfinden müssen:
1
const UserData* data = processUserInput(...);
2
if (!data) {
3
   // ... Fehlerbehandlung
4
   exit(1);
5
}
6
const Result result = evaluateData(data);

Ggf. kann man diese auch noch im Caller explizit dokumentieren:
1
const UserData* data = processUserInput(...);
2
if (!data) {
3
   // ... Fehlerbehandlung
4
   exit(1);
5
}
6
7
assert(data); // Kommentar, der tatsächlich überprüft wird
8
const Result result = evaluateData(data);

Bei den Tests der Software wird nun dieser Fehler auftauchen, sofern die 
Tests auch mit
falschen externen Daten durchgeführt werden. Das Schöne dabei ist, dass 
die Fehlermeldung
dann auch die Zeilennummer und Dateiname enthält. Ohne die Assertion 
wäre eine unspezifische
segmentation violation die Folge; zum Glück bei diesem Fehler sogar 
definitiv, dass liegt
aber daran, dass das Beispiel sehr sehr einfach ist (s.o.).

Sorry für den langen Text: ich hatte keine Zeit, mich kürzer zu fassen.

von Wilhelm M. (wimalopaan)


Lesenswert?

Zombie schrieb:
> Rolf M. schrieb:
>> Da es hier um einen programminternen logischen Fehler geht (z.B. deiner
>> Variable, die im Bereich 0 bis 99 liegen muss, soll jetzt plötzlich 120
>> zugewiesen werden), gibt es keinen sinnvollen Weg, das zu behandeln. Du
>> hast eigentlich in dem Fall nur drei Möglichkeiten:
>> 1. Geordneter Rückzug, also Programm beenden
>> 2. Schreibzugriff unterdrücken - dann steht aber ein falscher Wert in
>> der Variable
>> 3. Schreibzugriff trotzdem durchführen - dann steht aber ein illegaler
>> Wert in der Variable
>
> Was passiert bei?
>
1
> char a = 1234;
2
>
> -> undefined behavior
> das würde ich auch für
>
1
> int<-128,127> a = 1234;
2
>
> erwarten. das sagt dem Compiler lediglich, dass er platz für Ganzzahlen
> zwischen -128 und 127 bereitstellen soll. Diesen Bereich nicht zu
> verlassen liegt dann in der Verantwortung des Programmierers.


Die Initialisierung
1
char a = 1234;
ist natürlich kein UB.
Es handelt sich hier um eine gültige Integerkonvertierung.

Daher schreibt man die Initialisierung besser als
1
char a{1234};
Dann erhält man einen Compilezeit-Fehler.
1
int<-128, 127> a = 1234;
ergibt natürlich auch kein UB, sondern einen Assertionsfehler, wenn
das ein UDT ist, ansonsten sollten wir die Sprache ja so erweitern, dass 
es kein UB ist, sondern eine interne Assertion feuert.

von Wilhelm M. (wimalopaan)


Lesenswert?

Wilhelm M. schrieb:

Sorry, da war ein Fehler drin (hätte nicht compiliert):
1
Result evaluateData(const UserData* const data) {
2
   Result result;
3
   assert(data);
4
   for(const UserData* it = data; *data; ++data)
5
       result.featureA(computeA(*data));
6
   }
7
   return result;
8
}

: Bearbeitet durch User
von Rolf M. (rmagnus)


Lesenswert?

Nano schrieb:
> 1-3 bedeutet behandeln. Was meinst du was das ist?

1 terminert das Programm, 2 und 3 hinterlässt es in einem inkonsistenten 
Zustand, in dem es eigentlich nicht sein darf. Behandeln bedeutet für 
mich sinnvoll damit umgehen, aber es gibt keine Möglichkeit, sinnvoll 
damit umzugehen.

> Mal angenommen du hast Höhendaten vom Satellit und willst das mit einer
> anderen Karte kombinieren. Dann ist ein Wolkenkratzer ein Spike, der da
> nicht in die Bodenleveldaten hingehört.
> Also kannst du das behandeln und bspw. mit den umgebenden Daten
> nivellieren. Die Daten werden nicht perfekt sein, aber für einen
> Flugsimulator reicht's.

Das ist dann aber ein Fehler in den Daten und nicht im Programm.

> Wie schon gerade beschrieben, es kommt ganz darauf an.

Ja, genau. Ich hab das Gefühl, wir reden an einander vorbei. Ich 
unterscheide zwischen logischen Fehlern im Programm und Fehlern im 
Input. Ersterer kann normalerweise nicht sinnvoll behandelt werden, 
letzterer natürlich schon - und sollte auch.

Wilhelm M. schrieb:
> Also statt double etwa Distance<Km>, was man dann durch Duration teilen
> kann, und dann kommt Velocity dabei heraus, und eben nicht ein
> semantikfreier double-Wert.

Das hat durchaus einen gewissen Charme, wobei ich die Einheit vom Typ 
trennen würde. Ich habe letztens an einer Sprache mitgearbeitet, die 
bereits einen eingebauten Mechanismus für physikalische Typen hat. 
Einheiten für diese Typen kann man sich dann separat definieren. Da geht 
dann sowas (in der Syntax dieser Sprache):
1
distance: length = 100km
2
duration: time = 1hour
3
my_speed: speed = distance / duration
statt 1hour kann ich z.B. genauso gut auch 60min schreiben oder die 
distance in Meilen angeben. Beim Auslesen muss man natürlich dann 
angeben, in welcher Einheit man's haben will. Die Umrechnung erfolgt 
automatisch.   Auch die lästige Unterscheidung zwischen rad und Grad 
fällt z.B. weg.
In C++ sollte sich das nachbilden lassen, allerdings im Vergleich 
vermutlich recht umständlich.

W.S. schrieb:
> Rolf M. schrieb:
>> Was du bisher nicht plausibel erklären konntest ist, warum es überhaupt
>> eine Rolle spielt, ob uint32_t nun im Sprachkern oder einem
>> Standardheader umgesetzt ist.
>
> Dann erkläre ich es dir: jeder könnte sich eine Headerdatei schreiben
> und sich Namen nach eigenem Gusto für die im Sprachstandard enthaltenen
> Variablentypen selber machen.

Deine Erklärung enthält nur das, was du hier gebetsmühlenartig 
wiederholst, aber es beantwortet die Frage nicht. Warum ist das für 
dich so ein riesiges Problem? Natürlich kann ich mir auch selbst einen 
Header schreiben und mir irgendwelche eigenen Namen für die Typen 
ausdenken und dann ggf. für jeden Compiler, mit dem ich arbeite, einzeln 
anpassen. Nur, warum sollte ich das tun, wenn der Compiler bereits einen 
Standardheader liefert, der genau das schon fix und fertig enthält? Die 
Funktion sin() ist ebenfalls Teil der Standardbibliothek und kann über 
einen Header verfügbar gemacht werden. Die könnte ich auch selber 
schreiben, aber ich tue es nicht, da der Compiler sie ja schon 
mitbringt. Wo ist da jetzt der Unterschied zu Typen wie uint32_t?

> In der Vergangenheit wurde das ja auch sehr häufig gemacht.

Ja, weil stdint.h nicht von Anfang an im Standard war und man daher 
gezwungen war, es selbst zu machen. Und wie man ja am Titel des Thread 
sieht, ist C89 auch noch ziemlich lange in vielen Projekten die Basis 
gewesen. stdint.h wurde erst mit C99 im Standard aufgenommen.
Bei heute neu gestarteten Projekten sehe ich eher, dass auf den 
Standardheader zurückgegriffen wird. Warum auch nicht? Es wäre ja recht 
blödsinnig, dieses vorhandene Feature nicht zu nutzen.

> Sowas wie uint32_t ist genauso gut oder schlecht wie U32 oder DWORD und
> da das alles auf 'int' mit diversen Prädikaten (long, signed usw.)
> zurückgeführt wird, wozu eben zumeist besagte Headerdateien dienen, ist
> so etwas nicht zum Sprachstandard gehörig.

Der Standard ist ein offiziell von der ISO veröffentlichtes Dokument, in 
dem das schwarz auf weiß drin steht. Unter 
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.pdf kannst du den 
aktuellsten Draft finden. Kapitel 7.20 definiert den Header <stdint.h>.
Wie kannst du da behaupten, es sei nicht Teil des Standards?

> Man könnte es auch grob so sagen: was nicht der Compiler von sich aus
> versteht, das gehört auch nicht zum Sprachumfang.

Ich würde sagen: Es gehört nicht zum Sprachkern. Die Standardbibliothek 
setzt auf diesen auf und gehört aber selbstverständlich zur Sprache 
dazu.

Zombie schrieb:
> Was passiert bei?
> char a = 1234;
> -> undefined behavior

Es werden alle Bits, die nicht in den Typ passen, abgeschnitten. Kein 
UB.

> das würde ich auch für
> int<-128,127> a = 1234;
> erwarten. das sagt dem Compiler lediglich, dass er platz für Ganzzahlen
> zwischen -128 und 127 bereitstellen soll.

Wenn das das angestrebte Ziel ist, kann man das natürlich machen. Und es 
hätte durchaus seine Vorteile, denn den Programmierer interessiert in 
vielen Fällen nicht die konkrete Anzahl an Bits, die der Typ hat, 
sondern der Wertebereich, den er abdecken können muss.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jemand schrieb:
> Nano schrieb:
>> Mal angenommen du hast Höhendaten vom Satellit und willst das mit einer
>> anderen Karte kombinieren. Dann ist ein Wolkenkratzer ein Spike, der da
>> nicht in die Bodenleveldaten hingehört.
>> Also kannst du das behandeln und bspw. mit den umgebenden Daten
>> nivellieren. Die Daten werden nicht perfekt sein, aber für einen
>> Flugsimulator reicht's.
>
> Vielleicht magst du noch einmal erläutern, welche Verwendung ein hart im
> Wertebereich eingeschränkter Typ für erwartbar abweichende Daten hat.
> Die Unterstellung, dass Wilhelm in diesem Fall einen solchen Typ
> verwenden würde, halte ich doch für ziemlich abwegig.

Hier verweise ich jetzt einfach mal auf mein obigen, längeren Post.

Wenn Messwerte einen Bereich von [0, 1024[ haben (der Sensor kann nichts 
anderes liefern) und man dafür einen DT wie int<0, 1023> verwendet, dann 
ist das absolut ok, weil der Sensor keine anderen Werte liefern kann, 
egal ob das jetzt im normativen Bereich liegt, oder eine Störung durch 
eine Einstrahlung ist.

von Wilhelm M. (wimalopaan)


Lesenswert?

Rolf M. schrieb:
> In C++ sollte sich das nachbilden lassen, allerdings im Vergleich
> vermutlich recht umständlich.

Dafür gibt es mittlerweile schöne Bibliotheken:
1
auto d = 42_km;
2
auto t = 3_min;
ist in C++ möglich (und mittlerweile üblich).

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Lesenswert?

Rolf M. schrieb:
> Zombie schrieb:
>> Was passiert bei?
>> char a = 1234;
>> -> undefined behavior
>
> Es werden alle Bits, die nicht in den Typ passen, abgeschnitten. Kein
> UB.
>
>> das würde ich auch für
>> int<-128,127> a = 1234;
>> erwarten. das sagt dem Compiler lediglich, dass er platz für Ganzzahlen
>> zwischen -128 und 127 bereitstellen soll.
>
> Wenn das das angestrebte Ziel ist, kann man das natürlich machen. Und es
> hätte durchaus seine Vorteile, denn den Programmierer interessiert in
> vielen Fällen nicht die konkrete Anzahl an Bits, die der Typ hat,
> sondern der Wertebereich, den er abdecken können muss.

S.o.:

Beitrag "Re: Linux ist endlich vom C89 Standard weg"

von Wilhelm M. (wimalopaan)


Lesenswert?

Rolf M. schrieb:
> Ich würde sagen: Es gehört nicht zum Sprachkern. Die Standardbibliothek
> setzt auf diesen auf und gehört aber selbstverständlich zur Sprache
> dazu.

Ihr redet immer noch aneinander vorbei:

der eine meint den Sprachstandard, und dieser ISO-Standard normiert die 
Kern-Sprache (dort language genannt), die Heaader, die Bibliothek, ...

der andere meint einfach nur die Kern-Sprache (language im Standard).

Solange Ihr das unter Euch nicht klärt, bleibt der Dissens.

: Bearbeitet durch User
von Rolf M. (rmagnus)


Lesenswert?

Wilhelm M. schrieb:
> Rolf M. schrieb:
>> In C++ sollte sich das nachbilden lassen, allerdings im Vergleich
>> vermutlich recht umständlich.
>
> Dafür gibt es mittlerweile schöne Bibliotheken:
> auto d = 42_km;
> auto t = 3_min;
> ist in C++ möglich (und mittlerweile üblich).

Was ich mit "recht umständlich" meinte, ist der Code, der dafür sorgt, 
dass das geht. Wie leicht kann ich da meine eigenen Typen hinzufügen? 
Wie sieht es mit dem Hinzufügen zusätzlicher Einheiten zu einem 
bestehenden Typ aus (natürlich nicht nur für Literals)?

Wilhelm M. schrieb:
> Solange Ihr das unter Euch nicht klärt, bleibt der Dissens.

Das Problem ist, dass W.S. den Standard mit dem Sprachkern gleichsetzt 
und die Standardbibliothek offenbar nicht als Teil des Standards 
betrachtet, weil man sich als Anwender der Sprache ja was vergleichbares 
selber schreiben könnte. Und diese Ansicht finde doch reichlich seltsam.

von Wilhelm M. (wimalopaan)


Lesenswert?

Rolf M. schrieb:
> Wilhelm M. schrieb:
>> Rolf M. schrieb:
>>> In C++ sollte sich das nachbilden lassen, allerdings im Vergleich
>>> vermutlich recht umständlich.
>>
>> Dafür gibt es mittlerweile schöne Bibliotheken:
>> auto d = 42_km;
>> auto t = 3_min;
>> ist in C++ möglich (und mittlerweile üblich).
>
> Was ich mit "recht umständlich" meinte, ist der Code, der dafür sorgt,
> dass das geht. Wie leicht kann ich da meine eigenen Typen hinzufügen?
> Wie sieht es mit dem Hinzufügen zusätzlicher Einheiten zu einem
> bestehenden Typ aus

Ich denke, die bekannteste bzw. zukunftsträchtigste Implementierung (es 
gibt einige) ist:

https://github.com/mpusz/units

Hier hast Du die kompletten SI-Einheiten, so dass der Bedarf nach 
Erweiterung gering sein sollte.

> (natürlich nicht nur für Literals)?

Naja, wenn Du UDL einsetzt, brauchst Du ja wohl einen sinnvollen 
Ergebnistyp, sonst ist das ja Quatsch.

von Wilhelm M. (wimalopaan)


Lesenswert?

Rolf M. schrieb:
> Wilhelm M. schrieb:
>> Solange Ihr das unter Euch nicht klärt, bleibt der Dissens.
>
> Das Problem ist, dass W.S. den Standard mit dem Sprachkern gleichsetzt
> und die Standardbibliothek offenbar nicht als Teil des Standards
> betrachtet, weil man sich als Anwender der Sprache ja was vergleichbares
> selber schreiben könnte. Und diese Ansicht finde doch reichlich seltsam.

Deswegen hatte ich ja in

Beitrag "Re: Linux ist endlich vom C89 Standard weg"

explizit auf den Standard verwiesen: dort gibt es keine Diskussion, der 
Standard schließt die Header, Bib, ... mit ein.

W.S. meint den Sprachkern (language): dann hat er Recht mit seinen 
Aussagen.

Du meinst den Standard: dann hast auch Du Recht mit Deinen Aussagen.

Hier der Link:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Rolf M. schrieb:
> Deine Erklärung enthält nur das, was du hier gebetsmühlenartig
> wiederholst, aber es beantwortet die Frage nicht. Warum ist das für
> dich so ein riesiges Problem? Natürlich kann ich mir auch selbst einen
> Header schreiben und mir irgendwelche eigenen Namen für die Typen
> ausdenken und dann ggf. für jeden Compiler, mit dem ich arbeite, einzeln
> anpassen.

Also erstens: Für MICH ist das alles überhaupt kein Problem.

Und zweitens: Stefan hat es bis heute noch nicht kapiert, deswegen 
versuche ich wiederholt, ihm klarzumachen, was an seiner Denke falsch 
ist, auch wenn Mawin mal dazwischengesprungen ist.
Ursprung:
"Kennst du uint8_t uint16_t uint32_t und Verwandte nicht?"

W.S.

von Rolf M. (rmagnus)


Lesenswert?

W.S. schrieb:
> Rolf M. schrieb:
>> Deine Erklärung enthält nur das, was du hier gebetsmühlenartig
>> wiederholst, aber es beantwortet die Frage nicht. Warum ist das für
>> dich so ein riesiges Problem? Natürlich kann ich mir auch selbst einen
>> Header schreiben und mir irgendwelche eigenen Namen für die Typen
>> ausdenken und dann ggf. für jeden Compiler, mit dem ich arbeite, einzeln
>> anpassen.
>
> Also erstens: Für MICH ist das alles überhaupt kein Problem.

Warum reitest du dann ständig darauf rum? Jedem hier ist bekannt, dass 
<stdint.h> ein Header ist und dass man Header-Dateien auch selber 
schreiben kann.

> Und zweitens: Stefan hat es bis heute noch nicht kapiert, deswegen
> versuche ich wiederholt, ihm klarzumachen, was an seiner Denke falsch
> ist, auch wenn Mawin mal dazwischengesprungen ist.
> Ursprung:
> "Kennst du uint8_t uint16_t uint32_t und Verwandte nicht?"

Ja, als Antwort auf
"Nicht einmal eine saubere Größenfestlegung für Integers ... haben die 
in den letzten 30 Jahren hingekriegt."

Und das ist eben falsch. Solche Integers wurden in Form von typedefs vor 
33 Jahren im Standard aufgenommen und sind seitdem bei jedem 
standardkonformen Compiler mit dabei. Man muss sie lediglich per 
#include <stdint.h> aktivieren. Das scheinst du aber aus irgendeinem 
Grund nicht akzeptieren zu wollen. Selbst wenn man dir die Stelle im 
Standard, wo das definiert ist aufzeigt, behauptest du felsenfest, das 
gehöre nicht zum Standard.
Eine Frage: Gibt es für dich in Standard-C auch keinen Weg, Text 
auszugeben, weil printf() ebenfalls zur Standardbibliothek gehört und 
nicht wie z.B. das Pascal-Pendant Teil des Sprachkerns ist?

von Zombie (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Die Initialisierung
> char a = 1234;
> ist natürlich kein UB.
> Es handelt sich hier um eine gültige Integerkonvertierung.

Rolf M. schrieb:
> Es werden alle Bits, die nicht in den Typ passen, abgeschnitten. Kein
> UB.

Anscheinend habt ihr recht. Das gilt nur für Überlauf durch 
Berechnungen. Wieder etwas gelernt.
1
signed char a = 128;
2
// kein UB
3
4
signed char b = 127;
5
++b;
6
// UB

von Rolf M. (rmagnus)


Lesenswert?

Zombie schrieb:
> signed char b = 127;
> ++b;
> // UB

Eigentlich auch nicht, auf Grund der Integer-Promotion. Die Berechnung 
wird in int durchgeführt. Es wird also erst b auf int erweitert, dann ++ 
gerechnet, dann das Ergebnis wieder zurück konvertiert.

von Zombie (Gast)


Lesenswert?

Rolf M. schrieb:
> Eigentlich auch nicht, auf Grund der Integer-Promotion. Die Berechnung
> wird in int durchgeführt. Es wird also erst b auf int erweitert, dann ++
> gerechnet, dann das Ergebnis wieder zurück konvertiert.

Jetzt bin ich verwirrt. Unter welchen Bedingungen ist ein "signed 
integer overflow" denn UB?

von udok (Gast)


Lesenswert?

signed int i = INT_MAX;
++i; // UB

von MaWin (Gast)


Lesenswert?

W.S. schrieb:
> Also erstens: Für MICH ist das alles überhaupt kein Problem.

Anscheinend ja doch, da du es offenbar nötig hast ständig Nebelkerzen zu 
zünden, um von deinem ursprünglichen Irrtum, von dem alles ausging, 
abzulenken:

Rolf M. schrieb:
>> "Kennst du uint8_t uint16_t uint32_t und Verwandte nicht?"
>
> Ja, als Antwort auf
> "Nicht einmal eine saubere Größenfestlegung für Integers ... haben die
> in den letzten 30 Jahren hingekriegt."
>
> Und das ist eben falsch. Solche Integers wurden in Form von typedefs vor
> 33 Jahren im Standard aufgenommen

An dieser Stelle hättest du sagen können: Ok, ich lag falsch. Danke für 
die Korrektur, jetzt bin ich schlauer geworden.

Stattdessen hast du eine irrwitzige Argumentationskette mit Sprache, 
Sprachstandard und Standardlibrary angefangen, die sowieso nur in deinem 
Kopf einen Sinn ergibt.

Fakt ist, dass fixed size Integers (und vieles mehr) standardisiert sind 
und jeder Compiler sie liefern muss.
Ob das in einem Header oder sonst wo passiert, spielt überhaupt keine 
Rolle.

von Wilhelm M. (wimalopaan)


Lesenswert?

Wilhelm M. schrieb:
> Die Initialisierung
> char a = 1234;
> ist natürlich kein UB.
> Es handelt sich hier um eine gültige Integerkonvertierung.

Ich muss das hier nochmal das etwas genauer schreiben: weil bei `char` 
es implementation-defined ist,
ob `char` nun `signed char` oder `unsigned char` ist, macht es das ggf. 
etwas komplizierter (`char` habe N Bits):

`unsigned char`:
es findet eine Initialisierung mit den unteren N Bits der rhs statt 
(modulo-N)

`signed char` bei C / C++ < c++20:
das Ergebnis ist implementation-defined (kein UB)

`signed char` bei C++ >= c++20:
es findet eine Initialisierung mit den unteren N Bits der rhs statt und 
die werden
als N-Bit 2er-Komplement interpretiert (alle Ganzzahltypen sind 
2er-Komplement seit C++20)

Die nä. Frage war nach signed-integer-overflow (unsigned-integer 
overflow ist well-defined):
1
int8_t x = std::numeric_limits<int8_t>::max();
2
++x; // signed-integer overflow -> UB

Haben wir `signed char`, dann kann `++a` oder `a++` potentiell ein 
integer-overflow auftreten, was dann UB (NDR)
ist. Dies kann man in einem constexpr-Ausdruck testen, denn dann muss(!) 
das UB einem Fehler ergeben.
Der GCC macht das auch (der clang leider nicht???).
1
constexpr auto b = []{ // constexpr: UB -> compile-time error
2
    int8_t x = std::numeric_limits<int8_t>::max();
3
    ++x; // signed-integer overflow -> UB
4
    // x += 1;
5
    return (x > std::numeric_limits<int8_t>::max());
6
}();

Da `++a` (und `a++`) lt. Standard exakt gleich zu `a += 1` ist, ist das 
dann auch UB. Hier versagt auch der GCC im o.g. constexpr-Kontext.

Bei `a = a + 1` haben wir auf der rechten Seite zunächst eine 
Integralpromotion auf `int` (das kann je nach
data-model 16, 32 oder 64 Bit sein) und dann kann ein Overflow 
stattfinden (ggf. erst bei 2^64-1).
Bei der Zuweisung gilt dann dasselbe wie oben, also bei C / C++ < c++20 
ist es implementation-defined, ab
c++20 dann eine N-Bit-Konvertierung ins 2er-Komplement.

von MaWin (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Da `++a` (und `a++`) lt. Standard exakt gleich zu `a += 1` ist, ist das
> dann auch UB.

Bist du dir da sicher?
Ist es nicht eher äquivalent zu `a = a + 1`?

von Wilhelm M. (wimalopaan)


Lesenswert?

MaWin schrieb:
> Wilhelm M. schrieb:
>> Da `++a` (und `a++`) lt. Standard exakt gleich zu `a += 1` ist, ist das
>> dann auch UB.
>
> Bist du dir da sicher?
> Ist es nicht eher äquivalent zu `a = a + 1`?

Dachte ich eigentlich auch, doch:

https://en.cppreference.com/w/cpp/language/operator_incdec

Ja, ich weiß, dass ist nicht der Standard selbst ... für genauere 
Recherche fehlte mir die Zeit gerade

von (prx) A. K. (prx)


Lesenswert?

Standard: "The expression ++E is equivalent to (E+=1)."
Beim Postfix-Operator besteht keine Alternative.

Bei E = E + 1 wird E zweimal ausgewertet, ist also nicht äquivalent. 
Denn *p++ += 1 ist nicht äquivalent zu *p++ = *p++ + 1.

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Lesenswert?

(prx) A. K. schrieb:
> Standard: "The expression ++E is equivalent to (E+=1)."
> Beim Postfix-Operator besteht keine Alternative.

Da sagt der Standard, dass (E+=1) als Seiteneffekt des Ausdrucks (E++) 
stattfindet (as-if rule).

von Rolf M. (rmagnus)


Lesenswert?

Wilhelm M. schrieb:
> Haben wir `signed char`, dann kann `++a` oder `a++` potentiell ein
> integer-overflow auftreten, was dann UB (NDR) ist.

Ich weiß nicht, ob es in C++ anders ist, aber den C-Standard lese ich 
so, dass das nicht der Fall ist. Zumindest für Präfix-++ gilt das:

(prx) A. K. schrieb:
> Standard: "The expression ++E is equivalent to (E+=1)."

Und wenn man sich das Kapitel zu compound assignment anschaut, steht da 
wiederum:
"A compound assignment of the form E1 op= E2 differs from the simple 
assignment expression E1 = E1 op (E2) only in that the lvalue E1 is 
evaluated only once."
Das bedeutet also, das bis auf die fehlende mehrfach-Evaluation ++a 
äquivalent ist zu a = a + 1, das aber kein UB ist.

> Dies kann man in einem constexpr-Ausdruck testen, denn dann muss(!)
> das UB einem Fehler ergeben.
> Der GCC macht das auch (der clang leider nicht???).

Ggf. ist es der GCC, der hier falsch liegt.

von Wilhelm M. (wimalopaan)


Lesenswert?

Rolf M. schrieb:
> Und wenn man sich das Kapitel zu compound assignment anschaut, steht da
> wiederum:
> "A compound assignment of the form E1 op= E2 differs from the simple
> assignment expression E1 = E1 op (E2) only in that the lvalue E1 is
> evaluated only once."
> Das bedeutet also, das bis auf die fehlende mehrfach-Evaluation ++a
> äquivalent ist zu a = a + 1, das aber kein UB ist.

Wenn a vom Typ int8_t ist, dann ist (a + 1) immer UB frei (wegen 
integer-promo kein overflow)

Wenn a vom Typ int (oder größer), dann ist (a + 1) bei overflow UB.

Das ist in C und C++ gleich.

Der Unterschied besteht nur bei einer signed-integer-conversion: die ist 
implementation-defined, nur bei C++ ab C++20 ist das well-defined, weil 
da alle integer-Type 2er Komplemente sein müssen.

von W.S. (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Bei E = E + 1 wird E zweimal ausgewertet, ist also nicht äquivalent.
> Denn *p++ += 1 ist nicht äquivalent zu *p++ = *p++ + 1.

Ihr kreischt ja noch immer.
Naja, wer partout immer alles in möglichst wenige Zeichen zusammenfassen 
will, muß sich auch um Nebeneffekte kümmern. Und darum, daß selbige sich 
bei doppelter Verwendung auch zweimal einstellen.

Und nun? Tun sich neue Paradiese auf, wenn der Linux-Kernel mit einem 
"brandneuen" C übersetzt wird? Oder ist es (für euch) eher der Eingang 
in die Hölle? Oder passiert überhaupt nix?

W.S.

von Wilhelm M. (wimalopaan)


Lesenswert?

W.S. schrieb:
> (prx) A. K. schrieb:
>> Bei E = E + 1 wird E zweimal ausgewertet, ist also nicht äquivalent.
>> Denn *p++ += 1 ist nicht äquivalent zu *p++ = *p++ + 1.
>
> Ihr kreischt ja noch immer.
> Naja, wer partout immer alles in möglichst wenige Zeichen zusammenfassen
> will, muß sich auch um Nebeneffekte kümmern. Und darum, daß selbige sich
> bei doppelter Verwendung auch zweimal einstellen.

Leider Thema verfehlt.

von Karl Käfer (Gast)


Lesenswert?

Nano schrieb:
> Wenn du das in deiner Schnittstelle überprüfst, was Performance kosten
> wird, dann kannst du auf den Fehler eingehen und den behandeln, sofern
> es behandelbar ist. Der Nutzer deiner Schnittstelle müsste sich dann
> nicht darum kümmern, da es ja deine Schnittstelle schon macht.

Entwickler machen sich viel häufiger Gedanken über Performance, als es 
in der Praxis aus sachlichen Gründen auf deren Verbesserung oder 
Maximierung ankommt. Darum haben die interpretierten Sprachen in der 
Praxis auch fast überall gewonnen, und nach den einschlägigen 
Programmiersprachenindizes sind die interpretierten Sprachen Java und 
Python heute die beliebtesten und verbreitetsten Sprachen der Welt. (Das 
ist in der Mikrocontrollerwelt, um die es hier ja geht, zwar (noch?) 
nicht so, aber auch hier scheinen einige Benutzer besondere Verträge mit 
den Herstellern zu haben, auf deren Basis sie für ungenutzte Ressourcen 
Geld zurück bekommen...) ;-)

von Nano (Gast)


Lesenswert?

Karl Käfer schrieb:
> Entwickler machen sich viel häufiger Gedanken über Performance, als es
> in der Praxis aus sachlichen Gründen auf deren Verbesserung oder
> Maximierung ankommt. Darum haben die interpretierten Sprachen in der
> Praxis auch fast überall gewonnen, und nach den einschlägigen
> Programmiersprachenindizes sind die interpretierten Sprachen Java und
> Python heute die beliebtesten und verbreitetsten Sprachen der Welt.

Die sind verbreitet, weil die Entwickler für Firmen günstig sind, die 
Newbs damit schnell zu recht kommen und die Auftraggeber die Software 
möglichst kostengünstig haben wollen.
Mit beliebt hat das somit nur wenig zu tun, gut, für Newbs mag das 
anders aussehen, aber die mögen bzw. mochten ja auch Basic.

Erfahrene Entwickler würden lieber in Rust oder C++ programmieren, 
manche auch in C.


>(Das
> ist in der Mikrocontrollerwelt, um die es hier ja geht, zwar (noch?)
> nicht so, aber auch hier scheinen einige Benutzer besondere Verträge mit
> den Herstellern zu haben, auf deren Basis sie für ungenutzte Ressourcen
> Geld zurück bekommen...) ;-)

Da muss man ja auch ressourcensparend programmieren weil so mancher µC 
nur ein paar KB hat.
Vielleicht ändert sich das mal mit neuen Speichertypen um das klassische 
RAM zu ersetzen. Arbeitsspeicher der keinen Strom braucht und dabei die 
Daten halten kann und trotzdem schnell wie normales RAM ist und sich gut 
fertigen lässt und wenig Chipfläche benötigt und beliebig viele Schreib- 
und Lesezyklen erlaubt. Dann wird es nicht lange dauern und die µC 
werden mit MB an solchem Arbeitsspeicher ausgeliefert und dann darfst du 
in bspw. Java oder Python programmieren.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Nano schrieb:

> Erfahrene Entwickler würden lieber in Rust oder C++ programmieren,
> manche auch in C.

Ich mochte Perl mehr als Python, aber Python hat die bessere 
Infrastruktur inzwischen.

Jeder Aufgabe ihr Tool. Alles, was ich mittlerweile in Python so gemacht 
habe, hätte ich unmöglich im gleichen Zeitrahmen mit C++, C oder Rust 
machen können. Allein der Interpreter, bei dem man mal fix auf der 
Kommandozeile ein paar Dinge austesten kann, um sie dann mit copy&paste 
ins aktuelle Projekt zu übernehmen, ist mehr als hilfreich.

> Vielleicht ändert sich das mal mit neuen Speichertypen um das klassische
> RAM zu ersetzen.

Auch mit "klassischem RAM" gibt es inzwischen genügen MCUs, die man mit 
microPython programmieren kann, angefangen bei den ESPs. Aber auch die 
diversen Einsteigerboards wie micro:bit oder Calliope sind nett, und sie 
eröffnen die Welt der Controllerprogrammierung einer 
Zielgruppe/Altersklasse, die man mit "nacktem C" nie hätte erreichen 
können.

von Hannes B. (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Freischalten von Funktionen von HW, die einem bereits gehört.
> Proprietäre Firmware. Signieren von Firmware, ohne dem Nutzer eine
> Möglichkeit zu geben, seien eigene Firmware mit einem eigenen Key zu
> signieren. Das gehört alles verboten!

Nein das gehört nicht verboten. Das nennt sich Marktwirtschaft. Machen 
wir auch so weil es einfacher ist als 10 verschiedene Hardwareversionen 
zu entwickeln und wir machen nur Platinen. Das wird bei Halbleitern 
nicht besser. Die Entwicklung der Zeitaufwand in der Fab ist eh der 
gleiche.

von MaWin (Gast)


Lesenswert?

Hannes B. schrieb:
> Machen
> wir auch so weil es einfacher ist als 10 verschiedene Hardwareversionen
> zu entwickeln

Ja.
Aber warum

>> ohne dem Nutzer eine
>> Möglichkeit zu geben, seien eigene Firmware mit einem eigenen Key zu
>> signieren.

?

von (prx) A. K. (prx)


Lesenswert?

Dir gehört ein bestimmtes Produkt, bestehend aus einer Kombination von 
HW und SW, mit einer bestimmten gekauften Funktionalität. Wie das 
implementiert wird, ist Sache des Herstellers.

von MaWin (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Dir gehört ein bestimmtes Produkt, bestehend aus einer Kombination von
> HW und SW, mit einer bestimmten gekauften Funktionalität. Wie das
> implementiert wird, ist Sache des Herstellers.

Das ist mir schon klar.
Und ja, ich muss den Kram nicht kaufen.

Aber trotzdem könnte man es mir ja mal verständlich erklären, warum 
diese Verrammelung notwendig ist?

Dass viele Hersteller ihre Crypto nicht im Griff haben, sieht man 
derzeit mal wieder eindrucksvoll an dem EC-Terminal-Chaos.

Wenn ein Hersteller das Produkt vor mir verschließt, dann habe ich halt 
Bedenken, dass er irgendwann entscheidet mir das Produkt abzustellen. 
Aus welchem Grund auch immer. Als Unfähigkeit (EC-Karte), oder mutwillig 
(Supportende. jetzt kannst du es halt nicht mehr nutzen. Kaufen Sie 
unser neues Produkt!).

Ich sehe da bei den allermeisten Produkten keinen Nachteil für den 
Hersteller, wenn der Hersteller es mir freistellt, eigene Software 
aufzuspielen.

von Oliver S. (oliverso)


Lesenswert?

MaWin schrieb:
> Ich sehe da bei den allermeisten Produkten keinen Nachteil für den
> Hersteller, wenn der Hersteller es mir freistellt, eigene Software
> aufzuspielen.

Du willst die Viren und Trojaner im Microcode des Prozessors haben, und 
nicht in den Ebenen da drüber?

Mutig ;)

Oliver

von MaWin (Gast)


Lesenswert?

Oliver S. schrieb:
> Du willst die Viren und Trojaner im Microcode des Prozessors haben, und
> nicht in den Ebenen da drüber?

Warum sollte ich die da einspielen?

Und warum sollte das ein Argument dagegen sein, mir die Möglichkeit zu 
geben eigenen Code zu signieren?

Und außerdem haben wir die Trojaner lange in den Intel- und AMD-CPUs 
drin. Da laufen ganze Betriebssysteme (Minix) drin mit vollem System- 
und Netzwerkzugriff.
Ich brauche keine Bemutterung von den Herstellern. Ich bin selbst in der 
Lage zu entscheiden, was bei mir laufen soll und darf.

von Operator S. (smkr)


Lesenswert?

MaWin schrieb:
> Ja.
> Aber warum

Es geht hier um zwei verschiedene Dinge.

Die einen sprechen davon, dass man dem Kunden "mehr" ausliefert, aber 
die Funktionalitäten dann sperrt. Sei das Silizum, oder 
Softwarefunktionen, die nur mit gültiger Lizenz laufen.

So wie ich dich verstehe geht es dir aber darum, dass du ein Gerät 
kaufst und darauf deine eigene Software laufen lassen möchtest.
Meiner Erfahrung nach verbieten das viele Firmen aus Angst, dass sie 
sich so Wettbewerbsnachteile erschaffen könnten oder auch Bedenken vor 
Betrug. Wenn du deine eigene Firmware drauf flashst und das Gerät geht 
deswegen kaputt, dann müssen sie dir erst nachweisen, dass du eine 
andere Firmware darauf geladen hast.

von MaWin (Gast)


Lesenswert?

Operator S. schrieb:
> dann müssen sie dir erst nachweisen, dass du eine
> andere Firmware darauf geladen hast.

Das ist doch trivial.

Ich habe nichts gegen Ausleseschutz der Firmware und Modifikationsschutz 
der Originalfirmware.
Aber es sollte immer möglich sein die Firmware zu löschen und komplett 
neu anzufangen.

Diese Möglichkeit geht aber immer mehr und mehr verloren.

von Oliver S. (oliverso)


Lesenswert?

MaWin schrieb:
> Diese Möglichkeit geht aber immer mehr und mehr verloren.

???

Bei 99,99999% aller kaufbaren Geräte, in denen eine Firmware steckt, ist 
diese Möglichkeit nicht verloren gegangen, weil es die da nie gegeben 
hat.

Oliver

von 🐧 DPA 🐧 (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Dir gehört ein bestimmtes Produkt, bestehend aus einer Kombination von
> HW und SW, mit einer bestimmten gekauften Funktionalität. Wie das
> implementiert wird, ist Sache des Herstellers.

Mir gehört nicht nur die Kombination / das Paket, von dem, was ich 
Kaufe. Mir gehört jeder Teil, jedes Atom von dem, was ich kaufe. Der 
Hersteller darf mir nicht vorschreiben, wie ich meine Sachen zu 
verwenden habe.

Aber Hersteller nutzen Legale und Technische Wege, das zu umgehen / 
trotzdem zu tun:
 1) * as a service. Mit der Methode gehört einem schlicht nichts, und 
man ist dem Hersteller voll ausgeliefert.
 2) Technische Massnahmen (Verkleben, Signieren, usw.)

Die Hersteller sorgen also dafür, dass wir entweder möglichst keine 
Rechte haben, oder wir diese nicht wahrnehmen können, ohne dagegen 
vorgehen zu können. Das ist nicht, was unsere rechte sind, oder was wir 
mit unserem zeug machen dürfen. Das ist was die willkürliche Kontrolle 
der Unternehmen über unsere Besitztümer & Rechte uns machen lässt. Das 
darf nicht rechtens sein! Verteidigt die Hersteller und Firmen doch 
nicht auch noch! "Das ist halt so", Nein! Es muss gehandelt werden! Es 
muss geändert werden!

von Operator S. (smkr)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Mir gehört jeder Teil, jedes Atom von dem, was ich kaufe.

Du kaufst aber nicht, was du meinst gekauft zu haben.

Dein uC mag doppelt so viel Ram auf dem Silizium haben, wie er dir 
vorgibt zu haben - allein durch die Markierung des Chips durch den 
Hersteller wird dies bestimmt. Du hast aber auch nur für die Hälfte des 
Rams bezahlt, ergo gekauft.

Ich verstehe worauf du hinaus willst, unterstütze es sogar im Grundsatz. 
Man sollte doch auch immer 100% der zur Verfügung stehenden Ressourcen 
nutzen, die wir, die Menschheit erschaffen haben. Unternehmen stehen da 
bloss im Wege.
Stand heute sehe ich aber keinen praktischen Weg, wie wir das im 
aktuellen System umsetzen könnten.

von Oliver S. (oliverso)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Aber Hersteller nutzen Legale und Technische Wege, das zu umgehen

Das Recht ist schon eine blöde Sache: Es nutzt nicht nur einem selber, 
sondern auch anderen. Das MUSS sofort geändert werden.

Oliver

von MaWin (Gast)


Lesenswert?

Oliver S. schrieb:
> Bei 99,99999% aller kaufbaren Geräte, in denen eine Firmware steckt, ist
> diese Möglichkeit nicht verloren gegangen, weil es die da nie gegeben
> hat.

Das ist falsch.
Die allermeisten Geräte, die ich mir bisher genauer angeschaut habe, 
hatten:
- Einen Ausleseschutz für die Firmware. Das ist Ok. Einige hatten aber 
nicht einmal einen Ausleseschutz.
- Die Möglichkeit die Originalfirmware zu löschen und eine eigene 
Firmware aufzuspielen.

Und ich habe bei etlichen dieser Geräte eben genau jenes getan. Alte 
Firmware raus, neue Firmware rein.

Das erste berühmte Beispiel, das stark durch die Medien ging, wo das 
nicht mehr ging, war Tivo. Woraus der Begriff "Tivoization" entstand.

Ich beobachte, dass immer mehr Geräte tivoisiert werden.
Ich habe auch nichts grundsätzlich dagegen. Dort, wo es Sinn ergibt, 
kann man das gerne einsetzen. Ich verstehe zum Beispiel, wenn man es in 
safetykritischen Geräten einsetzt.
Aber bitte nicht in breiter Masse.

von Oliver S. (oliverso)


Lesenswert?

MaWin schrieb:
> Und ich habe bei etlichen dieser Geräte eben genau jenes getan. Alte
> Firmware raus, neue Firmware rein.

Rein interessehalber: was waren das für Geräte?

Oliver

von MaWin (Gast)


Lesenswert?

Oliver S. schrieb:
> was waren das für Geräte?

Das geht von kleinen Gadgets über handgetragene Geräte bis hin zu 
PCI-Karten, auf denen ja auch immer öfter ein eigener kleiner Computer 
werkelt.

von Karl Käfer (Gast)


Lesenswert?

Nano schrieb:
> Karl Käfer schrieb:
>> Entwickler machen sich viel häufiger Gedanken über Performance, als es
>> in der Praxis aus sachlichen Gründen auf deren Verbesserung oder
>> Maximierung ankommt. Darum haben die interpretierten Sprachen in der
>> Praxis auch fast überall gewonnen, und nach den einschlägigen
>> Programmiersprachenindizes sind die interpretierten Sprachen Java und
>> Python heute die beliebtesten und verbreitetsten Sprachen der Welt.
>
> Die sind verbreitet, weil die Entwickler für Firmen günstig sind, die
> Newbs damit schnell zu recht kommen und die Auftraggeber die Software
> möglichst kostengünstig haben wollen.
> Mit beliebt hat das somit nur wenig zu tun, gut, für Newbs mag das
> anders aussehen, aber die mögen bzw. mochten ja auch Basic.

Vielleicht solltest Du nicht so arrogant auf die "Newbs" herabblicken... 
Du warst auch mal einer, und wenn ich Deine Ausführungen so lese, 
beschleicht mich der leise Verdacht, daß das womöglich noch gar nicht so 
lange her ist.

> Erfahrene Entwickler würden lieber in Rust oder C++ programmieren,
> manche auch in C.

Erfreulicherweise kann sich jeder in den Stackoverflow-Surveys der 
letzten fünf Jahre (weiter habe ich nicht geschaut) überzeugen, daß dort 
jedes Jahr Python die "Most Wanted" unter den Programmiersprachen war, 
vor JavaScript und Go -- mit Ausnahme von 2021, da lag TypeScript 
zwischen Python und JavaScript.

C++ liegt in den besagten Surveys in dieser Disziplin meisten so etwa 
auf Platz 5, bei den abgegebenen Stimmprozenten liegt Python etwa um den 
Faktor 2,5 höher, wobei der prozentuale Stimmanteil von C++ im Laufe der 
Jahre eher abnimmt. Ähnliches gilt auch für C, während von den von Dir 
genannten Sprachen zumindest Rust aktuell einen gewissen Aufwind 
vorweisen kann. Allerdings hat es zwischendrin immer so, ich sage mal, 
modische Ausreißer gegeben, die so ein bis drei Jahre einen großen Hype 
gehabt haben und wie die New Kids On The Block aussahen, mittlerweile 
aber wieder deutlich nachzulassen scheinen: Kotlin, Julia und Scala zum 
Beispiel.

Fakt ist jedenfalls: überall dort, wo es um maximale Leistung ohne 
Beschränkungen der Ressourcen geht, haben die interpretierten Sprachen 
die Oberhand. Und das liegt ganz sicher nicht daran, daß Java- oder 
Python-Entwickler besonders "günstig zu bekommen" wären, sondern an 
gänzlich anderen Faktoren -- insbesondere der Tatsache, daß eine hohe 
Performanz viel unwichtiger ist als viele Entwickler glauben, daß man in 
Skriptsprachen wesentlich schneller entwickeln kann und die 
Time-To-Market eine wichtige ökonomische Größe ist, die nicht selten 
über Erfolg oder Mißerfolg eines Produkts entscheidet. Und in 
dynamischen Umfeldern wie der Datenanalyse und dem Machine Learning 
spielen die nativen Sprachen nahezu keine Rolle, allenfalls zum 
Ansteuern der GPUs und in den Rechenwerken hinter den Interpretierten 
werden sie (aus offensichtlichen Gründen) in größerem Umfang genutzt.

Und um Dir gleich den Wind aus den Segeln zu nehmen, ich sei ja auch nur 
so einer von diesen "günstigen" Newbs: meine ersten 
"Programmiererfahrungen" bestanden darin, das Spiel "Moon Landing" auf 
dem HP97-Tischrechner meines alten Herrn schwieriger zu machen, danach 
kamen Basic und Assembler auf dem VC-20 und später dem C64, danach C auf 
einer PDP-11... tatsächlich habe ich schon mehr Programmiersprachen 
vergessen, als ich heute noch beherrsche. Manchmal benutze ich Python 
sogar, um C++-Code zu generieren, ist das nicht verrückt?

Wie dem auch sei: es geht nicht um "günstige" Entwickler, sondern es 
geht vielmehr um Entwicklungszeit und Flexibilität. Mit "günstigen" 
Entwicklern kannst Du ohnehin niemals ein marktfähiges Produkt 
entwickeln, das spielt dabei überhaupt keine Rolle -- sonst wäre 
übrigens COBOL die richtige Sprache für Dich, denn die guten alten 
Coboleros zählen heute zu den bestbezahlten Entwicklern überhaupt. In 
einigen sehr speziellen Bereichen erfreuen sich übrigens auch Smalltalk- 
und Fortran-Entwickler einer hohen Beliebtheit, die sich sehr direkt in 
den Gehältern niederschlägt.

Insofern, sei mir bitte nicht böse, aber von kommerzieller 
Softwareentwicklung und deren ökonomischen Hintergründen scheinst Du 
nicht allzu viel Ahnung zu haben, und solltest deswegen vielleicht auch 
nicht versuchen, damit zu argumentieren. Für Dein Hobby kannst Du ja 
benutzen, was Du magst, C, C++, Rust oder Go, meinetwegen auch 
Brainfuck, APL, Erlang oder was auch immer -- ist ja okay, Deine Wahl. 
Viel Spaß, Erfolg und Vergnügen damit!

> Da muss man ja auch ressourcensparend programmieren weil so mancher µC
> nur ein paar KB hat.

Vielen Dank für Deine Belehrungen. Mir ist selbstverständlich klar, 
warum Assembler, C und C++ auf den kleinsten und winzigsten 
Mikrocontrollern nicht so bald aussterben werden, aber die hatte ich aus 
meiner Betrachtung schließlich auch ganz ausdrücklich ausgenommen. Du 
darfst schon ein bisschen Mitdenken, wenn Du meine Beiträge liest, 
immerhin mache ich das auch beim Verfassen.

Darüber hinaus gibt es einen unübersehbaren Trend im 
Mikrocontrollerumfeld: von der aktuellen Nachschubkrise einmal 
abgesehen, gibt es immer größere Mikrocontroller mit immer mehr Leistung 
und Speicher zu immer kleineren Preisen. Einen ESP32, auf dem mit 
Micropython immerhin schon ein Python-Interpreter lauffähig ist, gibt es 
heute schon für weniger als einen Euro. Für jeden einzelnen der 
ATMega644 und ATMega1284 in meinem Bauteilemagazin habe ich ein 
Vielfaches davon bezahlt. Daß Dir solcherlei Entwicklungen anscheinend 
nicht gefallen, ändert ja nichts daran, daß es sie sehr offensichtlich 
gibt, und ich fürchte, Du kannst dagegen auch nicht viel mehr tun, als 
Dich damit abzufinden und diese schlichte Realität zu akzeptieren.

> Vielleicht ändert sich das mal mit neuen Speichertypen um das klassische
> RAM zu ersetzen. Arbeitsspeicher der keinen Strom braucht und dabei die
> Daten halten kann und trotzdem schnell wie normales RAM ist und sich gut
> fertigen lässt und wenig Chipfläche benötigt und beliebig viele Schreib-
> und Lesezyklen erlaubt. Dann wird es nicht lange dauern und die µC
> werden mit MB an solchem Arbeitsspeicher ausgeliefert und dann darfst du
> in bspw. Java oder Python programmieren.

Ja, derartige Prognosen hinsichtlich der Entwicklung von Arbeitsspeicher 
höre und lese ich jetzt seit den Neunzigern. Damals hatte ein 
skandinavisches Unternehmen angekündigt, binnen weniger Jahre einen 
neuen Arbeitsspeichertypus auf der Basis dünner Kunststoff-Folien zu 
entwickeln, mit ganz großartigen Features: er sollte wesentlich 
preiswerter sein, eine deutlich höhere Speicherdichte aufweisen, zudem 
erheblich schneller und zum Ladungserhalt keinen und zum Lesen und 
Schreiben nur ganz geringe Spannungen und Ströme benötigen. Zu meinem 
größten Bedauern war der Wunderspeicher allerdings letztes Jahr, als ich 
meinen aktuellen Numbercruncher aufgebaut habe, leider immer noch nicht 
verfügbar... :-(

Nebenbei bemerkt, entwickle ich zwar in Python, aber nicht in Java -- 
ich glaube, in meinem ganzen Leben habe ich höchstens 1k LOC in Java für 
eine Integration mit einer Distributed Realtime Streaming Engine namens 
Apache Storm geschrieben. Python macht mir allerdings großen Spaß, 
ebenso wie C++ -- das man mit Boost::Python übrigens  sehr einfach und 
elegant in Python einbinden kann, wenn man die maximale Leistung 
wirklich mal ausnahmsweise benötigt.

Insofern, bleib' locker: niemand will Dir Deinen Compiler, Deine 
Lieblingssprache oder sonst etwas wegnehmen. Ich auch nicht, warum auch? 
Ich freue mich, wenn junge Menschen sich mit Technik auseinandersetzen 
und ihrerseits die Maschine beherrschen anstatt davon beherrscht zu 
werden. Also weiter so, viel Spaß und Erfolg! ;-)

von Nano (Gast)


Lesenswert?

Karl Käfer schrieb:
> Nano schrieb:
>> Die sind verbreitet, weil die Entwickler für Firmen günstig sind, die
>> Newbs damit schnell zu recht kommen und die Auftraggeber die Software
>> möglichst kostengünstig haben wollen.
>> Mit beliebt hat das somit nur wenig zu tun, gut, für Newbs mag das
>> anders aussehen, aber die mögen bzw. mochten ja auch Basic.
>
> Vielleicht solltest Du nicht so arrogant auf die "Newbs" herabblicken...

Newbs ist das kürzeste Wort um das auszudrücken was ich meinte.

> Du warst auch mal einer, und wenn ich Deine Ausführungen so lese,
> beschleicht mich der leise Verdacht, daß das womöglich noch gar nicht so
> lange her ist.

Falsche Korrektheit.
Schäm dich dass du es wagst, hier wegen so etwas rumzuplärren!


Bei mir heißt es im Code immer noch Master und Slave und jetzt reg dich 
auf.
Tipp: Renne dreimal um den Block, dann wird das wieder.

So, nächstes Thema:

>
>> Erfahrene Entwickler würden lieber in Rust oder C++ programmieren,
>> manche auch in C.
>
> Erfreulicherweise kann sich jeder in den Stackoverflow-Surveys der
> letzten fünf Jahre (weiter habe ich nicht geschaut) überzeugen, daß dort
> jedes Jahr Python die "Most Wanted" unter den Programmiersprachen war,
> vor JavaScript und Go -- mit Ausnahme von 2021, da lag TypeScript
> zwischen Python und JavaScript.

Nur weil es für die einfacheren Sprachen mehr Programmierer gibt, 
bedeutet das nicht, dass erfahrene Entwickler sie für alles bevorzugen.
Es gibt Dinge, da kommt es auf Performance und geringem Platzbedarf an 
und dann wird ein erfahrener Entwickler da kein Javascript einsetzen.


> Ähnliches gilt auch für C, während von den von Dir
> genannten Sprachen zumindest Rust aktuell einen gewissen Aufwind
> vorweisen kann. Allerdings hat es zwischendrin immer so, ich sage mal,
> modische Ausreißer gegeben, die so ein bis drei Jahre einen großen Hype
> gehabt haben und wie die New Kids On The Block aussahen, mittlerweile
> aber wieder deutlich nachzulassen scheinen: Kotlin, Julia und Scala zum
> Beispiel.

Rust wird weiter Erfolg haben, da Rust das gleiche kann wie C und C++ 
und sich prinzipiell für das gleiche eignet, aber man damit schneller 
zum Ziel kommt, und sich weniger Bugs einschleichen weil es by default 
nicht die Fehler hat, die C und C++ haben und oben drauf kommen dann 
noch so Sachen wie Ownership und Borrowing. Und für die nebenläufige 
Programmierung eignet es sich auch besser.
In dem Feld ist Rust also die Zukunft und besseres ist nicht in Sicht.
Das einzige was man versucht ist in C++ Features von Rust an C++ wieder 
dranzuflanschen. Das kann für bei gewachsenem Code und der breiten Masse 
an C++ Programmierer sinnvoll sein, löst aber nicht die Grundprobleme 
von C++.

> daß man in
> Skriptsprachen wesentlich schneller entwickeln kann und die
> Time-To-Market eine wichtige ökonomische Größe ist,

Das habe ich alles schon oben erwähnt.
Du wiederholst mich.


> Mit "günstigen"
> Entwicklern kannst Du ohnehin niemals ein marktfähiges Produkt
> entwickeln, das spielt dabei überhaupt keine Rolle -- sonst wäre
> übrigens COBOL die richtige Sprache für Dich, denn die guten alten
> Coboleros zählen heute zu den bestbezahlten Entwicklern überhaupt.

Du widersprichst dir.
Wenn Cobold Entwickler die bestbezahlten Entwickler sind, dann kann 
Cobold als Sprache nicht günstig sein.


> Insofern, sei mir bitte nicht böse, aber von kommerzieller
> Softwareentwicklung und deren ökonomischen Hintergründen scheinst Du
> nicht allzu viel Ahnung zu haben,

Wenn du richtig lesen könntest, dann hättest du oben das hier, wo du 
mich wiederholst, nicht geschrieben:
> daß man in
> Skriptsprachen wesentlich schneller entwickeln kann und die
> Time-To-Market eine wichtige ökonomische Größe ist,

Also bla bla bla und Tschüß.


> Insofern, bleib' locker: niemand will Dir Deinen Compiler, Deine
> Lieblingssprache oder sonst etwas wegnehmen.

Der einzige der nicht locker geblieben ist, bist du. Denn sonst hättest 
du dir deinen obigen Erguss sparen können.
Du gehört zu solchen Leuten, die sich triggern lassen, wenn man im Code 
so Sachen wie master und slave benutzt.
Dann gehst du auf die Barrikaten und kriegst nen roten Hals und besser 
wird der Code durch dein Rummeckern dann auch nicht.

von W.S. (Gast)


Lesenswert?

Nano schrieb:
> Dann gehst du auf die Barrikaten und kriegst nen roten Hals und besser
> wird der Code durch dein Rummeckern dann auch nicht.

OK. Der Ton dieses Threads hat sich etwas geändert: Jetzt ist 
allgemeines Wehklagen dran. Naja, das erinnert mich an den ellenlangen 
Thread zum Thema "warum mögen die Leute unser gutes Linux nicht".

Nur weiter so, dann kriegt ihr auch die 300 Posts hin.

W.S.

von Wilhelm M. (wimalopaan)


Lesenswert?

W.S. schrieb:
> Nano schrieb:
>> Dann gehst du auf die Barrikaten und kriegst nen roten Hals und besser
>> wird der Code durch dein Rummeckern dann auch nicht.
>
> OK. Der Ton dieses Threads hat sich etwas geändert: Jetzt ist
> allgemeines Wehklagen dran.

Das sehe ich weniger als Wehklagen, sondern als "zur Schau stellen" der 
vermeintlichen eigenen Kompetenz kombiniert mit Präsentation sozialer 
Inkompetenz. Also, für dieses Forum alles im grünen Bereich ;-) 
Vielleicht reicht es dann später noch fürs Popcorn ...

von Stefan F. (Gast)


Lesenswert?

Karl Käfer schrieb:
> mittlerweile
> aber wieder deutlich nachzulassen scheinen: Kotlin

Ich dachte Kotlin sei bei Android der Standard, ist das etwa schon 
wieder vorbei?

von Stefan F. (Gast)


Lesenswert?

Ich halte es für Unklug, sich auf eine bestimmte Programmiersprache fest 
zu legen. Man schränkt sich damit nur unnötig ein. Im Beruf läuft man so 
Gefahr, links und rechts von anderen überholt zu werden.

In meinem Umfeld führend folgende Dinge meistens zu einer konkreten 
Wahl:

- Vorgabe vom Kunden
- Vorgabe von der Projektleitung
- Zeit-Budget (wenn es schnell gehen muss, nimmt man das, womit man 
gerade am schnellsten zum Ziel kommt. Und das hängt unter anderem auch 
vom Know-How ab)
- Man führt neues nur ein, wenn man dazu einen wirklich guten Grund hat 
(neue Tools -> neue Probleme)
- technische Aspekte (Performance, Speicherbedarf, Startup-Zeit, 
benötigte Libraries)

Meistens wurde mir die Programmiersprache vorgegeben. Ich nehme an, dass 
es den meisten hier im Beruf ebenso geht.

Ich habe total untechnischen Grund, zuhause bestimmte andere 
Programmiersprachen zu benutzen: Weil sie anders sind, weil ich flexibel 
bleiben will.

von Zombie (Gast)


Lesenswert?

Ich möchte nochmals auf das Thema "sicherer Integer-Typ" zurück zu 
kommen. Boost stellt so einen Typ zur Verfügung:

https://www.boost.org/doc/libs/1_79_0/libs/safe_numerics/doc/html/safe_range.html
1
//  Copyright (c) 2018 Robert Ramey
2
//
3
// Distributed under the Boost Software License, Version 1.0. (See
4
// accompanying file LICENSE_1_0.txt or copy at
5
// http://www.boost.org/LICENSE_1_0.txt)
6
7
#include <exception>
8
#include <iostream>
9
#include <type_traits>
10
#include <boost/safe_numerics/safe_integer.hpp>
11
#include <boost/safe_numerics/safe_integer_range.hpp>
12
#include <boost/safe_numerics/safe_integer_literal.hpp>
13
14
#include <boost/safe_numerics/utility.hpp>
15
16
using namespace boost::safe_numerics;
17
18
int main(){
19
    safe_unsigned_range<7, 24> i;
20
    
21
    // since the range is included in [0,255], the underlying type of i
22
    // will be an unsigned char.
23
    try{
24
        i = 0;  // throws out_of_range exception
25
        std::cout << "fails to detect erroneous assignment" << std::endl;
26
    }
27
    catch(std::exception & e){
28
        // should arrive here
29
    }
30
    try{
31
        i = 9;  // ok - no exception expected
32
    }
33
    catch(std::exception & e){
34
        std::cout << "erroneous error for legal assignment" << std::endl;
35
    }
36
    try{
37
        i *= 9; // fails to compile because result can't fin in range
38
        std::cout << "fails to out of range result" << std::endl;
39
    }
40
    catch(std::exception & e){
41
        // should arrive here
42
    }
43
    try{
44
        i = -1; // throws out_of_range exception
45
        std::cout << "fails to detect erroneous assignment" << std::endl;
46
    }
47
    catch(std::exception & e){
48
        // should arrive here
49
    }
50
    std::uint8_t j = 4;
51
    auto k = i + j;
52
53
    // if either or both types are safe types, the result is a safe type
54
    // determined by promotion policy.  In this instance
55
    // the range of i is [7, 24] and the range of j is [0,255].
56
    // so the type of k will be a safe type with a range of [7,279]
57
    static_assert(
58
        is_safe<decltype(k)>::value
59
        && std::numeric_limits<decltype(k)>::min() == 7
60
        && std::numeric_limits<decltype(k)>::max() == 279,
61
        "k is a safe range of [7,279]"
62
    );
63
    return 0;
64
}
Optional auch detailliert konfigurierbar über Templateparameter.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Zombie schrieb:
> Boost stellt so einen Typ zur Verfügung:

Nur, was hat das mit C (und C89 vs. C99 vs. C11) zu tun?

von Wilhelm M. (wimalopaan)


Lesenswert?

Zombie schrieb:
> ch möchte nochmals auf das Thema "sicherer Integer-Typ" zurück zu
> kommen. Boost stellt so einen Typ zur Verfügung:
>
> 
https://www.boost.org/doc/libs/1_79_0/libs/safe_numerics/doc/html/safe_range.html

Bisher bin ich bei dem Thema ja immer sehr belächelt worden ;-)

Ich hatte vor Jahren das ja schonmal vorgestellt (eigene kleine 
Implementierung mit uint_ranged<>, uint_ranged_NaN<>, uint_circular<>, 
int_ranged<> ...).

Eine weitere sehr gute Implementierung ist:

https://github.com/davidstone/bounded-integer

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Zombie schrieb:
>> Boost stellt so einen Typ zur Verfügung:
>
> Nur, was hat das mit C (und C89 vs. C99 vs. C11) zu tun?

Der Thread hat sich thematisch ja schon eher in die Richtung weiter 
bewegt, was man ggf. verbessern kann und wie das u.U. in anderen 
Sprachen aussieht.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Naja, deshalb nun die x-te "C++ ist doch besser"-Diskussion anzufangen, 
halte ich dennoch nicht für sinnvoll.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Naja, deshalb nun die x-te "C++ ist doch besser"-Diskussion anzufangen,
> halte ich dennoch nicht für sinnvoll.

Es geht nicht primär, um "C++ ist besser". Sondern es geht darum, wie 
Dinge (hier "zufälligerweise" in C) ggf. besser zu machen sind. Und da 
gibt sicher den ein oder anderen Punkt, der in C++ besser zu machen ist, 
gerade wenn der Vergleich eben C ist. Und - Du kennst das von mir - dann 
weise ich darauf hin, dass man C nicht "verlassen" muss, und trotzdem 
die Vorteile von C++ "genießen" kann. Ich denke, dass das durchaus 
erlaubt ist, auch weil ja nicht immer dieselben Leute hier mitlesen.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Wer sowas wie Boost gewillt ist zu benutzen, wird das sicher selbst 
finden.

Wenn jetzt jeder hier für seine Lieblingssprache anfängt, Rezepte zu 
posten, ist der Thread völlig aus dem Ruder. Dass bspw. in Python ein 
Integer gar keinen Overflow kennt, muss ich dir sicher nicht erklären.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:

> Dass bspw. in Python ein
> Integer gar keinen Overflow kennt, muss ich dir sicher nicht erklären.

Nein, nicht wirklich.
Jedoch ist der Bezug im Kontext Linux-Kernel und C zu Python noch loser 
als zu C++.

S.a.
Beitrag "Re: Linux ist endlich vom C89 Standard weg"

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Den Linux-Kernel wird weder C++ noch Python interessieren. ;-)

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Den Linux-Kernel wird weder C++ noch Python interessieren. ;-)

Wer vom Linux-Kernel-Team liest denn hier mit?

von Zombie (Gast)


Lesenswert?

Jörg W. schrieb:
> Naja, deshalb nun die x-te "C++ ist doch besser"-Diskussion anzufangen,
> halte ich dennoch nicht für sinnvoll.
Wenn C++ besser wäre, würde so ein Typ zum Sprachstandard gehören. (Und 
das sage ich als C++ fanboy ;)

Jörg W. schrieb:
> Dass bspw. in Python ein
> Integer gar keinen Overflow kennt, muss ich dir sicher nicht erklären.
Auch dieser Typ fehlt leider im C++ Sprachstandard. Selbst 
boost::multiprecision ist fix, was den Wertebereich betrifft.

Jörg W. schrieb:
> Wer sowas wie Boost gewillt ist zu benutzen, wird das sicher selbst
> finden.
Nicht zwangsläufig, boost ist so riesig und wächst beständig weiter. Ich 
benutze boost oft, aber kenne vielleicht 20% davon. Die Existenz von 
safe numerics ist mir erst heute wieder eingefallen (à la: da war doch 
mal was...)

> Wenn jetzt jeder hier für seine Lieblingssprache anfängt, Rezepte zu
> posten, ist der Thread völlig aus dem Ruder.
Ist er sowieso schon lange.
Ich hätte gerne noch mehr über das folgende diskutiert, was genau dabei 
das (potentielle) Problem ist:

Zombie schrieb:
> Kann mir das bitte jemand in C-Code übersetzen?
>
>> Koschel hatte eine Unsicherheit identifiziert, die auf ein in C89 nicht
>> lösbares Problem zurückzuführen war.
>> Beim Fix einer USB-Komponente entdeckte Koschel, dass nach dem Durchlauf
>> einer Schleife über eine verkettete Liste der Kopfzeiger der Liste mit
>> ungültigem Inhalt nachfolgenden Code-Teilen fälschlich zur Verfügung stand.
>> Das liegt schlicht daran, dass in C89 die Laufvariable der Schleife
>> außerhalb der Schleife deklariert werden muss und damit auch nach dem
>> Schleifenblock weiterhin sichtbar ist. Ein klassischer "Leak" der
>> Laufvariablen. Beim Zugriff auf die Variable nach der Schleife kommt es zum
>> Bug.
>
> Ich habe versucht, die Konversation
> (https://lore.kernel.org/all/20220217184829.1991035-1-jakobkoschel@gmail.com/)
> nach zu vollziehen, aber verstehe nur Bahnhof.
>
> Danke!
1
struct S { S *next; };
2
3
S *iterator = get_iterator();
4
5
for (; iterator != NULL; iterator = iterator->next) {
6
7
   do_something(iterator);
8
9
}

von Wilhelm M. (wimalopaan)


Lesenswert?

Zombie schrieb:
>> Ich habe versucht, die Konversation
>> (https://lore.kernel.org/all/20220217184829.1991035-1-jakobkoschel@gmail.com/)
>> nach zu vollziehen, aber verstehe nur Bahnhof.
>>
>> Danke!
>
>
1
> struct S { S *next; };
2
> 
3
> S *iterator = get_iterator();
4
> 
5
> for (; iterator != NULL; iterator = iterator->next) {
6
> 
7
>    do_something(iterator);
8
> 
9
> }
10
>

Nach der Schleife gilt iterator == NULL.
Und wenn Du den dann dereferenzierst ...

Zumindest verstehe ich das folgende Excerpt mal so:

Zombie schrieb:
>>> Koschel hatte eine Unsicherheit identifiziert, die auf ein in C89 nicht
>>> lösbares Problem zurückzuführen war.
>>> Beim Fix einer USB-Komponente entdeckte Koschel, dass nach dem Durchlauf
>>> einer Schleife über eine verkettete Liste der Kopfzeiger der Liste mit
>>> ungültigem Inhalt nachfolgenden Code-Teilen fälschlich zur Verfügung stand.
>>> Das liegt schlicht daran, dass in C89 die Laufvariable der Schleife
>>> außerhalb der Schleife deklariert werden muss und damit auch nach dem
>>> Schleifenblock weiterhin sichtbar ist. Ein klassischer "Leak" der
>>> Laufvariablen. Beim Zugriff auf die Variable nach der Schleife kommt es zum
>>> Bug.

Womit wir wieder bei dem Thema Zusicherungen wären ...

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Zombie schrieb:
> was genau dabei das (potentielle) Problem ist

Die Iteration erfolgt eben offenbar nicht bis der Zeiger Null ist (wie 
in deinem Beispiel), sondern bis "head" erreicht ist. Siehst du hier:

https://www.vusec.net/projects/kasper/

(etwa in der Mitte)

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Zombie schrieb:
>> was genau dabei das (potentielle) Problem ist
>
> Die Iteration erfolgt eben offenbar nicht bis der Zeiger Null ist (wie
> in deinem Beispiel), sondern bis "head" erreicht ist. Siehst du hier:
>
> https://www.vusec.net/projects/kasper/
>
> (etwa in der Mitte)

Verstehe ich das richtig (ich habe bislang nur den Text gelesen, nicht 
den Code), dass der letzte Listeknoten nicht auf den ersten zeigt, 
sondern auf den Kopfknoten. Dieser ist natürlich anders strukturell 
aufgebaut, wird aber trotzdem wild ge-castet. Da dieser Iterator eben 
außerhalb der Schleife auch noch zugreifbar ist, führt ein Zugriff auf 
member dann zum Knall. Oder?

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ich habe das auch nicht völlig verstanden (hatte nicht so viel Zeit, das 
alles zu lesen), aber irgendsowas offenbar.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Ich habe das auch nicht völlig verstanden (hatte nicht so viel Zeit, das
> alles zu lesen), aber irgendsowas offenbar.

Na, dann würde ich sagen: mit einer generischen Liste (template) in C++ 
und einer vernünftigen Schleifenform mit lokalem Iterator wäre das nicht 
passiert (sorry, das war jetzt ne Steilvorlage ...)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Wilhelm M. schrieb:
> Na, dann würde ich sagen

was völlig Nutzloses?

Oder wolltest du dich jetzt freiwillig melden, den kompletten Kernel auf 
C++ umzuschreiben? Viel Spaß dabei … ich mein, es ist Opensource, du 
kannst deinen eigenen Fork davon machen, wenn dir danach ist.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Wilhelm M. schrieb:
>> Na, dann würde ich sagen
>
> was völlig Nutzloses?

Warum so unentspannt?

> Oder wolltest du dich jetzt freiwillig melden, den kompletten Kernel auf
> C++ umzuschreiben? Viel Spaß dabei … ich mein, es ist Opensource, du
> kannst deinen eigenen Fork davon machen, wenn dir danach ist.

Danke, ich arbeite schon in genug OSS Projekten mit ;-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Wilhelm M. schrieb:
> Jörg W. schrieb:
>> Wilhelm M. schrieb:
>>> Na, dann würde ich sagen
>>
>> was völlig Nutzloses?
>
> Warum so unentspannt?

Weil's ein ziemlich sinnloser Kommentar war.

Wenn sie halt eine Listen-/Iterator-Implementierung haben und die an 
hunderten Stellen benutzt wird, dann hilft es keinem, wenn du irgendeine 
C++-Standard-Liste stattdessen "empfiehlst".

Linux schmeißt auch so schon häufig genug interne APIs über den Haufen 
(VMware-Nutzer können ein Lied davon singen), da braucht man nicht noch 
etwas derart zentrales von Grund auf neu zu implementieren.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Wilhelm M. schrieb:
>> Jörg W. schrieb:
>>> Wilhelm M. schrieb:
>>>> Na, dann würde ich sagen
>>>
>>> was völlig Nutzloses?
>>
>> Warum so unentspannt?
>
> Weil's ein ziemlich sinnloser Kommentar war.

Das mit der Steilvorlage hast Du schon verstanden, oder?
Und dass es in diesem Thread eben längst nicht mehr nur um den 
Linux-Kernel geht, auch? Schließlich hast Du Dich ja hier auch zum Thema 
Python geäußert ...

von Wilhelm M. (wimalopaan)


Lesenswert?

W.S. schrieb:

> Nur weiter so, dann kriegt ihr auch die 300 Posts hin.

Erledigt ;-)

von W.S. (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Womit wir wieder bei dem Thema Zusicherungen wären ...

Zusicherungen? Ach nö, es ist immer wieder die generelle 
Erwartungshaltung der C-Programmierer, daß Variablen gefälligst ohne 
eigenes Zutun initialisiert zu sein haben. Woanders lautet das 
Paradigma: vor Benutzung einer Variablen hat man diese selbst 
wenigstens einmal beschrieben zu haben, sonst ist deren Inhalt 
unbestimmt.

Und wenn das Abbruchkriterium für eine Schleife darin besteht, daß das 
letzte Element einer Liste eben keinen Nachfolger hat, dann sollte dem 
Programmierer auch klar sein, daß nach Abarbeitung der Schleife der 
betreffende Zeiger eben NICHT auf irgendwas sinnvolles zeigt. Also wo 
ist der Fehler?

Immerhin besteht normalerweise eine nicht leere Liste aus zumindest 
einem Element (oder mehreren) und da hat das allererste Element keinen 
Vorgänger und das letzte Element keinen Nachfolger. Man könnte also auch 
als Abbruchkriterium hernehmen, daß der Nachfolger des letzten Elementes 
nicht existiert und somit nach Abarbeitung der Schleife der Zeiger auf 
das letzte Element zeigt. Ob das sinnvoller wäre, wage ich zu 
bezweifeln.

W.S.

von Wilhelm M. (wimalopaan)


Lesenswert?

W.S. schrieb:

> Immerhin besteht normalerweise eine nicht leere Liste aus zumindest
> einem Element (oder mehreren) und da hat das allererste Element keinen
> Vorgänger und das letzte Element keinen Nachfolger.

Wenn Du den Text liest, stellst Du fest, dass es ein zirkuläre Liste 
war, wobei der Kopfknoten Teil der Liste selbst ist. Sie hat also 
mindestens einen Knoten.

von Oliver S. (oliverso)


Lesenswert?

W.S. schrieb:
> Zusicherungen? Ach nö, es ist immer wieder die generelle
> Erwartungshaltung der C-Programmierer, daß Variablen gefälligst ohne
> eigenes Zutun initialisiert zu sein haben.

Ach nö, ewig das selbe Geplärre von dir. Die Erwartungshaltung der 
C-Programmierer ist, wie bei allen anderen Programmieren von 
Programmiersprachen auch (ausser dir), daß sich die Compiler an die 
Spezifikation der Sprache halten. Und ja, das selbstverständlich 
gefälligst ohne eigenes Zutun.

Du betreibst Cargokult-Programmierung. Kann man machen, macht man aber 
besser nicht.

Oliver

von Georg A. (georga)


Lesenswert?

Zombie schrieb:
> Ich möchte nochmals auf das Thema "sicherer Integer-Typ" zurück zu
> kommen. Boost stellt so einen Typ zur Verfügung:

Lustig, dass "man" jetzt nach unzähligen 
selbst-in-den-Fuss-geschossen-Fällen das implementiert, was in den ach 
so übel streng typisierten "Steinzeit"-Sprachen ADA und VHDL schon in 
der Sprachdefinition selbst drin ist...

So insgesamt finde ich diese Trends recht unterhaltsam. Wir werden uns 
evtl. noch so 5-10 Jahre mit immer strengerer Typprüfung aufhalten, und 
dann wird auf den Konferenzen der nächste "Paradigm Shift" verkündet. 
Wird ganz schickes "Untypescript" geben, das mit KI automatisch immer 
die richtigen Cast und Konverter findet und es muss sich mehr mehr um 
irgendwelche blöden Typen kümmern ;)

von Wilhelm M. (wimalopaan)


Lesenswert?

Georg A. schrieb:
> Zombie schrieb:
>> Ich möchte nochmals auf das Thema "sicherer Integer-Typ" zurück zu
>> kommen. Boost stellt so einen Typ zur Verfügung:
>
> Lustig, dass "man" jetzt nach unzähligen
> selbst-in-den-Fuss-geschossen-Fällen das implementiert, was in den ach
> so übel streng typisierten "Steinzeit"-Sprachen ADA und VHDL schon in
> der Sprachdefinition selbst drin ist...

Da hast Du ggf. Recht.
Jedoch ist es ja so, dass eben Ada nicht sooo verbreitet ist: weder im 
Linux-Kernel noch auf den µC.

Ich denke eher, dass die meisten hier ihren "Stepanov" nicht gelesen 
haben. Und mangels der Möglichkeiten der Sprache C auch gar nicht auf 
die Idee gekommen sind.

von Stefan F. (Gast)


Lesenswert?

Georg A. schrieb:
> Wird ganz schickes "Untypescript" geben, das mit KI automatisch immer
> die richtigen Cast und Konverter findet und es muss sich mehr mehr um
> irgendwelche blöden Typen kümmern ;)

Bitte nicht, denn dann ergibt "1"+2 wieder 12.

von Ein T. (ein_typ)


Lesenswert?

Jörg W. schrieb:
> Den Linux-Kernel wird weder C++ noch Python interessieren. ;-)

$ find /usr/src/linux/linux-source-5.4.0/ -iname '*.py' | wc -l
105

;-)

von Ein T. (ein_typ)


Lesenswert?

Stefan ⛄ F. schrieb:
> Bitte nicht, denn dann ergibt "1"+2 wieder 12.

Aber genau das ergibt es doch. Okay, jedenfalls in Perl und PHP. ;-)

von Wilhelm M. (wimalopaan)


Lesenswert?

Ein T. schrieb:
> Stefan ⛄ F. schrieb:
>> Bitte nicht, denn dann ergibt "1"+2 wieder 12.
>
> Aber genau das ergibt es doch. Okay, jedenfalls in Perl und PHP. ;-)

Und in C / C++ einen Zeigerwert, der beim Dereferenzieren UB liefert 
(zurück zum Thema).

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ein T. schrieb:
> Stefan ⛄ F. schrieb:
>> Bitte nicht, denn dann ergibt "1"+2 wieder 12.
>
> Aber genau das ergibt es doch. Okay, jedenfalls in Perl und PHP. ;-)

In Perl?

Nö.
1
$ perl -e 'print "1"+2'
2
3

von Nano (Gast)


Lesenswert?

W.S. schrieb:
> Zusicherungen? Ach nö, es ist immer wieder die generelle
> Erwartungshaltung der C-Programmierer, daß Variablen gefälligst ohne
> eigenes Zutun initialisiert zu sein haben. Woanders lautet das
> Paradigma: vor Benutzung einer Variablen hat man diese _selbst_
> wenigstens einmal beschrieben zu haben, sonst ist deren Inhalt
> unbestimmt.

C soll aber auch performant für alle möglichen Szenarien sein.
Wenn du ein Array bestehend aus vielen int Werten füllen sollst und es 
nicht nötig ist, die int Werte im Array vorher auf 0 zu setzen, weil die 
Werte ohnehin überschrieben werden sollen, dann kann man sich das 
initialisieren auch sparen.

Andere Sprachen würden hier Zeit verschwenden und das Array erst einmal 
initialisieren, was in dem Fall aber gar nicht notwendig wäre.

Und wenn du das brauchst, dann geht, solange die Werte nur mit einer 0 
initialisiert werden sollen, auch bei 10000 Werten immer noch einfach 
mit einem:
1
#define ELEMENTE 10000
2
int daten1[ELEMENTE] = { };

Lediglich wenn du das Array mit anderen Werten als 0 füllen willst, wird 
es gemäß Sprachstandard doof, da wird es dann Compilerspezifisch.
Mit GCC und CLANG geht folgendes:
1
#define ELEMENTE 10000
2
int daten[ELEMENTE]={ [0 . . . ELEMENTE-1] = 1 };
Dann hast du auch lauter Einsen im Array stehen.

Und ja, da wäre es schön, wenn man bei der ISO C Standarddefinition 
nachhelfen würde und mit c2x oder später etwas einbaut, mit dem das dann 
standardisiert geht.

> Und wenn das Abbruchkriterium für eine Schleife darin besteht, daß das
> letzte Element einer Liste eben keinen Nachfolger hat, dann sollte dem
> Programmierer auch klar sein, daß nach Abarbeitung der Schleife der
> betreffende Zeiger eben NICHT auf irgendwas sinnvolles zeigt. Also wo
> ist der Fehler?

Was ja auch logisch ist.
Denn die Prüfung kostet Zeit, während ein einfacher Zähler der mitzählt 
und der so gar nicht zu einer Überschreitung führt, performancegünstiger 
ist.

von Wilhelm M. (wimalopaan)


Lesenswert?

Nano schrieb:
> Lediglich wenn du das Array mit anderen Werten als 0 füllen willst, wird
> es gemäß Sprachstandard doof, da wird es dann Compilerspezifisch.
> Mit GCC und CLANG geht folgendes:#define ELEMENTE 10000
> int daten[ELEMENTE]={ [0 . . . ELEMENTE-1] = 1 };
> Dann hast du auch lauter Einsen im Array stehen.

Auch hier könnte man wieder die Goodies von C++ nutzen (hier: IIFE):
1
    auto a = []{
2
        std::array<uint8_t, 100> a;
3
        for(size_t i{}; auto& e: a) {
4
            e = i++;
5
        }
6
        return a;
7
    }();

Dann kannst Du beliebigen Inhalt als Initialisierung generieren - und 
nicht compiler-spezifisch.

: Bearbeitet durch User
von Nano (Gast)


Lesenswert?

Nano schrieb:
> Und wenn du das brauchst, dann geht, solange die Werte nur mit einer 0
> initialisiert werden sollen, auch bei 10000 Werten immer noch einfach
> mit einem:

Korrektur, ISO konform muss in der geschweiften Klammer eine 0 Stehen,
sonst gibt es bei aktiviertem -pedantic eine Warnung.
Leider darf es nichts anderes als eine 0 sein, nimmt man eine andere 
Zahl, wird nur der erste Wert mit diesem initialisiert und der Rest 
bekommt Nullen.
<c>
#define ELEMENTE 10000
int daten1[ELEMENTE] = { 0 };
</c>

Beitrag #7084115 wurde vom Autor gelöscht.
von Wilhelm M. (wimalopaan)


Lesenswert?

Nano schrieb:
> C soll aber auch performant für alle möglichen Szenarien sein.
> Wenn du ein Array bestehend aus vielen int Werten füllen sollst und es
> nicht nötig ist, die int Werte im Array vorher auf 0 zu setzen, weil die
> Werte ohnehin überschrieben werden sollen, dann kann man sich das
> initialisieren auch sparen.

Wenn der Compiler nachweisen kann, dass die Initialisierung wieder 
überschrieben wird, ohne dass sie woanders sichtbar wurde, wird er sie 
auch nicht ausführen. Das kannst Du ruhig dem Compiler überlassen. Wenn 
Du dagegen ein Element vergisst, dass hast Du wieder UB.

von Nano (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Auch hier könnte man wieder die Goodies von C++ nutzen (hier: IIFE):
>     auto a = []{
>         std::array<uint8_t, 100> a;
>         for(size_t i{}; auto& e: a) {
>             e = i++;
>         }
>         return a;
>     }();
>
> Dann kannst Du beliebigen Inhalt als Initialisierung generieren - und
> nicht compiler-spezifisch.

Geht zwar, ist aber keine schöne Lösung, da man zu viel Text für so 
etwas schreiben muss.

Schön wäre etwas kurzes, wie bei dem GCC/CLANG Beispiel. Und dafür 
sollte so etwas dann halt in den Sprachstandard.

In Rust geht das viel einfacher und kürzer (ein weiteres Beispiel warum 
man mit Rust schneller zum Ziel kommt):
1
fn main(){
2
  let data: [i32; 10] = [1; 10]; // 10 Elemente vom Typ i32 (32 Bit Integer) die mit dem Wert 1 initialisiert werden
3
  println!("i= {:?}\n",data); // Ausgabe des kompletten Arrays
4
}

von Nano (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Nano schrieb:
>> C soll aber auch performant für alle möglichen Szenarien sein.
>> Wenn du ein Array bestehend aus vielen int Werten füllen sollst und es
>> nicht nötig ist, die int Werte im Array vorher auf 0 zu setzen, weil die
>> Werte ohnehin überschrieben werden sollen, dann kann man sich das
>> initialisieren auch sparen.
>
> Wenn der Compiler nachweisen kann, dass die Initialisierung wieder
> überschrieben wird, ohne dass sie woanders sichtbar wurde, wird er sie
> auch nicht ausführen. Das kannst Du ruhig dem Compiler überlassen. Wenn
> Du dagegen ein Element vergisst, dass hast Du wieder UB.

Das kann natürlich sein. An die Optimierung durch den Compiler habe ich 
jetzt nicht gedacht.

von Wilhelm M. (wimalopaan)


Lesenswert?

Nano schrieb:
> Wilhelm M. schrieb:
>> Auch hier könnte man wieder die Goodies von C++ nutzen (hier: IIFE):
>>     auto a = []{
>>         std::array<uint8_t, 100> a;
>>         for(size_t i{}; auto& e: a) {
>>             e = i++;
>>         }
>>         return a;
>>     }();
>>
>> Dann kannst Du beliebigen Inhalt als Initialisierung generieren - und
>> nicht compiler-spezifisch.
>
> Geht zwar, ist aber keine schöne Lösung, da man zu viel Text für so
> etwas schreiben muss.

Ja, ich weiß: auch in Rust kann man einen Generator verwenden um 
folgendes zu erreichen. Ja, was wird kürzer dann als dies:
1
    auto a = []{
2
        std::array<uint8_t, 100> a;
3
        for(size_t i{}; auto& e: a) {
4
            e = sin(2 * M_PI / a.size());
5
        }
6
        return a;
7
    }();

> Schön wäre etwas kurzes, wie bei dem GCC/CLANG Beispiel. Und dafür
> sollte so etwas dann halt in den Sprachstandard.

Das obige ist Standard.


> In Rust geht das viel einfacher und kürzer.

Ja, aber wie schon zum wiederholten Mal gesagt, und das ist mein Punkt 
hier: es geht ja nicht um die Migration von C nach Rust, sondern darum, 
dass man in C auch die Goodies von C++ benutzen kann, ohne sich groß 
umstellen zu müssen: man kann das nutzen, und bleibt sonst bei C-Code 
bzw. C-like Code.

von Nano (Gast)


Lesenswert?

Wilhelm M. schrieb:
>> Schön wäre etwas kurzes, wie bei dem GCC/CLANG Beispiel. Und dafür
>> sollte so etwas dann halt in den Sprachstandard.
>
> Das obige ist Standard.

Also das hier ist GCC /CLANG spezifisch und nicht im C ISO Standard:
1
#define ELEMENTE 10000
2
int daten[ELEMENTE]={ [0 . . . ELEMENTE-1] = 1 }; // Nicht ISO konform

GCC
1
gcc -std=c17 -pedantic -Wall array.c -o array.bin
2
array.c: In function ‘main’:
3
array.c:11:31: warning: ISO C forbids specifying range of elements to initialize [-Wpedantic]
4
   11 |    int daten[ELEMENTE] = { [0 ... ELEMENTE-1] = 1 };
5
      |                               ^~~
6
                                        ^~~

und
CLANG
1
clang -std=c17 -pedantic -Wall array.c -o array.bin
2
array.c:11:31: warning: use of GNU array range extension [-Wgnu-designator]
3
   int daten[ELEMENTE] = { [0 ... ELEMENTE-1] = 1 };
4
                              ^
5
1 warning generated.


>> In Rust geht das viel einfacher und kürzer.
>
> Ja, aber wie schon zum wiederholten Mal gesagt, und das ist mein Punkt
> hier: es geht ja nicht um die Migration von C nach Rust, sondern darum,
> dass man in C auch die Goodies von C++ benutzen kann, ohne sich groß
> umstellen zu müssen: man kann das nutzen, und bleibt sonst bei C-Code
> bzw. C-like Code.

Ok.

von Wilhelm M. (wimalopaan)


Lesenswert?

Nano schrieb:
> Wilhelm M. schrieb:
>>> Schön wäre etwas kurzes, wie bei dem GCC/CLANG Beispiel. Und dafür
>>> sollte so etwas dann halt in den Sprachstandard.
>>
>> Das obige ist Standard.
>
> Also das hier ist GCC /CLANG spezifisch und nicht im C ISO Standard:

Ich sprach nicht von der Compiler-Erweiterung, sondern von meinem Code 
natürlich ;-) Ist doch klar ersichtlich. Der ist standard-konform.

: Bearbeitet durch User
von Nano (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Nano schrieb:
>> Wilhelm M. schrieb:
>>>> Schön wäre etwas kurzes, wie bei dem GCC/CLANG Beispiel. Und dafür
>>>> sollte so etwas dann halt in den Sprachstandard.
>>>
>>> Das obige ist Standard.
>>
>> Also das hier ist GCC /CLANG spezifisch und nicht im C ISO Standard:
>
> Ich sprach nicht von der Compiler-Erweiterung, sondern von meinem Code
> natürlich ;-) Ist doch klar ersichtlich. Der ist standard-konform.

Ok, da haben wir dann aneinander vorbeigeredet.
Ich habe nicht bestritten, dass dein gezeigter C++ Code nicht 
standardkonform sei. Wäre es so, hätte ich es vorher schon gesagt. Da 
sagte ich aber nur, dass er sehr viel Tipparbeit bedeutet und gewünscht 
wäre ja etwas sehr kurzes ohne viel Tipparbeit bei gleichzeitiger 
Standardkonformität.

Interessant wäre aber mal zu erfahren, warum man so etwas wie das, was 
GCC und Clang bei C bietet, nicht irgendwie in den Sprachstandard 
einbaut.
Da wären die Gründe sicher interessant.

von Wilhelm M. (wimalopaan)


Lesenswert?

Nano schrieb:
> Ok, da haben wir dann aneinander vorbeigeredet.
> Ich habe nicht bestritten, dass dein gezeigter C++ Code nicht
> standardkonform sei. Wäre es so, hätte ich es vorher schon gesagt. Da
> sagte ich aber nur, dass er sehr viel Tipparbeit bedeutet und gewünscht
> wäre ja etwas sehr kurzes ohne viel Tipparbeit bei gleichzeitiger
> Standardkonformität.

Auch das stand schon oben in meinem Beitrag, und dass man in Rust auch 
Generatoren verwenden kann. Naja, haste eben nicht gelesen ...

Nano schrieb:
> Interessant wäre aber mal zu erfahren, warum man so etwas wie das, was
> GCC und Clang bei C bietet, nicht irgendwie in den Sprachstandard
> einbaut.

Der Standardisierungsprozess ist offen, Du kannst Dich da gerne 
einbringen ;-)

von Karl Käfer (Gast)


Lesenswert?

Nano schrieb:
> Karl Käfer schrieb:
> Bei mir heißt es im Code immer noch Master und Slave und jetzt reg dich
> auf.
> Tipp: Renne dreimal um den Block, dann wird das wieder.

Nicht nötig, ich bin völlig ruhig und entspannt. Meine Kritik galt nicht 
Deiner Wortwahl, sondern den Inhalten Deiner Ausführungen.

>>> Erfahrene Entwickler würden lieber in Rust oder C++ programmieren,
>>> manche auch in C.
>>
>> Erfreulicherweise kann sich jeder in den Stackoverflow-Surveys der
>> letzten fünf Jahre (weiter habe ich nicht geschaut) überzeugen, daß dort
>> jedes Jahr Python die "Most Wanted" unter den Programmiersprachen war,
>> vor JavaScript und Go -- mit Ausnahme von 2021, da lag TypeScript
>> zwischen Python und JavaScript.
>
> Nur weil es für die einfacheren Sprachen mehr Programmierer gibt,
> bedeutet das nicht, dass erfahrene Entwickler sie für alles bevorzugen.

Du behauptest, Java sei eine "einfachere Sprache"? Und auch Python ist, 
sobald man ein gewisses Niveau erreicht hat, keine einfache Sprache 
mehr. Softwareentwicklung ist ja ohnehin keine ganz einfache Tätigkeit, 
und daran ändert die Wahl der einen oder anderen Sprache relativ wenig.

Ansonsten sind die Umfragen von SO bislang die beste Datenbasis, die ich 
zum Thema kenne, und andere unabhängige Rankings wie TIOBE, RedMonk und 
PYPL kommen gänzlich unabhängig von ihrer jeweiligen Methodik auf sehr 
ähnliche Ergebnisse wie SO. Daher beziehe ich mich bei meiner 
Einschätzung der Realität auf diese Datenbasis, behalte dabei aber 
natürlich im Hinterkopf, daß diese nicht unbedingt der Weisheit letzter 
Schluß sein können -- das ist der Natur der Sache nun einmal inhärent. 
Und was ich persönlich mir wünsche und worauf ich hoffe, ist davon 
unbenommen -- es gibt viele Dinge auf dieser Welt, die anders sind als 
ich sie mir wünsche, aber leider komme ich nicht darum herum, trotzdem 
anzuerkennen, daß sie sind wie sie sind.

Deine Argumentation beruht hingegen lediglich auf Deinen Hoffnungen, 
Wünschen und Überzeugungen. Wenn Du die Welt aus dieser Perspektive 
siehst, hast Du sicher ein sehr entspanntes Leben (jedenfalls, solange 
ich hier nichts schreibe...), und ich gönne Dir das ehrlich, aufrichtig 
und von ganzem Herzen. Bedauerlicherweise hat die Basis Deiner 
Argumentation aber nur wenig Berührungspunkte mit einer Realität, in der 
wir anderen Menschen leben (müssen), und die zumindest einige wenige von 
uns nach Kräften so zu verändern versuchen, daß sie sich unseren 
Wünschen, Hoffnungen und Überzeugungen annähert. Das geht nur, wenn man 
die Realität in ihrer ganzen häßlichen Schönheit erkennt und ihre 
traurige Existenz zumindest anerkennt.

Letzten Endes führen unsere unterschiedlichen Ansätze aber dazu, daß wir 
gar keine gemeinsame Diskussionsgrundlage haben. Hey, ich würde es toll 
finden, wenn Rust zu besserer Software führen würde. Aber deswegen kann 
ich doch nicht abstreiten, daß eine riesige Codebasis in anderen 
Sprachen existiert, daß Rust heute noch eher ein Nischendasein führt, 
daß andere Sprachen wie Python, Java, JavaScript und Go heute offenbar 
noch immer viel beliebter und weiter verbreitet sind als Rust. Das hab 
ich mir ja nicht ausgedacht und ich sage das auch nicht, weil ich Rust 
abwerten wollte oder es nicht mögen würde, sondern das ist einfach eine 
Tatsache.

Andererseits hast Du immerhin Anlaß zur Hoffnung, denn die letzten 
beiden neuen Sprachen, die erfolgreich aus dem Niemandsland aufgestiegen 
sind und weiterhin wachsen, sind beides native Sprachen, nämlich Go und 
Rust. Vielleicht sieht die Sache also in einigen Jahren schon wieder 
ganz anders aus. Aber im Moment ist es ausweislich aller vorliegenden 
Daten nun einmal Tatsache, daß die interpretierten Sprachen sowohl 
verbreiteter als auch beliebter sind.

> Es gibt Dinge, da kommt es auf Performance und geringem Platzbedarf an
> und dann wird ein erfahrener Entwickler da kein Javascript einsetzen.

Ich hatte NICHT gesagt, daß es solche "Dinge" nicht gäbe. Ich HATTE 
gesagt, daß diese "Dinge" seltener vorkommen, als viele Entwickler 
glauben.

> Rust wird weiter Erfolg haben, da Rust das gleiche kann wie C und C++
> und sich prinzipiell für das gleiche eignet, aber man damit schneller
> zum Ziel kommt, und sich weniger Bugs einschleichen weil es by default
> nicht die Fehler hat, die C und C++ haben und oben drauf kommen dann
> noch so Sachen wie Ownership und Borrowing. Und für die nebenläufige
> Programmierung eignet es sich auch besser.

Na das will ich doch sehr hoffen. Nicht nur, weil ich Rust mag, sondern 
vor allem auch, weil ich als Architekt, Entwickler, Betreiber und 
Benutzer von Software ein starkes Interesse daran habe, daß sie 
fehlerärmer, sicherer und stabiler wird.

Im Übrigen wäre es ein sehr starkes Argument für Rust, wenn man damit 
schneller zum Ziel käme als mit C oder C++. Dieses "schneller zum Ziel 
kommen" ist ja auch einer der wichtigsten Vorzüge vieler interpretierter 
Sprachen und insbesondere Python -- und dieses "schneller zum Ziel 
kommen" ist ja der Grund, warum die interpretierten Sprachen bisher 
gewonnen haben. Eine von Pythons wichtigsten Stärken ist nämlich genau 
das, schneller zum Ziel zu kommen, und meiner ganz persönlichen Ansicht 
nach ist das einer der Gründe, warum sich Python gegenüber ähnlichen 
Sprachen wie Ruby und Raku erfolgreich durchsetzen konnte.

Andererseits sehe ich auch, daß C++ mit dem Standard C++11 und dessen 
Nachfolgern eine enorme Weiterentwicklung gemacht und dabei auch 
verschiedene Features und Ideen aus anderen Sprachen mitgenommen hat. 
Wenn ich modernes C++ mit seinen Vorgängern vergleiche, empfinde ich 
ähnlich wie Bjarne Stroustrup, der gesagt hat: "es fühlt sich an wie 
eine andere Programmiersprache". Ich glaube zwar nicht, daß C++ jemals 
sein wichtigstes Alleinstellungsmerkmal aufgeben wird, nämlich die 
weitestgehende Abwärtskompatibilität mit C, weswegen C++ immer gewisse 
Altlasten mit sich herum schleppen wird. Aber das ändert nichts daran, 
daß es besser für die immer größer werdenden Anforderungen an 
Funktionalität und Komplexität von moderner Software gerüstet ist als 
seine älteren Versionen. Abschreiben und verabschieden würde ich C++, 
jedenfalls heute, noch lange nicht -- insbesondere dann nicht, wenn man 
mal betrachtet, was im Boost-Projekt so alles vorhanden oder in der 
Entstehung ist, und Boost gilt ja gemeinhin als eine Art Inkubator für 
die zukünftige Weiterentwicklung des Sprachstandards. Das ist aber nur 
meine persönliche Ansicht und lediglich von meinen Erfahrungen und 
Beobachtungen der letzten Jahrzehnte gespeist.

> In dem Feld ist Rust also die Zukunft und besseres ist nicht in Sicht.
> Das einzige was man versucht ist in C++ Features von Rust an C++ wieder
> dranzuflanschen. Das kann für bei gewachsenem Code und der breiten Masse
> an C++ Programmierer sinnvoll sein, löst aber nicht die Grundprobleme
> von C++.

Ach, ich mache das Softwarezeugs ja schon eine Weile und habe im Laufe 
der Jahre so viele Lobpreisungen, Heils- und Zukunfsversprechen 
gesehen... Ich würde mich enorm darüber freuen, wenn das Eine oder 
Andere davon endlich mal einträte -- allein, mir fehlt der Glaube. Weißt 
Du, wir Profis haben da einen Spruch: "Immer, wenn Du etwas 
idiotensicher gemacht hast, kommt die Natur und erfindet bessere 
Idioten".

> Du wiederholst mich.

Na dann freu Dich doch. Das ist ein prima Indikator dafür, daß Du Recht 
hast. ;-)

> Du widersprichst dir.

Nö.

> Wenn Cobold Entwickler die bestbezahlten Entwickler sind, dann kann
> Cobold als Sprache nicht günstig sein.

Die Kosten von Softwareentwicklung hängen nur in sehr geringem Maße von 
Gehältern einzelner Entwickler ab. Im Falle von Cobol und anderen 
Sprachen ist es so, daß es eine riesige Codebasis gibt, in der enorme 
Investitionen stecken und die die Basis etlicher geschäftskritischer 
Applikationen ist. Für die Betreiber ist es deswegen viel billiger, 
diese besonders teuren Entwickler mit der Pflege und Wartung dieser 
Software zu betreuen, als sie neu zu entwickeln. Und da es einen hohen 
Bedarf, aber nur ein überschaubares Angebot an solchen Entwicklern gibt, 
kommen da die üblichen Gesetze der Marktwirtschaft ins Spiel. Diese 
Sache mit Angebot und Nachfrage, die hast Du doch bestimmt mal in der 
Schule gehört, oder nicht?

> Also bla bla bla und Tschüß.
> Der einzige der nicht locker geblieben ist, bist du. Denn sonst hättest
> du dir deinen obigen Erguss sparen können.
> Du gehört zu solchen Leuten, die sich triggern lassen, wenn man im Code
> so Sachen wie master und slave benutzt.
> Dann gehst du auf die Barrikaten und kriegst nen roten Hals und besser
> wird der Code durch dein Rummeckern dann auch nicht.

Ach, wie langweilig, Du wirst immer so aggressiv und unsachlich. Wenn Du 
Dich nicht beherrschen kannst oder nicht darauf klarkommst, daß ich 
andere Perspektiven und Überlegungen habe als Du, und deswegen andere 
Meinungen vertrete, ist es vielleicht besser, wenn Du nicht mehr auf 
meine Beiträge antwortest. Denn offenbar schaffst Du es weder, mich 
einzuschüchtern, noch, mich zum Schweigen zu bringen. Am Ende regst 
immer wieder nur Du Dich auf, pöbelst herum und beleidigst mich, ohne zu 
bemerken, daß dieses Verhalten nur etwas über Dich aussagt. Das muß doch 
echt nicht sein -- zumal unsere Mitleser dann ständig meine Popcorn- und 
Biervorräte plündern! ;-)

von Wilhelm M. (wimalopaan)


Lesenswert?

Karl Käfer schrieb:
> zumal unsere Mitleser dann ständig meine Popcorn- und
> Biervorräte plündern! ;-)

Lach-Flash!

Ich plündere gar nix von Dir ;-) Meine Vorräte gehen dabei drauf ...

: Bearbeitet durch User
von Karl Käfer (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Karl Käfer schrieb:
>> mittlerweile
>> aber wieder deutlich nachzulassen scheinen: Kotlin
>
> Ich dachte Kotlin sei bei Android der Standard, ist das etwa schon
> wieder vorbei?

Ich glaube, der Standard ist eigentlich Java, aber die meisten (laut 
Quellen etwa 60%) Android-Entwickler sollen Kotlin nutzen, das ja 
Java-Bytecode erzeugen kann.

von Karl Käfer (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich halte es für Unklug, sich auf eine bestimmte Programmiersprache fest
> zu legen. Man schränkt sich damit nur unnötig ein. Im Beruf läuft man so
> Gefahr, links und rechts von anderen überholt zu werden.

Das sehe ich genauso wie Du. Dennoch sind mir schon einige Entwickler 
begegnet, die tatsächlich nur eine Sprache kannten und konnten, und die 
sich zum Teil mit Händen und Füßen dagegen gewehrt haben, eine weitere 
Sprache auch nur anzuschauen -- auch im professionellen Bereich.

Anfangs konnte ich mir das nicht erklären, mittlerweile habe ich aber 
zumindest eine Vermutung. Und die geht so: das Erlernen der ersten 
Programmiersprache ist besonders schwierig, weil man nicht nur Sprache, 
Tooling und Infrastruktur, sondern auch das Programmieren selbst 
erlernen muß. Also zu denken wie ein Entwickler, Probleme in kleine 
Teilaufgaben zu zerlegen, größere Projekte auf mehrere Dateien zu 
verteilen, Dateien und Ressourcen zu organisieren, die Dokumentation zu 
finden und korrekt zu verstehen, all diese Dinge eben -- das muß ich Dir 
nicht erzählen.

Das zu erlernen ist IMHO viel schwieriger als die Sprache selbst, und 
viele tun sich mit dem Programmierenlernen wesentlich schwerer als mit 
der Sprache. Manche erkennen aber nicht, daß man Programmieren nur 
einmal lernen muß und dieses einmal erworbene Wissen dann auch auf die 
meisten anderen Sprachen übertragen kann. Die Aneignung einer neuen 
Sprache ist danach nurmehr ein bisschen Vokabeln und Grammatik, aber das 
sehen manche leider nicht. Sie befürchten stattdessen, wieder bei Null 
anfangen zu müssen, und scheuen diesen Aufwand.

> Ich habe total untechnischen Grund, zuhause bestimmte andere
> Programmiersprachen zu benutzen: Weil sie anders sind, weil ich flexibel
> bleiben will.

Naja, auf der Arbeit wirst Du ja nach meiner Erinnerung auch dazu 
gezwungen, Java zu programmieren. Da kann ich gut verstehen, daß man das 
nicht auch noch in seiner oh viel zu raren Freizeit haben will... ;-)

von Stefan F. (Gast)


Lesenswert?

Karl Käfer schrieb:
> ...das muß ich Dir nicht erzählen.
> Das zu erlernen ist IMHO viel schwieriger als die Sprache selbst

Ja genau. Bei der Vielzahl der Programmiersprachen bringe ich manchmal 
Syntaktische Kleinigkeiten durcheinander, aber das merkt man spätestens 
beim Testen und man hat ja Tutorials + StackOverflow als 
Erinnerungshilfe.

> Naja, auf der Arbeit wirst Du ja nach meiner Erinnerung auch
> dazu gezwungen, Java zu programmieren.

Vor 2 Jahren ist Go dazu gekommen. Interessanterweise von einem 
Projektleiter initiiert, nicht von den Programmierern.

von Karl Käfer (Gast)


Lesenswert?

Jörg W. schrieb:
>
1
> $ perl -e 'print "1"+2'
2
> 3
3
>

Aber an sich wäre es doch viel schöner, wenn so etwas passieren würde, 
meinst Du nicht auch?
1
>>> "1" + 2
2
Traceback (most recent call last):
3
  File "<stdin>", line 1, in <module>
4
TypeError: can only concatenate str (not "int") to str

von Stefan F. (Gast)


Lesenswert?

Karl Käfer schrieb:
> Aber an sich wäre es doch viel schöner, wenn so etwas passieren würde,
> meinst Du nicht auch?

Ich wette, dass dies als ordentliche Umfrage etwa 50/50 ergeben wird.

von Karl Käfer (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Karl Käfer schrieb:
>> zumal unsere Mitleser dann ständig meine Popcorn- und
>> Biervorräte plündern! ;-)
>
> Lach-Flash!
>
> Ich plündere gar nix von Dir ;-) Meine Vorräte gehen dabei drauf ...

Das tut mir leid -- ich schulde Dir drei Flaschen Bier und eine Tüte 
Popcorn! ;-)

von Nano (Gast)


Lesenswert?

Karl Käfer schrieb:

> Hey, ich würde es toll
> finden, wenn Rust zu besserer Software führen würde. Aber deswegen kann
> ich doch nicht abstreiten, daß eine riesige Codebasis in anderen
> Sprachen existiert, daß Rust heute noch eher ein Nischendasein führt,
> daß andere Sprachen wie Python, Java, JavaScript und Go heute offenbar
> noch immer viel beliebter und weiter verbreitet sind als Rust.

Was du leider immer noch nicht verstanden hast ist folgender 
Sachverhalt:

Aus einer ökonomischen Sachverhalt (einfach, günstige Programmierer, 
kurze Entwicklungszeit) der sich aus dem Markt bedingt, ergibt sich 
nicht automatisch auch eine Beliebtheit, sondern eine Notwendigkeit und 
das war meine Aussage in meinem allerersten Kommentar zu diesem Thema.

Und deine ganze Diskussion wo du mit "der ist gegen Newbs" gestellten 
political Correctness Empörung anfängst und somit völlig am Thema vorbei 
diskutierst hättest du dir sparen können. Denn einmal ging es nur um 
eine kurze prägnante Beschreibung wo jeder weiß, was gemeint ist, daher 
Newbs und das eigentliche Thema war beliebte Sprache vs.  Sprache 
genutzt aufgrund von ökonomischem Druck.

Und deswegen sind auch deine ganzen Rankings Nullaussagen in dieser 
Sache.

Stell dir mal vor, Assembler macht Spaß! Bezahlen und daher nutzen tut's 
in der Wirtschaft zwar fast keiner mehr, aber Spaß machen tut es.
Und C macht auch Spaß, das gilt erst recht, wenn die Ressourcen auch 
noch begrenzt sind. Und darum geht es oben.

Javascript ist dagegen ziemlich langweilig. Und Basic auch.

Und du willst nun mit deiner falschen Interpretation des Marktes, dem es 
um Ökonomie und nicht um Beliebtheit geht, weiß machen, dass Javascript 
mehr Spaß macht als Assembler und C.

> Andererseits hast Du immerhin Anlaß zur Hoffnung, denn die letzten
> beiden neuen Sprachen, die erfolgreich aus dem Niemandsland aufgestiegen
> sind und weiterhin wachsen, sind beides native Sprachen, nämlich Go und
> Rust.

Go wird man nicht für die Systemprogrammierung nutzen.
Rust schon, da es sich auch dafür eignet.

Bei Go verhindert das bereits der Garbage Collector, als das man damit 
einen generell für alles mögliche geeigneten Kernel schreiben wollte.

> Aber im Moment ist es ausweislich aller vorliegenden
> Daten nun einmal Tatsache, daß die interpretierten Sprachen sowohl
> verbreiteter als auch beliebter sind.

Es geht nicht ums verbreiteter und zum beliebter siehe oben. Thema 
verfehlt.

> Ich hatte NICHT gesagt, daß es solche "Dinge" nicht gäbe. Ich HATTE
> gesagt, daß diese "Dinge" seltener vorkommen, als viele Entwickler
> glauben.

Und es geht hier nicht um selten oder häufig.

> Thema Cobold
> Und da es einen hohen
> Bedarf, aber nur ein überschaubares Angebot an solchen Entwicklern gibt,
> kommen da die üblichen Gesetze der Marktwirtschaft ins Spiel.

Siehste.
Und deswegen sind Javascript, Java, PHP, Python usw. Programmierer 
billig zu haben, weil es da genug davon gibt und die Anforderungen 
teilweise sogar gering sind.

> Ach, wie langweilig, Du wirst immer so aggressiv und unsachlich.

Wenn du mich persönlich angreifst, musst du das erwarten.

> Wenn Du
> Dich nicht beherrschen kannst oder nicht darauf klarkommst, daß ich
> andere Perspektiven und Überlegungen habe als Du, und deswegen andere
> Meinungen vertrete,

Persönliche Angriffe sind aber keine Meinungen.

> Am Ende regst
> immer wieder nur Du Dich auf, pöbelst herum und beleidigst mich, ohne zu
> bemerken, daß dieses Verhalten nur etwas über Dich aussagt.

Mein großes Vorbild ist wahrscheinlich Linus Torvald.

von Nano (Gast)


Lesenswert?

Karl Käfer schrieb:
> Stefan ⛄ F. schrieb:
>> Ich halte es für Unklug, sich auf eine bestimmte Programmiersprache fest
>> zu legen. Man schränkt sich damit nur unnötig ein. Im Beruf läuft man so
>> Gefahr, links und rechts von anderen überholt zu werden.
>
> Das sehe ich genauso wie Du.

Und darum ging es nicht.

von Roland F. (rhf)


Lesenswert?

Hallo,
Karl Käfer schrieb:
> Die Aneignung einer neuen Sprache ist danach nurmehr ein bisschen
> Vokabeln und Grammatik...

Nun ja, wer z.B. mit einer prozeduralen Programmiersprache 
"aufgewachsen" ist und dann auf eine objektorientierte Sprache (und dem 
damit verbundenen Programmierparadigma) umsteigt hat mehr zu lernen als 
ein paar Vokabeln und eine bisschen Grammatik.

> Sie befürchten stattdessen, wieder bei Null anfangen zu müssen,
> und scheuen diesen Aufwand.

Ich glaube eher das solche Leute sich die Frage stellen warum sie sich 
mit neuen Programmierparadigmen beschäftigen sollen, wo sie doch alle 
Probleme auch mit ihrem bisherigen "Werkzeug" lösen konnten.
Hier ist doch ständig zu lesen unter welchem Zeitdruck Software 
entwickelt werden muss. Da kann ich gut verstehen das sich manche 
Programmierer lieber auf ihre Erfahrungen verlassen anstatt neue Wege 
(mit neuen Fallstricken) zu gehen.

rhf

von Zeno (Gast)


Lesenswert?

Nano schrieb:
> C soll aber auch performant für alle möglichen Szenarien sein.
> Wenn du ein Array bestehend aus vielen int Werten füllen sollst und es
> nicht nötig ist, die int Werte im Array vorher auf 0 zu setzen, weil die
> Werte ohnehin überschrieben werden sollen, dann kann man sich das
> initialisieren auch sparen.
>
Hier haust Du aber was durcheinander bzw. würde ich W.S. Aussage hier 
nicht so starr sehen.
Um mal bei dem Arraybespiel zu bleiben: Wenn ich sicher weis, das ich 
das Array mit Werten fülle bevor ich den ersten lesenden Zugrriff auf 
selbiges mache, dann muß ich das ganz sicher nicht initialisieren, das 
geschieht dann halt bei Befüllen mit Werten. Gilt natürlich analog auch 
für alle anderen Variablen. Wenn ich allerdings nicht sicher stellen 
kann das eine Variable bei der ersten Abfrage mit sinnvollen Werten 
belegt ist, dann macht die Initialisierung schon Sinn, sonst können da 
sehr lustige Dinge raus kommen.
> Andere Sprachen würden hier Zeit verschwenden und das Array erst einmal
> initialisieren, was in dem Fall aber gar nicht notwendig wäre.
Das wäre z.B.?

von Wilhelm M. (wimalopaan)


Lesenswert?

Nano schrieb:
> Mein großes Vorbild ist wahrscheinlich Linus Torvald.

Nachgewiesenermaßen ist er sozial ein Totalausfall. Bin jetzt nicht 
sicher, wie Du das mit dem Vorbild meinst ...

von Wilhelm M. (wimalopaan)


Lesenswert?

Zeno schrieb:
> Nano schrieb:
>> C soll aber auch performant für alle möglichen Szenarien sein.
>> Wenn du ein Array bestehend aus vielen int Werten füllen sollst und es
>> nicht nötig ist, die int Werte im Array vorher auf 0 zu setzen, weil die
>> Werte ohnehin überschrieben werden sollen, dann kann man sich das
>> initialisieren auch sparen.
>>
> Hier haust Du aber was durcheinander bzw. würde ich W.S. Aussage hier
> nicht so starr sehen.
> Um mal bei dem Arraybespiel zu bleiben: Wenn ich sicher weis, das ich
> das Array mit Werten fülle bevor ich den ersten lesenden Zugrriff auf
> selbiges mache, dann muß ich das ganz sicher nicht initialisieren, das
> geschieht dann halt bei Befüllen mit Werten. Gilt natürlich analog auch
> für alle anderen Variablen. Wenn ich allerdings nicht sicher stellen
> kann das eine Variable bei der ersten Abfrage mit sinnvollen Werten
> belegt ist, dann macht die Initialisierung schon Sinn, sonst können da
> sehr lustige Dinge raus kommen.

Genauer gesagt ist der Zugriff auf nicht-initialisierten Speicher UB.
Kann man gut in einem constexpr-Kontext beobachten bzw. zeigen.

Wie ich oben schon mal gesagt habe, wird der Compiler "unnötige" 
Initialisierungen weg-optimieren, wenn er nachweisen kann, das kein 
anderer Zugriff erfolgen kann.

Ansonsten hilft ggf. auch der Einsatz einen UB-sanitizers, um das 
aufzudecken.

Anfänger machen sich meisten viel zu viel Gedanken um 
Mikro-Optimierungen, und vergessen dabei manchmal andere wichtigere 
Entscheidungen, etwa ob eine Datenstruktur für den angestrebten Einsatz 
wirklich performant ist (s.a. std::vector<> im Vergleich zu 
std::list<>).

von MaWin (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Nachgewiesenermaßen ist er sozial ein Totalausfall

Damit würde er sich hervorragend hier in das Forum integrieren.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Nano schrieb:
>> Mein großes Vorbild ist wahrscheinlich Linus Torvald.
>
> Nachgewiesenermaßen ist er sozial ein Totalausfall. Bin jetzt nicht
> sicher, wie Du das mit dem Vorbild meinst ...

Die Kondition des Sozial seins, auch manchmal als "Normal" sein 
bezeichnet, ist eine ernstzunehmende mentale Störung!

von (prx) A. K. (prx)


Lesenswert?

Wilhelm M. schrieb:
> Nano schrieb:
>> Mein großes Vorbild ist wahrscheinlich Linus Torvald.
>
> Nachgewiesenermaßen ist er sozial ein Totalausfall. Bin jetzt nicht
> sicher, wie Du das mit dem Vorbild meinst ...

Bekannt ist seine Neigung zu drastischer Ausdrucksweise. Sozialverhalten 
umfasst aber viel mehr als das.

von Nano (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Nano schrieb:
>> Mein großes Vorbild ist wahrscheinlich Linus Torvald.
>
> Nachgewiesenermaßen ist er sozial ein Totalausfall. Bin jetzt nicht
> sicher, wie Du das mit dem Vorbild meinst ...

Dann bin ich für alle Übertretungen entschuldigt. Ich kann ja dann nicht 
anders. Ihr braucht also mit mir Verständnis und Toleranz, ich kann 
nichts dafür. :)

von Karl Käfer (Gast)



Lesenswert?

Nano schrieb:
> Was du leider immer noch nicht verstanden hast ist folgender
> Sachverhalt:
>
> Aus einer ökonomischen Sachverhalt (einfach, günstige Programmierer,
> kurze Entwicklungszeit) der sich aus dem Markt bedingt, ergibt sich
> nicht automatisch auch eine Beliebtheit, sondern eine Notwendigkeit und
> das war meine Aussage in meinem allerersten Kommentar zu diesem Thema.

Bedauerlicherweise bist Du derjenige, der nicht versteht.

> Und deine ganze Diskussion wo du mit "der ist gegen Newbs" gestellten
> political Correctness Empörung anfängst und somit völlig am Thema vorbei
> diskutierst hättest du dir sparen können.

Das habe ich ja auch, bitte lern lesen. Mit keinem Wort habe ich mich an 
Deiner Wortwahl gestört, das ist allein Deine eigene Fehlinterpretation. 
Könntest Du jetzt wohl bitte damit aufhören, mit diesen Unterstellungen 
vom Thema abzulenken? Danke.

> Und deswegen sind auch deine ganzen Rankings Nullaussagen in dieser
> Sache.

Warum fühle ich bloß mich gerade an Morgensterns Palmström erinnert?

> Stell dir mal vor, Assembler macht Spaß! Bezahlen und daher nutzen tut's
> in der Wirtschaft zwar fast keiner mehr, aber Spaß machen tut es.
> Und C macht auch Spaß, das gilt erst recht, wenn die Ressourcen auch
> noch begrenzt sind. Und darum geht es oben.

Stell' Dir mal vor, Assembler und C haben mir auch Spaß gemacht. Mit C++ 
und Python habe ich allerdings Sprachen entdeckt, die mir noch mehr Spaß 
machen.

> Javascript ist dagegen ziemlich langweilig. Und Basic auch.

Ach, wenn man wie ich vom HP-97 kam, dann war Basic schon eine sehr 
coole Sache. Und JavaScript, naja... als die ersten Browser mit 
JavaScript kamen, habe ich noch CGIs in C entwickelt (mit der bekannten 
Library von Lincoln D. Stein, hach...), und daß dieses Browserdingsi auf 
einmal bewegte Dinge jenseits von <marquee>, <blink> und animierten GIFS 
animieren konnte, das war schon schick. Die Sprache selbst war aber 
schon damals ein ziemlicher Krampf, und ihr seitdem immer weiter 
ausgeuferter Mißbrauch zu Werbe-, Ressourcenverschleuder- und ähnlichen 
Nervzwecken hat meine Freude daran immer schneller abkühlen lassen. 
Zudem kenne ich bis heute leider keine einzige JavaScript-Engine, die 
keine erheblichen Memoryleaks aufweist.

> Und du willst nun mit deiner falschen Interpretation des Marktes, dem es
> um Ökonomie und nicht um Beliebtheit geht, weiß machen, dass Javascript
> mehr Spaß macht als Assembler und C.

Ich find' JavaScript auch nicht so toll, komme aber nicht darum herum, 
daß eine Vielzahl der Entwickler in der SO-Survey JavaScript als eine 
ihrer "Most Wanted" Sprachen angeben. Also: nicht als Sprache, zu der 
sie durch ihren Beruf gezwungen werden, sondern als Sprache, die sie 
nutzen WOLLEN (siehe dazu auch unter [3]). Diese Tatsache einfach 
sachlich und objektiv festzustellen zwingt mich ja nicht dazu, mir die 
Wünsche dieser Mehrheit zueigen zu machen.

[3] https://dict.leo.org/englisch-deutsch/to%20want

> Go wird man nicht für die Systemprogrammierung nutzen.
> Rust schon, da es sich auch dafür eignet.

Wer redet denn von Systemprogrammierung? Ach ja, Du. Und nur Du. 
Ausschließlich Du. Veränderst Du wieder mal mitten in einer Diskussion 
das Thema, um dann am Ende doch noch irgendwie glauben zu können, daß Du 
Recht hattest? Pardon, aber das hatten wir ja schon häufiger, und 
diesmal werde ich mich nicht darauf einlassen.

> Es geht nicht ums verbreiteter und zum beliebter siehe oben. Thema
> verfehlt.

Aber klar doch, haargenau darum ging es in meinem Ausgangsbeitrag, auf 
den Du so aggressiv und arrogant geantwortet hast. Warte, ich verlinke 
Dir den Beitrag noch einmal, dann kannst Du das noch einmal nachlesen: 
[1]. In diesem Beitrag von mir steht wörtlich: "[...] die beliebtesten 
und verbreitetsten Sprachen der Welt".

[1] Beitrag "Re: Linux ist endlich vom C89 Standard weg"

>> Ich hatte NICHT gesagt, daß es solche "Dinge" nicht gäbe. Ich HATTE
>> gesagt, daß diese "Dinge" seltener vorkommen, als viele Entwickler
>> glauben.
>
> Und es geht hier nicht um selten oder häufig.

Doch, genau darum geht es. Mein Eingangssatz in dem soeben erwähnten und 
verlinkten Beitrag [1] von mir war nämlich: "Entwickler machen sich viel 
häufiger Gedanken über Performance [...]". "Häufig" steht da, 
wortwörtlich, siehst Du das? Beherrschst Du die Kulturtechnik des 
verstehenden Lesens? Hier noch einmal zur Erinnerung:

[1] Beitrag "Re: Linux ist endlich vom C89 Standard weg"

> Siehste.
> Und deswegen sind Javascript, Java, PHP, Python usw. Programmierer
> billig zu haben, weil es da genug davon gibt und die Anforderungen
> teilweise sogar gering sind.

Da ich mir angesichts meiner einschlägigen Erfahrung mit Deinen Aussagen 
angewöhnt habe, jede davon genauer zu überprüfen, habe ich mal ein wenig 
mit Python, Pandas und den Rohdaten der StackOverflow-Survey von 2021 
herumgespielt, die kann man ja als CSV herunterladen. Nachdem ich zuerst 
alle NaNs und Outlier verworfen und die Daten dann nach den jeweiligen 
Programmiersprachen aufgedröselt habe, habe ich nun einige meiner 
Vermutungen bestätigt gefunden, und zudem neue Erkenntnisse gewonnen. 
Vielen Dank dafür, daß Du (wenngleich unfreiwillig) meinen Horizont 
erweitert hast.

Ich habe folgende Sprachen untersucht, weil sie hier im Thread erwähnt 
worden sind, und sie nach "interpretierten" und "nativen" Sprachen 
gruppiert, wie folgt:
1
interesting_languages = {
2
    'interpreted': [
3
        'Java', 'JavaScript', 'TypeScript', 'Python', 
4
        'Ruby', 'PHP', 'Perl', 'Raku'
5
    ], 
6
    'native': [
7
        'C', 'C++', 'Rust', 'Go'
8
    ]
9
}

Dabei kam heraus, daß Entwickler interpretierter Sprachen im Schnitt ca. 
66931.85 US-$ im Jahr verdienen, Entwickler nativer Sprachen dagegen 
71785.31 US-$. Anders gesagt, bekommen Entwickler interpretierter 
Sprachen 6.76 % weniger Gehalt, wie die angehängte Grafik 
"native_vs_interpreted_with_php.png" zeigt. Wenn ich die PHP-Leute 
herausrechne, sind es sogar nur 5.85 %.

Bestätigt sehe ich mich also, daß Entwickler für interpretierte Sprachen 
und solche für native Sprachen gar nicht so unterschiedlich viel kosten. 
Das hatte ich vorher schon vermutet, aber eben nur vermutet und deswegen 
nicht öffentlich äußern wollen. (Tatsächlich lege ich nämlich Wert 
darauf, meine Aussagen begründen und belegen zu können; das 
Hinausposaunen gefühlter Annahmen überlasse ich gerne anderen.)

Was mich hingegen überrascht hat, ist, daß Perl- und Ruby-Entwickler 
heute ähnlich teuer wie Rust-Entwickler sind 
("mean_salary_per_language.png"). Nur knapp darunter liegen C-, C++-, 
Java- und Python-Entwickler und das Schlußlicht von den in diesem Thread 
erwähnten Sprachen bilden die armen PHP-Entwickler. Mit Ausnahme der 
PHP-Entwickler liegen die Gehälter aber relativ nah beieinander, und ein 
Unternehmen, das seine Sprache(n) und Entwickler auf so einer Basis 
auswählt, lebt ohnehin nicht lange. (Achtung: die X-Achse der 
letztgenannten Grafik beginnt NICHT bei 0!)

Ein Whiskerplot über die Gehälter nach Sprachen 
"salaries_per_language.png" zeigt jedoch, wie groß die Varianzen sind 
und wie nah die Sprachen am Ende dann doch beieinander liegen. Der obere 
Plot in der Grafik zeigt die Verteilunge der Gehälter unterhalb von 300k 
US-D, deswegen die vielen Ausreißer, während ich in der unteren Grafik 
nur die realistischeren Gehälter zwischen 10k und 150k US-$ 
berücksichtigt habe. Im Kern zeigen beide Grafiken jedoch sehr ähnliche 
Gehaltsverteilungen, die sich weitestgehend überschneiden und daher 
vermutlich von anderen Faktoren als der präferierten künftigen 
Programmiersprache abhängen.

Die Behauptung, daß Entwickler interpretierter Sprachen signifikant 
günstiger seien als jene nativer Sprachen, können wir also getrost dem 
Reich der urbanen Legenden zuordnen. Dies vor allem auch wegen der sehr 
hohen Gehälter für die interpretierten Sprachen Ruby und, vor allem, dem 
(für mich überraschenden) Spitzenreiter Perl, der sogar Rust noch 
abhängt. Wegen so geringer Differenzen macht sich jedenfalls kein 
Betriebswirt ins Höschen oder muß sich gar sein Näschen pudern.

Okay, wenn billige Entwickler als Erklärung für die große Beliebtheit 
und die hohe Verbreitung von interpretierten Sprachen also ausfallen und 
diese Sprachen außerdem ja noch andere bekannte Nachteile haben, 
namentlich eine geringere Performance und einen höheren 
Ressourcenbedarf, ergibt sich als einziger logischer Schluß, daß die 
interpretierten Sprachen andere Vorteile haben, aufgrund derer sie so 
erfolgreich sind. Meine Vermutung ist immer noch dieselbe, die ich schon 
sehr früh in diesem Thread angedeutet habe: daß nämlich die Performance 
und der Ressourcenbedarf keine allzu große Rolle spielen. Mit haargenau 
dieser Aussage war ich in meinem ersten Beitrag in diesen Thread 
eingestiegen, nachzulesen hier: [1].

[1] Beitrag "Re: Linux ist endlich vom C89 Standard weg"

>> Ach, wie langweilig, Du wirst immer so aggressiv und unsachlich.
>
> Wenn du mich persönlich angreifst, musst du das erwarten.

Ich soll Dich persönlich angegriffen haben? Wie denn? Womit denn? 
Tatsächlich warst Du es doch, der hier wie ein betrunkener Holzfäller um 
sich geschlagen hat, gleich mit Deinen ersten Sätzen in Deiner ersten 
Antwort [2] auf meinen Beitrag von oben [1] ließest Du mich wissen, daß:

  - Entwickler, die mit interpretierten Sprachen arbeiten,
    billige Anfänger ("Newbs") seien

  - Entwickler, die mit interpretierten Sprachen arbeiten,
    so dumm seien, daß sie sogar Basic mochten

  - Entwickler, die mit interpretierten Sprachen arbeiten,
    unerfahrene, unfähige Dummbeutel sind, die mit "richtigen"
    (nach Deiner Definition von "richtig") Sprachen nicht zurecht
    kommen können

  - Erfahrene Entwickler lieber mit C, C++ und Rust arbeiten

Das heißt: trotz meiner mehr als 35 Jahre Berufserfahrung mit etlichen 
Sprachen tust Du mich gleich mal von vorneherein als billigen Anfänger 
ab. Und natürlich weißt nur Du, was erfahrene Entwickler wollen. 
Janeeisklaa.

Tatsächlich gebe ich mir aufgrund meiner sattsamen Erfahrungen mit Dir 
mittlerweile gar keine Mühe, mich zurückzuhalten, wenn ich es mit Dir zu 
tun habe. Ich weiß ja, daß Du Kritik und Widerspruch nicht ertragen 
kannst, und dann schnell aggressiv und beleidigend wirst. Deswegen gibt 
es nichts einfacheres für mich, als Dich immer nur höflich und 
respektvoll zu behandeln und nichts weiter zu tun, als völlig sachlich 
meine Meinungen zu vertreten. Danach muß ich nur noch anwarten, bis Du 
irgendwann ausflippst und Dich selbst entlarvst -- für mich ist das sehr 
komfortabel. ;-)


[1] Beitrag "Re: Linux ist endlich vom C89 Standard weg"
[2] Beitrag "Re: Linux ist endlich vom C89 Standard weg"

von (prx) A. K. (prx)


Lesenswert?

Karl Käfer schrieb:
> Was mich hingegen überrascht hat, ist, daß Perl- und Ruby-Entwickler
> heute ähnlich teuer wie Rust-Entwickler sind

Das könnte ein typisches Problem mit Statistiken sein. Wenn sich nämlich 
herausstellen sollte, dass Perl-Entwickler wesentlich älter sind, weil 
andere Sprachen schon vor langer Zeit den Rang abgelaufen haben. Mit dem 
Alter steigt meist auch das Einkommen.

In dem Fall hättest du nicht den sich im Gehalt ausdrückenden Wert der 
Programmierkenntnis in Perl ermittelt, sondern bloss die Abhängigkeit 
des Gehalts vom Alter. ;-)

Eine weiterer Schmutzeffekt könnten die Bereiche sein, wo die Sprachen 
eingesetzt werden. Das erklärt beispielsweise PHP, das jeder Wordpress 
nutzende 08/15 Webdesigner für bescheidene Ansprüche irgendwie kennen 
muss. Und davon gibts reichlich, viele sind vergleichsweise niedrig 
bezahlte Frischlinge.

: Bearbeitet durch User
Beitrag #7085548 wurde vom Autor gelöscht.
von Karl Käfer (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Karl Käfer schrieb:
>> Was mich hingegen überrascht hat, ist, daß Perl- und Ruby-Entwickler
>> heute ähnlich teuer wie Rust-Entwickler sind
>
> Das könnte ein typisches Problem mit Statistiken sein. Wenn sich nämlich
> herausstellen sollte, dass Perl-Entwickler wesentlich älter sind, weil
> andere Sprachen schon vor langer Zeit den Rang abgelaufen haben. Mit dem
> Alter steigt meist auch das Einkommen.
>
> In dem Fall hättest du nicht den sich im Gehalt ausdrückenden Wert der
> Programmierkenntnis in Perl ermittelt, sondern bloss die Abhängigkeit
> des Gehalts vom Alter. ;-)

Das könnte sein, ich bin ja selbst einer von diesen "Konvertiten", die 
von Perl zu Python gewechselt sind. Aber erfreulicherweise enthalten die 
Daten auch Angaben zum Alter sowie dazu, wann der Entwickler mit dem 
Programmieren angefangen und wieviele Jahre professioneller Erfahrung er 
hat. Insofern werde ich Deinen Hinweis morgen gerne ein wenig genauer 
recherchieren, danke!

Nebenbei: da ich ja selbst zu jenen gehöre, die von Perl auf Python 
umgestiegen sind, mithin also früher viele Jahre lang in Perl entwickelt 
habe, weil ich auch, wie häufig Perl damals eingesetzt wurde und wie 
groß die vorhandene Codebasis in dieser Sprache ist. Und da wir 
sicherlich beide wissen, wie ungerne Unternehmen neues Geld dafür 
ausgeben, vorhandene und funktionierende Lösungen zu ersetzen, könnte 
auch eine Verknappung der verfügbaren Perl-Entwickler die Daten 
beeinflußt haben. Vielleicht fällt mir ja eine Möglichkeit ein, auch das 
noch zu prüfen.

In dem Zusammenhang fällt insbesondere auch Ruby in den obengenannten 
Daten auf. Einen Weggang der Entwickler, wie er bei Perl zu beobachten 
war, habe ich bei Ruby noch nicht wahrgenommen, und der Ruby-Boom -- 
nicht zuletzt befeuert von Ruby On Rails, auf dem meines Wissens auch 
dieses Forum basiert -- begann IIRC deutlich später als die große Zeit 
von Perl. Auch diesbezüglich werde ich mal nachgrübeln, inwieweit ich 
solche Entwicklungen in den Daten nachvollziehen kann. Vielleicht sollte 
ich auch mal in die Daten der Vorjahre schauen und mit Plotly Express 
ein paar hübsch animierte Visualisierungen erstellen, mal schauen... ;-)

> Eine weiterer Schmutzeffekt könnten die Bereiche sein, wo die Sprachen
> eingesetzt werden. Das erklärt beispielsweise PHP, das jeder Wordpress
> nutzende 08/15 Webdesigner für bescheidene Ansprüche irgendwie kennen
> muss. Und davon gibts reichlich, viele sind vergleichsweise niedrig
> bezahlte Frischlinge.

Naja, Web- und insbesondere PHP-Entwicklung wurde schon seit jeher 
schlechter entlohnt als andere Bereiche und Sprachen. Das ist kein neues 
Phänomen und hat womöglich auch zu dem verbreiteten Vorurteil 
beigetragen, daß die Entwickler interpretierter Sprachen generell 
weniger verdienten.

Was mich im Übrigen auch wundert, ist, daß Java-Entwickler so 
vergleichsweise schlecht bezahlt werden. Java ist insbesondere im 
Enterprise-Umfeld besonders beliebt und große Konzerne neigen häufig zu 
eher höheren Gehältern, wie man auch hier im Forum daran erkennen kann, 
wieviele Leute gerne einen gut bezahlten und sicheren Konzernjob 
ergattern wollen. Und auch im Javabereich gibt es ja viele ältere, 
erfahrene Entwickler, bei denen das von Dir erwähnte Senioriätsprinzip 
zumindest theoretisch greifen müßte. Was mag da los sein, hast Du eine 
Idee?

von (prx) A. K. (prx)


Lesenswert?

Karl Käfer schrieb:
> bei denen das von Dir erwähnte Senioriätsprinzip
> zumindest theoretisch greifen müßte

Als Java-Programmierer wird man zwar auch älter, aber anders als bei 
Perl wachsen viele nach. Es sind heute viel mehr als früher, aufgrund 
des erheblichen Wachstums der Branche. Welche Sprachen werden heute als 
Teil akademischer Ausbildung gelehrt? Mir fehlt der Überblick.

Das erwähnte Alter ist nur ein einzelner Parameter, da gibts noch 
andere. Die Schwierigkeit bei Statistiken ist eben, die vielen Parameter 
einzufangen und einzurechnen, um sicher zu sein, dass man nicht zum 
Ergebnis kommt, die Störche brächten die Babys.

von Nano (Gast)


Lesenswert?

Karl Käfer schrieb:
> Nano schrieb:
>> Es geht nicht ums verbreiteter und zum beliebter siehe oben. Thema
>> verfehlt.
>
> Aber klar doch, haargenau darum ging es in meinem Ausgangsbeitrag,

Du hast ja auch schon da das Thema verfehlt.


> [1] Beitrag "Re: Linux ist endlich vom C89 Standard weg"

Und direkt darunter habe ich geantwortet und dir gesagt:

"Die sind verbreitet, weil die Entwickler für Firmen günstig sind, die
Newbs damit schnell zu recht kommen und die Auftraggeber die Software
möglichst kostengünstig haben wollen.
Mit beliebt hat das somit nur wenig zu tun, gut, für Newbs mag das
anders aussehen, aber die mögen bzw. mochten ja auch Basic.

Erfahrene Entwickler würden lieber in Rust oder C++ programmieren,
manche auch in C."

Daraus ergeben sich 2 Aussagen:
1. Firmen nutzen diese vielfach, weil damit Geld gespart wird.
2. Und im zweiten Abschnitt geht es gleich um die Beliebtheit, wo ich 
dir anhand von 1 begründe, dass es da nicht um Beliebtheit geht.


> Dabei kam heraus, daß Entwickler interpretierter Sprachen im Schnitt ca.
> 66931.85 US-$ im Jahr verdienen, Entwickler nativer Sprachen dagegen
> 71785.31 US-$. Anders gesagt, bekommen Entwickler interpretierter
> Sprachen 6.76 % weniger Gehalt, wie die angehängte Grafik
> "native_vs_interpreted_with_php.png" zeigt. Wenn ich die PHP-Leute
> herausrechne, sind es sogar nur 5.85 %.
>
> Bestätigt sehe ich mich also, daß Entwickler für interpretierte Sprachen
> und solche für native Sprachen gar nicht so unterschiedlich viel kosten.

6 bis 7 % Gehaltsunterschied ist nicht unerheblich.


> Was mich hingegen überrascht hat, ist, daß Perl- und Ruby-Entwickler
> heute ähnlich teuer wie Rust-Entwickler sind

Ja, was wohl an der Seltenheit liegt entsprechende Leute zu finden.
Dann muss man halt mehr zahlen.

> Die Behauptung, daß Entwickler interpretierter Sprachen signifikant
> günstiger seien als jene nativer Sprachen, können wir also getrost dem
> Reich der urbanen Legenden zuordnen.

6-7 % Gehaltsunterschied ist kein Hintergrundrauschen.
Deine Daten bestätigen eher meine Aussage als deine.


>>> Ach, wie langweilig, Du wirst immer so aggressiv und unsachlich.
>>
>> Wenn du mich persönlich angreifst, musst du das erwarten.
>
> Ich soll Dich persönlich angegriffen haben? Wie denn? Womit denn?

Na hier:
Beitrag "Re: Linux ist endlich vom C89 Standard weg"

Dein erster Satz zur Anleitung, dabei war das gar nicht relevant:
> Vielleicht solltest Du nicht so arrogant auf die "Newbs" herabblicken...

Und im gleichen Kommentar deine nächste Beleidigung:
> Insofern, sei mir bitte nicht böse, aber von kommerzieller
> Softwareentwicklung und deren ökonomischen Hintergründen scheinst Du
> nicht allzu viel Ahnung zu haben, und solltest deswegen vielleicht auch
> nicht versuchen, damit zu argumentieren. Für Dein Hobby kannst Du


> Tatsächlich warst Du es doch, der hier wie ein betrunkener Holzfäller um
> sich geschlagen hat,

Ich habe nur auf deine Angriffe entsprechend reagiert.


> gleich mit Deinen ersten Sätzen in Deiner ersten
> Antwort [2] auf meinen Beitrag von oben [1] ließest Du mich wissen, daß:
>
>   - Entwickler, die mit interpretierten Sprachen arbeiten,
>     billige Anfänger ("Newbs") seien
>
>   - Entwickler, die mit interpretierten Sprachen arbeiten,
>     so dumm seien, daß sie sogar Basic mochten
>
>   - Entwickler, die mit interpretierten Sprachen arbeiten,
>     unerfahrene, unfähige Dummbeutel sind, die mit "richtigen"
>     (nach Deiner Definition von "richtig") Sprachen nicht zurecht
>     kommen können

Dergleichen habe ich gar nicht geschrieben. Ich habe geschrieben:

"Die sind verbreitet, weil die Entwickler für Firmen günstig sind, die
Newbs damit schnell zu recht kommen und die Auftraggeber die Software
möglichst kostengünstig haben wollen.... "

Da steht günstig und nicht billig und es stimmt auch. Ein PHP 
Programmierer kostet weniger als ein C oder C++ Programmierer.

Und es ist auch richtig, dass Python bei Newbs beliebt ist, weil man 
damit schnell zum Ziel kommt, während man sich bei C noch um die 
Speicherverwaltung selber kümmern müsste, was Newbs abschreckt.

Ich habe also lediglich Fakten geliefert, und wie du jetzt oben 
verlautbaren lässt, hast du das falsch verstanden und mich dann 
anschließend, siehe oben angegriffen.


>   - Erfahrene Entwickler lieber mit C, C++ und Rust arbeiten

Und das ist auch wahr.
Java mit seinem Garbage Collector ist bei erfahrenen Entwicklern nicht 
so beliebt wie C++.



> Das heißt: trotz meiner mehr als 35 Jahre Berufserfahrung mit etlichen
> Sprachen tust Du mich gleich mal von vorneherein als billigen Anfänger
> ab.

Von dir habe ich gar nicht gesprochen, ich bin auf deine Aussage ein und 
habe dir versucht zu erklären, woran das liegt und dafür hast du mich 
angegriffen und ich habe dann darauf entsprechend reagiert. Das Problem 
liegt also an dir, weil du nen Elefanten aus nichts machst.

> Und natürlich weißt nur Du, was erfahrene Entwickler wollen.
> Janeeisklaa.

Jupp.

>  Ich weiß ja, daß Du Kritik und Widerspruch nicht ertragen
> kannst, und dann schnell aggressiv und beleidigend wirst.

Das ist eine weitere Unterstellung. Ich gebe nur raus, wenn man mich 
vorher beleidigt, nie anders herum und das war hier schon immer so.
Wer mit mir also niveauvoll diskutiert, der kriegt von mir auch 
niveauvolle Antworten.
Wer mich aber persönlich angreift, wie du es getan hast, der kriegt dann 
eben auch die entsprechende Reaktion darauf.

>Deswegen gibt
> es nichts einfacheres für mich, als Dich immer nur höflich und
> respektvoll zu behandeln und nichts weiter zu tun, als völlig sachlich
> meine Meinungen zu vertreten.

An deinen obigen Unterstellungen war nichts sachlich.

von W.S. (Gast)


Lesenswert?

Ach, inzwischen sind wir bei der verbalen Prügelei angekommen. O ha.

Da kommt mir ein altberliner Witz in den Sinn: sagt ein Gammler zu einem 
anderen: "Du, da hat eena jesacht, ick seh aus wie du" - Antwort: "Wer 
war det? Den hau ick inne Fresse".

Na dann, frohes Weiterprügeln.

W.S.

von Ein T. (ein_typ)


Lesenswert?

Georg A. schrieb:
> So insgesamt finde ich diese Trends recht unterhaltsam. Wir werden uns
> evtl. noch so 5-10 Jahre mit immer strengerer Typprüfung aufhalten, und
> dann wird auf den Konferenzen der nächste "Paradigm Shift" verkündet.
> Wird ganz schickes "Untypescript" geben, das mit KI automatisch immer
> die richtigen Cast und Konverter findet und es muss sich mehr mehr um
> irgendwelche blöden Typen kümmern ;)

Das wäre doch toll, wenn man sich nicht mehr um blöde Typen kümmern 
müsste. Noch besser wäre aber, wenn dabei auch gleich das Problem mit 
blöden Typinnen gelöst werden könne. Aber ich fürchte, dass das weder 
eine Sprache noch eine KI leisten können, denn dabei scheitert ja 
manchmal sogar die RI.

von Karl Käfer (Gast)



Lesenswert?

(prx) A. K. schrieb:
> Als Java-Programmierer wird man zwar auch älter, aber anders als bei
> Perl wachsen viele nach. Es sind heute viel mehr als früher, aufgrund
> des erheblichen Wachstums der Branche. Welche Sprachen werden heute als
> Teil akademischer Ausbildung gelehrt? Mir fehlt der Überblick.

Meines Wissens sind Java und C++ dort weit verbreitet.

> Das erwähnte Alter ist nur ein einzelner Parameter, da gibts noch
> andere. Die Schwierigkeit bei Statistiken ist eben, die vielen Parameter
> einzufangen und einzurechnen, um sicher zu sein, dass man nicht zum
> Ergebnis kommt, die Störche brächten die Babys.

Ach, ich weiß nicht... an der Churchill zugeschriebenen Aussage, "ich 
glaube keiner Statistik, die ich nicht selbst gefälscht habe", ist 
sicherlich etwas dran, und für Umfragen, deren Ergebnisse nach 
einschlägigen Untersuchungen sehr stark von der Art der Fragestellung 
abhängen, gilt das natürlich noch viel mehr. Andererseits erlebe ich 
auch sehr häufig, daß viel mehr in eine Statistik hinein interpretiert 
wird, als eigentlich darin steht. Das geschieht mal bewußt, häufiger 
aber sogar unbewußt. Man muß also nicht nur als Produzent, sondern auch 
als Konsument von Statistiken immer darauf achten, wie die Datenbasis 
zustande gekommen ist, welche Aussagekraft sich daraus ableiten läßt, 
welche(r) Aspekt(e) betrachtet und sie das getan wurde. Wer das nicht 
penibel beachtet, wird schnell entweder vom Statistiker oder sogar vom 
eigenen Kopf in die Irre geführt.

Wie dem auch sei, Du scheinst mit Deiner Vermutung absolut Recht zu 
haben. In den Daten von SO ist das Alter leider nur in Altersklassen 
angegeben und deswegen nur begrenzt aussagekräftig. Aber in den Daten 
sind die Jahre als Coder ("yearscode") sowie die Jahre als 
professioneller Entwickler ("yearscodepro") angegeben, und mit diesen 
Daten ergeben sich, nach Sprachen sortiert, die in der angehängten 
Grafik "yearscode_yearscodepro_per_language.png" abgebildeten Plots. In 
beiden Diagrammen zeigt sich, daß Perl-Entwickler im Schnitt deutlich 
mehr Erfahrung haben als die Entwickler in anderen Sprachen.

Schon häufiger habe ich nun gehört, daß das Senioritätsprinzip in 
Deutschland besonders ausgeprägt sei. Darum habe ich mir das in den 
weltweit gesammelten Daten von SO einmal genauer angeschaut, einmal 
insgesamt und einmal nach den Sprachen aufgesplittet. Die Ergebnisse 
finden sich in den anderen angehängten Diagrammen "salary_per_<xyz>.png" 
und zeigen das Erwartete, daß das Senioritätsprinzip keine rein deutsche 
Spezialität zu sein scheint.

von Karl Käfer (Gast)


Lesenswert?

Nano schrieb:
> Dergleichen habe ich gar nicht geschrieben.

Laß' gut sein. Ich habe schon sehr gut verstanden, was Du geschrieben 
hast, wie es gemeint, und an wen es gerichtet war. Und wenn Du gar so 
empfindlich bist und alle Kritik und jeden Widerspruch gleich als 
persönliche Beleidigung und als Angriff wahrnimmst, stünde es Dir besser 
zu Gesicht, Dich von vorneherein erst einmal an die eigene Nase zu 
fassen und Dich in Deiner eigenen Wortwahl zu mäßigen. Erstmal den 
Lauten geben, über Unternehmen und "Newbs" ranten, und uns anderen 
vorschreiben zu wollen, in welcher Sprache sie gefälligt gerne zu coden 
haben, um als "erfahrene Entwickler" durchgehen zu dürfen, dann aber das 
Schneeflöckchen zu geben, wenn die sich das nicht gefallen lassen und 
Dir widersprechen, wirkt leider ein bisschen... arrogant und 
inkonsequent.

All das habe ich Dir schon zwei- oder dreimal gesagt und auch, was schon 
unsere Mütter wußten: wie man in den Wald hineinruft, so schallt es 
wieder heraus. Ich reagiere gemeinhin sehr sensibel auf mein Gegenüber, 
und wenn Du mir immer gleich mit der Keule kommst, wirst Du auch 
fürderhin damit rechnen müssen, daß auch ich eine solche besitze -- und 
bisher nicht glaube, daß Deine größer ist.

Was die Gehaltsunterschiede angeht, so mǘßte eigentlich jeder leicht aus 
meinen Diagrammen erkennen können, wie groß die Streuungen und wie 
vernachlässigbar also popelige sechs oder sieben Prozent sein müssen. 
Aber laß' gut sein, Du hast Recht und ich hab' meine Ruhe. Au reservoir, 
mondamin. ;-)

von Nano (Gast)


Lesenswert?

Karl Käfer schrieb:
> Nano schrieb:
> Und wenn Du gar so
> empfindlich bist und alle Kritik und jeden Widerspruch gleich als
> persönliche Beleidigung und als Angriff wahrnimmst, stünde es Dir besser
> zu Gesicht, Dich von vorneherein erst einmal an die eigene Nase zu
> fassen und Dich in Deiner eigenen Wortwahl zu mäßigen.

Der Unterschied ist, ich  habe meine Aussagen allgemein gehalten und 
niemanden beleidigt, mein Newb oben enthält nicht einmal einen wertenden 
Charakter, der entstand bei dir lediglich nur in deinem Kopf, weil du 
etwas dazu gedichtet hast, was nicht da steht. Während du deine Aussage 
direkt auf mich gerichtet hast. Und das macht einen sehr großen 
Unterschied aus, insbesondere juristisch.

Uns selbst wenn mein Newb eine wertende Komponente enthalten hätte und 
ich z.b. gesagt hätte:
"Newbs blicken es nicht."

Dann dürfte ich das sogar sagen, denn Newbs ist nicht näher definiert, 
die Gruppe ist nicht fassbar, wann ist man ein Newb, wann beginnt man 
keiner mehr zu sein? Daher wäre das trotz wertendem Charakter eine 
Meinung und keine Beleidigung.

Wenn du nun aber sagst:
"Nano blickt es nicht."

Dann sieht's schon juristisch ganz anders aus. Denn meine Person ist 
eindeutig und dann ist das keine Meinung mehr, sondern eine klare 
Beleidigung.

Deswegen nochmal, ich habe keinen beleidigt, du aber mich sehr wohl.


> Erstmal den
> Lauten geben,... "Newbs" ranten,

Eben nicht.
Nochmal, der Defekt entstand in deinem Kopf.

Und über Unternehmen habe ich schon gar nicht "geranted". Ich sagte 
lediglich, dass Unternehmen Sprachen, wo die Programmierer günstig sind, 
bevorzugen und das ist ökonomisch völlig normal und entspricht auch der 
Realtität.


> wie man in den Wald hineinruft, so schallt es
> wieder heraus.

Dann streng dich das nächste mal an und dichte beim Lesen nicht Sachen 
dazu, die nicht da stehen.

> Ich reagiere gemeinhin sehr sensibel auf mein Gegenüber,

Das sieht man. Deswegen habe ich dir auch gesagt, dass ich in meinem 
Code noch eine Master und Slave Bezeichnung nutze.
Wahrscheinlich fällst du da gleich vom Stuhl, weil ich das benutze.
Vermutlich achtest du auch ganz penibel auf Gendersprech und wenn das 
Fußgängermännchen bei einer Ampel nicht geschlechtsneutral ist, dann 
springst du wahrscheinlich aufgrund von political Fehlverständnis auf 
die Barrikaden und schreibst dem Bürgermeister einen dicken 
Beschwerdebrief anstatt die Kirche einfach mal im Dorf zu lassen.

> und wenn Du mir immer gleich mit der Keule kommst, wirst Du auch
> fürderhin damit rechnen müssen, daß auch ich eine solche besitze -- und
> bisher nicht glaube, daß Deine größer ist.

Machst du jetzt auf Trump?

von Zeno (Gast)


Lesenswert?

Schon erstaunlich wie man sich an so einem Thema aufgeilen kann.
Jeder huldigt halt seinem Gott oder snders herum: "Du sollst keine 
Götter haben neben mir"

von W.S. (Gast)


Lesenswert?

Nano schrieb:
> Wenn du nun aber sagst:
> "Nano blickt es nicht."
>
> Dann sieht's schon juristisch ganz anders aus. Denn meine Person ist
> eindeutig und dann ist das keine Meinung mehr, sondern eine klare
> Beleidigung.

Ach wo, das ist weder eine Beleidigung noch eine Meinung, sondern 
lediglich das Nennen einer Tatsache.
Oder?
Hiermit erlaube ich mir, auch mal ne homöopatische Prise Schlamm für die 
hier gerade stattfindende Schlacht aufzunehmen. Was - bittesehr - hat 
das alles mit dem Thema dieses Threads zu tun? Rein garnichts. Außer der 
Gereiztheit, daß Leute sich nicht in der ihrer eigenen Meinung nach 
ihnen gebührenden Verehrung angesehen fühlen.

Karl Käfer schrieb:
> Au reservoir, mondamin. ;-)

Törööh!

W.S.

von Stefan F. (Gast)


Lesenswert?

Nano schrieb:
> Denn meine Person ist eindeutig

?????? Schon vergessen, dass dein Ego hier anonym auftritt?

von Nano (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Nano schrieb:
>> Denn meine Person ist eindeutig
>
> ?????? Schon vergessen, dass dein Ego hier anonym auftritt?

Das spielt keine Rolle, weil ein Angriff sich ja an die Person hinter 
dem Pseudonym richtet.

von Nano (Gast)


Lesenswert?

Nano schrieb:
> Stefan ⛄ F. schrieb:
>> Nano schrieb:
>>> Denn meine Person ist eindeutig
>>
>> ?????? Schon vergessen, dass dein Ego hier anonym auftritt?
>
> Das spielt keine Rolle, weil ein Angriff sich ja an die Person hinter
> dem Pseudonym richtet.

Ihr kriegt mich nicht!

von Nano (Gast)


Lesenswert?

Nano schrieb:
> Ihr kriegt mich nicht!

Mein Pseudonym kopieren und sich als mich ausgeben ist eine ganz billige 
unterwürfige Taktik.
Insofern, wer immer du auch bist, schäm dich.

Alle anderen dürfen auf die Uhrzeit desjenigen gucken, als er das 
Kommentar gepostet hat. Um 7:49 Uhr poste ich höchst selten.
Und der Mod kann die IP vergleichen, insofern ist das recht eindeutig.

von Nano (Gast)


Lesenswert?

@Moderation
Könntest ihr mal all IPs in diesem Thread vergleichen und gucken, 
welcher Forennutzer die gleiche IP hat, wie die des Kommentators der 
hier im Thread am 04.06.2022 um 07:49 Uhr gepostet hat?

Wäre doch mal interessant zu erfahren, wer da dahintersteckt.

von MaWin (Gast)


Lesenswert?

Nano schrieb:
> Mein Pseudonym kopieren und sich als mich ausgeben ist eine ganz billige
> unterwürfige Taktik.

Ja. Schäme dich!

von Nano (Gast)


Lesenswert?

MaWin schrieb:
> Nano schrieb:
>> Mein Pseudonym kopieren und sich als mich ausgeben ist eine ganz billige
>> unterwürfige Taktik.
>
> Ja. Schäme dich!

Damit hast du dich jetzt verraten. Jetzt wissen wir, wer es war.

von MaWin (Gast)


Lesenswert?

Nano schrieb:
> Jetzt wissen wir, wer es war.

Auf wen von uns beziehst du dich?

von Nano (Gast)


Lesenswert?

MaWin schrieb:
> Nano schrieb:
>> Jetzt wissen wir, wer es war.
>
> Auf wen von uns beziehst du dich?

Du bist nicht uns, du sprichst nur für dich alleine.

von MaWin (Gast)


Lesenswert?

Nano schrieb:
> Du bist nicht uns, du sprichst nur für dich alleine.

Das will ich doch hoffen.
Aber wer von uns bin ich?

von W.S. (Gast)


Lesenswert?

Nano schrieb:
> eine ganz billige unterwürfige Taktik.

Was bittesehr ist eine unterwürfige Taktik?

Etwa sowas wie damals im späten oströmischen Reich aka Byzanz: sich im 
Staube rückwärts kriechend wälzen vor dem Herrscher? Oder was?

W.S.

von Daniel A. (daniel-a)


Lesenswert?

Oliver S. schrieb:
> 🐧 DPA 🐧 schrieb:
>> Aber Hersteller nutzen Legale und Technische Wege, das zu umgehen
>
> Das Recht ist schon eine blöde Sache: Es nutzt nicht nur einem selber,
> sondern auch anderen. Das MUSS sofort geändert werden.

Jetzt haben sie es auf eure Autos abgesehen!
https://www.theverge.com/2022/7/12/23204950/bmw-subscriptions-microtransactions-heated-seats-feature

Tick Tack, schaut ruhig nur zu, bis ihr euch 2mal überlegen müsst, ob 
ihr lieber einen gefrorenen Arsch oder weniger auf dem Konto haben 
wollt! Es könnte ja sonst dem Gewinn der Autoindustrie schaden!

von Mombert H. (mh_mh)


Lesenswert?

Daniel A. schrieb:
> Jetzt haben sie es auf eure Autos abgesehen!
> 
https://www.theverge.com/2022/7/12/23204950/bmw-subscriptions-microtransactions-heated-seats-feature
>
> Tick Tack, schaut ruhig nur zu, bis ihr euch 2mal überlegen müsst, ob
> ihr lieber einen gefrorenen Arsch oder weniger auf dem Konto haben
> wollt! Es könnte ja sonst dem Gewinn der Autoindustrie schaden!

Das war doch bis jetzt auch so. Wer etwas besseres mit seinem Geld zu 
tun weiß, der kauft keine Sitzheizung.

von Daniel A. (daniel-a)


Lesenswert?

Aber jetzt musst du dir das jeden Monat von neuem überlegen.

von Mombert H. (mh_mh)


Lesenswert?

Daniel A. schrieb:
> Aber jetzt musst du dir das jeden Monat von neuem überlegen.

Kann ich, muss ich aber nicht. Ich kann mich sogar nach einem 
ausgedehnten Test dagegen entscheiden.

von Bauform B. (bauformb)


Lesenswert?

Daniel A. schrieb:
> Jetzt haben sie es auf eure Autos abgesehen!
> 
https://www.theverge.com/2022/7/12/23204950/bmw-subscriptions-microtransactions-heated-seats-feature

Das ist doch inzwischen ganz normal ;)
https://imgur.com/gallery/WloVDmK

Und falls jemand meint, er könnte sich von Monat zu Monat entscheiden:
https://twitter.com/moyix/status/1388586550682861568

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.