Stimmt eigentlich nicht. Weder war es vorher C89, noch ist es jetzt C11,
denn der Kernel hat schon immer sehr rege zahlreiche GNU-Erweiterungen
genutzt. Das ist der Grund, weshalb es ein riesiger Aufwand ist, den
Kernel mit was anderem als GCC übersetzt zu bekommen.
also die Hardware-Kastration zu ermöglichen, ist schon starker Tobak.
Anscheinend ist für Linus und Co. die Idee von open source einfach nur
quelloffene Projektdateien - und nichts mehr. Die Geeks kann man damit
verjagen und neue Kunden kommen so auch keine dazu.
Überhaupt gibt es unter Linux immer mehr Sachen, die fraglich sind.
linux fährt gegen die wand schrieb:> also die Hardware-Kastration zu ermöglichen, ist schon starker Tobak.
Naja, ob das mit dem Enablen von Features jetzt zB. nur übers Bios
möglich ist oder auch im Kernel ist eigentlich recht egal.
linux fährt gegen die wand schrieb:> also die Hardware-Kastration zu ermöglichen, ist schon starker Tobak.
Naja, ohne das "Feature" ist die Hardware auch kastriert.
> Anscheinend ist für Linus und Co. die Idee von open source einfach nur> quelloffene Projektdateien - und nichts mehr. Die Geeks kann man damit> verjagen und neue Kunden kommen so auch keine dazu.
Was sollten sie denn tun? Wenn sie es nicht einbauen, ist Linux halt das
System, das den kompletten Funktionsumfang eines Intel-Prozessors nicht
nutzen kann. Auf die Weise kommen mit Sicherheit auch keine Kunden dazu.
> Überhaupt gibt es unter Linux immer mehr Sachen, die fraglich sind.
Es geht halt heute kaum anders.
linux fährt gegen die wand schrieb:> also die Hardware-Kastration zu ermöglichen, ist schon starker Tobak.
Die ermöglichen keine Hardware-Kastration, sondern genau das Gegenteil:
das freischalten von zusätzlichen Funktionen. Das Intel-Konzept wird
dadurch zwar nicht besser, aber ob ignorieren dagegen hilft, ist doch
sehr fraglich.
linux fährt gegen die wand schrieb:> Anscheinend ist für Linus und Co. die Idee von open source einfach nur> quelloffene Projektdateien - und nichts mehr. Die Geeks kann man damit> verjagen und neue Kunden kommen so auch keine dazu.
Geeks sind für Linux schon lange keine Zielgruppe mehr. Und das ist auch
gut so.
Oliver
Stefan ⛄ F. schrieb:> Vielleicht schaffen die letzten Mikrocontroller Mohikaner hier auch noch> den Wechsel.
Nö, verschiedene Welten verschiedenen Programmiersprachen.
Ist doch gut so. Warum soll die ganze Welt Chinesisch sprechen nur weil
die derzeit grösste Tageszeitung in Mandarin gedruckt wird.
Und weder die Guangzhou Daily noch Linux ist der Nabel der Welt.
Geradlinig in alle Richtungen schrieb:> Stefan ⛄ F. schrieb:>> Vielleicht schaffen die letzten Mikrocontroller Mohikaner hier auch noch>> den Wechsel.>> Nö, verschiedene Welten verschiedenen Programmiersprachen.> Ist doch gut so.
Aber völlig unverständlich! Sonst muss es doch immer die neueste Version
einer Software sein und jedes Update wird mitgemacht. Bei C würde es
sich auf jeden Fall lohnen, was wäre bei C11 schlechter als bei C89? Wer
nicht gerade Millionen Zeilen Code umstellen muss, wechselt natürlich
gleich zu C17 oder sogar C2x.
Was spricht in diesem Fall für total veraltetes Werkzeug?
Bei Bauteilen staune ich auch immer wieder, dass hier bevorzugt die
ältesten Chips eingesetzt werden. Na gut, dafür gibt's seit 1 bis 2
Jahren immerhin ein Argument. Aber Compiler sind lieferbar.
Bei Chips ist noch das Problem, dass man die längerfristig braucht. Da
will man dann nicht, das man mit allem Fertig wäre, und dann gibts den
Chip schon nicht mehr, man soll den neueren nehmen. Ein 5 Jahre alter
Chip gibt es noch weitere 5 Jahre oder so. Der neue Chip von Gestern ist
vieleicht schon nächsten Monat wieder obsolete...
linux fährt gegen die wand schrieb:> also die Hardware-Kastration zu ermöglichen, ist schon starker Tobak.
Einigen wir uns drauf, dass du das ganz falsch verstanden hast. Außerdem
ist diese Geschäftsidee doch bei Messgeräten bewährt und akzeptiert,
wenn nicht sogar beliebt, oder?
Und dann wieder: gut für AMD, falls die Leute das wirklich ernsthaft
nicht mögen.
Bauform B. schrieb:> Bei C würde es> sich auf jeden Fall lohnen, was wäre bei C11 schlechter als bei C89?
Steht alles in den entsprechenden Meldungen, z.B. bei heise:
Ein neuer Sprachstandard bedeutet anscheinend die Nutzung eines neuen
Parsers beim gcc.
Mit allen Risiken und Nebenwirkungen, die das bei einem auf außerhalb
des Standards liegenden gcc-Erweiterungen angewiesenen, nicht ganz
kleinen Stückchen Software halt so mit sich bringt.
Oliver
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!
Im Endeffekt sind all diese Modelle rein nur dazu da, den Gewinn zu
maximieren, ohne einen Mehrwert zu bringen. Die Hardware - die man ja
schon gekauft hat - hat das ja alles schon verbaut, das Deaktivieren der
Features macht die HW nicht billiger herzustellen. Somit könnte die
ganze HW massiv günstiger verkauft werden!
Pakete, Produkte als Service, etc. Das sind alles Abzockmethoden, um
mehr Geld zu machen, ohne dass der Verbraucher etwas davon hat. Statt
gute Produkte zwingt man den Kunden schlechtere Angebote anzunehmen,
weil es halt nicht anders geht.
Der Zweck des freien Marktes / Kapitalismus ist es, dass Konkurrenz dazu
führt, das Unternehmen, bessere, billigere/mehr, oder sich sonst wie
abhebende Produkte macht, und wir so alle von mehr, billigeren &
besseren Produkten Profitieren. All diese Methoden der Unternehmen
anderweitig ihren Gewinn zu maximieren, sollten verboten werden! Das ist
ja auch die Idee hinter Antitrust/Kartellrecht, nur ist das leider in
der Zeit vor der Technologierevolution stehengeblieben!
Und Limitationen durch Software sind nochmal eine Nummer gefährlicher.
Da kann man nämlich nichts dagegen machen. Es ist quasi ein paralleles
Rechtssystem. Einen Safe kann ich aufbrechen. Verbote kann ich
ignorieren. Und Gesetze sind auch nicht dazu da, einem das Leben schwer
zu machen, sondern werden anhand der Situation und Intention ausgelegt -
theoretisch dem Willen des Folkes folgend. Aber künstliche
Softwarerestriktionen sind anders. Sie werden vom Hersteller Diktiert,
können nicht umgangen werden, und orientieren sich ausschliesslich an
den Eigeninteressen des Unternehmens, statt an den Interessen des
Volkes. Sozusagen eine Diktatur durch die Technologie-Hintertür!
Es besteht dringender Handlungsbedarf. Da darf nicht einfach weiter
zugesehen werden, die Technologiediktatur & Bevormundung muss gestoppt
werden! Es muss jetzt endlich mal gehandelt werden! Das Kartellrecht
braucht Weltweit ein saftiges Update.
🐧 DPA 🐧 schrieb:> Sie werden vom Hersteller Diktiert,> können nicht umgangen werden, und orientieren sich ausschliesslich an> den Eigeninteressen des Unternehmens, statt an den Interessen des> Volkes.
Rotfl ;)
Oliver
Ja ja, noch ist das lustig. Aber es kann nichts gutes daraus folgen,
eine kaputte fitness funktion nicht zu fixen. Sobald du für deinen
Toaster ein Abo brauchst, verstehst du es vielleicht.
DPA schrieb:> Sobald du für deinen> Toaster ein Abo brauchst, verstehst du es vielleicht.
Kein Sorge, ich werde keinen Toaster mit Abo bekommen. Und das wird
daran liegen, daß ich grundsätzlich und immer nur einen ohne kaufen
werde.
Ohne jetzt große Diskussionen über "das Volk" los zu brechen, hat dieses
nämlich immer noch die einfache, aber wirkungsvolle Macht, irgend einen
Schxxx schlicht nicht zu kaufen. Und selbst das kapitalistischste
Unternehmen kann daran nichts ändern. Gerade solche Unternehmen wissen
das aber auch ganz genau.
Oliver
Oliver S. schrieb:> hat dieses nämlich immer noch die einfache, aber wirkungsvolle Macht,> irgend einen Schxxx schlicht nicht zu kaufen.
Das setzt immer voraus, dass es entweder Alternativen gibt, oder man
darauf verzichten kann. Bei einem Toaster ist das (noch) so. Bei vielen
anderen Dingen aber schon nicht mehr.
linux fährt gegen die wand schrieb:> Überhaupt gibt es unter Linux immer mehr Sachen, die fraglich sind.
Je bunter die Anwendungsfälle, umso mehr Leuten missfallen einzelne
Farben. Damit muss man wohl leben - solange man kein eigenes OS
entwickelt.
Geradlinig in alle Richtungen schrieb:> Warum soll die ganze Welt Chinesisch sprechen nur weil> die derzeit grösste Tageszeitung in Mandarin gedruckt wird.
Es würde einiges vereinfachen. Doch nachdem Esperanto schon ein
Rohrkreppierer war würde ich es in diesem Leben nicht nochmal versuchen.
Stefan ⛄ F. schrieb:> Stattdessen wird nun auch C11 gesetzt
Warum eigentlich nicht gleich zu C17? Das sind doch eh nur bug fixes und
kleine Ergänzungen.
Bauform B. schrieb:> Aber völlig unverständlich! Sonst muss es doch immer die neueste Version> einer Software sein und jedes Update wird mitgemacht. Bei C würde es> sich auf jeden Fall lohnen, was wäre bei C11 schlechter als bei C89? Wer> nicht gerade Millionen Zeilen Code umstellen muss, wechselt natürlich> gleich zu C17 oder sogar C2x.>> Was spricht in diesem Fall für total veraltetes Werkzeug?
- Die neuen Tools sind deutlich langsamer.
- Die Programmierer haben sich den Assemblercode kritischer Funktionen
angeschaut, und den C Code so geschrieben dass das gewünschte Asm
rauskommt.
Der neue Compiler macht das eine oder andere anders, und keiner wird
da noch mal drüberschauen...
- C11 hat keine weltbewegenden Verbesserungen gegenüber C89.
Interessanter wäre C++, aber dann würde der Kernel mit jeder neuen
Compilerversion auseinanderfliegen.
- Der Kernel verwendet sowieso schon Gnu Erweiterungen wo nötig.
udok schrieb:> - Die Programmierer haben sich den Assemblercode kritischer Funktionen> angeschaut, und den C Code so geschrieben dass das gewünschte Asm> rauskommt.
In 90% der fälle macht das keiner. nur wenn was nicht läuft, wie es
soll, schaut man mal.
> Der neue Compiler macht das eine oder andere anders, und keiner wird> da noch mal drüberschauen...
Keiner wird alter Compiler Versionen verwenden, auch wenn der Code
weiterhin c89 wäre, und --std=c89 gesetzt wäre, würden alle moderne
Compilerversionen nehmen.
udok schrieb:> - C11 hat keine weltbewegenden Verbesserungen gegenüber C89.> Interessanter wäre C++, aber dann würde der Kernel mit jeder neuen> Compilerversion auseinanderfliegen.
Es gibt schon ein paar nette Sachen. z.B. static_assert ist einer meiner
Favoriten. _Generic ist manchmal auch ganz praktisch. Da lässt sich dann
das ein oder andere Macro etwas verschönern & sicherer machen.
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!
Auch nur schon in C99 sind gigantische Verbesserungen. "int x" nicht nur
am Anfang der Funktion schreiben zu können, Sachen wie "for(int x;;)",
usw. das macht den Code auch weniger Fehleranfällig.
Zombie schrieb:> 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.
Das ist in C89 aber noch einfach zu fixen. Ein Block { ... { int bla;
for(...){...} } ... } ist valide.
Es lässt sich aber nicht in das bestehende Macro verpacken, man hätte
also den Code mit vielen {} verunstalten müssen.
Zombie schrieb:> aber verstehe nur Bahnhof.
Seit C99 kannst du eine (allerdings auch nur eine) Schleifenvariable
direkt in der for-Anweisung definieren; deren Scope ist dann lediglich
die for-Anweisung selbst und die durch for gesteuerte Anweisung (die
häufig wieder ein ganzer Block ist).
Nach diesen beiden Anweisungen ist diese Variable nicht mehr sichtbar.
🐧 DPA 🐧 schrieb:> Auch nur schon in C99 sind gigantische Verbesserungen. "int x" nicht nur> am Anfang der Funktion schreiben zu können, Sachen wie "for(int x;;)",> usw. das macht den Code auch weniger Fehleranfällig.
Gigantische Verbesserung? Ich weiß nicht...
Ist alles natürlich Gewöhnungssache, aber ich mag es eigentlich lieber,
wenn alle Variablen am Anfang der Funktion klar deklariert sind.
Da weiß ich sofort wo ich suchen muss, und mit einem Tastenkürzel komme
ich hin.
Wenn ich aber viel C++ Programmiere, dann finde ich den C Weg wieder
komisch...
Auf jeden Fall nur Kosmetik.
Aber aus eigener Erfahrung (Spieltrieb!), kann ich dir sagen,
das der alte WinDDK 7.1 MS Compiler (2008) ca. 2x so schnell compiliert,
wie der neue 2019'er.
Der C Code ist teilweise um bis zu 20% schneller und meist etwas
kleiner.
Dafür macht der 2019 cl besseren C++ Code, und ist C++11 konform.
Ich habe sogar die Vermutung, das die Intel Entwickler auf die Asm
Ausgabe
des WinDDK 7.1 Compilers ihre CPU optimiert haben, der Asm Code ist oft
etwas "komisch", aber meist schneller als der vom 2019 cl, clang oder
gcc.
Zumindest bei den C Kompilern dürte das die "Krone" gewesen sein,
zumindest ist es nicht mehr besser geworden.
Gruss,
Udo
🐧 DPA 🐧 schrieb:>> - Die Programmierer haben sich den Assemblercode kritischer Funktionen>> angeschaut, und den C Code so geschrieben dass das gewünschte Asm>> rauskommt.>> In 90% der fälle macht das keiner. nur wenn was nicht läuft, wie es> soll, schaut man mal.
Eben, das ist das Problem. Du findest die Fehler oft ja nicht,
und meist läuft ja alles - nur halt 10% langsamer
(Auch wenn ich eher auf 0.1-1% tippe).
Ich muss jetzt gerade an ein paar wirklich böse Überraschungen der neuen
Compiler denken. Der gcc nützt ja jede Freiheit des Standards aus, um
den Entwicklern das Leben schwer zu machen, und um in theoretischen
Benchmarks besser auszuschauen. So ist etwa Überlaufverhalten von
INT in C nicht definiert. Daher folgern die Deppen, dass man Code
wegoptimieren kann das Überlaufen abfängt... viel Spaß beim
Fehlersuchen...
udok schrieb:> So ist etwa Überlaufverhalten von> INT in C nicht definiert. Daher folgern die Deppen, dass man Code> wegoptimieren kann das Überlaufen abfängt... viel Spaß beim> Fehlersuchen...
Code, der einen Überlauf abfängt, nach dem der schon aufgetreten ist,
ist halt unnötig, weil der Standard erst gar keinen Überlauf zulässt.
Klingt logisch, ist auch so.
Oliver
🐧 DPA 🐧 schrieb:> Sachen wie "for(int x;;)", usw.> das macht den Code auch weniger Fehleranfällig.
Exakt damit konnte Torvalds überzeugt werden, Linux von der Beschränkung
auf C89 zu lösen.
Jörg W. schrieb:> Seit C99 kannst du eine (allerdings auch nur eine) Schleifenvariable> direkt in der for-Anweisung definieren; deren Scope ist dann lediglich> die for-Anweisung selbst und die durch for gesteuerte Anweisung (die> häufig wieder ein ganzer Block ist).>> Nach diesen beiden Anweisungen ist diese Variable nicht mehr sichtbar.> for (int i = 0; i < I_MAX; i++)> do_something(i);> // hier gibt es "i" nicht mehr
Soweit bin ich noch mitgekommen, aber wo genau liegt der Bug bei:
1
structS{S*next;};
2
3
S*iterator=get_iterator();
4
5
for(;iterator!=NULL;iterator=iterator->next){
6
do_something(iterator);
7
}
8
// hier ist entweder iterator == NULL oder (falls man mit break die
9
// Schleife vorzeitig verlassen hat) ist iterator ein gültiger Pointer auf
10
// ein Element der Liste (solange die Liste nicht manipuliert wurde). Eine
11
// dritte Möglichkeit sehe ich nicht.
notfalls gebe es noch
1
{
2
S*iterator=get_iterator();
3
4
for(;iterator!=NULL;iterator=iterator->next){
5
do_something(iterator);
6
}
7
}
oder gibt es das in C auch nicht?
P.S. ich programmiere seit Jahren nur C++, wahrscheinlich ist das kein
korrekter C-Code. Man möge es mir nachsehen. Aber das Prinzip sollte ja
gleich sein.
(prx) A. K. schrieb:>> Sachen wie "for(int x;;)", usw.>> das macht den Code auch weniger Fehleranfällig.> Exakt damit konnte Torvalds überzeugt werden, Linux von der Beschränkung> auf C89 zu lösen.
Erstaunlich, dass man sich darüber noch streiten muss. Ich frage mich,
ob der Meister jemals in modernen Sprachen (z.B. Go) programmieren
würde, ohne Herpes-Bläschen zu bekommen.
(geschrieben auf einem Linux Laptop)
Stefan ⛄ F. schrieb:> Erstaunlich, dass man sich darüber noch streiten muss.
Dazu solltest du die entsprechende Diskussion im Detail nachlesen. Ich
bin mir ziemlich sicher, dass Torvalds keine Herpes-Bläschen als Grund
für seine Haltung nannte.
Stefan ⛄ F. schrieb:> Erstaunlich, dass man sich darüber noch streiten muss. Ich frage mich,> ob der Meister jemals in modernen Sprachen (z.B. Go) programmieren> würde, ohne Herpes-Bläschen zu bekommen.
Darüber muss man auch nicht streiten...
Per Punkt ist: Wenn man das zulässt, dann geht das nicht mit dem C89
Standard, und dann hat man einen anderen Compiler und einen
Rattenschwanz an Problemchen...
Schon klar das die, die Bugs nicht suchen müssen lautstark dafür sind.
Weil neu muss ist ja definitionsgemäss immer vieell besser.
In irgendeiner Pimperlsoftware spielt das auch eher keine grosse Rolle.
Linux ist aber nun mal extrem Hardware- und Compilerabhängig.
Das ist so wie bei einer uC Firmware, da will ich auch keinen Compiler,
der glaubt gescheiter zu sein als ich.
Wobei was ich weiss, der Kernel schon seit Jahren mit neuen gcc
Versionen compiliert wird, und da wurde auch heftig mit den gcc
Entwicklern gestritten.
Daher dürfte das aber hier schon alles durch sein, und das Thema ist nur
eine Zeitungsente...
(prx) A. K. schrieb:> Exakt damit konnte Torvalds überzeugt werden, Linux von der Beschränkung> auf C89 zu lösen.
Er hat doch schon vorher aufgegeben. Bei Rust. Bald steigt er ganz aus.
Der Laden wird immer mehr von den anderen übernommen.
Stallman zeigt dagegen immer noch, dass sein Rückgrat aus Stahl ist
(egal was man von seinen Ideen hält).
udok schrieb:> Ich muss jetzt gerade an ein paar wirklich böse Überraschungen der neuen> Compiler denken. Der gcc nützt ja jede Freiheit des Standards aus, um> den Entwicklern das Leben schwer zu machen, und um in theoretischen> Benchmarks besser auszuschauen. So ist etwa Überlaufverhalten von> INT in C nicht definiert. Daher folgern die Deppen, dass man Code> wegoptimieren kann das Überlaufen abfängt... viel Spaß beim> Fehlersuchen...
Oder die Crashes mit total komischem Backtrace, wenn in einer als "int
foo(...)" deklarierten Funktion ein return mit Wert fehlt (zB. return 0
am Ende). Gerade wenn man viel obskure Sachen mit Objekten, malloc und
Co macht, sucht man erstmal lange an dert völlig falschen Stelle...
Also ich finde es sehr gut, dass man auf eine neuere C Version
umsteigt.
Allerdings hätte man auch gleich auf C18 umsteigen können, anstatt nur
C11.
Denn C18 ist nur ein Bugfix von C11, während C11 die Bugs noch hat.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2244.htm
Zombie schrieb:> oder gibt es das in C auch nicht?
Iteratoren? Per se nicht, kann man sicher irgendwie nachbilden.
Und C++ konnte diese Syntax der for-Schleife schon lange.
udok schrieb:> Ich muss jetzt gerade an ein paar wirklich böse Überraschungen der neuen> Compiler denken. Der gcc nützt ja jede Freiheit des Standards aus, um> den Entwicklern das Leben schwer zu machen, und um in theoretischen> Benchmarks besser auszuschauen. So ist etwa Überlaufverhalten von> INT in C nicht definiert. Daher folgern die Deppen, dass man Code> wegoptimieren kann das Überlaufen abfängt... viel Spaß beim> Fehlersuchen...
Deppen sind diejenigen, die sich auf ein bestimmtes Überlaufverhalten
verlassen, obwohl sie eigentlich wissen, dass das in C undefiniert ist.
(prx) A. K. schrieb:> Ich> bin mir ziemlich sicher, dass Torvalds keine Herpes-Bläschen als Grund> für seine Haltung nannte.
Die Gründe, die er bei verschiedenen Themen für seine Haltung angibt,
sind manchmal nicht viel besser.
udok schrieb:> Weil neu muss ist ja definitionsgemäss immer vieell besser.
"neu" ist aber auch Ansichtssache. Es geht hier darum, eine Version von
C, die noch aus den Achtzigern stammt, durch eine zu ersetzen, die
inzwischen auch schon über ein Jahrzehnt alt ist.
Jörg W. schrieb:> Zombie schrieb:>> oder gibt es das in C auch nicht?>> Iteratoren? Per se nicht, kann man sicher irgendwie nachbilden.> Und C++ konnte diese Syntax der for-Schleife schon lange.
Nein, ich meinte anonyme Block scopes (mir fiel der Name vorher nicht
ein)
Stefan ⛄ F. schrieb:> Stattdessen wird nun auch C11 gesetzt.
Was ist da jetzt der Vorteil?
Sorry, ich habe vor 20 Jahren das letzte mal etwas programmiert.
fritz schrieb:> Was ist da jetzt der Vorteil?
Im verlinkten Heise Artikel wurde der konkrete Vorteil genannt, der zu
der Entscheidung für das Upgrade führte.
Oder wolltest zu eine Zusammenfassung aller Neuigkeiten in C11? Dazu
gibt es bestimmt ein Buch zu kaufen. Die Liste ist lang.
Jörg W. schrieb:> Zombie schrieb:>> oder gibt es das in C auch nicht?>> Iteratoren? Per se nicht, kann man sicher irgendwie nachbilden.> Und C++ konnte diese Syntax der for-Schleife schon lange.
Natürlich gibt es Iteratoren in C!
Alle Zeiger sind Iteratoren (also auch in C vorhanden).
Nicht alle Iteratoren sind Zeiger (andere Iteratoren gibt es dann eben
in C nicht).
Stefan ⛄ F. schrieb:> Stattdessen wird nun auch C11 gesetzt.
OMG! Welch eine weltbewegende Revolution!
Also, die einzige wirklich bedeutsame Verbesserung an C war der Übergang
von K&R nach ANSI. Was danach noch weiters aufgefallen ist, war die
Einführung von // und 'long long' und das war's. All das Gelaber über
das Herumwurschteln in den mitgelieferten Funktionen und die Einführung
einer Header-Datei für das Kanalisieren von Wildwuchs bei
Integer-Bezeichnungen und das Einführen des Wortes 'bool' sind eher wie
Trampeln auf der Stelle, weil jegliche Fortbewegung verboten ist zuliebe
der 'Kompatibilität'. Nicht einmal eine saubere Größenfestlegung für
Integers oder die Trennung von Textzeichen und Integer haben die in den
letzten 30 Jahren hingekriegt.
Und das soll jetzt Grund sein für weitere Diskussionen?
Selbst HIER ?
Kopfschüttel...
W.S.
W.S. schrieb:> OMG! Welch eine weltbewegende Revolution!
Für Linux ist es eine. Und für einige Mikrocontroller-Experten wäre es
das ebenfalls.
Hier gibt es doch jede Woche irgend jemanden, der Vorschläge mit "das
ist aber nicht originales C" (womit meist C89 gemeint ist) ablehnt.
W.S. schrieb:> Was danach noch weiters aufgefallen ist, war die> Einführung von // und 'long long' und das war's.
Ehm, tut mir leid. Aber du hast leider keine Ahnung.
https://en.cppreference.com/w/c
C hat mittlerweile viele nützliche Dinge im Sprachstandard/Stdlib
eingebaut. Unter anderem auch Threading und alles was dazu gehört.
Und es wird noch viel mehr kommen:
https://en.cppreference.com/w/c/23
Stefan ⛄ F. schrieb:> Stattdessen wird nun auch C11 gesetzt.
Ich halte das eher für eine Formalität.
Linux war noch nie in einem standardisierten C-Dialekt geschrieben und
verwendete schon immer extrem viele Gnu-Spracherweiterungen.
Sehr viele C99-Features sind über Gnu-Erweiterungen seit Ewigkeiten im
Kernel in Verwendung. Zum Beispiel Named Initializers.
Ich war ehrlich gesagt recht überrascht, dass Linux bisher C89+Gnu als
"den Standard" für sich definierte. Der Code sieht nämlich durch und
durch sehr C99-like aus.
Der gemeinsame Compiler-Nenner wird vielmehr von den
Enterprise-Distributionen bestimmt.
Der Kernel unterstützt schon immer sehr alte Gnu-Compilerversionen und
hat Tonnen von Workarounds an Bord für alte verbuggte
Enterprise-Compiler.
Und es wurde schon immer regelmäßig Support für alte Compiler
rausgeworfen, wenn man sich sicher war, dass niemand es mehr benötigen
wird.
Und das ist in diesem Fall auch nicht anders. Außer, dass jetzt das
Label "C11" dran klebt und man damit natürlich schönere
Fachzeitschriftenartikel generieren kann, als wenn irgendein alter
RHEL-Compiler aus dem Support rausgenommen wird.
W.S. schrieb:> Stefan ⛄ F. schrieb:>> Stattdessen wird nun auch C11 gesetzt.>> OMG! Welch eine weltbewegende Revolution!>> Also, die einzige wirklich bedeutsame Verbesserung an C war der Übergang> von K&R nach ANSI. Was danach noch weiters aufgefallen ist, war die> Einführung von // und 'long long' und das war's.
Das sehe ich aber anders.
Mit C11 kam Spracheigener Multi-threading support und verbesserter
Unicode Support:
> Improved Unicode support based on the C Unicode Technical Report ISO/IEC> TR 19769:2004 (char16_t and char32_t types for storing UTF-16/UTF-32> encoded data, including conversion functions in <uchar.h> and the> corresponding u and U string literal prefixes, as well as the u8 prefix> for UTF-8 encoded literals).https://en.wikipedia.org/wiki/C11_(C_standard_revision)> Nicht einmal eine saubere Größenfestlegung für> Integers oder die Trennung von Textzeichen und Integer haben die in den> letzten 30 Jahren hingekriegt.
Weil ein Integer nun einmal auf einer 16 Bit, 32 Bit und 64 Bit Maschine
immer anders ist und es gewachsenen Code gibt.
Außerdem konntest du schon immer deine eigenen Integertypen definieren
bzw. die von größeren Bibliotheken nutzen, wenn du diese benutzt hast.
W.S. schrieb:> Nicht einmal eine saubere Größenfestlegung für Integers> ... haben die in den letzten 30 Jahren hingekriegt.
Kennst du uint8_t uint16_t uint32_t und Verwandte nicht?
Nano schrieb:> Wilhelm M. schrieb:>> Nano schrieb:>>> fritz schrieb:>>>> Stefan ⛄ F. schrieb:>>>>> Stattdessen wird nun auch C11 gesetzt.>>>>>>>> Was ist da jetzt der Vorteil?>>>> Sorry, ich habe vor 20 Jahren das letzte mal etwas programmiert.>>>>>> Ab hier geht's los:>>>>>> https://de.wikipedia.org/wiki/Varianten_der_Programmiersprache_C#Neuerungen_von_C90>>>> In dem Abschnitt "Beispiele" des o.g. Artikels liest es sich fast so,>> als wäre bei C99/11 das Schlüsselwort `const` wieder entfallen.>> Gut aufgepasst.
const-correctness ist ein zentraler Baustein zu fehlerarmen Code.
Doch an diesem schwachsinnigen Edit bei WP sieht man mal wieder, wie
viele Unwissende es da wie hier gibt.
Wie sinnvoll bspw. folgendes ist, können die C89-Verfechter kaum
erahnen:
Die Deklarationssyntax von C wurde von Anfang an verkackt. C89 konnte
das aus Kompatibilitätsgründen nicht ändern und musste mit const&Co eine
neue Klasse der Verwirrung beisteuern.
Und so muss man eben mit solch seltsamen Konstruktionen leben. Oder die
Sprache wechseln. Aber von C zu erwarten, sich nicht zu erweitern,
sondern sich von Grund auf zu ändern, widerspricht dem Ansatz seit
Jahrzehnten.
Wilhelm M. schrieb:> Wie sinnvoll bspw. folgendes ist, können die C89-Verfechter kaum> erahnen
Ich habe da noch nie durchgeblickt, deswegen nutze ich es nicht.
> Die Deklarationssyntax von C ist von Anfang an verkackt.
Allerdings, "static" ist so ein Wort. Kennt ihr die Videorecorder aus
den 80er Jahren, wo jede Taste vierfach belegt wurde? Die kommen von der
selben Generation der Entwickler.
Stefan ⛄ F. schrieb:> Wilhelm M. schrieb:>> Wie sinnvoll bspw. folgendes ist, können die C89-Verfechter kaum>> erahnen>> Ich habe da noch nie durchgeblickt, deswegen nutze ich es nicht.
Das solltest Du schleunigst ändern: suche Dir eine Variante von
west-const oder east-const aus, und bleib dabei. Der Rest ist doch easy.
(Dann war es dann ja wohl für Dich mit besserem C++)
>> Die Deklarationssyntax von C ist von Anfang an verkackt.>> Allerdings, "static" ist so ein Wort.
... allerdings für jeden Zweck (storage duration, linkage, class member)
wieder eigene Schlüsselwörter wäre auch nicht gut.
Stefan ⛄ F. schrieb:> Allerdings, "static" ist so ein Wort
Das ist vergleichsweise harmlos. Der Knaller ist der deklaratorische
Rösselsprung mit dynamischem Richtungswechsel der Interpretation über
Operatorvorrang, statt strikt linearer Syntax. Also statt
(ausgeschrieben)
array of pointer to const char
array of const pointer to char
pointer to array of const char
hat man so Schönheiten wie
const char * []
char * const []
const char (*) []
Also nicht hübsch von links nach rechts gehen, sondern erst einmal
mitten drin in dem Salat die Stelle finden, bei der man anfängt, und
dann anhand des Vorrangs teils links teils rechts weiter machen. Der
Compiler tut sich damit leicht, der Mensch weniger.
Das const konnte man dann anno C89 nicht mehr vor * schreiben, ohne das
Prinzip zu verletzen. Skrupellose Genossen haben das zwar anno 16-Bit
x86 mit _far gemacht (1), und das sah auch schöner aus, war indes
seitens der Sprachlogik eine Zumutung.
Das hing natürlich mit dem Grundfehler in Expressions zusammen, die
Dereferenzierung davor zu schreiben, die Indizierung jedoch
dahinter. Mit Dereferenzierung auch dahinter wäre einiger Spuk
verschwunden. Ich meine mich zu erinnern, dass man das in der
Vorgeschichte auch so plante, dann aber über eine Zweideutigkeit mit der
Multiplikation stolperte. Aber statt dann eben für die Dereferenzierung
ein anderes Symbol zu verwenden, schmiss man ersatzweise das Kind in den
Brunnen.
1: In "_far * const" haben beide Keywords eigentlich die gleiche Rolle
im Bezug, stehen aber an unterschiedlicher Stelle. Angebrachter wäre "*
_far const" gewesen.
(prx) A. K. schrieb:> Stefan ⛄ F. schrieb:>> Allerdings, "static" ist so ein Wort>> Das ist vergleichsweise harmlos. Der Knaller ist der deklaratorische> Rösselsprung mit dynamischem Richtungswechsel der Interpretation über> Operatorvorrang, statt strikt linearer Syntax.
Naja, diesen Syntax-Kram finde ich vergleichsweise harmlos. Die größte
Sünde m.E. ist, dass man mit etwa dem Übergang zu C89 aus C nicht eine
objekt-basierte Sprache draus gemacht hat. Der Grund dafür ist
natürlich, dass es das dann mit C++ schon gab (C++ inkludiert u.a. das
objektorientierte Paradigma, welches das objektbasierte inkludiert).
In C kann man bis heute nicht eine vorzeichenlose Ganzzahl von einem
Zeichen von einem (semantikfreien) Byte unterscheiden.
Das ist der Grund, warum ich nur noch C++ verwende, und dies auch immer
jedem empfehle.
Wilhelm M. schrieb:> dass man mit etwa dem Übergang zu C89 aus C nicht eine> objekt-basierte Sprache draus gemacht hat
Das wäre eine neue Sprache gewesen, die verwirrenderweise heisst wie die
alte. Und hätte folglich zu einer Gabelung in der Sprachentwicklung
geführt. Immerhin gab es ja schon reichlich Code, massgeblich basierend
auf Unix. Solche radikalen Schritte kann man machen, hat man seither
immer wieder gemacht, aber dann freundlicherweise anders genannt.
(prx) A. K. schrieb:> Wilhelm M. schrieb:>> dass man mit etwa dem Übergang zu C89 aus C nicht eine>> objekt-basierte Sprache draus gemacht hat>> Das wäre eine neue Sprache gewesen,
Habe ich ja oben geschrieben: und die heißt C++.
Wer C mag, aber wem C++/Java/C# zu hoch ist, dem kann ich mal Go
empfehlen (leider nur auf PC, nicht Mikrocontroller).
Go hat sehr viel von C abgeguckt und ist ähnlich rudimentär. Aber es
unterstützt auch so etwas ähnliches wie Objekte, nur viel primitiver als
in C++ und hat eine praktische Garbage Collection.
Für mich ist es ein angenehmer Kompromiss zwischen den absolut nötigen
Basics und einer akademisch aufgeblähten Sprache die nur jeder 5.
Anwender vollständig versteht.
Mir würde es gefallen, wenn Go auch für AVR und Cortex-M verwendbar
wäre. Ist leider nicht der Fall.
Zum Beispiel haben sie dort mit dem "deklaratorischen
Rösselsprung mit dynamischem Richtungswechsel der Interpretation"
aufgeräumt.
1
Zeichenkette: string
2
Zeiger auf String: *string
3
Array von Strings: []string
4
Array von Zeigern auf Strings: []*string
5
Zeiger auf Array von Strings: *[]string
6
Zeiger auf Array von Zeigern auf Strings: *[]*string
So ist das total logisch, oder?
Was ich auch mega praktisch finde: In Go können Funktionen mehrere
Rückgabewerte haben.
Stefan ⛄ F. schrieb:> So ist das total logisch, oder?
Ist es. War mir auch schon aufgefallen. Die vielleicht erste von C
inspirierte Sprache, die mit dem Unfug aufräumte. Davor hatte sich das
niemand getraut.
Stefan ⛄ F. schrieb:> Wer C mag, aber wem C++/Java/C# zu hoch ist, dem kann ich mal Go> empfehlen (leider nur auf PC, nicht Mikrocontroller).>> Go hat sehr viel von C abgeguckt und ist ähnlich rudimentär.
Ja, Go ist ganz cool, vor allem recht stressfrei bei Nebenlääufigkeit.
> Aber es> unterstützt auch so etwas ähnliches wie Objekte, nur viel primitiver als> in C++ und hat eine praktische Garbage Collection.
Ich bin sehr froh, das in C++ keine GC notwendig / vorhanden ist.
Wilhelm M. schrieb:> Ich bin sehr froh, das in C++ keine GC notwendig / vorhanden ist.
Gibt es eigentlich eine Programmiersprache, wo man (ohne Tricks bzw
fremder Bibliotheken) wahlweise mit oder ohne Garbage Collection
arbeiten kann?
Stefan ⛄ F. schrieb:> Gibt es eigentlich eine Programmiersprache, wo man (ohne Tricks bzw> fremder Bibliotheken) wahlweise mit oder ohne Garbage Collection> arbeiten kann?
Was soll das bringen?
Man kann in Python den GC abschalten und dann manuell die Objekte
freigeben.
In CPython ist der GC wegen refcounting eh nur mit Nebensächlichkeiten
beschäftigt. Deshalb brauchts für viele Python-Programme auch gar keinen
GC.
Wilhelm M. schrieb:> Ich bin sehr froh, das in C++ keine GC notwendig / vorhanden ist.
Dito.
Mit std::shared_ptr<> optional zu arbeiten, wenn man massiv dynamische
Gebilde allokieren muss, ist sehr nützlich. Aber per default für alles
möcht ich's auch nicht unbedingt haben in C++. Das Gute an C++ sind die
unterschiedlichen Lösungsmöglichkeiten für Implementierungen damit -
aber halt eben manchmal auch die Ursache von Problemen.
Zum Thema selber: ich finds grundsätzlich nicht verkehrt, dass C11 beim
Kernel genutzt werden soll. Ich konnte diese Fokussiertheit auf C89
nicht so richtig verstehen - wenn man den alten Deklarationsstyle halt
im Kernel als Stil beibehalten möchte, spricht ja nix dagegen, dass über
Style-Guides festzulegen.
Könnte aber vielleicht n Thema sein für jemand, der nen alten
zertifizierten GCC nutzen muss, um nen Kernel zu übersetzen - k.a.
vielleicht isses da ungünstig dafür.
Egal. Btw. kann man mittlerweile eigentlich beim MSVC die SQLite mit C99
übersetzen? Wär auch mal an der Zeit...
(prx) A. K. schrieb:> Die Deklarationssyntax von C wurde von Anfang an verkackt. C89 konnte> das aus Kompatibilitätsgründen nicht ändern> ...> Aber von C zu erwarten, sich nicht zu erweitern,> sondern sich von Grund auf zu ändern, widerspricht dem Ansatz seit> Jahrzehnten.
Ja, man hätte möglichst früh aufräumen müssen.
Soviel C Code konnte das Ende 1980 ja noch nicht gewesen sein, dass es
unmöglich sei, das alles anzupassen.
Jetzt wäre es viel teurer.
(prx) A. K. schrieb:> Stefan ⛄ F. schrieb:>> So ist das total logisch, oder?>> Ist es. War mir auch schon aufgefallen. Die vielleicht erste von C> inspirierte Sprache, die mit dem Unfug aufräumte. Davor hatte sich das> niemand getraut.
Das gab es schon in Java, Java erlaubt nur beide Formen, also:
Datentyp[] varname; // so wie man es in Java machen soll
und
Datentyp varname[]; // wie in C
Siehe dazu auch:
https://openbook.rheinwerk-verlag.de/javainsel/04_001.html#u4.1.2
Und bei Go ließ man sich von Java inspirieren und damit kam es auch
später.
Stefan ⛄ F. schrieb:> Wilhelm M. schrieb:>> Ich bin sehr froh, das in C++ keine GC notwendig / vorhanden ist.>> Gibt es eigentlich eine Programmiersprache, wo man (ohne Tricks bzw> fremder Bibliotheken) wahlweise mit oder ohne Garbage Collection> arbeiten kann?
Die Programmiersprache D erlaubt es die Sprache mit und ohne GC
wahlweise zu nutzen.
https://de.wikipedia.org/wiki/D_(Programmiersprache)
Stefan ⛄ F. schrieb:> Kennst du uint8_t uint16_t uint32_t und Verwandte nicht?
Und wozu dient dann sowas wie stdint.h ? Nee, ne Headerdatei kann sich
jeder selber schreiben. Das ist was anderes, als Datentypen in einer
Sprachdefinition. Man könnte rein theoretisch die Typen auch karkheinz,
moritz und ottokar nennen. Das geht auch mit einer Headerdatei und dem
Compiler ist das schnurz, weil der nach dem Präprozessor diesen ganzen
Zirkus nicht mehr sieht, sondern eben wie ganz früher char, int und long
int usw.
W.S.
Nano schrieb:> Soviel C Code konnte das Ende 1980 ja noch nicht gewesen sein, dass es> unmöglich sei, das alles anzupassen.
Damals hielt man es für viel. Vorhersagen über mehrere Jahrzehnte sind
etwas problematisch, weshalb man solche Bilanzen in umgekehrter Richtung
einfacher ziehen kann. Keiner wusste während der Standisierungsphase
Mitte 80er, dass ausgerechnet C derart dominieren wird.
(prx) A. K. schrieb:> Aber statt dann eben für die Dereferenzierung> ein anderes Symbol zu verwenden, schmiss man ersatzweise das Kind in den> Brunnen.
Naja, so ähnlich sehe ich das auch. Was die Spracherfinder geritten hat,
bereits langetablierte Zeichen anderweitig zu verwenden, weiß bloß der
Geier.
Das Gleichheitszeichen als Zuweisungsoperator, womit man sich Vergleiche
verbaut hat und dann als Ausweich 'gleichgleich' für die Vergleiche.
Oder eben den Asterisk als 'Adresse von', womit man dann eben in
Konflikt mit dem Multiplikationszeichen kommt.
Und das alles ohne Rücksicht darauf, daß zumindest in Europa so ziemlich
alle Kinder mal zur Schule gegangen sind und dort sowas wie = und * für
etwas ganz anderes gelernt haben und es sogar bereits damals auf den
Tastaturen ein @ gegeben hat, was als Zeichen für das Zeigen auf..
durchaus in Frage gekommen wäre.
Naja, und von sowas wie einem Unitsystem mit geregelter Bekanntgabe von
Dingen, die in einer Quelle sind, wollen wir erst garnicht reden.
Allerdings sehe ich bei so einigen Leuten hier eine Kurzsichtigkeit, die
mich graust. Da meint z.B. der Stefan, daß das Schreiben einer
Headerdatei, wo lediglich einige Alias-Namen für altgediente
Integerbezeichnungen bereits eine Sprachänderung sei.
W.S.
Stefan ⛄ F. schrieb:> Ich denke die meisten sind sich einig: C ist hässlich, aber für uns> führt kaum ein Weg daran vorbei.
Oh Stefan das aus Deinem Munde - macht mich fast sprachlos :-)
db8fs schrieb:> wenn man den alten Deklarationsstyle halt> im Kernel als Stil beibehalten möchte
Im Kernel werden seit jeher Gnu-Struct-declarations verwendet, bis die
durch C99-Style ersetzt wurden. C89-Struct-Initializers findet man
praktisch nicht.
W.S. schrieb:> Und wozu dient dann sowas wie stdint.h ? Nee, ne Headerdatei kann sich> jeder selber schreiben. Das ist was anderes, als Datentypen in einer> Sprachdefinition.
Ziemlicher Unsinn.
Die stdlib gehört zum Sprachumfang und wird mit der Sprache gepflegt.
Das mit einem selbstgefrickelten Header zu vergleichen, ist einfach nur
Unsinn.
Ja, das Typsystem von C ist völlig verbastelt und unzulänglich.
Aber die fixed-size-Typen aus stdint gehören zur Sprache.
MaWin schrieb:> Aber die fixed-size-Typen aus stdint gehören zur Sprache.
Nein, sie gehören lediglich zu einer Headerdatei. Und wenn irgendwer
dazu Lust haben sollte, dann schreibt er eine andere Headerdatei und
benennt dort eben int in mawin um. Das geht, wäre so auch benutzbar,
gehört aber nicht zum Sprachumfang.
Nur mal so als Denkanstoß: Wenn es im Winter kalt ist und du einen
Mantel trägst, gehört dann der Mantel zu deinen Körperteilen? Er ist
vermutlich dein Eigentum, aber er ist kein Körperteil von dir, sage ich.
W.S.
W.S. schrieb:> Oder eben den Asterisk als 'Adresse von', womit man dann eben in> Konflikt mit dem Multiplikationszeichen kommt.>> Und das alles ohne Rücksicht darauf, daß zumindest in Europa so ziemlich> alle Kinder mal zur Schule gegangen sind und dort sowas wie = und * für> etwas ganz anderes gelernt haben und es sogar bereits damals auf den> Tastaturen ein @ gegeben hat, was als Zeichen für das Zeigen auf..> durchaus in Frage gekommen wäre.
Ich schätze mal, dass man den Asterisk deswegen genommen hat, weil er
eben wie in Mathe und Physik in Schriftform am ehesten einem Vektor
entspricht, der in die Ebene hineinzeigt.
Das @ dagegen war damals gar nicht groß etabiliert, das hat fast keiner
als "at" Symbol gekannt und war daher viel zu abstrakt.
W.S. schrieb:> Nein, sie gehören lediglich zu einer Headerdatei. Und wenn irgendwer> dazu Lust haben sollte, dann schreibt er eine andere Headerdatei und> benennt dort eben int in mawin um.
So ein Bullenkot.
Stefan ⛄ F. schrieb:> Ich denke die meisten sind sich einig: C ist hässlich, aber für uns> führt kaum ein Weg daran vorbei.
Ich weiss nicht, ich mag C und finde es sehr elegant.
C hat gewaltige Vorteile gegenüber jeder anderen Sprache:
- EIN einziger Weg zum Ziel (z.B. Nur Pointer, keine Referenzen)
- Relativ schnell erlernbar, wer will ist je nach Vorwissen in einer
Woche bis einem Monat dabei.
- Klare Strukturen und geradlinige und lesbare Programme.
(Die wichtigen Dinge werden linear abgearbeitet und nicht in einer
virtuellen Klasse in einer dreifach verschachtelten Inline-Funktion
versteckt, oder in einem Konstruktor wo keiner genau weiss wann der
aufgerufen wird.
- Keine überladenen Operatoren, wo man nicht weiss was passiert wenn man
es nicht selber geschrieben hat.
- Einfache Fehlerbehandlung, keine Exceptions die irgendwohin springen.
- Effizient und doch portabel.
- Gute Standard Bibliotheken.
- Wenig Schreibarbeit und leicht lesbar.
- Kleine Versuchung unnötigen Code zu schreiben weil eine "Klasse sonst
nicht vollständig" ist.
Zugegeben ist das Typensystem etwas verbastelt, aber das liegt an den
Compilerherstellern, die zu Altlasten kompatibel sein wollen.
Dank Typedef auch kein Problem.
Der zweite Punkt stimmt meiner Meinung auch nicht.
Wer es nicht mag: es führen heute mehr Wege als jemals zuvor an C
vorbei.
Früher gab es ja wirklich nur Pascal.
Klaus W. schrieb:> Und ich Depp dachte immer, malloc(), printf(), FILE, und wie sie alle> heißen, würden zu C gehören. Wie naiv!
Der C Standard beinhaltet nicht nur die Sprache sonder auch Standard
Libs. Da sind malloc, printf und FILE drinnen.
W.S. schrieb:> Aber die fixed-size-Typen aus stdint gehören zur Sprache.>> Nein, sie gehören lediglich zu einer Headerdatei. Und wenn irgendwer> dazu Lust haben sollte, dann schreibt er eine andere Headerdatei und> benennt dort eben int in mawin um. Das geht, wäre so auch benutzbar,> gehört aber nicht zum Sprachumfang.https://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf
Seite 217
Natürlich kannst du dir dein eigenes Header File schreiben, und den dazu
passenden Compiler für deine Sprache gleich dazu...
udok schrieb:> Stefan ⛄ F. schrieb:>> Ich denke die meisten sind sich einig: C ist hässlich, aber für uns>> führt kaum ein Weg daran vorbei.>> Ich weiss nicht, ich mag C und finde es sehr elegant.
Ich finde C zwar nicht hässlich, aber es hat für mich zu viele
Beschränkungen, die Intention exakt auszudrücken. Da ist C++ m.E.
wesentlich besser.
(Und ich habe das Gefühl, dass Du hier oft als Vergleich C++ und Java
heranziehst).
> C hat gewaltige Vorteile gegenüber jeder anderen Sprache:> - EIN einziger Weg zum Ziel (z.B. Nur Pointer, keine Referenzen)
In C++- sind Referenzen non-nullable / non-modifyable, Zeiger als
abstrakte Referenzen sind nullable und bieten eine
Iterator-Schnittstelle. Sid also zwei völlig verschiedenen Werkzeuge.
> - Relativ schnell erlernbar, wer will ist je nach Vorwissen in einer> Woche bis einem Monat dabei.
Nein, das dauert länger. Was dabei dann heraus kommt, sieht man ja hier
im Forum.
> - Klare Strukturen und geradlinige und lesbare Programme.
Echt jetzt? Wenn ein größeres C Programm klar strukturiert und lesbar
sein soll, braucht es schon sehr viel Erfahrung. Natürlich gilt dies für
jede Sprache, allerdings schätze ich die Gefahr bei C hier höher ein.
> (Die wichtigen Dinge werden linear abgearbeitet und nicht in einer> virtuellen Klasse in einer dreifach verschachtelten Inline-Funktion> versteckt, oder in einem Konstruktor wo keiner genau weiss wann der> aufgerufen wird.
Virtuelle Klasse? Auf welche Sprache beziehst Du Dich?
Dreifach verschachtelte Inline-Funktion? Du steigst also schon aus, wenn
drei Funktionen geschachtelt aufgerufen werden (Inline hat damit nichts
zu tun)? Dann solltest Du das Programmieren aufgeben bzw. an dieser
Stelle hilft nur eine bessere Abstraktion, und da ist C schlecht drin.
In C++ ist es absolut klar, wann ein ctor aufgerufen wird. Oder meinst
Du den dtor?
> - Keine überladenen Operatoren, wo man nicht weiss was passiert wenn man> es nicht selber geschrieben hat.
Ja, Operator-Überladung wird oft von Unwissenden missbraucht. Richtig
eingesetzt ist es aber ein große Hilfe. Und in C++ ist es notwendig, um
generischen Code schreiben zu können.
> - Einfache Fehlerbehandlung, keine Exceptions die irgendwohin springen.
Das Exceptions kein Allheilmittel sind, hat sich ja mittlerweile
herumgesprochen. In C++ gibt es dazu ja gute Alternativen.
> - Gute Standard Bibliotheken.
Es gibt genau eine Standard-Bibliothek ;-)
> - Wenig Schreibarbeit und leicht lesbar.
Lesbar? Ich glaube, Du hast noch nicht viel C-Code gesehen.
> - Kleine Versuchung unnötigen Code zu schreiben weil eine "Klasse sonst> nicht vollständig" ist.
Wer so argumentiert, hat von Software-Engineering keine Ahnung.
>> Zugegeben ist das Typensystem etwas verbastelt, aber das liegt an den> Compilerherstellern, die zu Altlasten kompatibel sein wollen.
An den Herstellern? Nein, an der Sprachdefinition.
Das schlechte ist, dass das Typsystem fix und nicht wirklich erweiterbar
ist.
> Dank Typedef auch kein Problem.
Ist ein Typ-Alias.
> Wer es nicht mag: es führen heute mehr Wege als jemals zuvor an C> vorbei.
Ja, und das ist vor allem (noch) C++. Man muss in C++ nicht OO machen,
das ist nur eines der Programmierparadigmen, die C++ unterstützt. Man
kann sehr gut prozedural bleiben wir in C, aber die Vorteile mitnehmen.
MaWin schrieb:> So ein Bullenkot.
Man muss dazu wissen, dass W.S. sich gerne sämtliche Header Dateien
selber neu schreibt, mit ganz vielen magischen Nummern.
Nano schrieb:> Ich schätze mal, dass man den Asterisk deswegen genommen hat, weil er> eben wie in Mathe und Physik in Schriftform am ehesten einem Vektor> entspricht, der in die Ebene hineinzeigt.
Klingt zwar recht hergeholt, ist aber vielleicht so. Bloß kommt das
nicht aus Mathe und Physik her, sondern vermutlich aus der
Elektrotechnik.
Andererseits konnte man bereits damals mit ^ vor- oder nachgestellt
Zeiger kreieren und damit hantieren. Das ging also bereits damals. Und
das @ gabs bereits auf jeder englischsprachigen Schreibmaschine. Da
ausgerechnet das * zu nehmen, war schon ziemlich seltsam.
udok schrieb:> Natürlich kannst du dir dein eigenes Header File schreiben, und den dazu> passenden Compiler für deine Sprache gleich dazu...
Ach nö. Schwanz wackelt mit Hund - oder?
Headerdateien können nur Ausdrücke benutzen, die bereits zum
Sprachumfang gehören. Sie können zwar alternative Bezeichner einführen,
aber nur deshalb, weil diese eben nur Zweitnamen sind für die bereits
dem Compiler bekannten Dinge. Na und ein jeder schreibt sich seine
eigenen Headerdateien, sobald sein Projekt nicht nur eine Datei enthält.
Das ist die normale Anwendung .
W.S.
Wilhelm M. schrieb:> Wie sinnvoll bspw. folgendes ist, können die C89-Verfechter kaum> erahnen:
1
>voidfoo(constchar*const*);
2
>voidfoo(constchar*const*consta){}
3
>voidbar(int);
4
>voidbar(constintb){}
Beim Zeigerziel ist das keine Frage, aber den Parameter selbst const zu
machen - weiß nicht. Der Parameter ist Teil des Interface, aber seine
constness hat keinerlei Auswirkung auf den Aufrufer.
(prx) A. K. schrieb:> Die Deklarationssyntax von C wurde von Anfang an verkackt.
Am liebsten wäre mir, wenn es mit dem const umgekehrt wäre, also wenn es
das Schlüsselwort const gar nicht gäbe, weil alles per Default konstant
ist und man stattdessen mit einem Schlüsselwort wie z.B. mutable oder
variable die Konstantheit explizit ausschalten müsste.
Stefan ⛄ F. schrieb:> Wilhelm M. schrieb:>> allerdings für jeden Zweck>> wieder eigene Schlüsselwörter wäre auch nicht gut.>> Doch, finde ich schon.
Jedes zusätzliche Schlüsselwort kann halt nirgends mehr als Identifier
verwendet werden, daher hat man in C versucht, die Zahl der
Schlüsselwörter möglichst gering zu halten. Das gilt insbesondere für
nachträglich eingeführte Schlüsselwörter, da diese immer dazu führen,
dass ein Teil des bestehenden Codes nicht mehr kompatibel ist.
(prx) A. K. schrieb:> Also statt (ausgeschrieben)> array of pointer to const char> array of const pointer to char> pointer to array of const char> hat man so Schönheiten wie> const char * []> char * const []> const char (*) []>> Also nicht hübsch von links nach rechts gehen, sondern erst einmal> mitten drin in dem Salat die Stelle finden, bei der man anfängt, und> dann anhand des Vorrangs teils links teils rechts weiter machen.
Die Richtung ist von rechts nach links. Nur gibt es beim const, das
normalerweise immer auf das wirkt, was links davon steht, eine
Besonderheit: Wenn es ganz links steht, wirkt es stattdessen auf das,
was rechts davon steht. Wenn du also z.B. aus const char * [] ein char
const * [] machst, dann kommt beim lesen von rechts nach links genau das
raus, was du oben schreibst. Nur beim letzten Eintrag passt es dann
nicht mehr.
> Das hing natürlich mit dem Grundfehler in Expressions zusammen, die> Dereferenzierung davor zu schreiben, die Indizierung jedoch> dahinter.
Auf die obigen Zeilen wirkt sich das aber auch nur deshalb aus, weil man
es für eine gute Idee gehalten hat, die Dereferenzierung eines Zeigers
genauso aussehen zu lassen, wie dessen Deklaration (also mit Sternchen
vor dem Namen).
W.S. schrieb:> MaWin schrieb:>> Aber die fixed-size-Typen aus stdint gehören zur Sprache.>> Nein, sie gehören lediglich zu einer Headerdatei.
… zu einem Standard-Header, wie printf() auch.
> Und wenn irgendwer dazu Lust haben sollte, dann schreibt er eine andere> Headerdatei und benennt dort eben int in mawin um. Das geht, wäre so auch> benutzbar, gehört aber nicht zum Sprachumfang.
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?
> Nur mal so als Denkanstoß: Wenn es im Winter kalt ist und du einen> Mantel trägst, gehört dann der Mantel zu deinen Körperteilen? Er ist> vermutlich dein Eigentum, aber er ist kein Körperteil von dir, sage ich.
Er erfüllt seinen Zweck. Warum es dabei ein Problem sein soll, dass er
kein Körperteil ist, erschließt sich mir nicht.
Rolf M. schrieb:> Am liebsten wäre mir, wenn es mit dem const umgekehrt wäre, also wenn es> das Schlüsselwort const gar nicht gäbe, weil alles per Default konstant> ist und man stattdessen mit einem Schlüsselwort wie z.B. mutable oder> variable die Konstantheit explizit ausschalten müsste.
Mir wäre es am liebsten, wenn die Sonne im Westen aufginge...
C ist nun mal C. Keiner behauptet, daß das die konzeptuell beste,
logischste und fehlerfreiste Programmiersprache aller Zeiten ist. Ist es
nicht, und wird es auch nie sein.
Wer es nicht braucht, nimmt was anders. Wer es nicht mag, nimmt was
anderes, wenn er kann. Wer es nutzen muß, sollte sich damit arrangieren,
oder eine neue Programmiersprache schaffen und etablieren, die alles
besser kann und macht.
Oliver
Nano schrieb:> Ich schätze mal, dass man den Asterisk deswegen genommen hat, weil er> eben wie in Mathe und Physik in Schriftform am ehesten einem Vektor> entspricht, der in die Ebene hineinzeigt.
Nö da werden Vektoren mit lateinischen Buchstaben und einem Pfeil
darüber oder mit altdeutschen Buchstaben in Schreibschrift dargestellt.
Beim wird ein in die Zeichenebene zeigender Vektor durch ein Kreuz
dargestellt (so wie es eben aussieht, wenn auf einen Pfeil von hinten
schaut).
Asterisk kenne ich in diesem Zusammenhang nicht. Kann natürlich sein das
man im angelsächsischen da mit dem Asterisk hantiert.
Oliver S. schrieb:> Mir wäre es am liebsten, wenn die Sonne im Westen aufginge...>> C ist nun mal C.
<Loriot>Ach…</Loriot>
> Wer es nicht braucht, nimmt was anders. Wer es nicht mag, nimmt was> anderes, wenn er kann.
Ich kann mit C gut leben. Dennoch kann ich doch in einer Diskussion
sagen, wenn mir bestimmte Dinge anders lieber gewesen wären. Und das mit
dem "umgedrehten const" macht im übrigen keine mir bekannte Sprache.
Viele Sprachen scheitern ja schon an dem generellen Konzept von
const-correctness, das ich durchaus wichtig finde.
> Wer es nutzen muß, sollte sich damit arrangieren, oder eine neue> 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.
Zeno schrieb:> Beim wird ein in die Zeichenebene zeigender Vektor durch ein Kreuz> dargestellt (so wie es eben aussieht, wenn auf einen Pfeil von hinten> schaut).
Nur gab es früher so ein Kreuz in den Zeichensätzen nicht, wenn man mal
vom x absieht. Also hat man eben das genommen, was da am nächsten dran
kommt.
Rolf M. schrieb:> Wilhelm M. schrieb:>> Wie sinnvoll bspw. folgendes ist, können die C89-Verfechter kaum>> erahnen:> void foo(const char* const*);>> void foo(const char* const* const a) {}>> void bar(int);>> void bar(const int b) {}>> Beim Zeigerziel ist das keine Frage, aber den Parameter selbst const zu> machen - weiß nicht. Der Parameter ist Teil des Interface, aber seine> constness hat keinerlei Auswirkung auf den Aufrufer.
Richtig, die zusätzliche const-Qualifizierung wirkt nicht auf den
Caller, aber eben im Callee: genau wie lokale Variablen read-only sein
sollten, um einen schleichenden Bedeutungswechsel (oder ungewolltes
Ändern) zu verhindern, ist das bei Parametervariablen um so wichtiger:
denn diese sind "ganz oben" in der Signatur deklariert und können bspw.
nicht in einem lokalen Block nach bei Ihrer Verwendung deklariert
werden. Daher können Bedeutungswechsel durch eine Modifikation
unentdeckt bleiben. Das ist eine (häufige) Fehlerquelle.
Rolf M. schrieb:> Am liebsten wäre mir, wenn es mit dem const umgekehrt wäre, also wenn es> das Schlüsselwort const gar nicht gäbe, weil alles per Default konstant> ist und man stattdessen mit einem Schlüsselwort wie z.B. mutable oder> variable die Konstantheit explizit ausschalten müsste.
Richtig. Und das gilt eben für Parametervariablen genauso: s.o.
Oliver S. schrieb:> Rolf M. schrieb:>> Am liebsten wäre mir, wenn es mit dem const umgekehrt wäre, also wenn es>> das Schlüsselwort const gar nicht gäbe, weil alles per Default konstant>> ist und man stattdessen mit einem Schlüsselwort wie z.B. mutable oder>> variable die Konstantheit explizit ausschalten müsste.>> Mir wäre es am liebsten, wenn die Sonne im Westen aufginge...
Da fehlt noch, das alle einstellig verwendbaren Konstruktoren 'explicit'
seon sollten (autsch, das war jetzt wieder C++).
Oliver S. schrieb:> C ist nun mal C. Keiner behauptet, daß das die konzeptuell beste,> logischste und fehlerfreiste Programmiersprache aller Zeiten ist. Ist es> nicht, und wird es auch nie sein.
Mit C++ sind aber schon einige Verbesserungen eingezogen. Deswegen ist
ja meine Empfehlung, die zu nutzen, indem man einfach einen C++-Compiler
benutzt. Das hat für 90% des C-Codes keine Auswirkungen. Dann kann man
beim prozeduralen Code bleiben (kein OOP, keine Generizität, ...) und
hat trotzdem ein paar Vorteile, ohne das es sich in eine ganz andere
Richtung entwickelt.
Rolf M. schrieb:> Und das mit> dem "umgedrehten const" macht im übrigen keine mir bekannte Sprache.
In Rust sind alle Variablen immutable (const), wenn sie nicht explizit
als mut (mutable) definiert wurden.
Das funktioniert erstaunlich gut. Vor allem, weil Rust Sprachkonstrukte
bietet, die immutable-Variablen (ja, komisches Wort) fördern.
Die Rust-Syntax ist sehr C-like. Das macht den Umstieg etwas leichter.
Es gibt natürlich einige Spracheigenschaften, die man als langjähriger
C-Programmierer erst komisch oder als falsch empfindet. Erst später
erkennt man den Nutzen. Das ging mir zum Beispiel bei 'return' so. In
Rust gibt jedes Statement einen Wert zurück. Deshalb braucht man am Ende
von Funktionen kein return hinzuschreiben. (Man kann es aber, wenn man
es will).
MaWin schrieb:> Rolf M. schrieb:>> Und das mit>> dem "umgedrehten const" macht im übrigen keine mir bekannte Sprache.>> In Rust sind alle Variablen immutable (const), wenn sie nicht explizit> als mut (mutable) definiert wurden.
Ja, und das ist sehr gut (s.o. dazu meine Erklärung).
> Das funktioniert erstaunlich gut. Vor allem, weil Rust Sprachkonstrukte> bietet, die immutable-Variablen (ja, komisches Wort) fördern.
Der Name Variable wird eben von vielen Leuten falsch als eine
"mathematische" Variable verstanden. Das ist natürlich falsch, denn es
sind in der SW-Technik keine Platzhalter sondern "benannte Objekte".
Rolf M. schrieb:> Zeno schrieb:>> Beim wird ein in die Zeichenebene zeigender Vektor durch ein Kreuz>> dargestellt (so wie es eben aussieht, wenn auf einen Pfeil von hinten>> schaut).>> Nur gab es früher so ein Kreuz in den Zeichensätzen nicht, wenn man mal> vom x absieht. Also hat man eben das genommen, was da am nächsten dran> kommt.
Ne der W.S. hat's im Prinzip schon korrigiert. Wenn, dann kommt das mit
dem Pfeil aus der E-Technik. Da lag ich falsch, daß ich das in die
Mathematik/Physik verortet habe. Dort gibt es das eigenlich gar nicht.
Ist aber am Ende auch egal der Asterisk als Kennzeichnung für einen
Zeiger ist noch eines der kleineren Übel bei C.
Wilhelm M. schrieb:> Oliver S. schrieb:>> Rolf M. schrieb:>>> Am liebsten wäre mir, wenn es mit dem const umgekehrt wäre, also wenn es>>> das Schlüsselwort const gar nicht gäbe, weil alles per Default konstant>>> ist und man stattdessen mit einem Schlüsselwort wie z.B. mutable oder>>> variable die Konstantheit explizit ausschalten müsste.>>>> Mir wäre es am liebsten, wenn die Sonne im Westen aufginge...>> Da fehlt noch, das alle einstellig verwendbaren Konstruktoren 'explicit'> seon sollten (autsch, das war jetzt wieder C++).
Dazu gehört natürlich auch, dass es bei primitiven DT keine impliziten
einengenden Typwandlungen geben sollte.
Rolf M. schrieb:>> Wer es nutzen muß, sollte sich damit arrangieren, oder eine neue>> 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.
<Loriot>Ach…</Loriot>
;)
Oliver
Wilhelm M. schrieb:> Richtig, die zusätzliche const-Qualifizierung wirkt nicht auf den> Caller, aber eben im Callee:
Die Parameterliste ist aber eine Vereinbarung zwischen beiden. Daher
sollte dort nur das stehen, was auch für beide relevant ist.
Wilhelm M. schrieb:> Der Name Variable wird eben von vielen Leuten falsch als eine> "mathematische" Variable verstanden.
Du meinst als etwas, das gerade nicht wie eine mathematische Variable
ist. In einem mathematischen Gleichungssystem können sich die Werte von
Variablen auch nicht ändern, da es auch im Gegensatz zu einem Programm
keine sequenzielle Ausführung gibt, durch die sich z.B. in der dritten
Zeile ein Variablenwert ändern könnte.
Das ist übrigens auch in der Programmierung nicht unbedingt immer so. Es
gibt durchaus Programmier-Paradigmen, in denen sich die Variablen eher
wie mathematische Variablen verhalten, z.B. in der funktionalen
Programmierung. Da arbeiten auch Funktionen eher so, wie man sie aus der
Mathematik kennt.
Wilhelm M. schrieb:> Da fehlt noch, das alle einstellig verwendbaren Konstruktoren 'explicit'> seon sollten (autsch, das war jetzt wieder C++).
Ja, es wäre besser, wenn man Konvertierkonstruktoren explizit ("no pun
intended") als solche kennzeichnen müsste.
Wilhelm M. schrieb:> Dazu gehört natürlich auch, dass es bei primitiven DT keine impliziten> einengenden Typwandlungen geben sollte.
Das finde ich nun wieder schwierig. Da die Datentypen keine feste Größe
haben, kann sehr vieles potenziell einengend sein. So sagt mein GCC
beispielsweise bei folgendem C++-Code:
1
voidfunc(charparam)
2
{
3
longdoubled{param};
4
// ...
5
}
warning: narrowing conversion of ‘param’ from ‘char’ to ‘long double’
Oliver S. schrieb:> <Loriot>Ach…</Loriot>
😀
Rolf M. schrieb:> Wilhelm M. schrieb:>> Richtig, die zusätzliche const-Qualifizierung wirkt nicht auf den>> Caller, aber eben im Callee:>> Die Parameterliste ist aber eine Vereinbarung zwischen beiden. Daher> sollte dort nur das stehen, was auch für beide relevant ist.
Beachte, dass in meinem Beispiel die Deklaration und Definition
unterschiedlich sind. Es ist dort genau der relevante Unterschied
eingefügt.
Rolf M. schrieb:> Die Parameterliste ist aber eine Vereinbarung zwischen beiden. Daher> sollte dort nur das stehen, was auch für beide relevant ist.
Nein. Nicht alle Eigenschaften der Parameterliste sind Teil dieser
Vereinbarung.
So sind zum Beispiel auch die Parameternamen nicht Teil der technischen
Schnittstelle. Ja, ich weiß, dass man die in der Deklaration weglassen
kann. Was aber nicht sinnvoll ist.
Im Vergleich dazu ist der (umgekehrte) Fall in Rust mit mut (=
nicht-const) auch kein Teil der Schnittstellenvereinbarung.
Wenn du das nicht magst, zwingt dich aber niemand es anders zu machen.
W.S. schrieb:> Andererseits konnte man bereits damals mit ^ vor- oder nachgestellt> Zeiger kreieren und damit hantieren. Das ging also bereits damals.
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.
Rolf M. schrieb:> Am liebsten wäre mir, wenn es mit dem const umgekehrt wäre, also wenn es> das Schlüsselwort const gar nicht gäbe, weil alles per Default konstant> ist und man stattdessen mit einem Schlüsselwort wie z.B. mutable oder> variable die Konstantheit explizit ausschalten müsste.
Das liess sich aber aufgrund der heiligen Kuh in C89 nicht mehr machen.
Rolf M. schrieb:> In einem mathematischen Gleichungssystem können sich die Werte von> Variablen auch nicht ändern
In einer Summen- oder Produktformel ändert sich der Wert der
Zählvariable.
MaWin schrieb:> Rolf M. schrieb:>> Die Parameterliste ist aber eine Vereinbarung zwischen beiden. Daher>> sollte dort nur das stehen, was auch für beide relevant ist.>> Nein. Nicht alle Eigenschaften der Parameterliste sind Teil dieser> Vereinbarung.> So sind zum Beispiel auch die Parameternamen nicht Teil der technischen> Schnittstelle.
Genau aus dem Grunde habe ich sie ja oben auch weggelassen: der Name des
Parameters hat keine syntaktische / typspezifische Bedeutung für den
Aufrufer. Die Semantik kann der Compiler eh nicht prüfen, daher darf man
den Namen auch weglassen.
Wilhelm M. schrieb:> Genau aus dem Grunde habe ich sie ja oben auch weggelassen: der Name des> Parameters hat keine syntaktische / typspezifische Bedeutung für den> Aufrufer. Die Semantik kann der Compiler eh nicht prüfen, daher darf man> den Namen auch weglassen.
Ja. Aber sinnvoll ist es halt trotzdem nicht, weil die Namen der
Dokumentation und dem Verständnis dienen.
int funktion(char *, int *, int, int, int);
Da weiß kein Mensch, welcher Parameter jetzt wohin kommt.
Und ohne Benennung, hat man auch Schwierigkeiten das in der
Dokumentation zu beschreiben. Da bleiben nur Krücken wie "als vierten
Parameter wird XYZ übergeben...".
MaWin schrieb:> Wilhelm M. schrieb:>> Genau aus dem Grunde habe ich sie ja oben auch weggelassen: der Name des>> Parameters hat keine syntaktische / typspezifische Bedeutung für den>> Aufrufer. Die Semantik kann der Compiler eh nicht prüfen, daher darf man>> den Namen auch weglassen.>> Ja. Aber sinnvoll ist es halt trotzdem nicht, weil die Namen der> Dokumentation und dem Verständnis dienen.>> int funktion(char *, int *, int, int, int);>> Da weiß kein Mensch, welcher Parameter jetzt wohin kommt.> Und ohne Benennung, hat man auch Schwierigkeiten das in der> Dokumentation zu beschreiben. Da bleiben nur Krücken wie "als vierten> Parameter wird XYZ übergeben...".
Schönes Beispiel wie man es eben nicht machen soll: mehrstellige
Funktion mit Parametern desselben Typs sind immer schlecht.
Die Bedeutung des Argumentes einer Funktion muss eindeutig aus dem Namen
der Funktion und dem Typ des Parameters hervorgehen, nicht aus dem Namen
des Parameters.
(prx) A. K. schrieb:> Eher von innen nach aussen.> char *p[]
Das System ist halt völlig unintuitiv.
1
char(*p)[]
ist ein Pointer auf ein Array. Und nicht wie ich es intuitiv lesen würde
ein Array von Pointern.
Das C-Typsystem ist völlig kaputt. An allen Ecken und Enden. Das endet
nicht bei der Syntax.
Wilhelm M. schrieb:> Die Bedeutung des Argumentes einer Funktion muss eindeutig aus dem Namen> der Funktion und dem Typ des Parameters hervorgehen
Interessante Idee, wirkt auf mich aber ein wenig bizarr.
Wilhelm M. schrieb:> Schönes Beispiel wie man es eben nicht machen soll: mehrstellige> Funktion mit Parametern desselben Typs sind immer schlecht.> Die Bedeutung des Argumentes einer Funktion muss eindeutig aus dem Namen> der Funktion und dem Typ des Parameters hervorgehen, nicht aus dem Namen> des Parameters.
Ja. In einer idealen Welt. Die bricht aber schon zusammen, wenn deine
Funktion zwei Parameter hat.
Ich bin still geworden, aber ich lese noch mit. Das sind einige
interessante Sachen bei, die ich noch nicht kannte bzw. noch nie drüber
nachgedacht habe.
(prx) A. K. schrieb:> Wilhelm M. schrieb:>> Die Bedeutung des Argumentes einer Funktion muss eindeutig aus dem Namen>> der Funktion und dem Typ des Parameters hervorgehen>> Interessante Idee, wirkt auf mich aber ein wenig bizarr.
Bizarr? Ich bin ziemlich sicher, dass es in den Cpp-Core-Guidelines
steht, wenn gleich diese Regel schon wirklich sehr alt ist.
MaWin O. schrieb:> Das System ist halt völlig unintuitiv.> char (*p)[]>> ist ein Pointer auf ein Array. Und nicht wie ich es intuitiv lesen würde> ein Array von Pointern.
1
char (*p)[]
2
^ hier gehts los p ist
3
^ () hat Vorrang vor []
4
^ pointer
5
^ to array
6
^ of char
Ist völlig logisch, vorausgesetzt man denkt wie ein Parser, nicht wie
ein Mensch. ;-)
MaWin O. schrieb:> Wilhelm M. schrieb:>> Schönes Beispiel wie man es eben nicht machen soll: mehrstellige>> Funktion mit Parametern desselben Typs sind immer schlecht.>> Die Bedeutung des Argumentes einer Funktion muss eindeutig aus dem Namen>> der Funktion und dem Typ des Parameters hervorgehen, nicht aus dem Namen>> des Parameters.>> Ja. In einer idealen Welt. Die bricht aber schon zusammen, wenn deine> Funktion zwei Parameter hat.
Natürlich nicht.
Der Klassiker ist doch
1
Dated{2,1,2012};
Besser:
1
Dated{Month{2},Day{1},Year{2012}}
Dann kann man auch eine permutierte Schnittstelle anbieten und es bleibt
eindeutig:
Stefan ⛄ F. schrieb:> Ich bin still geworden, aber ich lese noch mit. Das sind einige> interessante Sachen bei, die ich noch nicht kannte bzw. noch nie drüber> nachgedacht habe.
Da bist Du einer der wenigen, die bei so einer Abdrift noch dabei sind
;-)
Wilhelm M. schrieb:> Bizarr? Ich bin ziemlich sicher, dass es in den Cpp-Core-Guidelines> steht, wenn gleich diese Regel schon wirklich sehr alt ist.
Kann man in C++ auf Objekte machen, wenn man komplexe Funktionen mit
etlichen Parametern in einzelne Methoden aufsplittet, die irgendwas im
Objekt modifizieren, und erst dann die Aktion startet.
In C geht das mangels Objekten nicht so ohne weiteres.
Wilhelm M. schrieb:> (prx) A. K. schrieb:>> Wilhelm M. schrieb:>>> Die Bedeutung des Argumentes einer Funktion muss eindeutig aus dem Namen>>> der Funktion und dem Typ des Parameters hervorgehen>>>> Interessante Idee, wirkt auf mich aber ein wenig bizarr.
Finde ich auch. Wie macht man dann sowas:
Oder ähnlich bei einem Vektor mit x-, y- und z-Koordinate?
> Bizarr? Ich bin ziemlich sicher, dass es in den Cpp-Core-Guidelines> steht, wenn gleich diese Regel schon wirklich sehr alt ist.
Hmm, dafür wird davon aber in der Standardbibliothek ziemlich häufig
abgewichen. Wahlfrei rausgegriffenes Beispiel:
(prx) A. K. schrieb:> Wilhelm M. schrieb:>> Bizarr? Ich bin ziemlich sicher, dass es in den Cpp-Core-Guidelines>> steht, wenn gleich diese Regel schon wirklich sehr alt ist.>> Kann man in C++ auf Objekte machen, wenn man komplexe Funktionen mit> etlichen Parametern in einzelne Methoden aufsplittet, die irgendwas im> Objekt modifizieren, und erst dann die Aktion startet.
Nein, das Chaining (oder named-parameter-idiom) ist hier gar nicht
gemeint. Es geht einfach um unterschiedliche Typen in der
Parameterliste.
Aber Du hast schon Recht: ein weiterer Punkt der C fehlt ist eben
Funktionsüberladung. Ich wiederhole mich: benutzt C++ auch dort, wo
normalerweise C benutzt wird, und profitiert von den kleinen Goodies.
Rolf M. schrieb:> Wilhelm M. schrieb:>> (prx) A. K. schrieb:>>> Wilhelm M. schrieb:>>>> Die Bedeutung des Argumentes einer Funktion muss eindeutig aus dem Namen>>>> der Funktion und dem Typ des Parameters hervorgehen>>>>>> Interessante Idee, wirkt auf mich aber ein wenig bizarr.>> Finde ich auch. Wie macht man dann sowas:>
(prx) A. K. schrieb:> Kann man in C++ auf Objekte machen, wenn man komplexe Funktionen mit> etlichen Parametern in einzelne Methoden aufsplittet, die irgendwas im> Objekt modifizieren, und erst dann die Aktion startet.>> In C geht das mangels Objekten nicht so ohne weiteres.
Einfach ein strukt uns stink normale Funktionen nehmen. Funktioniert
einwandfrei.
Daniel A. schrieb:> (prx) A. K. schrieb:>> Kann man in C++ auf Objekte machen, wenn man komplexe Funktionen mit>> etlichen Parametern in einzelne Methoden aufsplittet, die irgendwas im>> Objekt modifizieren, und erst dann die Aktion startet.>>>> In C geht das mangels Objekten nicht so ohne weiteres.>> Einfach ein strukt uns stink normale Funktionen nehmen. Funktioniert> einwandfrei.
Ja, wie ich oben sagte.
Allerdings meint er glaube ich eher sowas wie das named-parameter-idiom:
Wilhelm M. schrieb:> Es geht einfach um unterschiedliche Typen in der> Parameterliste.
Wie wärs mit einem Beispiel für C89, in dem in einer traditionellen
Implementierung einer Funktion je ein Wert für Rot, Grün und Blau
vorkommt. Erleichtert das Verständnis. Mit etwas Fokus auf jene Zeit, in
der C entstand, nicht 2022.
(prx) A. K. schrieb:> Daniel A. schrieb:>> Einfach ein strukt uns stink normale Funktionen nehmen. Funktioniert>> einwandfrei.>> Also C++ zu Fuss.
Genau. Deswegen ja mein Rat: nimm gleich C++ und profitiere von den
Goodies.
MaWin O. schrieb:> Wilhelm M. schrieb:>> Natürlich nicht.>> Der Klassiker ist dochDate d{2, 1, 2012};>> Keine Ahnung was das ist. Jedenfalls kein C.
Sorry, C kann keine uniform-initialisation:
Oliver S. schrieb:> Wilhelm M. schrieb:>> Wieder ein Punkt für die kleinen Goodies von C++.>> Du meinst sicher die wunderbaren Vorzüge der uniform Initialization wie> in>>
Wilhelm M. schrieb:> udok schrieb:>
>> Wer es nicht mag: es führen heute mehr Wege als jemals zuvor an C>> vorbei.>> Ja, und das ist vor allem (noch) C++.
Nach und nach wird C++ in dieser Rolle meiner Meinung nach von Rust
verdrängt.
In 10 Jahren dürfte Rust bei neuen Projekten gegenüber C++ vorgezogen
werden. Momentan hat C++ noch einen Vorteil beim Drumherum und der
Anzahl an Leuten die es können.
Der Altbestand an SW bleibt natürlich in C++, das ist klar.
W.S. schrieb:> Nano schrieb:>> Ich schätze mal, dass man den Asterisk deswegen genommen hat, weil er>> eben wie in Mathe und Physik in Schriftform am ehesten einem Vektor>> entspricht, der in die Ebene hineinzeigt.>> Klingt zwar recht hergeholt, ist aber vielleicht so. Bloß kommt das> nicht aus Mathe und Physik her, sondern vermutlich aus der> Elektrotechnik.
Magnetismus und elektrische Felder sind ein Teil, den man in Physik
lernt und da wird das dann häufig benutzt wenn ein Vektor in die
Tafel/Papierebene hineinzeigen soll.
Da es hier zwischen der Physik und Elektrotechnik Überschneidungen gibt,
hat die das natürlich auch.
> Andererseits konnte man bereits damals mit ^ vor- oder nachgestellt> Zeiger kreieren und damit hantieren.
'^' braucht man auch für den Exponenten, damit wäre nichts gewonnen.
> Und> das @ gabs bereits auf jeder englischsprachigen Schreibmaschine.
Ja, aber im Rest der Welt war es eher unüblich.
Und dann wurde es früher im englischsprachigen Raum laut WP als
kaufmännisches Zeichen als Ersetz für "zu je" benutzt.
Da besteht also gar kein Zusammenhang zu einem Zeiger.
So gesehen hätte man also genauso gut auch jedes beliebige andere
Zeichen für den Zeiger nehmen können.
Ich habe einen C compiler, fuer embedded. Was wuerdet ihr da empfehlen
was von c89 hinausgeht.
Decl ala statement habe ich mir schon mehrmals gedacht, wegen debugging
und variabile scope/aliasing habe ich dies noch gelassen.
Zeno schrieb:> Nano schrieb:>> Ich schätze mal, dass man den Asterisk deswegen genommen hat, weil er>> eben wie in Mathe und Physik in Schriftform am ehesten einem Vektor>> entspricht, der in die Ebene hineinzeigt.> Nö da werden Vektoren mit lateinischen Buchstaben und einem Pfeil> darüber oder mit altdeutschen Buchstaben in Schreibschrift dargestellt.> Beim wird ein in die Zeichenebene zeigender Vektor durch ein Kreuz> dargestellt (so wie es eben aussieht, wenn auf einen Pfeil von hinten> schaut).> Asterisk kenne ich in diesem Zusammenhang nicht. Kann natürlich sein das> man im angelsächsischen da mit dem Asterisk hantiert.
Der Asterisk steht für den Punkt und für den Punkt nimmt man in der
Zeichenebene ein x. Es ist aber so, dass man hier zwei Varianten hat,
die, die in die Zeichenebene hineinragt und die, die aus der
Zeichenebene herausragt.
Das x ist ist für das hineinzeigen vergeben, weswegen man für das
herauszeigen einen Punkt nimmt.
Siehe:
http://www.dieter-heidorn.de/Physik/SS/K07_Magnetisches%20Feld/K2_Flussdichte/K2_Flussdichte.html
Beim Programmieren braucht man das x aber für die Bezeichnernamen und
der Punkt ist viel zu klein, als dass der groß auffällt.
Der Asterisk ist hier somit als Ersatz für den Punkt, so wie bei der
Multiplikation auch, also durchaus passend, wenn da nicht die
Möglichkeit des Konflikts mit der Multiplikation stehen würde.
Es ist gut möglich, dass man daran anfangs nicht gedacht hat oder
dachte, dass man das ausreichend gut umschiffen könnte.
Rolf M. schrieb:>> Wer es nicht braucht, nimmt was anders. Wer es nicht mag, nimmt was>> anderes, wenn er kann.>> Ich kann mit C gut leben. Dennoch kann ich doch in einer Diskussion> sagen, wenn mir bestimmte Dinge anders lieber gewesen wären. Und das mit> dem "umgedrehten const" macht im übrigen keine mir bekannte Sprache.
Rust macht es so.
"Variables in Rust are immutable by default, and require the mut keyword
to be made mutable."
https://doc.rust-lang.org/std/keyword.let.html> 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.
Rust ist durchaus eine gute Alternative zu C und C++.
Zeno schrieb:> Rolf M. schrieb:>> Zeno schrieb:>>> Beim wird ein in die Zeichenebene zeigender Vektor durch ein Kreuz>>> dargestellt (so wie es eben aussieht, wenn auf einen Pfeil von hinten>>> schaut).>>>> Nur gab es früher so ein Kreuz in den Zeichensätzen nicht, wenn man mal>> vom x absieht. Also hat man eben das genommen, was da am nächsten dran>> kommt.> Ne der W.S. hat's im Prinzip schon korrigiert. Wenn, dann kommt das mit> dem Pfeil aus der E-Technik. Da lag ich falsch, daß ich das in die> Mathematik/Physik verortet habe. Dort gibt es das eigenlich gar nicht.
Schonmal Feldlinien in Physik gezeichnet?
Also ich schon.
> Ist aber am Ende auch egal der Asterisk als Kennzeichnung für einen> Zeiger ist noch eines der kleineren Übel bei C.
Ein anderes Übel von C ist implizites Fall-Through Verhalten bei Switch
Anweisungen.
Hier gibt's nen Artikel dazu:
https://lwn.net/Articles/794944/
(prx) A. K. schrieb:> dafür aber mit XOR ^ - das gibts in Pascal ja nicht.
Wo haste denn das her? Na klar gibt es XOR in Pascal, da heißt es, wer
hätte das gedacht, XOR.
Zeno schrieb:> (prx) A. K. schrieb:>> dafür aber mit XOR ^ - das gibts in Pascal ja nicht.> Wo haste denn das her?
Guck nochmal hin, was ich schrieb. Das ^ war kein Tippfehler.
Nano schrieb:> Ein anderes Übel von C ist implizites Fall-Through Verhalten bei Switch> Anweisungen.
Da muss man einfach so denken, wie die C Erfinder. Die case sind nicht
eine Liste von alternativen Bedingungen sondern switch springt zu einer
bestimmten Stelle innerhalb einer Liste von Befehlen. Unterhalb von
Switch kommt nur ein einziger Code Block. Case definieren keine Blöcke,
sondern Sprungziele.
In Go haben sie das geändert, da fallen die case nicht implizit durch.
Nano schrieb:> Schonmal Feldlinien in Physik gezeichnet?
Ja sicher und in Theorethischer Elektrotechnik und in Feldtheorie auch,
da kam aber kein Asterisk vor. Das war entweder x oder . evtl noch mit
einem Kringel drum herum.
Nano schrieb:> '^' braucht man auch für den Exponenten, damit wäre nichts gewonnen.
Steht aber auch für XOR. Das wäre ja dann die nächste Doppelbelegung.
(prx) A. K. schrieb:> Rolf M. schrieb:>> Am liebsten wäre mir, wenn es mit dem const umgekehrt wäre, also wenn es>> das Schlüsselwort const gar nicht gäbe, weil alles per Default konstant>> ist und man stattdessen mit einem Schlüsselwort wie z.B. mutable oder>> variable die Konstantheit explizit ausschalten müsste.>> Das liess sich aber aufgrund der heiligen Kuh in C89 nicht mehr machen.
Es wäre aber möglich es mit einer Compilerwarnung wie bei dem Switch
Fallhrough umzusetzen.
Hat eine Variable kein const davor gesetzt, dann gibt es eine Warnung,
es sei denn, eine veränderliche Variable ist explizit gewünscht.
Und das könnte man dann mit einem Kommentar davor anzeigen.
Z.B.
/* mutable */ int c = 42;
oder kürzer:
/* mut */ int c = 42;
Der Compiler könnte dann nachgucken, ob so ein Kommentar davor steht und
wenn das nicht der Fall ist, und mit sagen wir mal -Wconst compilert
werden soll, dann wirft er eine Warnung und zeigt auf die Zeile.
Damit könnte man explizites mutable machen verlangen und so ein
implizites const haben ohne die Sprache umdefinieren zu müssen.
Keine Ahnung ob es so etwas auch schon gibt, gefunden habe ich
diesbezüglich nichts, zumindest nicht bei GCC:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Es wäre natürlich viel Aufwand und den ein oder anderen wird es sogar
stören, aber es wäre machbar.
Noch einfacher wäre es aber, wenn man einfach ab C2x für veränderliche
Variablen folgendes verlangen würde:
mut int c = 42;
ansonsten gibt es eine Warnung, der Code compiliert aber dennoch.
Dann müsste man in Zukunft immer nur entweder mut oder const setzten:
mut int c = 42; // explizit veränderlich
const int c = 42; // explizit unveränderlich/konstant
int c = 42; // implizit veränderlich, compilert, aber mit geworfener
Compilerwarnung
Stefan ⛄ F. schrieb:> Nano schrieb:>> Ein anderes Übel von C ist implizites Fall-Through Verhalten bei Switch>> Anweisungen.>> Da muss man einfach so denken, wie die C Erfinder. Die case sind nicht> eine Liste von alternativen Bedingungen sondern switch springt zu einer> bestimmten Stelle innerhalb einer Liste von Befehlen. Unterhalb von> Switch kommt nur ein einziger Code Block. Case definieren keine Blöcke,> sondern Sprungziele.>> In Go haben sie das geändert, da fallen die case nicht implizit durch.
Mit -Wextra bzw. -Wimplicit-fallthrough wird das gewarnt.
Ist tatsächlich ein fallthrough gemeint, kann man den case mit
fallthrough attributieren.
Zeno schrieb:> Nano schrieb:>> Schonmal Feldlinien in Physik gezeichnet?> Ja sicher und in Theorethischer Elektrotechnik und in Feldtheorie auch,> da kam aber kein Asterisk vor. Das war entweder x oder . evtl noch mit> einem Kringel drum herum.>> Nano schrieb:>> '^' braucht man auch für den Exponenten, damit wäre nichts gewonnen.> Steht aber auch für XOR. Das wäre ja dann die nächste Doppelbelegung.
Du kannst gerne für die Operatoren auch die "alternative tokens" wie
xor, or, ... einsetzen.
Nano schrieb:> Der Compiler könnte dann nachgucken, ob so ein Kommentar davor steht
Nein. Bitte nicht. Kommentare mit semantischer Bedeutung sind schlimm.
Jede Sprache, die das gemacht hat, hat es verkackt. Das kann man gar
nicht sinnvoll umsetzen und verwenden.
Kommentare sind Kommentare. Keine Syntax.
Wilhelm M. schrieb:> Du kannst gerne für die Operatoren auch die "alternative tokens" wie> xor, or, ... einsetzen.
Mag ja alles sein, aber es wurde explizit darauf hingewiesen das ^ für
XOR bzw. Potenz steht und das ist schlichtweg ne Doppelbedeutung. Ob man
dafür auch xor, or, and etc. schreiben kan stand nicht zur Debatte - es
ändert ja auch nichts an der Doppelbedeutung.
MaWin O. schrieb:> Nano schrieb:>> Der Compiler könnte dann nachgucken, ob so ein Kommentar davor steht>> Nein. Bitte nicht. Kommentare mit semantischer Bedeutung sind schlimm.> Jede Sprache, die das gemacht hat, hat es verkackt. Das kann man gar> nicht sinnvoll umsetzen und verwenden.>> Kommentare sind Kommentare. Keine Syntax.
Kein Syntax? Nun, dann würden Sie von der Sprache nicht erkannt. Diese
Aussage ist also Quatsch.
Kommentare werden in Phase 3 eliminiert, also vor dem Präprozessor.
Aber Du hast recht: wenn Kommentare eine Semantik bekommen, sind sie
i.a. keine wirklichen Kommentare mehr. Java kennt dafür Annotationen:
auch so ein Krücke.
Kommentare werden i.a. überbewertet. Das Grundübel dabei ist, das
Kommentare anders altern als der umgebende Code!
Daher die Regel: Kommentier nur das, was der Code nicht sagen kann, und
nicht das, was der Code nicht sagt. Wie man leicht sieht, erwächst
daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare
braucht.
Wilhelm M. schrieb:> Kein Syntax? Nun, dann würden Sie von der Sprache nicht erkannt.
Also für Autisten noch einmal: Der Inhalt von Kommentaren ist keine
Syntax.
> Das Grundübel dabei ist, das> Kommentare anders altern als der umgebende Code!
Nur, wenn man sich nicht im Griff hat.
> erwächst> daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare> braucht.
Das geht aber gar nicht.
Man kann in einer Programmiersprache ohne Kommentare gar nicht alle
Dinge ausdrücken, die man sinnvollerweise dokumentieren sollte.
MaWin O. schrieb:> Wilhelm M. schrieb:>> Kein Syntax? Nun, dann würden Sie von der Sprache nicht erkannt.>> Also für Autisten noch einmal: Der Inhalt von Kommentaren ist keine> Syntax.
Danke für Deine psychologische Analyse ;-)
Oben hast Du es anders geschrieben, jetzt sagst Du "der Inhalt".
Jetzt für Dich nochmal: Ein Kommentar hat bei C ein paar mögliche
Ausprägungen, die durch die Syntax der Sprache beschrieben sind.
>>> Das Grundübel dabei ist, das>> Kommentare anders altern als der umgebende Code!>> Nur, wenn man sich nicht im Griff hat.
Welcher Programmierer hat sich denn im Griff im echten Leben. Schau Dir
mal echten Code an!
>> erwächst>> daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare>> braucht.>> Das geht aber gar nicht.
(Du hast den Satz aus dem Zusammenhang gerissen, der vorangehende Satz
fehlt)
Natürlich geht das.
Wenn man sich genügend Mühe gibt, geht das sogar mit C. Ok, mit C++ ist
es leichter. Aber das verlangt eben vom Programmierer viel mehr
Nachdenken und Designabwägungen, als einfach mal einen Kommentar dahin
zu schmieren. Letztendlich führt das meistens zu besserem Code.
> Man kann in einer Programmiersprache ohne Kommentare gar nicht alle> Dinge ausdrücken, die man sinnvollerweise dokumentieren sollte.
Ich habe auch nicht gesagt, dass man nichts(!) kommentieren sollte. Lies
Dir meinen Satz dazu nochmal ganz in Ruhe durch und denke nach.
Wilhelm M. schrieb:> Natürlich geht das.
Wie beschreibt man denn in C, warum man eine Berechnung macht?
Ich kann das nur in einem Kommentar.
Wilhelm M. schrieb:> Ich habe auch nicht gesagt, dass man nichts(!) kommentieren sollte. Lies> Dir meinen Satz dazu nochmal ganz in Ruhe durch und denke nach.
Ich finde den Satz ziemlich eindeutig:
Wilhelm M. schrieb:> Wie man leicht sieht, erwächst> daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare> braucht.
MaWin O. schrieb:> Also für Autisten noch einmal: Der Inhalt von Kommentaren ist keine> Syntax.
In realem Pascal gab es schon früh sprachrelevante Kommentare mit
eigener Syntax.
MaWin O. schrieb:> Ich finde den Satz ziemlich eindeutig:>> Wilhelm M. schrieb:>> Wie man leicht sieht, erwächst>> daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare>> braucht.
Schon wieder falsch zitiert.
Das folgende war die Regel:
Daher die Regel: Kommentier nur das, was der Code nicht sagen kann, und
nicht das, was der Code nicht sagt.
Wilhelm M. schrieb:> Schon wieder falsch zitiert.> Das folgende war die Regel:
Du reitest darauf herum, dass ich mit "ein Kommentar" eigentlich "den
Kommentarinhalt" meinte. Was IMO offensichtlich war.
Wilhelm M. schrieb:> Daher die Regel: Kommentier nur das, was der Code nicht sagen kann, und> nicht das, was der Code nicht sagt. Wie man leicht sieht, erwächst> daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare> braucht.
Der zweite Satz schränkt den ersten ein.
Und dann bleibt über:
> Wie man leicht sieht, erwächst> daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare> braucht.
MaWin O. schrieb:> Wilhelm M. schrieb:>> Schon wieder falsch zitiert.>> Das folgende war die Regel:>> Du reitest darauf herum, dass ich mit "ein Kommentar" eigentlich "den> Kommentarinhalt" meinte. Was IMO offensichtlich war.
Ach so, Du meintest eigentlich ... nun, dann bin ich bei Deinen Aussagen
in Zukunft etwas "kreativer" ;-)
>> Wilhelm M. schrieb:>> Daher die Regel: Kommentier nur das, was der Code nicht sagen kann, und>> nicht das, was der Code nicht sagt. Wie man leicht sieht, erwächst>> daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare>> braucht.>> Der zweite Satz schränkt den ersten ein.> Und dann bleibt über:>>> Wie man leicht sieht, erwächst>> daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare>> braucht.
Nun, wenn Du oben "eigentlich nur" den Kommentarinhalt meintest, dann
solltest Du eigentlich auch erfassen können was durch das folgende
gemeint war (immer noch falsch zitiert):
Kommentare werden i.a. überbewertet. Das Grundübel dabei ist, das
Kommentare anders altern als der umgebende Code!
Daher die Regel: Kommentier nur das, was der Code nicht sagen kann, und
nicht das, was der Code nicht sagt. Wie man leicht sieht, erwächst
daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare
braucht.
Wilhelm M. schrieb:> Nun, wenn Du oben "eigentlich nur" den Kommentarinhalt meintest, dann> solltest Du eigentlich auch erfassen können was durch das folgende> gemeint war (immer noch falsch zitiert):>> Kommentare werden i.a. überbewertet. Das Grundübel dabei ist, das> Kommentare anders altern als der umgebende Code!> Daher die Regel: Kommentier nur das, was der Code nicht sagen kann, und> nicht das, was der Code nicht sagt. Wie man leicht sieht, erwächst> daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare> braucht.
Ok. Also eine Pflicht zu kommentarfreiem Code. Das steht da
wortwörtlich. Und der Kontext ändert daran genau gar nichts.
Auch in dieser Zitatfassung.
Was willst du uns eigentlich sagen? Dass der Fehler bei uns liegt, wenn
du dich vertippst?
MaWin O. schrieb:> Wilhelm M. schrieb:>> Nun, wenn Du oben "eigentlich nur" den Kommentarinhalt meintest, dann>> solltest Du eigentlich auch erfassen können was durch das folgende>> gemeint war (immer noch falsch zitiert):>>>> Kommentare werden i.a. überbewertet. Das Grundübel dabei ist, das>> Kommentare anders altern als der umgebende Code!>> Daher die Regel: Kommentier nur das, was der Code nicht sagen kann, und>> nicht das, was der Code nicht sagt. Wie man leicht sieht, erwächst>> daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare>> braucht.> Was willst du uns eigentlich sagen? Dass der Fehler bei uns liegt, wenn> du dich vertippst?
Ich erwarte von Dir das gleiche wie Du vorher von mir. So wie Du oben
eigentlich nur den Inhalt des Kommentars und nicht das syntaktische
Konstrukt Kommentar meintest, so darfst Du auch hier gerne ein
"möglichst" ergänzen. Nun verstanden?
Wilhelm M. schrieb:> So wie Du oben> eigentlich nur den Inhalt des Kommentars und nicht das syntaktische> Konstrukt Kommentar meintest, so darfst Du auch hier gerne ein> "möglichst" ergänzen. Nun verstanden?
Ja. Kein Problem. Dann interpretiere ich das nun so.
Hättest du natürlich auch gleich so schreiben können, statt mir den
Fehler beim Leseverständnis zuzuschreiben.
MaWin O. schrieb:> Nano schrieb:>> Der Compiler könnte dann nachgucken, ob so ein Kommentar davor steht>> Nein. Bitte nicht. Kommentare mit semantischer Bedeutung sind schlimm.> Jede Sprache, die das gemacht hat, hat es verkackt. Das kann man gar> nicht sinnvoll umsetzen und verwenden.>> Kommentare sind Kommentare. Keine Syntax.
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.
Und wenn du es nicht nutzen willst, dann nutzt du einfach die
Compileroption nicht, so wie bei dem Fallthrough Problem auch.
Und, wie ich bereits sagte, für spätere Versionen, z.b. C2x
definiert man es dann zu
mut int x = 42;
Dann ist es Sprachstandard und würde dann ab C2x funktionieren.
Wilhelm M. schrieb:> Daher die Regel: Kommentier nur das, was der Code nicht sagen kann, und> nicht das, was der Code nicht sagt. Wie man leicht sieht, erwächst> daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare> braucht.
Code der gar keine Kommentare enthält ist Müll.
Du brauchst mindestens Dokumentationskommentare was der Code macht.
Bei Funktionen gehören dazu bspw. auch eine Erläuterung der
Funktionsparameter, sowie Vor- und Nachbedingungen dazu.
Nano schrieb:> Wie schon gesagt, bei dem Fallthrough Problem wird genau das gemacht:
Nein. Das war nur eine (schlechte) Idee.
Vielleicht wurde es auch irgendwo implementiert. Keine Ahnung. Es ist
und bleibt eine Nicht-Standard schlechte Idee.
Die wirkliche Syntax sieht so aus:
https://en.cppreference.com/w/c/language/attributes/fallthrough
MaWin O. schrieb:> Nano schrieb:>> Wie schon gesagt, bei dem Fallthrough Problem wird genau das gemacht:>> Nein. Das war nur eine (schlechte) Idee.> Vielleicht wurde es auch irgendwo implementiert. Keine Ahnung. Es ist> und bleibt eine Nicht-Standard schlechte Idee.
Nein, die Idee ist gut, weil du das nicht nutzen musst, aber der, der es
nutzen möchte, z.b. bei Falllthrough die Linux Kernel Entwickler, die
können es dann nutzen.
Der Code compiliert so auch immer.
> Die wirkliche Syntax sieht so aus:> https://en.cppreference.com/w/c/language/attributes/fallthrough
Und das ist die Erweiterung erst ab C2x.
Bei dem mutable Problem könntest du also hier bei C2x, wie ich oben
schrieb ein:
mut int ...
haben.
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.
Letzteres macht deinen Code aber Compilerabhängig und auch
Compilerversionsabhängig, was auch das Problem bei dem fallthrough
Problem war und weswegen die Kernelentwickler das als Kommentare immer
noch bevorzugen.
Und später, kann man es dann als Sprachstandard nutzen.
Für dich ändert sich somit nichts, wenn du dieses Feature nicht nutzen
möchtest, aber andere könnten davon so schon viel früher profitieren.
Nano schrieb:> Nein, die Idee ist gut, weil du das nicht nutzen musst
Die Idee ist sehr schlecht, weil Kommentare plötzlich syntaktisch oder
semantisch relevant werden.
Wenn ich irgendwie /* fallthrough */ geschrieben habe, weil in meinem
Spiel halt dort der Charakter irgendwo durchfallen soll, dann hat das
plötzlich eine Bedeutung für den Compiler.
Das ist eine absolut dumme Idee.
MaWin O. schrieb:> Nano schrieb:>> Nein, die Idee ist gut, weil du das nicht nutzen musst>> Die Idee ist sehr schlecht, weil Kommentare plötzlich syntaktisch oder> semantisch relevant werden.
Nur wenn du es nutzen willst, ansonsten nicht.
Und wenn du es nutzen willst, dann weißt du ja darum.
> Wenn ich irgendwie /* fallthrough */ geschrieben habe, weil in meinem> Spiel halt dort der Charakter irgendwo durchfallen soll, dann hat das> plötzlich eine Bedeutung für den Compiler.
Ja, der Compiler guckt dann aber auch nach, ob das sich wirklich vor
einem
case Bezeichner innerhalb eines Switchblocks befindet.
Und das ist doch ein sehr unüblicher Ort für Kommentare.
Oder schreibst du ein Kommentar immer vor den Befehl innerhalb der
gleichen Zeile?
> Das ist eine absolut dumme Idee.
Nein, s.o.
Nano schrieb:> Nur wenn du es nutzen willst, ansonsten nicht.
Oder, wenn es halt per Zufall dort steht.
Funktionalität in Kommentare zu bringen, ist eine sehr sehr sehr
schlechte Idee.
Wo hört man auf?
Nano schrieb:> Ja, der Compiler guckt dann aber auch nach, ob das sich wirklich vor> einem> case Bezeichner innerhalb eines Switchblocks befindet.
Ja dann bin ich aber froh, dass er doch noch orakelt, um zu erkennen,
dass er möglicherweise falsch liegt.
Wenn bei anderen APIs gilt, dass man sie wegen Rückwärtskompatibilität
nicht syntaktisch und semantisch ändern darf, dann muss das auch für
Kommentare gelten.
Und da Kommentare keine syntaktische und semantische Relevanz haben, ist
die einzige Möglichkeit das beizubehalten.
MaWin schrieb:> Nano schrieb:>> Nur wenn du es nutzen willst, ansonsten nicht.>> Oder, wenn es halt per Zufall dort steht.
Nochmal, schreibst du ein Kommentar immer vor den Befehl innerhalb der
gleichen Zeile?
Also anstatt:
int c = 42; // Die Antwort auf alle Fragen
das hier:
/* Die Antwort auf alle Fragen */ int c = 42;
ernsthaft?
> Funktionalität in Kommentare zu bringen, ist eine sehr sehr sehr> schlechte Idee.
Im Linux Kernel hat das nachweislich viele Bugs beseitigt. Siehe der
Link.
Also kann das keine schlechte Idee sein.
> Wenn bei anderen APIs gilt, dass man sie wegen Rückwärtskompatibilität> nicht syntaktisch und semantisch ändern darf, dann muss das auch für> Kommentare gelten.
Wenn du dich um Rückwärtskompatibilität kümmern musst, dann nutzt du
diese Compileroption einfach nicht, falls das ein Problem sein sollte,
was zu bezweifeln ist.
Nano schrieb:> ernsthaft?
Es geht mir ums Prinzip.
Kommentare wurden mir vom Standard syntax- und semantikfrei versprochen.
Also muss das auch so bleiben.
> Im Linux Kernel hat das nachweislich viele Bugs beseitigt.
Ja. Ist mir bekannt.
Aber das heißt nicht, dass man diese Sonderimplementierung in einen
Spachstandard übernehmen soll.
Das kann man auch als Privat-Checker im Kernel-Projekt machen, bis es
dann vernünftig im Sprachstandard (ohne Kommentarverstümmelung)
implementiert wird.
MaWin schrieb:> Aber das heißt nicht, dass man diese Sonderimplementierung in einen> Spachstandard übernehmen soll.
Das wurde auch nicht behauptet. Es soll ja in den Compiler und später
kommt ein
mut int c = 42;
für den Sprachstandard.
Nano schrieb:> Es soll ja in den Compiler und später kommt
Und in der Zwischenzeit hat man inkompatiblen und inkonsistenten Mist,
der Kommentare interpretiert, im Compiler?
Nein, danke.
MaWin schrieb:> Nano schrieb:>> Es soll ja in den Compiler und später kommt>> Und in der Zwischenzeit hat man inkompatiblen und inkonsistenten Mist,> der Kommentare interpretiert, im Compiler?> Nein, danke.
Da es im Kommentar ist, stört es beim Compilieren nicht und kann den
Code trotzdem compilieren. Darfst dann halt nicht diese Option nutzen.
Als Anwender sollte das aber auch für dich kein Problem sein und der
Progger wird schon den passenden Compiler verwenden.
Und es steht ja nichts dagegen, dass sich die Compilerhersteller
einigen.
Hallo,
Nano schrieb:> Es soll ja in den Compiler und später kommt ein>> mut int c = 42;>> für den Sprachstandard.
Ich verstehe nicht warum es so wichtig sein soll eine 52 Jahre alte
Programmiersprache um solche Eigenschaften zu erweitern.
Lasst doch C einfach so wie es ist und wendet euch bei Bedarf anderen
Programmiersprachen zu, die das und die vielen anderen Eigenarten und
Merkwürdigkeiten von C nicht haben.
rhf
Roland F. schrieb:> Hallo,> Nano schrieb:>> Es soll ja in den Compiler und später kommt ein>>>> mut int c = 42;>>>> für den Sprachstandard.>> Ich verstehe nicht warum es so wichtig sein soll eine 52 Jahre alte> Programmiersprache um solche Eigenschaften zu erweitern.
Weil man damit bestehenden Code verbessern könnte.
Es bedeutet eine Fehlerquelle weniger und wer weiß schon wieviele
tausende unentdeckter Bugs darauf pro größerem Softwareprojekt basieren.
Nano schrieb:> Weil man damit bestehenden Code verbessern könnte.
Verbessern, oder zerstören.
Je nachdem, was denn nun in den Kommentaren steht.
Interpretierte Kommentare sind grundsätzlich abzulehnen.
Und ja, unsinnige Warnungen sind auch Zerstörungen.
Nano schrieb:> Damit könnte man explizites mutable machen verlangen und so ein> implizites const haben ohne die Sprache umdefinieren zu müssen.>> Keine Ahnung ob es so etwas auch schon gibt, gefunden habe ich> diesbezüglich nichts, zumindest nicht bei GCC
Ist in Arbeit. Wenn es fertig ist, reicht es aus, die Dateiendung von .c
in .rs zu ändern, und schon hast du deine expliziten mutables - und ganz
viele andere goodies dazu.
Ansonsten sind Compilerswitches, die sehr grundlegende Definitionen
einer Sprache beeinflussen, nicht das, was weiterhilft.
Oliver
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.
Nano schrieb:> Wilhelm M. schrieb:>> Daher die Regel: Kommentier nur das, was der Code nicht sagen kann, und>> nicht das, was der Code nicht sagt. Wie man leicht sieht, erwächst>> daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare>> braucht.>> Code der gar keine Kommentare enthält ist Müll.> Du brauchst mindestens Dokumentationskommentare was der Code macht.> Bei Funktionen gehören dazu bspw. auch eine Erläuterung der> Funktionsparameter, sowie Vor- und Nachbedingungen dazu.
Leider hast Du den Verlauf der Diskussion hier nicht ganz korrekt
verfolgt. Die Plakativität des Nachsatzes habe ich durch ein "möglichst"
entschärft (MaWin hatte Schwierigkeiten die Regel (erster Satz) von der
zu plakativen Folgerung (zweiter Satz) zu unterscheiden).
Deswegen hier nochmal in leicht geänderter Form (die ursprünglich
intendiert war):
Kommentare werden i.a. überbewertet. Das Grundübel dabei ist, das
Kommentare anders altern als der umgebende Code!
Daher die Regel: Kommentier nur das, was der Code nicht sagen kann, und
nicht das, was der Code nicht sagt. Wie man leicht sieht, erwächst
daraus die Pflicht, den Code möglichst so zu gestalten, dass er keine
Kommentare
braucht.
Bei einer Schnittstelle wie
sind dagegen natürlich Kommentare erforderlich, weil die Schnittstelle
schlecht ist: bei shutdown() ist connection anscheinend eine abstrakte
Referenz auf irgendein internes Objekt. Was passiert, wenn dieses Objekt
nicht existiert? Was ist der gültige Wertebereich?
Bei sendto() ebenso und auch bzgl. der Parameter device und endpoint.
Der Parameter data ist ein Zeiger, gehört nullptr zum Wertebereich? char
ist ein unspezifischer Datentyp: sind dies nun Ganzzahlen, Zeichen oder
einfach nur Bytes? Gehört length semantisch zu data? Gibt es eine
Obergrenze für die Anzahl length. Warum int als DT (Längen / Anzahlen
sind nicht-negativ).
Dies sind nur einige Anmerkungen.
Ja, dieses Beispiel ist konstruiert, trotzdem findet man es so ähnlich
allenthalben.
Was ich damit sagen will ist:
gestalte eine Schnittstelle so, dass sie leicht richtig und nur schwer
falsch zu benutzen ist.
Und je mehr Kommentare man lesen muss, desto größer ist die Chance, die
Schnittstelle falsch zu benutzen.
Nano schrieb:> Roland F. schrieb:>> Hallo,>> Nano schrieb:>>> Es soll ja in den Compiler und später kommt ein>>>>>> mut int c = 42;>>>>>> für den Sprachstandard.>>>> Ich verstehe nicht warum es so wichtig sein soll eine 52 Jahre alte>> Programmiersprache um solche Eigenschaften zu erweitern.>> Weil man damit bestehenden Code verbessern könnte.>> Es bedeutet eine Fehlerquelle weniger und wer weiß schon wieviele> tausende unentdeckter Bugs darauf pro größerem Softwareprojekt basieren.
Dann sollten wir die Diskussion mal erweitern auf ein weiteres Problem
mit den primitiven DT wie int, ...: der Wertebereich ist durch die
Implementierung vorgegeben und passt eben meistens nicht zur
Problemstellung. Besser wären Datentypen wie etwa
1
int<0,99>p;
um auszudrücken, welchen Wertebereich p nun tatsächlich umfasst. Das
würde auch viel Ungemach verhindern. Kann man sich natürlich bei C++
definieren (oder eine Bibliothek verwenden) als uint_ranged<0, 99> oder
uint_circular<0,99>, aber direkt in die fundamentalen DT eingebaut wäre
natürlich besser.
> 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.
Das ist allerdings eine gute Stelle für Kommentare.
> int p; // must be 0-99, requested in ticket 1234
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:
Wilhelm M. schrieb:> Natürlich eine Assertions-Verletzung feuern.
Ich bin da nicht sattelfest, korrigiere mich bitte wenn ich falsch
liege.
Aber eine Assertion führt nach meinem Kenntnisstand immer zu einem
Programmabbruch. Das will man oft nicht, weil dann die Maschine bzw. der
Dienst sofort ausfällt.
Daher heisst es (auf
https://ptolemy.berkeley.edu/~johnr/tutorials/assertions.html) völlig
korrekt:
> Assertions are not a mechanism for handling run-time errors
Stefan ⛄ F. schrieb:> Stattdessen wird nun auch C11 gesetzt.
Braucht man Linux überhaupt? Das ist doch dies mit der Kommanzozeile und
Basic? Nimm doch Windows, da kannst du bequem mit der Maus arbeiten und
es gibt auch viele Programme und Spiele.
Stefan ⛄ F. schrieb:> Wilhelm M. schrieb:>> Natürlich eine Assertions-Verletzung feuern.>> Ich bin da nicht sattelfest, korrigiere mich bitte wenn ich falsch> liege.>> Aber eine Assertion führt nach meinem Kenntnisstand immer zu einem> Programmabbruch. Das will man oft nicht, weil dann die Maschine bzw. der> Dienst sofort ausfällt.
Ja, das ist auch gut so (bei C / C++ nur, wenn NDEBUG nicht definiert
ist).
> Daher heisst es (auf> https://ptolemy.berkeley.edu/~johnr/tutorials/assertions.html) völlig> korrekt:>> Assertions are not a mechanism for handling run-time errors
Ja, eine Assertions-Verletzung darf nie dazu benutzt werden, um bspw.
Benutzerfehler, extern getriggerte Probleme odgl. zu behandeln.
Assertionen sind dazu da, die interne Logik des Artefaktes
sicherzustellen. Also bspw. Vor- und Nachbedingungen zu überprüfen,
Invarianten zu checken, etc.
Ein Schritt in die richtige Richtung beschreibt der Entwurf P0287 mit
den "contracts" und den Attributen ensures: condition und [[expects:
consdition]].
Leon schrieb:> Braucht man Linux überhaupt? Das ist doch dies mit der Kommanzozeile und> Basic? Nimm doch Windows, da kannst du bequem mit der Maus arbeiten und> es gibt auch viele Programme und Spiele.
Auch für Linux gibt es einen grafischen Desktop. Hauptsächlich findet
Linux jedoch dort Anwendung, wo kein Maus-Schubser arbeitet, sondern der
Rechner selbst. Ich wette dass du in deinem Haushalt bereits mehrere
Geräte mit Linux hast, ohne es zu wissen. Android ist zum Beispiel ein
Linux System.
Linux ist unter Programmierern beliebt, insbesondere denen, die
Programme für Linux entwickeln. Das finde ich auch total logisch. Warum
soll man sich beim Programmieren freiwillig mit zwei Betriebssystemen
gleichzeitig auseinander setzen (dem PC und dem Target), wenn es nicht
sein muss?
Wenn ich den ganzen Tag lang an Harleys schrauben würde, würde ich wohl
auch eine solche fahren.
Klar könnte man statt Linux auch Windows benutzen. Microsoft hat es mit
diversen embedded Versionen mehrfach versucht, jedoch mit mäßigem
Erfolg. Viel wichtiger finde ich aber, dass eine gewisse Vielfalt
vorhanden ist. Wenn es nur Windows gäbe, könnte Microsoft ganz alleine
die Welt regieren.
Wilhelm M. schrieb:> Rolf M. schrieb:>> Wie macht man dann sowas:>> void setColor(uint8_t r, uint8_t g, uint8_t b, uint8_t alpha);>>> void setColor(Red, Green, Blue, Alpha);
Also für jede Grundfarbe ein eigener Typ? Und beim geometrischen Vektor
auch für jede Dimension? Das halte ich für wenig sinnvoll. Wie macht man
das bei einem n-dimensionalen mathematischen Vektor, wo n ein
Template-Parameter ist? Irgendwelches Template-Gehampel, das dafür
sorgt, dass jede Dimension einen eigenen Datentyp bekommt?
Wilhelm M. schrieb:> Oliver S. schrieb:>> Wilhelm M. schrieb:>>> Wieder ein Punkt für die kleinen Goodies von C++.>>>> Du meinst sicher die wunderbaren Vorzüge der uniform Initialization wie>> in>>>>std::vector<int>{3}>>>> Oliver>> Ja, steht doch so oben ... (???)
Ich vermute, er will damit sagen, dass das - anders als man vielleicht
erwarten würde - was ganz anderes macht als
1
std::vector<int>(3)
Man hat also eine neue Initialisierungsmethode mit strengerer Typprüfung
eingeführt, die die alte ersetzt - bis auf die Stellen, wo sie auf
einmal eine ganz andere Bedeutung hat…
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.
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
MaWin O. schrieb:>> Das Grundübel dabei ist, das>> Kommentare anders altern als der umgebende Code!>> Nur, wenn man sich nicht im Griff hat.
Nein, das funktioniert nie richtig. Ich hab einfach schon zu viel Code
gesehen, bei dem der Kommentar nur verwirrt hat, weil er nicht zu dem
gepasst hat, was der Code tatsächlich macht. Und wenn das passiert,
richtet der Kommentar viel mehr Schaden an als er vorher an Verbesserung
gebracht hat.
> Man kann in einer Programmiersprache ohne Kommentare gar nicht alle> Dinge ausdrücken, die man sinnvollerweise dokumentieren sollte.
Es geht sicher nicht zu 100%, aber wenn man ein bisschen darauf achtet,
wird der überwiegende Anteil der Kommentare überflüssig, weil er nur
noch das offensichtliche dupliziert. Für mich ist das auch kein
schwarz/weiß. Man kann und soll nicht alle Kommentare weglassen, sondern
den Code so schreiben, dass ihre Anzahl minimiert werden kann, ohne die
Verständlichkeit zu verschlechtern.
Und eben nach der Regel vorgehen, dass Kommentare eher nicht beschreiben
sollen, was gemacht wird, sondern warum es gemacht wird bzw. warum
gerade so. Der Code selbst beschreibt bereits, was er tut.
Das bezieht sich für mich alles speziell auf Kommentare innerhalb des
Code. Beschreibungen von Funktionen, Typen u.s.w. a la Doxygen sind da
für mich nochmal ein eigenes Thema.
(prx) A. K. schrieb:> In realem Pascal gab es schon früh sprachrelevante Kommentare mit> eigener Syntax.
Ok, also ein guter Grund, diese Sprache zu meiden.
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.
Gut, ich bin jetzt nur ein minderbegabter Hobbyprogrammierer und weiß
deshalb nicht wie es bei den Profis zugeht. Aber mir erscheint obiges
Vorgehen höchst zweifelhaft zu sein.
rhf
Da zeigt sich nur mal wieder, dass es ein grundlegender Fehler ist, in
Sprachen nicht schon von Beginn an Mechanismen einzubauen, die spätere
Sprachänderungen vernünftig ermöglichen.
Oliver S. schrieb:> Nano schrieb:>> Damit könnte man explizites mutable machen verlangen und so ein>> implizites const haben ohne die Sprache umdefinieren zu müssen.>>>> Keine Ahnung ob es so etwas auch schon gibt, gefunden habe ich>> diesbezüglich nichts, zumindest nicht bei GCC>> Ist in Arbeit. Wenn es fertig ist, reicht es aus, die Dateiendung von .c> in .rs zu ändern, und schon hast du deine expliziten mutables - und ganz> viele andere goodies dazu.>> Ansonsten sind Compilerswitches, die sehr grundlegende Definitionen> einer Sprache beeinflussen, nicht das, was weiterhilft.>> Oliver
Die grundlegende Definition der Sprache würde dadurch nicht beeinflusst
werden. Lies oben nochmal.
Und Rust ist kein C.
Stefan ⛄ F. 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.
Und wenn du sie nutzt, dann weißt du auch darüber Bescheid.
Wilhelm M. schrieb:> Nano schrieb:>> Wilhelm M. schrieb:>>> Daher die Regel: Kommentier nur das, was der Code nicht sagen kann, und>>> nicht das, was der Code nicht sagt. Wie man leicht sieht, erwächst>>> daraus die Pflicht, den Code so zu gestalten, dass er keine Kommentare>>> braucht.>>>> Code der gar keine Kommentare enthält ist Müll.>> Du brauchst mindestens Dokumentationskommentare was der Code macht.>> Bei Funktionen gehören dazu bspw. auch eine Erläuterung der>> Funktionsparameter, sowie Vor- und Nachbedingungen dazu.>> Leider hast Du den Verlauf der Diskussion hier nicht ganz korrekt> verfolgt.
Doch habe ich, nur schreibe ich immer direkt nach dem ich ein Kommentar
gelesen habe. Ich warte grundsätzlich nicht damit, bis ich unten
ankomme.
Die Gefahr, dadurch etwas zu übersehen ist nämlich viel zu groß.
Und auch im späteren Verlauf, in dem du dich versuchst herauswinden und
dein ursprüngliches Kommentar umzudeuten, ändert zwar vielleicht das,
was du sagen wolltest, aber nicht das, was du gesagt hast.
> Die Plakativität des Nachsatzes habe ich durch ein "möglichst"> entschärft (MaWin hatte Schwierigkeiten die Regel (erster Satz) von der> zu plakativen Folgerung (zweiter Satz) zu unterscheiden).
Nein, MaWin hat das genauso richtig erkannt wie ich, du hast dich
anfangs nicht richtig ausgedrückt.
Aber wir können die Diskussion hier abkürzen, bringt ja nichts, du hast
ja mittlerweile deine erste Aussage umgedeutet und klarer ausformuliert,
so dass der Sachpunkt nicht mehr besteht.
Den jetzt mit der Umdeutung sagst du ja nichts anderes als: Code ohne
Kommentare gibt es nicht oder ist Murks.
Also genau die Aussage von mir und MaWin.
> Bei einer Schnittstelle wie>
>> brauche ich keine Kommentare. Ggf. kann in der Realisierung auf noch> eine Vorbedingung wie static_assert(N < 256) eingebaut werden.
Also doch nichts verstanden.
Natürlich brauchst du ein Kommentar und zwar ein
Dokumentationskommentar. Gerade und erst recht bei Schnittstellen, denn
wenn andere deine Schnittstelle nutzen können sollen, dann müssen sie
wissen, worauf sie sich verlassen können.
Du musst also, wie ich bereits sagte, auch die Vor- und Nachbedingung
definieren.
Eine Vorbedingung kann bspw. sein, dass eine als Parameter übergebener
int Wert z.B. den Wert 1024 nicht überschreiten darf.
Das kann z.B. vorkommen, wenn deine Schnittstelle häufig aufgerufen wird
und aus Performancegründen somit keine Prüfungen gemacht werden sollen
ob die Werte im gewünschten Bereich liegen, aber der Code bei Werten
über diesen Vorbedingungswert falsch rechnet.
Das ist damit gemeint.
Und das muss der wissen, der deine Schnittstelle nutzt. Es ist dann
dessen Aufgabe, dass er darauf achtet, deine Schnittstellenfunktion nur
mit den richtigen Daten zu füttern.
Damit er das aber weiß, ist es deine Pflicht, dies in einem
Dokumentationskommentar zu definieren.
Das lernst du so auch heute in einem Informatikstudiengang. Ich weiß
nicht, ob du irgendwas mit Informatik studiert hast, oder ob das schon
30 Jahre zurückliegt, aber so wird das heute gemacht und den Grund warum
habe ich dir oben genannt.
Lässt du das weg, dann machst du es falsch. Punkt!
> Was ich damit sagen will ist:> gestalte eine Schnittstelle so, dass sie leicht richtig und nur schwer> falsch zu benutzen ist.
Und wenn aus Performancegründen Wertebereichprüfungen bewusst
weggelassen werden, dann muss der gültige Wertebereich in einem
Dokumentationskommentar definiert sein.
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.
Wilhelm M. schrieb:> Dann sollten wir die Diskussion mal erweitern auf ein weiteres Problem> mit den primitiven DT wie int, ...: der Wertebereich ist durch die> Implementierung vorgegeben und passt eben meistens nicht zur> Problemstellung. Besser wären Datentypen wie etwa>
1
>int<0,99>p;
2
>
> um auszudrücken, welchen Wertebereich p nun tatsächlich umfasst. Das> würde auch viel Ungemach verhindern. Kann man sich natürlich bei C++> definieren (oder eine Bibliothek verwenden) als uint_ranged<0, 99> oder> uint_circular<0,99>, aber direkt in die fundamentalen DT eingebaut wäre> natürlich besser.
So etwas könnte ich mir lediglich als zusätzliches Feature vorstellen.
Denn hier müsste der Compiler dann ja immer Prüffunktionen in den Code
einbauen, ob die Grenzwerte auch eingehalten werden. Das kostet
Performance und ist nicht immer gewünscht und oftmals weiß der
Programmierer besser, an welcher Stelle so eine Prüfung sinnvoller ist,
also z.B. außerhalb der Performance wichtigen Schleife oder er kann
abschätzen, ob diese Werte überhaupt vorkommen können und darauf dann
entsprechend eingehen.
D.h. ein klassisches
int p;
muss es weiterhin geben.
So eine Wertebereicheinschränkung kann es nur als Zusatz geben.
Stefan ⛄ F. schrieb:> Wilhelm M. schrieb:>> Natürlich eine Assertions-Verletzung feuern.>> Ich bin da nicht sattelfest, korrigiere mich bitte wenn ich falsch> liege.>> Aber eine Assertion führt nach meinem Kenntnisstand immer zu einem> Programmabbruch. Das will man oft nicht, weil dann die Maschine bzw. der> Dienst sofort ausfällt.
Es macht auch keinen Sinn mit falschen Werten weiterzurechnen.
Ein Programmabbruch oder eine Behandlung des Fehlers, z.b. nächsten Wert
nehmen und Fehler in die Log hauen, der dann wieder passt, ist daher
schon sinnvoll.
> Daher heisst es (auf> https://ptolemy.berkeley.edu/~johnr/tutorials/assertions.html) völlig> korrekt:>> Assertions are not a mechanism for handling run-time errors
Assertions sind auch nur dazu da, automatisiert zu überprüfen, ob der
Code z.b. nach vielen Veränderungen immer noch das macht, was er soll,
oder sich ein Fehler nach den Umarbeiten eingeschlichen hat.
Thread beobachten
Seitenaufteilung abschalten