|
Anzeige
|
[C] Böse Falle: Datentyp korrekt angegeben, falscher verwendet
Gast
#5763897
Den meisten wird es bekannt sein. In dieser Ausprägung kannte ich das Problem aber selbst noch nicht, daher poste ich es mal dem Forum.
Im Gegensatz zu #define, wo das nachvollziehbar wäre, wäre ich hier eher davon ausgegangen, dass der Compiler gleich 32 Bit berechnet. Weil ihm ja der Typ (uint32_t) bekannt ist. Ist das nicht fast schon ein Compilerfehler?
Gast
#5763900
Die Erklkärung noch: Aus "30000 * 2" macht der Compiler ein int. Dadurch entsteht ein negativer Wert. Dieser negative Wert wird in unsigned long gespeichert, wodurch er a) wieder positiv wird und b) zum zweiten Mal seine Größe ändert.
Gast
#5763906
Man sollte seinen Compiler kennen: Du verwendest wohl einen AVR, da rechnet der gcc intern halt standardmäßig mit 16 Bit ints. Ein gcc für ARM Cortex-M würde hier mit 32 Bit ints rechnen.
Gast
#5763910
Zahlen sind in C immer int, solange sie dort rein passen.
Bei Mathematischen Ausdrücken wird der Typ des grössten Argumentes
verwendet. In deinem Fall sind beide Zahlen int, also wird mit einem
Algorithmus für int gerechnet. Wohin das Ergebnis des Ausdrucks
geschrieben wird, spielt keine Rolle.
> Ist das nicht fast schon ein Compilerfehler?
Nein, so ist C halt, es war nie anders. C ist an vielen Stellen
unnatürlich.
Bei Java hatte man angekündigt, mit allen Altlasten und Überraschungen
von C aufräumen zu wollen, aber auch dort gibt es trotzdem viele
derartiger Überraschungen.
Gast
#5763915
60000 schrieb: > Im Gegensatz zu #define, wo das nachvollziehbar wäre, wäre ich hier eher > davon ausgegangen, dass der Compiler gleich 32 Bit berechnet. C/C++ sind Dreckssprachen, die nur selten das machen, was man erwarten würde. Aber immerhin: es ist penibel und umfassend dokumentiert, was sie tatsächlich machen. Man sollte den Umfang dieser Doku vollständig beherrschen, BEVOR man es wagt, diese hochgefährlichen Sprachen zu benutzen, die offensichtlich genau dafür designed wurden, jegliche Erwartungen eines sinnvollen Grundverhaltens gnadenlos zu enttäuschen...
Gast
#5763918
Stefanus F. schrieb: > Bei Mathematischen Ausdrücken es müsste heißen: Bei mathematischen Ausdrücken. Das Wort "mathematisch" ist in diesem Zusammenhang kein Nomen und wird klein geschrieben, so lang es nicht am Anfang eines Satzes steht!
Gast
#5763919
c-hater schrieb: > C/C++ sind Dreckssprachen, die nur selten das machen, was man erwarten > würde. War ja klar, das das wieder kommt. Gut dass dich schon lange niemand mehr ernst nimmt. Bewerbe dich mal bei Putins Propaganda-Troll-Fabrik.
Gast
#5763922
c-hater schrieb: > BEVOR man es wagt, diese hochgefährlichen Sprachen zu > benutzen Welche Sprache nutzt du eigentlich? Nur Assembler?
Gast
#5763925
60000 schrieb: > Im Gegensatz zu #define, wo das nachvollziehbar wäre, wäre ich hier eher > davon ausgegangen, dass der Compiler gleich 32 Bit berechnet. Weil ihm > ja der Typ (uint32_t) bekannt ist. Ist das nicht fast schon ein > Compilerfehler? Nein, die rechte Seite der Zuweisung wird unabhängig von der linken Seite bewertet. Die Erklärung hinkt auch etwas. Genaugenommen macht der Compiler aus 30000 und aus 2 jeweils den kleinsten Integer-Typen, der passt (int, long int oder long long int). Bei dir ist int nunmal 16 Bit breit. Die Berechnung wird bei int*int auch als int ausgeführt, und 2*30000 passt da nicht mehr hinein. c-hater schrieb: > C/C++ sind Dreckssprachen, die nur selten das machen, was man erwarten > würde. Und in welcher Sprache wäre dieser Fehler deiner Meinung nach nicht exakt genauso passiert? Kleiner Tipp: Es wäre in Delphi, TurboPascal und Visual Basic und Java semantisch genau so passiert. 60000 schrieb: > Den meisten wird es bekannt sein. In dieser Ausprägung kannte ich das > Problem aber selbst noch nicht, daher poste ich es mal dem Forum. Tja, leider eine der vielen, kleine, fiesen Tücken von C. Stichwort Integer Promotion.
Und schon geht's. > Im Gegensatz zu #define, wo das nachvollziehbar wäre, wäre ich hier eher > davon ausgegangen, dass der Compiler gleich 32 Bit berechnet. Warum sollte er das? > Weil ihm > ja der Typ (uint32_t) bekannt ist. Nö. Es wird zuerst mit dem Zahlenformat der rechten Seite berechnet und DANACH ggf. eine Typerweiterung/umwandlung durchgeführt. Darum erzeugt deine Rechung einen Overflo, denn int ist bei avr gcc 16 Bit. > Ist das nicht fast schon ein > Compilerfehler? Nö. Das sind die Feinheiten von C. Muß man nicht mögen, ist aber so.
Gast
#5763949
c-hater schrieb: > diese hochgefährlichen Sprachen zu benutzen, Jetzt aber ;-) Sind die blutigen Spuren überall in den Wäldern also von dir. Ich weiß ja auch, dass es Bärenfallen gibt, aber in rede reitreten tue ich nicht ^^ Hallo, immerhin warnt die Arduino IDE vorm drohenden Overflow, sofern man die Warnungen einschaltet. Ansonsten schreib das meinetwegen so.
Gast
#5763959
Falk B. schrieb: >
> > Und schon geht's.
Geht auch. Er siehts also, der Compiler. Wieso er dann das uint32_t übersieht, ist eigentlich unerklärbar. Ist so, als wenn man dem Bäcker einen Korb für Brötchen hinhält und sagt: "5 mal ..." ... aber dann geht gerade das Telefon, und bevor man weiter reden und "5 mal ... 10 Brötchen" sagen kann, hat der Bäcker schon die ersten fünf in die kleine Tüte reingezählt. Ich finde, zwischen Bäckern und Programmierern ist -manchmal- nicht so ein großer Unterschied ^^
Gast
#5763961
Veit D. schrieb: > immerhin warnt die Arduino IDE vorm drohenden Overflow, sofern man die > Warnungen einschaltet. Die IDE warnt vor gar nichts, das macht der avr-gcc Compiler.
Gast
#5763962
Veit D. schrieb: > immerhin warnt die Arduino IDE vorm drohenden Overflow, sofern man die > Warnungen einschaltet. Ja, klar. Minniprogramm-Schreiber, oder Masochist. Was bist du?
Gast
#5763963
Frotho schrieb: > Wieso er dann das uint32_t übersieht, ist eigentlich unerklärbar. Die Antwort hast du bereits zweimal erhalten: Die Typen der Argumente des Ausdrucks werden verwendet. Das Ziel wo das Ergebnis gespeichert wird, spielt keine Rolle bei der Auswertung des Ausdrucks. Das ist halt so festgelegt worden und zahlreiche Programme verlassen sich darauf, das sich festgelegte Sachen nie ändern. > Ist so, als wenn man dem Bäcker einen Korb für Brötchen hinhält Nein, das ist so als ob du 10 Brötchen bestellt aber einen zu kleinen Korb dazu mitbringst. Das ist dem Bäcker ziemlich egal. Veit D. schrieb: > Hallo, > > immerhin warnt die Arduino IDE vorm drohenden Overflow, sofern man die > Warnungen einschaltet. Sind aber nicht, was eher doof ist. Und der Arduino-Normalo kann die auch nicht einschalten. > Ansonsten schreib das meinetwegen so.uint32_t b = 30000; > uint32_t c = b * 2; > Serial.println(c); Nö, eher so. Beitrag "Re: [C] Böse Falle: Datentyp korrekt angegeben, falscher verwendet" Oder so. https://www.mikrocontroller.net/articles/Festkommaarithmetik#Die_L.C3.B6sung Bissel runter gehen, bei "Achtung!" Bei Konstanten muss man halt die passende Endung wählen. L = long, meist 32 Bit UL = unsigned long LL = long long, meist 64 Bit ULL = unsigned long long Oder einen Cast vor die Konstante oder Variable setzen und die EXAKTEN Datentypen aus stdint.h nutzen, da weiß man IMMER was man bekommt!
Gast
#5763966
Frotho schrieb: > Wieso er dann das uint32_t übersieht, ist eigentlich unerklärbar. Er übersiehts ja nicht, aber es kommt halt später erst an die Reihe. Und warum das so ist? Naja, weil man in der Regel nicht jede Berechnung gleich breit auswalzen möchte. Es ist ja völlig legitim, dass du in dem Term astronomische Zwischenergebnisse hast, die letztlich wieder kleingemacht werden (Division, rechts-schieben) und in die Variable auf der linken Seite der Zuweisung passen. Dann wärs ja auch Käse, wenn der Compiler den Typ der Variablen annehmen würde. Mach dir Gedanken, ob die Ergebnisse in die Variablen passen. Das musst du ja letztlich in jeder Programmiersprache. Mindestens Anfänger, manchmal auch Fortgeschrittere, gehen oft davon
aus, dass bei einem Statement der Art
xxx_t Variable = Rechenausdruck;
offensichtlich sei, dass der Rechenausdruck in der Breite von xxx_t
erfolgt. Das stünde ja doch deutlich genug da.
Pustekuchen! Der Rechenausdruck wird isoliert betrachtet, ohne Rücksicht
auf den Kontext. Erst das Ergebnis dieser Erwägung wird an xxx_t
angepasst.
Gast
#5763970
Falk B. schrieb: > Oder einen Cast vor die Konstante oder Variable setzen und die EXAKTEN > Datentypen aus stdint.h nutzen, da weiß man IMMER was man bekommt! Dazu gibts sogar recht elegant Makros in stdint.h: INT32_C und so weiter.
Gast
#5763971
Falk B. schrieb: > Nö. Das sind die Feinheiten von C. Muß man nicht mögen, ist aber so. "Feinheiten", wo man Bug und Feature nicht mehr auseinander halten kann, kenne ich nur von M$ Produkten, und um die mache ich einen großen Bogen, wo immer es möglich ist. Die sogenannten "Feinheiten" sind im übrigen der Grund, dass man heutzutage noch solche Fragen stellen muss Beitrag "Welche Berechnungen erfolgen durch Präprozessor ?" und dass da auch noch zu lesen ist, um wieviel besser die Compiler zu ano damalsmal geworden sind...nichts ist besser. Nur die Klippen, die damals backbord waren, sind heute steuerbord. Raider heißt jetzt ....
Gast
#5763979
Fast alle Programmiersprachen verhalten sich so. Also wäre ich mit dem Meckern besser mal vorsichtig, zumindest wenn ich mit Programmieren meinen Lebensunterhalt erwirtschaften möchte. Ich hab das ganze mal kurz im Onlinecompiler mit dem MSP420 gcc 6.2.1 probiert. Da bekomme ich warning: integer overflow in expression [-Woverflow]. Wenn man also die richtigen Warnings einschaltet, dann meckert der Compiler auch.
Gast
#5763999
Stefanus F. schrieb: > Fast alle Programmiersprachen verhalten sich so. Also wäre ich mit dem > Meckern besser mal vorsichtig, zumindest wenn ich mit Programmieren > meinen Lebensunterhalt erwirtschaften möchte. Du hast ja recht. Nörgeln am Essen ist genau so unangenehm. Aber für wen? Für den Gast, oder die Küche .. Wer sich nie beklagt, muss alles essen, was ihm hingeworfen wird. Suche den Unterschied zwischen einem Programmierer und einem Straßenhund ... Will sagen, dass ich auch im Beruf "meckere". Wenn es einen Grund gibt, sage ich das natürlich. Die meisten Kollegen und das aber nicht. Fahren sie besser als ich? Ich vermute: ja. Der ET ist aber nicht zmm meckern, sondern um jenen etwas mitzuteilen, die vielleicht noch nicht wissen, wie sich fast alle Programmiersprachen verhalten ;-) Wen es interessiert, weshalb das so ist: Bei dem Statement long Variable = a*b; liesse sich die Rechenweise von a*b aus dem Kontext ableiten. Hier allerdings wäre das nicht mehr so einfach möglich: long Variable = (long)(a*b); // C long Variable = long(a*b); // C++ Denn aus (int)(a*b) oder int(a*b) lässt sich nicht mehr auf die Breite der Berechnung von a*b schliessen. Man müsste Konstruktionen wie long Variable = convert<long,int>(a*b); verwenden, in denen bei in der Konvertierung nicht nur der Typ vom Ergebnis, sondern auch der vom Operanden angegeben wird. Erst dadurch würde a*b eindeutig.
Gast
#5764004
Frotho schrieb: > Feinheiten", wo man Bug und Feature nicht mehr auseinander halten kann, Sinnloses Gezeter. Kontextfreie Sprachen, insbesondere viele Programmiersprachen, funktionieren nun einmal so, dass Ausdrücke von innen nach außen ausgewertet werden. Also erst die 30000, dann die 2, dann deren Produkt (inkl. Überlauf) und dann erst die Zuweisung unter Beachtung von uint32_t. Das ist einfach die grundlegende Funktionsweise von Ausdrücken und Parsern. Eine von außen dran geschriebene Information innen einzubringen würde die ganze Struktur der Sprache durcheinander bringen und das Typsystem dramatisch verkomplizieren. Wahrscheinlich lässt sich das gar nicht allgemeingültig aufbauen (wie würde sich das auf Funktionsaufrufe auswirken, auf verschachtelte Ausdrücke, auf Templates...?). Also damit abfinden und weniger jammern.
Gast
#5764012
M.K. B. schrieb: > Wenn man also die richtigen Warnings einschaltet, dann meckert der > Compiler auch. Noch einer. Was schreibt ihr alle für Miniprogramme? Ich habe 1x die Warnings eingeschaltet und bin fast erschlagen worden von unused-parameter Warnings. Das brauche ich nicht. Jedenfalls nicht bei jedem Compilieren. Wenn ich fertig bin, ja, zum optimieren und für QS. Aber nicht bei jedem Mal, da schwillt mir ja der Kopf. Habs gerade mal in ein Word doc kopiert: 16 A4-Seiten
Gast
#5764015
Dr. Sommer schrieb: > Frotho schrieb: >> Feinheiten", wo man Bug und Feature nicht mehr auseinander halten kann, > > Sinnloses Gezeter. NEIN ! Du bist konditioniert, das ist alles.
Gast
#5764019
Frotho schrieb: > Noch einer. Was schreibt ihr alle für Miniprogramme? Was schreibst du eigentlich für beschissenen Code? Frotho schrieb: > Ich habe 1x die > Warnings eingeschaltet und bin fast erschlagen worden von > unused-parameter Warnings. Die kannst du individuell abschalten.
Gast
#5764025
> Mindestens Anfänger, manchmal auch Fortgeschrittere, gehen oft davon > aus, dass bei einem Statement der Art > xxx_t Variable = Rechenausdruck; > offensichtlich sei, dass der Rechenausdruck in der Breite von xxx_t > erfolgt. Hier auch?
Es schon sinnvoll, dass ein und der selbe Ausdruck immer das gleiche Resultat liefert, egal in welchem Kontext er steht. Der Kontext entscheidet dann, wie das Resultat verwurstet wird. Dr. Sommer schrieb: > Sinnloses Gezeter. Yep. > Kontextfreie Sprachen, insbesondere viele > Programmiersprachen, funktionieren nun einmal so, dass Ausdrücke von > innen nach außen ausgewertet werden. Der Begriff einer "kontextfreien Sprache" bezieht sich üblicherweise auf die Grammatik/Syntax. Die ist hier aber nicht entscheidend, denn die Ableitung der Bedeutung, hier der Rechenweise, ist nicht Teil der Grammatik. > würde die ganze Struktur der Sprache durcheinander > bringen und das Typsystem dramatisch verkomplizieren. Es käme eine völlig andere Sprache dabei heraus, oft deutlich umständlicher, weil Operatoren und Funktionen (C++ Overloading), die in generischer Weise auf verschiedene Typen anwendbar sind, wesentlich komplizierter gestalten würde. Das Gejammer würde sich nur verlagern. Es läuft letztlich darauf hinaus, eine Fremdsprache mitsamt ihrem Wesen zu lernen und nicht zu versuchen, die muttersprachliche Intuition darauf anzuwenden. foobar schrieb: > Hier auch? Da sieht man es direkt. Im Problem des Startbeitrags nicht. > Es schon sinnvoll, dass ein und der selbe Ausdruck immer das gleiche > Resultat liefert, egal in welchem Kontext er steht. Ich habe nichts anderes behauptet. ;-) Frotho schrieb: > Noch einer. Was schreibt ihr alle für Miniprogramme? Ich habe 1x die > Warnings eingeschaltet und bin fast erschlagen worden von > unused-parameter Warnings. Auch im produktiven Code in sehr großen Projekten haben wir die Warnings an. Für manche externen Bibliotheken sind die dann explizit teilweise ausgeschaltet. Bisher war aber meine Erfahrung, dass die Warnings schon berechtigter Weise meckern und genau die hier beschriebenen Fehler aufdecken. Wenn die natürlich nicht gleich bei der Entwicklung an sind, dann kann es später erstmal Arbeit sein den Code entsprechend zu korrigieren. Aber einen Tod muss man sterben.
Gast
#5764038
Warum bekomme ich hier (auf meinem PC) trotzdem das richtige Ergebnis?
int16 mal int16 musste doch vom Typ her auch int16 ergeben? (und somit das falsche Ergebnis) Frotho schrieb: > NEIN ! Du bist konditioniert, das ist alles. Ist er, genauso wie ich. Das bringt beispielsweise ein Informatikstudium so ich sich. Lernen bedeutet konditioniert zu werden, in einer bestimmten Weise zu denken. zitter_ned_aso schrieb: > Warum bekomme ich hier (auf meinem PC) trotzdem das richtige Ergebnis? > uint32_t x = (int16_t)30000*(int16_t)2; > printf("%u\n", x); Weil int16_t vorzeichenbehaftet von -32768 bis 32767 geht? > int16 mal int16 musste doch vom Typ her auch int16 ergeben? Nö. 16 Bit * 16 Bit sind 32 Bit. Das Ergebnis fürht nur dann nicht zum Überlauf, wenn die Faktoren klein genug sind. > (und somit das falsche Ergebnis) zitter_ned_aso schrieb: > Warum bekomme ich hier (auf meinem PC) trotzdem das richtige Ergebnis? Weil durch %u ein implizites printf("%u\n", (unsigned)x); drin steckt. Abgesehen davon, dass in printf("%u\n", x); 4 Bytes übergeben aber nur 2 Bytes abgeholt werden. Was bei printf("%u,%u\n", x, x); je nach Umgebung voll in die Hose gehen kann. Allerdings ist dein Code sowieso undefiniert, weil Überlauf mit Vorzeichen. Und undefinierter Code muss nicht immer dein Haus zu Einsturz bringen. Er kann auch so arbeiten, wie man es eigentlich haben wollte. Soll heissen: Bloss weil sich ein Programm so verhält, wie man es erwartet, ist es noch lange nicht korrekt. Falk B. schrieb: >> int16 mal int16 musste doch vom Typ her auch int16 ergeben? > > Nö. 16 Bit * 16 Bit sind 32 Bit. In PL/I schon. In C nur dann, wenn ein "int" 32 Bits breit ist.
Gast
#5764056
Frotho schrieb: > Was schreibt ihr alle für Miniprogramme? Ich habe 1x die > Warnings eingeschaltet und bin fast erschlagen worden von > unused-parameter Warnings. Das brauche ich nicht. Man kann Programme (auch grosse) so schreiben, dass fast keine Warnungen erscheinen. Die wenigen, die übrig bleiben kann man stellenweise unterdrücken. Dann aber bitte mit Kommentar, was man sich dabei gedacht hat. Siehe: #pragma warning Ich programmiere beruflich in Java. Dort benutze ich zusätzlich zu den Warnungen des Compiler das Tool FindBugs mit projektspezifischer Konfiguration. Das Pendant dazu in C/C++ wäre lint. Diese Tools halte ich äusserst hilfreich. Sie helfen sehr dabei, dumme Fehler zu vermeiden - selbst wenn die meisten Warnungen falsche Treffer sind. > Habs gerade mal in ein Word doc kopiert: 16 A4-Seiten Das ist gar nichts! Ich arbeite an Programmen mit mehreren hundert Tausend Zeilen Quellcode (nicht Kommentare).
Gast
#5764059
A. K. schrieb: > Abgesehen davon, dass in > printf("%u\n", x); > 4 Bytes übergeben aber nur 2 Bytes abgeholt werden. Was bei > printf("%u,%u\n", x, x); > je nach Umgebung voll in die Hose gehen kann. Wo werden da Bytes "abgeholt"? Was geht nicht? Bitte bring ein Beispiel. leo
Gast
#5764061
Frotho schrieb: > Veit D. schrieb: > >> immerhin warnt die Arduino IDE vorm drohenden Overflow, sofern man die >> Warnungen einschaltet. > > Ja, klar. Minniprogramm-Schreiber, oder Masochist. Was bist du? Eigentlich haben nur Anfänger die Warnungen generell ausgeschaltet, abgesehen von z.b.legacy Code oder so. Profis haben alle Warnungen an, bis sie jede einzelne dann abschalten, wenn sie sie verstanden haben und die Effekte keine Gefahr mehr darstellen. Experten zwingen sich zusätzlich noch unter weit strengere, permanente Überwachung, z.b. MISRA-C.
Gast
#5764066
A. K. schrieb: > Weil durch %u ein implizites > printf("%u\n", (unsigned)x); > drin steckt. unsigned habe ich jetzt weggelasen.
Und wieder kommt das richtige Ergebnis raus. Falk B. schrieb: > Nö. 16 Bit * 16 Bit sind 32 Bit.
gibt tatsächlich 4 aus. (ist Standard-Int auf meinem System) Und ich dachte wenn man z.B. (short) + (char) rechnet, dann bekommt das Ergebnis implizit den größten Datentyp von beiden (also short).
Gast
#5764071
> Warum bekomme ich hier (auf meinem PC) trotzdem das richtige Ergebnis? > uint32_t x = (int16_t)30000*(int16_t)2; Weil in C alle Berechnungen in mindestens int-Größe stattfinden, die ints auf deinem PC sind 32-bit. Deine Casts verkleinern die (int-)Zahlen nur (hier ohne Effekt), danach kommen die impliziten Casts auf int. leo schrieb: > Wo werden da Bytes "abgeholt"? Was geht nicht? > Bitte bring ein Beispiel. Die Funktion printf("%u,&u",a,b) mit 32bit Typen a und b kennt keine definierten Parametertypen jenseits des Formatstrings. Ein Weg, das zu implementieren, geht über einen Stack. Übergeben werden die realen Typen von a und b, ohne Berücksichtigung des Formatstrings. Das kann dann auf einem abstrahierten 16-Bitter so aussehen: push 32bit b push 32bit a push 16bit address of "%u,%u" call printf add sp, #10 Die Funktion printf wird aus dem Formatstring ableiten, dass 2 16-Bit Werte auf dem Stack stehen. Das sind dann die beiden Hälften von "a". Je nachdem ob big- oder little-endian gibts die obere Hälfte vorne, oder die untere
Gast
#5764076
M.K. B. schrieb: > Bisher war aber meine Erfahrung, dass die Warnings schon berechtigter > Weise meckern Kann ja sein. Aber unused-Parameter (75%) brauche ich nicht gemeldet zu sehen, weiß ich selbst (meist optionalen Parametern). zitter_ned_aso schrieb: > Und ich dachte wenn man z.B. (short) + (char) rechnet, dann bekommt das > Ergebnis implizit den größten Datentyp von beiden (also short). Alles kleiner als int wird zu int. Erst wenn ein grösserer Typ als int mitspielt, stimmt das, was du schreibst.
Gast
#5764083
foobar schrieb: > Weil in C alle Berechnungen in mindestens int-Größe stattfinden Ja, jetzt klingelt's. Danke!
Gast
#5764084
> Und ich dachte wenn man z.B. (short) + (char) rechnet, dann bekommt das > Ergebnis implizit den größten Datentyp von beiden (also short). Eben nicht. In der theoretischen Maschine von C gibt es keine Multiplikation/Addition/etc mit Zahlen kleiner als int. Wenn du das in dem erzeugten Kode findest, war das der Optimizer, der das "verkleinert" hat.
Gast
#5764086
A. S. schrieb: > Eigentlich haben nur Anfänger die Warnungen generell ausgeschaltet, > abgesehen von z.b.legacy Code oder so. Wenn das so ist, bin ich Anfänger ;)
Gast
#5764093
Stefanus F. schrieb: > Man kann Programme (auch grosse) so schreiben, dass fast keine Warnungen > erscheinen. Die wenigen, die übrig bleiben kann man stellenweise > unterdrücken. Dann aber bitte mit Kommentar, was man sich dabei gedacht > hat. Das halte ich auch so. Wenn das Programm fertig ist, will ich keine Warnung mehr am Bildschirm sehen. Erst mal ist wichtig, dass das Prog die Anforderungen erfüllt, möglichst 100% feherlfrei, DANN kümmere ich mich um unused-Parameter. Ich hoffe, du machst das auch so. Und JA, es sind fast nur unused-Parameter. Warum soll ich mir da einen Kopf machen und Arbeitszeit verschwenden? Das stört mich AKTUELL überhaupt nicht. Frotho schrieb: > Wenn ich fertig bin, ja, zum optimieren und für QS.
Gast
#5764097
A. K. schrieb: > Übergeben werden die realen Typen > von a und b, ohne Berücksichtigung des Formatstrings. Ah, du sprichst von einer vollkommen kaputten Compiler, der keinerlei Vergleich der printf Argumente vornimmt.
Also wohl veraltet oder theoretisch. leo
Gast
#5764099
Wie dem auch sei, jeder wie er mag. Die Diskussionsbeteiligung sagt jedenfalls, dass das Thema nicht ganz unnütz gewesen sein kann. leo schrieb: > Ah, du sprichst von einer vollkommen kaputten Compiler, der keinerlei > Vergleich der printf Argumente vornimmt. Ich trenne Sprache von Compiler, spreche von der mir recht gut vertrauten Sprache C, nicht von einem bestimmten Compiler. > Also wohl veraltet oder theoretisch. GCC tut dem Programmierer den Gefallen, Formatstring und Parameter gegenzuchecken. Das ist aber keine Spracheigenschaft. Denk dir printf(s,a,b) mit einem dem Compiler unbekannten String s, und der Traum platzt.
Gast
#5764107
A. K. schrieb: > GCC tut dem Programmierer den Gefallen, Formatstring und Parameter > gegenzuchecken. Das ist aber keine Spracheigenschaft. Ok. Ich verwende halt einen Compiler der fuer mich funktioniert. Aber du hast schon recht. leo
Gast
#5764130
Schon richtig, C ist Sch... und nicht mehr zeitgemäß. Mal schauen, wie lange die Selbsterhaltungsstrategie der ach so supertollen C-Programmierer noch funktioniert. ;-) Und ja, ich muss mich seit Jahren mit der Sch... rumärgern und damit mein Geld verdienen. :-<<<
Gast
#5764135
Doris schrieb: > Stefanus F. schrieb: >> Bei Mathematischen Ausdrücken > > es müsste heißen: Bei mathematischen Ausdrücken. > > Das Wort "mathematisch" ist in diesem Zusammenhang kein Nomen und wird > klein geschrieben, so lang es nicht am Anfang eines Satzes steht! Das ist einfach zu gut! Da belehrt man andere in ihrer Rechtschreibung und dann ist doch tatsächlich der erste Buchstabe in diesem lehrreichen Text falsch. Wenn das keine Satire ist... no c tomorrow, no sorrow schrieb: > Und ja, ich muss mich seit Jahren mit der Sch... rumärgern und damit > mein Geld verdienen. :-<<< Je dümmer die Sprache, desto mehr Stunden kostet es. Diese Dummheit lässt also deine Kasse klingeln! ;-) Frotho schrieb: > A. S. schrieb: >> Eigentlich haben nur Anfänger die Warnungen generell ausgeschaltet, >> abgesehen von z.b.legacy Code oder so. > > Wenn das so ist, bin ich Anfänger ;) Full ACK, denn Fortgeschrittene wissen das man dem Compiler mit
mitteilen kann, daß das mit Wissen und Absicht passiert. c-hater schrieb: > C/C++ sind Dreckssprachen, die nur selten das machen, was man erwarten > würde. Einerseits ja, andererseits sind das die einzigen brauchbaren Sprachen ohne GC (ok, abgesehen von ADA). Rust ist noch nicht so weit.
Gast
#5764264
Frotho schrieb: > unused-Parameter. Warum soll ich mir da einen Kopf machen Weil das auch ein Hinweis auf einen Fehler sein kann. Beispiel:
Hier bekommst du so eine Fehermeldung und das ist auch gut so, weil deine Firma sonst nach dem Deployment dieser Software pleite geht.
Gast
#5764266
A. K. schrieb: > printf() > GCC tut dem Programmierer den Gefallen, Formatstring und Parameter > gegenzuchecken. Wenn man sich eine ähnliche Funktion selbst schreibt, hat man diese Kontrolle leider nicht.
Beitrag #5764267 wurde von einem Moderator gelöscht.
Gast
#5764288
Der Überlauf eines signed Typs ist übrigens nach Standard undefiniert. Das Ergebnis hätte also auch 42 lauten können. Die meisten C Programmierer gehen leider mit Konstanten und signed Typen relativ sorgenfrei um. Man muss aber sagen: Auch Konstanten haben einen Typ und signed Typen zeigen wesentlich häufiger undefiniertes Verhalten als unsigned Typen. Daher ein gut gemeinter Tipp: Konstanten immer durch passendes Postfix in den gewünschten Typ setzen und immer unsigned Typen verwenden sofern kein vorzeichenbehafteter Typ explizit notwendig ist. Selbst harmlos aussehende Dinge wie
sind mit signed Typen der absolute Horror, da gleich mehrfach undefiniertes Verhalten auftreten kann: n kann negativ sein => undefiniert, n kann größer als int Bitlänge sein => undefiniert, 1 (signed, daher Ausdruck int op int) kann ins Vorzeichen geschoben werden => undefiniert
Gast
#5764293
x^y schrieb: > Selbst harmlos aussehende Dinge wie...sind mit signed Typen der absolute Horror Das hast du sehr schön beschrieben. Ich habe mich schon darüber gewundert, dass in der CMSIS Core hinter sämtlichen Integer Literalen "U" oder "UL" steht.
Nach deiner Erklärung ergibt es absolut Sinn!
Gast
#5764299
c-hater schrieb: > Aber immerhin: es ist penibel und umfassend dokumentiert, was sie > tatsächlich machen. Man sollte den Umfang dieser Doku vollständig > beherrschen, BEVOR man es wagt, diese hochgefährlichen Sprachen zu > benutzen, die offensichtlich genau dafür designed wurden, jegliche > Erwartungen eines sinnvollen Grundverhaltens gnadenlos zu enttäuschen... Das ist so, damit der Compiler effizienten Code erzeugen kann. Würde man z.B. signed Überlauf präzise definieren, stünde man vor dem Problem, dass die Instruktionen der unterschiedlichen Architekturen sich nicht so verhalten. Der Compiler könnte dann nicht so einfach eine ADD oder MUL Instruktion erzeugen sondern müßte viel drum herum bauen damit er die Spezifikation einhalten kann. Da dieser Überbau aber in den seltensten Fällen wirklich notwendig wäre, ist das Overhead der das Programm ineffizienter macht. c-hater schrieb: > C/C++ sind Dreckssprachen, die nur selten das machen, was man erwarten > würde. Die Sprachen sind lediglich fair: Ich mache ja auch nicht alles was jeder dahergelaufene Trottel mir erwartet.
Gast
#5764327
Stefanus F. schrieb: > Wenn man sich eine ähnliche Funktion selbst schreibt, hat man diese > Kontrolle leider nicht. Der GCC hat ein Attribut für printf-artige Funktionen, die entsprechend geprüft werden. Ist natürlich nicht portabel und schon eine Art Hack. In C++ ist das mit std::cout viel besser - da wird immer automatisch richtig ausgegeben, abhängig vom tatsächlichen Typ. Leider sind die gängigen Implementationen davon nicht für uC geeignet. Von wegen Warnungen - gerade im professionellen Bereich sollte man immer so viele Warnungen wie möglich aktivieren. Sie weisen auf potentielle Probleme hin, die man natürlich nicht erst beim Kunden, sondern möglichst früh finden möchte. Wenn der Code so schlecht ist, dass er seitenweise Warnungen produziert, sollte man ihn dringend korrigieren, denn zwischen den unnötigen Warnungen fallen die tatsächlichen Probleme nicht sehr auf. Das Korrigieren ist in den meisten Fällen auch gar kein Problem. Wenn man die Warnungen immer an hat, macht man das automatisch zwischendurch. Gute IDEs zeigen manche Warnungen auch schon beim Tippen an. Ungenutzte Parameter sind gerade in C ein Zeichen für schlechten Code (kaum Polymorphie). Wie man diese mit dem (void)-Trick loswird wurde ja bereits gezeigt. In C++ taucht so etwas häufiger auf, da kann man aber einfach den Namen des Parameters weglassen, dann verschwindet die Warnung. So ist auch deutlich zu sehen dass der Parameter nicht genutzt wird. Übrigens kann man auch bei Arduino die Warnungen im Optionsmenü einschalten. Leider sind sie das nicht standardmäßig. Frotho schrieb: > NEIN ! Du bist konditioniert, das ist alles. Man sollte es nicht glauben, aber Jahrzehnte an Forschung und Entwicklung bringen durchaus sinnvolle Dinge zustande. Es hat oft schon seinen Grund, warum Dinge so sind wie sie sind. Wenn du es besser kannst, definiere deine eigene Sprache. A. K. schrieb: > Der Begriff einer "kontextfreien Sprache" bezieht sich üblicherweise auf > die Grammatik/Syntax. Die ist hier aber nicht entscheidend, denn die > Ableitung der Bedeutung, hier der Rechenweise, ist nicht Teil der > Grammatik. Stimmt zwar, aber aus der Grammatik und dem daraus entstehenden Syntaxbaum ergibt sich quasi natürlich dieses Vorgehen. Man arbeitet Ausdrücke von den Blättern des Baumes aus ab.
Gast
#5764334
Dr. Sommer schrieb: > definiere deine eigene Sprache. Als hätten wir nicht schon genug. Alle 1-2 Jahre wird eine neue von der Presse angekündigt. Doch nur wenige haben so langfristig Erfolg, wie C. Dr. Sommer schrieb: > Stefanus F. schrieb: >> Wenn man sich eine ähnliche Funktion selbst schreibt, hat man diese >> Kontrolle leider nicht. > > Der GCC hat ein Attribut für printf-artige Funktionen, die entsprechend > geprüft werden. Beispiel aus der GCC-Doku:
> In C++ ist das mit std::cout viel besser - da wird immer automatisch > richtig ausgegeben, abhängig vom tatsächlichen Typ. Leider sind die > gängigen Implementationen davon nicht für uC geeignet. Und das, obwohl das grundlegende Konzept von cout eigentlich deutlich besser für µCs geeignet ist, als printf. x^y schrieb: > Daher ein gut gemeinter Tipp: Konstanten immer durch passendes Postfix > in den gewünschten Typ setzen und immer unsigned Typen verwenden sofern > kein vorzeichenbehafteter Typ explizit notwendig ist. Generell spricht aber auch manches dafür, es umgekehrt zu machen. Denn wenn man signed und unsigned mischt, gibt es noch ein paar andere Fallstricke. Ich versuche, für Bitgefummel immer unsigned zu verwenden, für alles andere normalerweise signed. > Selbst harmlos aussehende Dinge wie > int f(int n) > { > return 1 << n; > } > > sind mit signed Typen der absolute Horror, da gleich mehrfach > undefiniertes Verhalten auftreten kann: n kann negativ sein => > undefiniert, n kann größer als int Bitlänge sein => undefiniert, 1 > (signed, daher Ausdruck int op int) kann ins Vorzeichen geschoben werden > => undefiniert Das meiste davon ist mit unsigned aber nicht besser. Wenn ich f(-1) aufrufe, ist n zwar nicht negativ, aber ein sehr großer positiver Wert, der devinitiv größer als die Bitlänge von int ist. Frotho schrieb: > M.K. B. schrieb: > >> Wenn man also die richtigen Warnings einschaltet, dann meckert der >> Compiler auch. > > Noch einer. Was schreibt ihr alle für Miniprogramme? Die schreiben keine "Miniprogramme", sondern einfach ordentlichen Code. Zu den Coding-Regeln gehört oft die Anforderung, dass das Programm komplett ohne Warnungen compilert werden muss (und das natürlich nicht durch Abschalten der Warnungen). > Ich habe 1x die Warnings eingeschaltet und bin fast erschlagen worden von > unused-parameter Warnings. Das brauche ich nicht. Jedenfalls nicht bei > jedem Compilieren. Wenn ich fertig bin, ja, zum optimieren und für QS. Umgekehrt solltest du es sehen. Die Warnungen sollen von Anfang an eingeschaltet sein, damit du gleich von vorn herein sauberen Code schreibst. Wenn du ein großes Programm komplett schreibst und dann erst ganz am Schluss die Warnungen einschaltest, ist natürlich klar, dass du davon praktisch erschlagen wirst. > Aber nicht bei jedem Mal, da schwillt mir ja der Kopf. Die Warnungen sind nicht dazu da, dich zu ärgern, sondern um dir potenzielle Probleme aufzuzeigen, die du natürlich auch beheben sollst. > Habs gerade mal in ein Word doc kopiert: 16 A4-Seiten Das ist ein Indiz dafür, dass mit deinem Code einiges nicht stimmt, nicht dafür, dass Warnungen nicht eingeschaltet werden sollten. Dr. Sommer schrieb: > Ungenutzte Parameter sind gerade in C ein Zeichen für schlechten Code > (kaum Polymorphie). Bei mir kommen sich durchaus öfters vor, nämlich dann, wenn man eine Funktion schreiben muss, die ein bestimmtes vordefiniertes Interface umsetzt. Beispielsweise Callback-Funktionen. Da braucht man aber nicht immer alle Parameter, die der Funktion übergeben werden. > In C++ taucht so etwas häufiger auf, da kann man aber einfach den Namen > des Parameters weglassen, dann verschwindet die Warnung. Ja. Ich finde es schade, dass das in C nicht geht.
Gast
#5764411
Stefanus F. schrieb: > Als hätten wir nicht schon genug. Wenn seine neue Sprache so toll ist hat sie bestimmt Erfolg. Rolf M. schrieb: > Und das, obwohl das grundlegende Konzept von cout eigentlich deutlich > besser für µCs geeignet ist, als printf. Es ist leider nicht so leicht ohne dynamischen Speicher umsetzbar... Rolf M. schrieb: > Bei mir kommen sich durchaus öfters vor, nämlich dann, wenn man eine > Funktion schreiben muss, die ein bestimmtes vordefiniertes Interface > umsetzt Ja, eigentlich nur dann ;-) Rolf M. schrieb: > Ja. Ich finde es schade, dass das in C nicht geht. Wie so vieles... zum Glück gibt es kaum noch einen Grund für C. Wenn ich eine fremde Bibliothek einbinde korrigiere ich manchmal erstmal ein paar Dutzend Stellen welche Warnungen produzieren. Geht aber leider nicht immer. Wenn man so etwas wie die stm32f1xx.h Header nutzt und beim g++ mit -Woldstyle-cast kompiliert hat man sonst Spaß ? Sven P. schrieb: > Kleiner Tipp: Es wäre in Delphi, TurboPascal und Visual Basic und Java > semantisch genau so passiert. Wohl kaum: # [18] i := 30000 * 2; ldi r20,96 ldi r21,-22 mov r19,r1 mov r18,r1 Womit 0x0000EA60 in i steht, was genau 60000 ist. Mit i := a * b; und a, b als Konstanen genau das Gleiche. Mit a, b als uint16 wird daraus: # Var a located in register r20 # [19] a := 30000; ldi r20,48 ldi r21,117 # Var b located in register r22 # [20] b := 2; ldi r22,2 mov r23,r1 # [22] i := a * b; mul r20,r22 movw r24,r0 mul r21,r22 add r25,r0 mul r20,r23 add r25,r0 clr r1 movw r2,r24 mov r4,r1 mov r5,r1 Kommt auch korrekt 60000 raus. Dr. Sommer schrieb: > Wie so vieles... zum Glück gibt es kaum noch einen Grund für C. Naja, C hat schon noch einen gehörigen Anteil am Programmiersprachenmarkt. Sei es der Linux-Kernel, verdammt viele Mikrocontroller und was weiß ich noch. Es ist nicht alles auf PC-Ebene und C++. Und nach über 40 Jahren in der Praxis sollten sich die Ecken und Kanten von C herumgesprochen haben und man kann sie praktisch überaus passabel umschiffen. tsts..wie gut das ja nur Profis in C programmieren. Daher war das ganz eindeutig Dein Fehler. Das C einfach eine Anhäufung von Fehlern ist..neinein..das kann gar nicht sein..es immer immer der Programmierer schuld..ist doch völlig logisch..
Gast
#5764510
Karl K. schrieb: > Sven P. schrieb: >> Kleiner Tipp: Es wäre in Delphi, TurboPascal und Visual Basic und Java >> semantisch genau so passiert. > > Wohl kaum: [x] Du hast das Problem exakt überhaupt nicht verstanden. Q"Aber immerhin: es ist penibel und umfassend dokumentiert, was sie tatsächlich machen." heheh..ja genauso...:-) Alles in C ist dokumentiert..nur das es totaler murks ist haben sie vergessen im Klartext zu schreiben :-) Und manche erkennen nur das was geschrieben steht..jedes C Buch sollte damit anfangen das C ein riesen Problem ist.. Autor: Sven P. (haku) man merkt sofort er kennt diese Sprachen nicht, denn sonst wüsste er das es in Pascal NICHT passiert wäre! Thomas M. schrieb: > Autor: Sven P. (haku) > man merkt sofort er kennt diese Sprachen nicht, denn sonst wüsste er das > es in Pascal NICHT passiert wäre! Sven P. schrieb: > [x] Du hast das Problem exakt überhaupt nicht verstanden.
Gast
#5764521
Rolf M. schrieb: > Das meiste davon ist mit unsigned aber nicht besser. Wenn ich f(-1) > aufrufe, ist n zwar nicht negativ, aber ein sehr großer positiver Wert, > der devinitiv größer als die Bitlänge von int ist. Es gibt aber noch den gemeinen Fall "1 << 31" was für signed (int: 32-bit) ebenfalls nicht definiert ist. Da lauert also ein recht bösartiger Bug selbst wenn man negative Werte und "n >= 32" abfängt, der nicht für jeden offensichtlich ist. Just dies war in einer SW die ich mal analysieren mußte tatsächlich fehlerursächlich, da damit ein Bittest gemacht wurde, der nicht wie erwartet funktionierte. Man muss sich auch immer fragen: Was ist einfacher korrekt zu behandeln. Je komplizierter, desto mehr Fehler passieren. Da hat unsigned eigentlich immer die Nase vorn, da es von vorne herein weniger undefinierte Fälle gibt. Beispiel Addition: Bei unsigned einfach Modulo Bitlänge, bei signed undefiniert. Für das gegebene Beispiel: a) Unsigned
b) Signed
Bei der Embedded Entwicklung habe ich ehrlich gesagt nur sporadisch Fälle, die tatsächlich signed Typen verlangen. Meist sind es entweder gleich float Typen oder aber unsigned Typen genügen. Float Typen haben natürlich ebenfalls viele Tücken, aber das steht auf einem anderen Blatt. Sobald man dann mit signed Typen konfrontiert ist, läßt man automatisch entsprechend größere Sorgfalt walten. Andernfalls hat man überall signed Typen und muss überall höllisch aufpassen.
geht unter Pascal fehlerfrei https://rextester.com/l/pascal_online_compiler Back to the roots.... Will mir einer vielleicht nochmals kurz erklären, warum ich bei uint32_t a = 30000 * 2; nicht 60000 bekomme, und es bei uint32_t a = (uint16_t) 30000 * 2; dann stimmt... Was ist denn da der Unterschied für den Compiler zwischen den beiden Berechnungen?
Gast
#5764541
Falk B. schrieb: > Und nach über 40 Jahren in der Praxis sollten sich die Ecken und Kanten > von C herumgesprochen haben und man kann sie praktisch überaus passabel > umschiffen. Aber warum bitte schön kann man die Ecken und Kanten nicht glätten? Warum quält man Genarationen von Programmieren? Warum erzeugt man unnötige SW-Fehler, die nur dieser Bastelsprache anzuhängen sind. Sorry, ich kann solch eine Denke nicht verstehen. Passt aber zur Zeit: Probleme verwalten und nicht die Ursachen beseitigen. :-<<<
Gast
#5764550
Rolf M. schrieb: > Umgekehrt solltest du es sehen. Die Warnungen sollen von Anfang an > eingeschaltet sein, damit du gleich von vorn herein sauberen Code > schreibst. Wenn du ein großes Programm komplett schreibst und dann erst > ganz am Schluss die Warnungen einschaltest, ist natürlich klar, dass du > davon praktisch erschlagen wirst. Sehe ich genauso und kann ich jedem nur dringend empfehlen. Von vorne herein Warnungen einschalten und deren Anzahl konsequent bei Null halten. Nur so springt einem eine neue Warnung direkt ins Auge wenn man etwas ändert. Hatte auch schonmal so eine SW übernommen. Problem des Vorgängers: Zu viele Warnungen. Lösung des Vorgängers: Warnungen abschalten. Habe mich nicht schlecht gewundert, nach -Wall mit fast einer vierstelligen Anzahl Warnungen konfrontiert zu sein. Da waren Dinger drin a la "return" in Funktion mit Rückgabewert vergessen. Hat (ohne Compiler Optimierung) tatsächlich funktioniert, da Ergebnis zufällig in richtigem Register. Mit Compiler Optimierung hat's dann in der SW gekracht. Aber da war dann natürlich der Compiler dran schuld ("Compiler-Bug!") ...
Gast
#5764555
Alexander M. schrieb: > Will mir einer vielleicht nochmals kurz erklären, warum ich bei > > uint32_t a = 30000 * 2; > > nicht 60000 bekomme Und das ist der Beweis schlecht hin: Nach seitenlangen Posts konnte die Umschiffung der Ecke nicht vermittelt werden. :-<<< Warum gibt es die Problematik überhaupt und warum wurde das nicht in C-Standard XYZ abgestellt?
Gast
#5764567
Signed und unsigned
Gast
#5764568
Alexander M. schrieb: > Was ist denn da der Unterschied für den Compiler zwischen den beiden > Berechnungen? Der Autor hat zwei andere Fälle gehabt?! Im wesentlichen:
Ich unterstelle, der Autor arbeitet auf einer 16-Bit Plattform (int: 16-Bit). Der Compiler sieht hier dann int16 * int16. In Bezug auf Integer/Integral-Promotion sind beide Seiten bereits int, d.h. es erfolgt kein implizites Casting der Operanden mehr. Wertebereich von int16 ist von -32768 bis +32767. Das echte Ergebnis 60000 paßt also nicht mehr in int16. C Standard sagt, Überlauf signed Multiplikation ist nicht definiert. Das Ergebnis von 60000 * 2 hängt damit von konkreter Architektur, Compiler und Flug der Schwalben ab. Was auch immer da raus kommt, wird dann konvertiert und in i gepackt. Fertig!
Gast
#5764569
x^y schrieb: > Das Ergebnis von 60000 * 2 hängt 30000 * 2
Gast
#5764571
Thomas M. schrieb: > jedes C Buch sollte damit anfangen das C ein riesen Problem ist.. Wenn C ein riesen Problem wäre, würde es kaum genutzt werden, denn es gibt ja reichlich Alternativen. Das es unschöne Eigenschaften hat, will ich gar nicht abstreiten. Mein Lieblingskäse stinkt. Mein liebster Tisch ist voller buchstäblicher Macken. Meine lieblings Schuhe sehen verschlissen aus. Mein Lieblings-Schraubendreher ist rostig. Kennst du die Serie "Herr Rossi sucht sein Glück?". Sie verdeutlicht schön, dass man auf der permanenten Suche nach Perfektion seine Zeit vergeudet und die Dinge verpasst, die wirklich glücklich machen. Okay habs (glaub) verstanden... "Standard": 30000 * 2 --> int16_t * int16_6 => int16_t Typcast uint16_t: (uint16_t) 30000 * 2 --> uint16_t * int16_t => uint16_t Alexander M. schrieb: > Will mir einer vielleicht nochmals kurz erklären, warum ich bei > uint32_t a = 30000 * 2; > nicht 60000 bekomme, und es bei > > uint32_t a = (uint16_t) 30000 * 2; > dann stimmt... Das Prinzip ist einfach. Was links vom Zuweisungsoperator steht, beeinflusst das, was rechts von ihm berechnet wird, nicht. Berechnungen werden, sofern nicht explizit andere Typen angegeben sind, mit int durchgeführt. Auf dem System, um das es hier geht, ist int ein 16-Bit-Datentyp. Also ist 30000 * 2 negativ, denn die größte mit einem 16-Bit-Int darstellbare Zahl ist 32767. Bei der nun erfolgenden Zuweisung wird das negative Ergebnis der vorzeichenlosen Zahl zugewiesen. Dabei wird zunächst das Ergebnis auf einen vorzeichenbehafteten Datentyp umgerechnet, der die gleiche Größe wie das Zuweisungsziel hat (also int32_t), und dann ohne weitere Konvertierung dieses Zwischenergebnis als vorzeichenlos behandelt. Und das ist dann eine ziemlich große Zahll. Im zweiten Fall wird durch den Typecast auf einen vorzeichenlosen Datentyp eine vorzeichenlose Berechnung durchgeführt. Das Ergebnis passt problemlos in den vorzeichenlosen 16-Bit-Datentyp, daher passiert bei der Zuweisung auch nichts ungewöhnliches. Hier treten also drei Eigenschaften der Programmiersprache C auf, die anscheinend einige Leute massiv überfordern. 1) Bei einer Zuweisung eines Rechenergebnisses beeinflusst der Datentyp der Zuweisung die Berechnung nicht 2) Berechnungen erfolgen, sofern nicht durch Verwendung anderer Datentypen anders formuliert, immer mit dem nativen int-Datentyp des Compilers 3) Das Mischen von vorzeichenlosen und vorzeichenbehafteten Werten führt zu unerwarteten Ergebnissen, wenn dabei der ohne Vorzeichenwechsel verwendbare Wertebereich überschritten wird. Alle diese drei Punkte sind elementares C, und nichts davon, was nicht in den ersten zwei Wochen der C-Erstsemstervorlesung oder in den ersten paar Kapiteln eines tauglichen Buches über die Programmiersprache behandelt werden sollte. Es kann so einfach sein ;) ... Danke! no c tomorrow, no sorrow schrieb: > Aber warum bitte schön kann man die Ecken und Kanten nicht glätten? Weil jede Änderung eines bestehenden Standards bestehende korrekte Programme aus der Kurve werfen kann, werden Standards meist nur erweitert. Bestehende korrekte Programme bleiben aber korrekt. Eine Ausnahme: In 16-Bit K&R-C durfte 30000u * 1L als 30000uL oder 30000L interpretiert werden, weil es im Standard weder als undefiniert noch als definiert vorkam. Das wurde in ANSI-C geklärt, potentiell zu Lasten bestehender Programme.
Gast
#5764587
no c tomorrow, no sorrow schrieb: > Aber warum bitte schön kann man die Ecken und Kanten nicht glätten? > Warum quält man Genarationen von Programmieren? Warum erzeugt man > unnötige SW-Fehler, die nur dieser Bastelsprache anzuhängen sind. > > Sorry, ich kann solch eine Denke nicht verstehen. Passt aber zur Zeit: > Probleme verwalten und nicht die Ursachen beseitigen. :-<<< Wenn du die erschreckende Wahrheit hören möchtest: Solange es Trottel gibt, die programmieren, wird es schlechte Software geben. Das ist kein Problem der Programmiersprache, sondern eine inhärente Eigenschaft des Homo Trottelensis. Sämtliche Versuche eine Heilung oder Genesung von Trotteln über die Medizin der Programmiersprache herbeizuführen sind bisher gescheitert. Das ist so als setzt jemand ohne Führerschein sein Auto an den nächsten Baum und erwartet zuverlässigere Autos. Trotzdem versucht man es immer wieder, nur um erneut festzustellen: es funktioniert nicht. Man hat es mit Java versucht: Man hat gedacht, okay, explizites Speichermanagement, viel zu gefährlich, schießt sich jeder Trottel sofort mit ins Bein. Lösung: Nur noch Referenzen und Garbage Collection. Wenn irgendwas nicht geht, nicht mit undefinierten Ergebnissen weiterlaufen, sondern Exception werfen. War das Ergebnis dessen, dass nun jeder Trottel fehlerfreie Software schreiben kann? Nein! Man hat einige Fehlerursachen ausgeschlossen und teilweise nur gegen neue getauscht. Das Programm läuft zwar nicht mehr per Wildpointer Amok, kann aber trotzdem mit einer unbehandelten Exception und 3 Seiten Stacktrace abstürzen. Daneben rauft man sich den Kopf wie Garbage Collection effizient und ohne Zyklen zu machen ist und warum die Performance insgesamt so mies ist. Zum Glück hat man das JNI sodass man solche performancekritischen Teile dann auslagern kann - in C/C++ Code. Alexander M. schrieb: > "Standard": > 30000 * 2 --> int16_t * int16_6 => int16_t Nur wenn sizeof(int16_t) == sizeof(int). Präziser: int * int => int, egal wie gross. x^y und genau wegen deiner Argumentation sind Atomkraftwerke auch so sicher.. Du hast es einfach nicht verstanden..und da es andere Programmiersprachen wie Pascal /Ada offenbar besser können , wäre es ja machbar. aber Programmierer wie Du, die denken sie wären unfehlbar sind der Grund für Software voller Bugs:-( no c tomorrow, no sorrow schrieb: > Sorry, ich kann solch eine Denke nicht verstehen. Passt aber zur Zeit: > Probleme verwalten und nicht die Ursachen beseitigen. :-<<< Um das mal auf einen anderen sehr bekannten Sachverhalt zu transponieren, hoffentlich ohne die üblichen Krieger auf den Plan zu rufen und ohne dabei den sachlichen Hintergrund zu bewerten: Im Rahmen von Standards Probleme verwalten hiesse, alle bestehenden Dieselfahrzeuge auf ewig überall zuzulassen. Ursachen beseitigen hiesse, sie streckenweise von der Strasse zu verbannen. Woran man erkennen kann, dass Änderungen, die bestehende Standards über den Haufen werfen, auch nicht alle glücklich machen. Thomas M. schrieb: > Du hast es einfach nicht verstanden..und da es andere > Programmiersprachen wie Pascal /Ada offenbar besser können , wäre es ja > machbar. Dann sollte man diese anderen Programmiersprachen eben auch verwenden. Wobei es dabei natürlich vorteilhaft wäre, eine Programmiersprache zu verwenden, die unabhängig von Macken und Eigenheiten realer Compiler und realer Maschinen definiert und in dieser Form realistisch einsetzbar ist. Was auf Ada zutrifft, auf Pascal aber m.W. nicht. Für einen systematisch korrekten Ansatz einer universelle Sprache muss es eine formale Definition der Sprache geben, an die sich die Compiler zu halten haben. Ebenso wie die Programmierer. Der Ansatz "Compiler X macht es so, also stimmt es" ist systematisch unkorrekt.
Gast
#5764614
no c tomorrow, no sorrow schrieb: > Warum gibt es die Problematik überhaupt und warum wurde das nicht in > C-Standard XYZ abgestellt? [x] Du hast das Wort Standard verstanden. Die M2-Schrauben sind mir zu klein und fehlertraechtig - warum werden die nicht doppelt so gross hergestellt. Altes bestehendes Zeug ist mir Wurst und kann ruhig brechen. leo Alexander M. schrieb: > Back to the roots.... > > Will mir einer vielleicht nochmals kurz erklären, warum ich bei > > uint32_t a = 30000 * 2; 30000 wird als vorzeichenbehaftetet int Wert gerechnet, Wertebereich -32768 bis 32767. Überlauf bei der Multiplikation. > nicht 60000 bekomme, und es bei > > uint32_t a = (uint16_t) 30000 * 2; uint16_t ist vorzeichenlos mit Werten von 0-65535, kein Überlauf bei der Multiplikation. no c tomorrow, no sorrow schrieb: > Falk B. schrieb: >> Und nach über 40 Jahren in der Praxis sollten sich die Ecken und Kanten >> von C herumgesprochen haben und man kann sie praktisch überaus passabel >> umschiffen. > > Aber warum bitte schön kann man die Ecken und Kanten nicht glätten? > Warum quält man Genarationen von Programmieren? Warum erzeugt man > unnötige SW-Fehler, die nur dieser Bastelsprache anzuhängen sind. Schon mal versucht, den Linksverkehr in England, Südafrika, Australien, Japan, Indien und sonstwo abzuschaffen?
Gast
#5764629
A. K. schrieb: > Wobei es dabei natürlich vorteilhaft wäre, eine Programmiersprache zu > verwenden, die unabhängig von Macken und Eigenheiten realer Compiler und > realer Maschinen definiert und in dieser Form realistisch einsetzbar > ist. Dann bist du bei Java. Aber es frisst Resourcen ohne Ende und eignet sich für µC daher nur sehr bedingt. Java sollte alle Altlasten von C/C++ abschaffen, dafür hat es leider mindestens genau so viele neue Probleme geschaffen. Ausserdem dauerte es nach Veröffentlichung der Version 1.0 weitere 10 Jahre, bis die Sprache ernsthaft einsatzbereit wurde. Was diese Integer-Berechnungen angeht verhält sich Java allerdings ziemlich genau so wie C. Aus irgendeinem Grund war man damals wohl sicher, dass so sein muss. x^y schrieb: > Wertebereich von int16 ist von -32768 bis +32767. Nur so nebenbei zur Zerstreuung: Zwar ist der Wertebereich von int16_t als -32768..+32767 definiert, der Wertebereich von int ist aber nur als mindestens -32767..+32767 definiert. Autor: leo (Gast) aha..wo wäre denn die Gefahr wenn dieser Fehler behoben würde?! Die Kompatibilität bliebe ja voll erhalten.... Falk B. schrieb: > Schon mal versucht, den Linksverkehr in England, Südafrika, Australien, > Japan, Indien und sonstwo abzuschaffen? ... oder in Japan einheitlich entweder 50 oder 60 Hz. ;-)
Gast
#5764650
Stefanus F. schrieb: > A. K. schrieb: >> Wobei es dabei natürlich vorteilhaft wäre, eine Programmiersprache zu >> verwenden, die unabhängig von Macken und Eigenheiten realer Compiler und >> realer Maschinen definiert und in dieser Form realistisch einsetzbar >> ist. C ist doch ganz exakt das, was du beschreibst. C ist maschinen- und compilerunabhängig beschrieben - ziemlich bündig und vollständig sogar. Und der C-Standard so formuliert, dass er sich gut auf realen Maschinen umsetzen lässt. Einige Ecken und Kanten stammen ja genau dort her, u.a. die Bitbreiten von Ganzzahlen oder auch die Darstellung vorzeichenbehafteter Zahlen.
Gast
#5764652
Die Technokraten dieses Landes könnten sich auch für die Abschaffung der Sommerzeit stark machen. Das würde mir viel mehr nützen, als dieser Integer Kinderkram. Ich will gar nicht wissen, wie viele Entwickler schon Schande und Stress erleiden mussten, weil wie diese besch***** Uhr-Umstellungen haben. Dagegen hilft auch keine andere Programmiersprache.
Gast
#5764654
Thomas M. schrieb: > Autor: leo (Gast) > aha..wo wäre denn die Gefahr wenn dieser Fehler behoben würde?! > Die Kompatibilität bliebe ja voll erhalten.... Ich denke nicht, dass die Kompatibilität erhalten bliebe. Wo waere dann ein "Fix" des Problems. leo Sven P. schrieb: > Stefanus F. schrieb: >> A. K. schrieb: >>> Wobei es dabei natürlich vorteilhaft wäre, eine Programmiersprache zu >>> verwenden, die unabhängig von Macken und Eigenheiten realer Compiler und >>> realer Maschinen definiert und in dieser Form realistisch einsetzbar >>> ist. > C ist doch ganz exakt das, was du beschreibst. Bitte Kontext beachten. Jenen Kontext, den Stefanus nicht mitzitierte. Mein Beitrag war eine Antwort auf die Vorzüge von Pascal und Ada. In Pascal existiert m.W. keine solche Definition.
Gast
#5764663
Stefanus F. schrieb: > Wenn C ein riesen Problem wäre ... Macht + Verantwortung --->> Disziplin Alternativ: Der Elefant im Porzellanladen Ich empfehle ein schönes dickes und modernes C oder C++ Buch! Und dann Seite für Seite auswendig lernen. Das hilft nicht gegen Fußpilz, aber verschafft einen Überblick. n Pascal und Ada. In Pascal existiert m.W. keine solche Definition. jup, genau deshalb haben sich die Sprachen so gut weiterentwickeln können und sind zu keinem Flickenteppich wie C geworden. Wenn irgendmöglich gibt es in Pascal die alte Variante, um dir Kompatibilität zu erhalten UND die neue. "Ich empfehle ein schönes dickes und modernes C oder C++ Buch! Und dann Seite für Seite auswendig lernen." DARUM geht es!! Macht man aber was falsch.... wenn man keine Fehler macht ist die Zuverlässigkeit der Sprache völlig wumpe!! Aber NUR die User aus diesem Forum sind unfehlbar, es fehlt also an Programmieren! Thomas M. schrieb: > "Ich empfehle ein schönes dickes und modernes C oder C++ Buch! > Und dann Seite für Seite auswendig lernen." > > DARUM geht es!! Jedes Detail auswendig lernen ist ein Weg. Das Wesen zu verstehen, die Grenzen zu kennen, und im konkreten Fall nachzuschlagen, ist ein anderer. > Aber NUR die User aus diesem Forum sind unfehlbar, es fehlt also an > Programmieren! Du meinst also, es mangele an Fachkräften? ;-)
Gast
#5764691
Thomas M. schrieb: > n Pascal und Ada. In > Pascal existiert m.W. keine solche Definition. Genau, mit Ada waere das nicht passiert ... "... Fehler bei der Typumwandlung gekommen. Als von Float nach Integer umgewandelt wurde und der Wert 32.768 erreichte, entstand ein Überlauf.[2] Dieser Überlauf hätte durch die verwendete Programmiersprache Ada eigentlich entdeckt und behandelt werden können. Diese Sicherheitsfunktionalität ließen die Verantwortlichen jedoch abschalten. Der Schaden betrug etwa 370 Millionen US-Dollar." https://de.wikipedia.org/wiki/Liste_von_Programmfehlerbeispielen Tl;dr 370 M$ Fehler. BTW wo sind Pascal und Ada bei der µC-Programmierung, wenn sie denn so gut sind? leo Thomas M. schrieb: > geht unter Pascal fehlerfrei > https://rextester.com/l/pascal_online_compiler Sven P. schrieb: > [x] Du hast das Problem exakt überhaupt nicht verstanden. Oliver in Go hat man sich dem angenommen und so gelöst https://blog.golang.org/constants die implizite Typwandlung integraler Typen in C und C++ ist wirklich ein Misfeature Apropos Pascal: Was kommt bei maxint + maxint und maxint * 2 raus, wenn man es auf der Wirth'schen Referenzmaschine exakt so ohne Optimierung berechnet? teste es
//fpc 3.0.0
program HelloWorld;
Uses sysutils;
var i : Longint;
i_str :String[32];
begin
i := 30000 * 2;
writeln(inttoStr(i));
end.
geht unter Pascal fehlerfrei
https://rextester.com/l/pascal_online_compiler
aber wen interessiert es? Wir reden hier von C aus dem Jahre 2019 und Pascal aus 2019 wen interessiert das Ref. Design aus 1970?!!? Beide Sprachen haben sich wieterentwickelt, falls es dir entgangen ist, Pascal offenbar etwas meh r als C Di Ref von Pascal bzw der Standard ist Delphi nocht PAscal 1.0
Gast
#5764764
Habe getestet:
//fpc 3.0.0
program HelloWorld;
Uses sysutils;
var i : Longint;
a : Shortint;
b : Shortint;
i_str :String[32];
begin
a := 30000;
b := 2;
i := a * b;
writeln(inttoStr(i));
end.
==> 96
Gast
#5764769
Kann es sein, dass die Integer Literale in Pascal einfach einen größeren Typ haben? Laut https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c04619807 table 2-5 ist der Datentyp von Integer Literalen Plattformabhängig.
Gast
#5764782
Jeder Entwickler macht sein Ding ohnehin so wie er/sie/es für richtig hält. Man kann sich also ganz entspannt zurücklehnen, durchatmen und sich einfach die passende Philosophie und Programmiersprache für die eigene Meinung suchen. Eine US Firma die irgendwas im Neuland macht, sagt zur signed/unsigned Geschichte z.B.: https://google.github.io/styleguide/cppguide.html#Integer_Types
Sinngemäß: Vor dem Autofahren nicht zu trinken bedeutet, dass der Spurhalteassistent eine Reihe von Fehlern nicht wahrnimmt. Und betrunken fährt man meistens auch schneller. Das unsigned Typen Optimierung behindern ist im Übrigen sogar Quatsch. Das Gegenteil ist auf den meisten Architekturen ist der Fall. Beispiel: Ein Zero Extend ist in vielen Fällen bei unterschiedlicher Bitbreite unnötig, ein Sign Extent allerdings nicht.
vs
@Stefan(Gast) source.pas(12,9) Warning: range check error while evaluating constants (30000 must be between -128 and 127) Du solltest wenn Du absichtlich sowas machst auch die Fehlermeldung veröffentlichen..
Gast
#5764787
x^y schrieb: > Man kann sich also ganz entspannt zurücklehnen, durchatmen und > sich einfach die passende Philosophie und Programmiersprache für die > eigene Meinung suchen. Diesen Luxus haben die meisten nur im Hobby. Auf der Arbeit bestimmen andere, mit welchen Mitteln gearbeitet wird. und sorry, mein code war fehlerhaft wegen unnötiger Variable..
ic habe dein provokatives Beispiel korrigiert, allerdings verstehe ich
nicht, was das beweise soll, wenn ich absichtlich sowas mache?!
Es geht hier darum wie schnell versehentlich Fehler aufftreten können
//fpc 3.0.0
program HelloWorld;
Uses sysutils;
var i : Longint;
a : Shortint;
b : Shortint;
begin
a := 30000;
b := 2;
i := a * b;
writeln(inttoStr(i));
end.
zum Onlinecompiler
https://rextester.com/l/pascal_online_compiler
Gast
#5764795
Stefanus F. schrieb: > Auf der Arbeit bestimmen > andere, mit welchen Mitteln gearbeitet wird. Dann ist es Masochismus, dagegen angehen zu wollen. So entstehen C-Hasser. x^y schrieb: > Das unsigned Typen Optimierung behindern ist im Übrigen sogar Quatsch. > Das Gegenteil ist auf den meisten Architekturen ist der Fall. Undefiniertes Verhalten gibt dem Compiler mehr Möglichkeiten zur Optimierung, weil er weniger Rücksicht auf korrektes Verhalten nehmen muss. Das gab von einigen Jahren etwas Knatsch, als GCC deutlich offensiver mit diesem Thema umging und kommentarlos mit manch bestehendem nicht sauber definierten C Code in für den Programmierer leicht überraschender Weise umging.
Bei TYPE=int darf der Compiler davon ausgehen, dass die Schleife unabhängig von n exakt 10 Durchläufe hat und kann sie durch sum=10 ersetzen. Bei TYPE=unsigned geht das nicht. Eine Abhandlung zum Overflow-Thema: http://www.cs.utah.edu/~regehr/papers/overflow12.pdf Rufus Τ. F. schrieb: > Berechnungen werden, sofern nicht explizit andere Typen angegeben sind, > mit int durchgeführt. Das heisst, eine Konstante secsperday = 24 60 60 geht krachen, weil der C-Compiler bei int16 hängt, aber secsperday = 86400 geht? Stefanus F. schrieb: > Wenn C ein riesen Problem wäre, würde es kaum genutzt werden, denn es > gibt ja reichlich Alternativen. Neo ist auch effizienter als Qwerty, dennoch bekommst Du die Leute ums Verrecken nicht auf Neo. Weil Querty macht ja jeder. leo schrieb: > Tl;dr 370 M$ Fehler. Weil man eine Software auf einem anderen Gerät als vorgesehen hat laufen lassen. Das liegt dann natürlich an der Programmiersprache. leo schrieb: > wo sind Pascal und Ada bei der µC-Programmierung, wenn sie denn so > gut sind? Die nehmen Leute, die damit mehr als ein paar blinkende LED zum laufen bringen. Die müssen das aber nicht jedem erzählen. Karl K. schrieb: > aber secsperday = 86400 geht? Richtig. Dr. Sommer schrieb: > Rolf M. schrieb: >> Und das, obwohl das grundlegende Konzept von cout eigentlich deutlich >> besser für µCs geeignet ist, als printf. > > Es ist leider nicht so leicht ohne dynamischen Speicher umsetzbar... Genauso leicht oder schwer wie printf, hätt ich gesagt. > Rolf M. schrieb: >> Bei mir kommen sich durchaus öfters vor, nämlich dann, wenn man eine >> Funktion schreiben muss, die ein bestimmtes vordefiniertes Interface >> umsetzt > > Ja, eigentlich nur dann ;-) Klar. no c tomorrow, no sorrow schrieb: > Falk B. schrieb: >> Und nach über 40 Jahren in der Praxis sollten sich die Ecken und Kanten >> von C herumgesprochen haben und man kann sie praktisch überaus passabel >> umschiffen. > > Aber warum bitte schön kann man die Ecken und Kanten nicht glätten? Das ist wie bei einem Sägeblatt. Das kann man auch "ohne Ecken und Kanten" bauen. Die Verletzungsgefahr sinkt dadurch deutlich, aber leider sägt es dann auch nicht mehr sonderlich effektiv. > Sorry, ich kann solch eine Denke nicht verstehen. Passt aber zur Zeit: > Probleme verwalten und nicht die Ursachen beseitigen. :-<<< Die Ursachen sind die verschiedenen Architekturen, auf denen man in der selben Sprache effiziente Programm schreiben können soll. Also müsste man erstmal alle Plattformen bis auf eine abschaffen. Das würde die Zahl der Fallstricke in C enorm reduzieren. x^y schrieb: > Das Programm läuft zwar nicht mehr per Wildpointer Amok, kann > aber trotzdem mit einer unbehandelten Exception und 3 Seiten Stacktrace > abstürzen. Ich muss immer wieder schmunzeln, wenn ein Java-Programm mal wieder mit einer "Nullpointer-Exception" abstürzt, wo die doch immer so stolz drauf sind, dass es da gar keine Pointer gibt, damit niemand einen solchen auf illegale Weise dereferenzieren kann. A. K. schrieb: > Thomas M. schrieb: >> "Ich empfehle ein schönes dickes und modernes C oder C++ Buch! >> Und dann Seite für Seite auswendig lernen." >> >> DARUM geht es!! > > Jedes Detail auswendig lernen ist ein Weg. Das Wesen zu verstehen, die > Grenzen zu kennen, und im konkreten Fall nachzuschlagen, ist ein > anderer. Letzteres scheinen einige hier nicht zu können (oder nicht zu wollen). In so einem Fall bleibt dann nur der erste Weg, oder als Alternative, z.B. Bäcker zu werden. Stefanus F. schrieb: > Auf der Arbeit bestimmen andere, mit welchen Mitteln gearbeitet wird. Kenne ich auch anders. Programmentwickler entscheidet, ob Perl, Java, VB, PHP, ... Ist aber nicht im µC-Bereich. Karl K. schrieb: > Rufus Τ. F. schrieb: >> Berechnungen werden, sofern nicht explizit andere Typen angegeben sind, >> mit int durchgeführt. > > Das heisst, eine Konstante secsperday = 24 60 60 geht krachen, weil > der C-Compiler bei int16 hängt, aber secsperday = 86400 geht? Der Compiler hängt nicht bei int16, sondern int. Auf manchen Plattformen ist int eben nur 16bit breit, wie z.B. bei AVR. Und außerdem gibt der Compiler eine Warnung aus, wenn diese eingeschaltet sind, was man sowieso immer machen sollte.
Gast
#5764912
Rolf M. schrieb: > Die Ursachen sind die verschiedenen Architekturen, auf denen man in der > selben Sprache effiziente Programm schreiben können soll. Eine derartige Argumentation ist heutzutage zu kurz gesprungen. Gerade in C hat es in der Vergangenheit immer wieder heftigste Widerstände gegen jegliche echte Modernisierung gegeben. Das ist der Grund - und deshalb ist auch heute noch immer nicht sauber festgenagelt, wieviele Bits die diversen Integertypen nun ganz genau zu haben haben, weswegen diese unsäglichen uint16_t und Konsorten aufgekommen sind. Kurzum: Effizienz wird im Kopfe des Programmierers durch das Erfinden effizienter Algorithmen erzeugt, Optimierung kann mittlerweile auch der Compiler (und oftmals besser als ihr) und eine Sprache, wo man sich auf Dinge wie festgeschriebene Integergrößen verlassen kann, ist auch besser für effiziente Algorithmen. Und nochwas: Heutzutage wäre es eigentlich nicht zuviel verlangt, daß ein Compiler von sich aus jegliche konstanten Integer-Ausdrücke intern mit erheblicher Bitbreite (von mir aus 256 Bit) berechnet und erst danach schaut, in was für eine Variable das Ganze hineinpassen soll. Anschließend dann die Zuweisung oder Fehlermeldung. Damit wäre den Programmierern wirklich geholfen - egal, ob nun C oder Pascal oder Frust oder sonstwas. Und es wäre auch komplett rückwärtskompatibel. Und man könnte sich sowas wie (unsigned long) oder 4711UL sparen. Aber an eine irgendwann mal erfolgende echte Modernisierung von C glaub ich nicht mehr. W.S. W.S. schrieb: > Heutzutage wäre es eigentlich nicht zuviel verlangt, daß ein Compiler > von sich aus jegliche konstanten Integer-Ausdrücke intern mit > erheblicher Bitbreite (von mir aus 256 Bit) berechnet und erst danach > schaut, in was für eine Variable das Ganze hineinpassen soll. Das ist kompletter Unsinn, denn dann könnte man sich auf nichts mehr verlassen. Code 1:
Code 2:
Wenn der Compiler Code 1 intern mit 256 Bit rechnen würde, kämen für beide Programmteile auf einem AVR unterschiedliche Ergebnisse raus. Die Integer-Promotion ist dokumentiert und Bestandteil der Sprache. Wer sie nicht beherrscht, ist selber schuld. W.S. schrieb: > Heutzutage wäre es eigentlich nicht zuviel verlangt, daß ein Compiler > von sich aus jegliche konstanten Integer-Ausdrücke intern mit > erheblicher Bitbreite (von mir aus 256 Bit) berechnet und erst danach > schaut, in was für eine Variable das Ganze hineinpassen soll. Eine künstliche Begrenzung von 256 Bits wäre unpassend. Hier wurde dieses Prinzip konsequenter gedacht: "As-if Infinitely Ranged Integer Model". https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9019
Gast
#5764926
A. K. schrieb: > TYPE i, n = parameter, sum = 0; > for (i = n; i < n+10; ++i) > sum += 1; > > Bei TYPE=int darf der Compiler davon ausgehen, dass die Schleife > unabhängig von n exakt 10 Durchläufe hat und kann sie durch sum=10 > ersetzen. Bei TYPE=unsigned geht das nicht. Interessantes Beispiel! Danke :) Das ist ein plausibles Beispiel. Ich hatte jetzt mehr auf Maschinenebene als C Ebene gedacht. Ich erinnere mich an zwei Fälle, wo der Compiler auch eine solche "undefined behavior" Optimierung ausgenutzt hat. In beiden waren die "Optimierungen" des Compilers allerdings fatal. Unsere Konsequenz war deshalb im Kodierstandard die Ausnutzung dieses Verhaltens sozusagen als "böse" zu verdammen. Ich werde jetzt nochmal sinnieren ob es Fälle gibt in denen das Verhalten auch positiv wäre. Der Vollständigkeit halber hier der Fall: Der Code stammt aus einem "Startup-Code in C weil Assembler ist doof" und realisiert eine Kopierschleife für Sections (".data" etc). Im Linker Script war eine spezielle Section angelegt, welche alle Kopieroperationen mit Quelle, Ziel und Anzahl Bytes beschrieben hat. Ich kann es hier nur sinngemäß wiedergeben:
Für dieses Beispiel hat der Compiler tatsächlich eine Endlos-Schleife(!) um memcpy() generiert. Das ganze passierte bei der Umstellung des Compilers auf eine neue Version. Nach unserem bestem Wissen war der Compiler dazu berechtigt unter Ausnutzung von "undefined behavior" Optimierungen. Da das Array aus Sicht des Compilers nur ein Element hat, kann er zunächst davon ausgehen, dass ein zweites Element nicht existiert. Man könnte dann denken er dürfte dann soetwas tun aber keine Endlosschleife:
Allerdings durfte er die Schleife ja nicht einfach ignorieren. Es bleibt je soetwas stehen:
Da für i keine Schleifenbedingung besteht, wurde natürlich noch i eingespart. Für den Compiler war nur ein Element erkennbar. Es blieb dann also übrig:
Die Lektion daraus könnte auch lauten: Schreib den Startup Code in Assembler.
Gast
#5764939
x^y schrieb: > Das ist so, damit der Compiler effizienten Code erzeugen kann. Wenn ich hocheffizienten Code will, schreibe ich ihn in Assembler. Da bin ich immer noch mindestens so gut wie der beste existierende C-Compiler, meist aber besser bis sogar sehr deutlich besser, letzteres allerdings oft nur mit "unfairen" Mitteln: ich benutze Eigenheiten des Zielsystems, die der Compiler schlicht (zumindest: noch) nicht kennt. Für den normalen, performance-unkritischen Scheiß will ich aber eine Hochsprache, die einfach das tut, was ich hinschreibe. Das ist, was ich von einer Hochsprache verlangen würde, die diese Bezeichnung tatsächlich verdient. Die darf vom Design her nicht PRIMÄR darauf optimiert sein, das sich der Quelltext zu einem möglichst effizienten Compilat verarbeiten läßt, sondern darauf, dass sie immer etwas möglichst sinnvolles mit den gegebenen Anweisungen anfängt. Eine Hochsprache sollte eine Sprache sein, die es dem Programmierer leicht macht, nicht eine, die es dem Compiler leicht macht. Das sollte der Job einer Hochsprache sein. Will ich das nicht: dann nehme ich Assembler. Bezogen auf Ausdrücke, die ausschließlich aus Literalen bestehen, würde das natürlich bedeuten, dass sie anfangs immer im jeweils kleinstmöglichen Typ dargestellt, aber auch immer automatisch "erweitert" werden. Und natürlich erwarte ich dann auch mindestens eine Warnung, wenn das Ergebnis eines solchen Ausdrucks zugewiesen wird und nicht in den Typ des Zuweisungsziels passt. Zumal dieses Szenario ganz offensichtlich rein garnix mit der Laufzeit-Effizienz zu schaffen hat, denn so ein Ausdruck läßt sich natürlich vollständig zur Compilezeit berechnen. Mehr noch: ich würde dasselbe Verhalten auch für literale Teilausdrücke erwarten. Die Warnung hätte dann zu erfolgen, wenn sie mit einem Term verknüpft werden, der zur Compilezeit einen unbekannten Inhalt (aber natürlich einen bekannten Typ) hat. Das ist definitiv für einen Compiler möglich ohne jeden Impact auf die Laufzeit-Performance. Er kennt den Wert des literalen Ausdrucks, die Grenzen des Typs des zu verknüpfenden Terms und die anzuwendende Operation, er könnte also problemlos zur Compilezeit auf mögliche Probleme hinweisen. Auch wieder: ohne jeden Impact auf die Laufzeit-Performance. Ja, das macht viel mehr Arbeit für die zwei, drei Dutzend Bauer eines Compilers. Aber spart viele Millionen Stunden Arbeitszeit für die Hunderttausende (oder auch Millionen) Benutzer des Compilers. Und verhindert viele Sicherheitslücken... In C/C++ nicht realisiert. Ende, aus, eigentlich untauglich als "Hochsprache". Schlimm nur, dass man diesen Müll trotzdem so oft benutzen muss... Ist C eine Hochsprache? Ich habe hier irgendwo ein Buch da werden PAscal und andere als solche bezeichnet, C aber eher als aufgebohrter Assembler... dazu habe ich gerade das gefunden.. "C gilt im Vergleich zu BASIC oder PASCAL nicht als Hochsprache, sondern wird oft als Sprache "mittlerer Ebene" (middle-level language) eingestuft. " http://c-buch.sommergut.de/Kapitel1/C-im-Vergleich-zu-anderen-Programmiersprachen.shtml Bei D scheint es auch besser gelöst zu sein..nur in C wird gefrickelt https://dlang.org/spec/type.html Hat eine Weile gedauert, aber nun sind wir wieder im gewohnten Fahrwasser. C-Hater ist auf Betriebstemperatur, Thomas hat auch sein Thema gefunden, und die Prügelei kann losgehen. das ist doch Quatsch...im Grunde wissen ja alle das Pascal/Delphi/Lazarus die bessere Sprache ist. Daher gibt es da doch gar keinen Streit;-) hehe So lange das halbwegs beim Thema Datentypen bleibt... Nun läuft es aber in die klassische Grundsatzdiskussion rein, ob man das Ei am dicken oder dünnen Ende aufschlägt. Da kann man auch gleich noch Windows vs Linux mit reinnehmen. W.S. schrieb: > Eine derartige Argumentation ist heutzutage zu kurz gesprungen. Gerade > in C hat es in der Vergangenheit immer wieder heftigste Widerstände > gegen jegliche echte Modernisierung gegeben. Man kann in C genug organisch weiterentwickeln ohne dabei die grundlegende Intension von C über den Haufen zu werfen. Mir würden genug solcher Sachen einfallen. Das sind alles Dinge die Kosten keine Performance und sind Free Lunch und vor allem ändern nichts an der grundlegenden Intension der Sprache. Ich denke die grundlegende Intension von C muss man schon akzeptieren. Wer alles komplett neu, anders und besser(TM) machen will muss seine eigene neue Sprache machen wie es jeder Info Student der was auf sich hält macht. Nur ein Beispiel was man organisch weiterentwickeln kann: Man kann mit Bitfeldern eigentlich sehr schön lesbar Registerzugriffe modellieren. Das ist komfortabl da man Bitpositionen, Bitlängen und mit AND/OR/NOT nichts händisch falsch machen kann. Quasi:
Diese Sache hat nur leider ein paar Schönheitsfehler: - Auch ein "0-bit-writes ignored" Register wird immer ausgelesen, dann das Bit eingefügt und dann zurückgeschrieben. Das wäre aber nicht notwendig. Ein reines Schreiben würde ja genügen. Dies kann man aber nicht ausdrücken. Läßt man volatile weg, entfernt der Compiler womöglich den gesamten Schreibzugriff oder verschiebt ihn munter durch die ganze Funktion. - Man kann mehrere Bitfeldzugriffe nicht kombinieren. Der Zugriff über diese Mechanik ist deshalb sehr ineffizient:
uvm. c-hater schrieb: > Wenn ich hocheffizienten Code will, schreibe ich ihn in Assembler. Da > bin ich immer noch mindestens so gut wie der beste existierende > C-Compiler, meist aber besser bis sogar sehr deutlich besser, letzteres > allerdings oft nur mit "unfairen" Mitteln: ich benutze Eigenheiten des > Zielsystems, die der Compiler schlicht (zumindest: noch) nicht kennt. Da würde ich meine Zweifel insofern anmelden, dass es nur noch mit unfairen Mitteln geht. Ich arbeite mit den neusten GCC Versionen für ARM, die optimieren für normale Funktionen unschlagbar gut. Gerade wenn Funktionen dann noch etwas größer sind steigt man mit händischer Optimierung nicht mehr durch. Und schließlich gibt's noch LTO. Da dreht der Compiler das gesamte Programm mit allen Modulen durch den Optimizer als wäre alles in einer Datei. Kein Mensch hat da eine Chance. Eigentlich ist es ja auch erschöpfend diskutiert..die C Leute verteidigen ihren Kack und schieben auf auf die Unfähigkeit der Nutzer..wie die Atomkraftbetreiber es auch Schicksal schieben oder sowas wenn was passiert. Kommt halt immer nur drauf an wer weiter denkt und bei den C Menschen die nur in ihren 4 Wänden sitzen..naja reicht es auch durch soweit.. Komisch ist das die PAscal, Basic etc Leute kein Problem damit haben das man Fehler ihrer Liebslngssprache kritisiert und in C ist es wie einer Sekte..wenn der Herr(Die Iso Norm) es Dokumentiert hat..dann sei es..es zu kritisieren ist nicht gestattet.. DAS ist das einzige was nervt..jede Sprache hat ihre Vor und NAchteile und manchem wollen es absolut nicht akzeptieren Nee, sowas wäre ja albern. Da würde man sich darüber streiten ob Rohrzange oder Schraubendreher das bessere Werkzeug ist. Es gibt für jedes Werkzeug eben die passende Anwendung.
Gast
#5765004
Thomas M. schrieb: > zu kritisieren ist nicht gestattet.. Schwachfug! Du kannst kritisieren, soviel du willst! Nur glücklicher macht dich das nicht. Und andere auch nicht. An der Realität kratzt es ebenso nicht. Kein Zugewinn zu erwarten! Also kritisiere... "Nur glücklicher macht dich das nicht." wie gesagt.. Akzeptiere die Dinge die du nicht ändern kannst. Der Herrgott wird dir den Weg weisen... Und es gibt die Menschen die Dinge hinterfrage, ansprechen, diskutieren und so vielleicht eine Änderung bewirken..nennt sich aktiv gestalten.. Aber akzeptiert ihr mal...amen Das geht anders: Gib mir die Gelassenheit, Dinge hinzunehmen, die ich nicht ändern kann, den Mut, Dinge zu ändern, die ich ändern kann, und die Weisheit, das eine vom anderen zu unterscheiden. Thomas M. schrieb: > DAS ist das einzige was nervt..jede Sprache hat ihre Vor und NAchteile > und manchem wollen es absolut nicht akzeptieren Das ist aber eine spezielle Eigenheit dieses Forums. So wie man geschlachtet wird, wenn man im dt. Raspberry-Forum Python kritisiert. Ich glaub das liegt daran, dass viele Leute die C* programmieren müssen eigentlich wissen wie scheisse das ist und wo es überall hängt, aber halt nix anderes können oder nix anderes dürfen. Und da werden dann die Unzulänglichkeiten als "muss so" deklariert. Karl K. schrieb: > Ich glaub das liegt daran, dass viele Leute die C* programmieren müssen > eigentlich wissen wie scheisse das ist und wo es überall hängt, aber > halt nix anderes können oder nix anderes dürfen. Oder weil es einfach überall da ist. Es geht oft weder darum, ob es gut ist ob man es mag oder ob man es darf, sondern dass man damit zu Lösungen kommen kann. Ich finde es weder gut, noch mag ich es, aber ich kenne es gut und nutze es wenn es passt - und anderes, wenn es nicht passt. So einfach kann das sein. Ich mache weder Fetisch noch Hassobjekt daraus. Weshalb Leute so viel Emotionen reinstecken kann ich nicht nachvollziehen. Das ist ein Werkzeug, keine Freundin. A. K. schrieb: > Es geht oft weder darum, ob es gut > ist ob man es mag oder ob man es darf, sondern dass man damit zu > Lösungen kommen kann. Aber ein Werkzeug, mit dem es keinen Spass macht zu arbeiten, ist irgendwie auch nervig. Das ist wie der billige Bitsatz aus dem Wühltisch. Ja klar sind da alle möglichen Bits bei, und klar bekommt man damit auch die meisten Schrauben raus und rein. Und irgendwann greift man doch zum besseren Bitsatz, und schon macht das Arbeiten Spass, die Bits greifen, die Schrauben werden nicht mehr ausgenüddelt, und man sucht nicht ständig nach dem einen Bit, der noch gerade so geht. Und dann ärgert man sich allenfalls noch drüber, dass man nicht schon viel eher zum besseren Bitsatz gegriffen hat. Zumal es bei vielen Alternativen zu C nichtmal eine Preisfrage ist wie beim Bitsatz. Karl K. schrieb: > Und irgendwann greift man doch zum besseren Bitsatz, und schon macht das > Arbeiten Spass, So ging es mir, als ich aufhörte, mich mit Pascal zu beschäftigen, und den ersten brauchbaren C-Compiler nutzen konnte. Das war Turbo-C 2.0, mit der exzellenten (deutschsprachigen) Dokumentation von Arne Schäpers. Rufus Τ. F. schrieb: > So ging es mir, als ich aufhörte, mich mit Pascal zu beschäftigen... Wir hatten in der Schule bißchen TurboPascal, fakultativ. Und dann kam im Studium der Prof mit dem puren Pascal. Alles, was in TurboPascal darüber hinausging, war verboten. Das war so ein Krampf - zum Abgewöhnen. Dadurch wurde mir Pascal über Jahre verleidet, und seitdem ich FreePascal entdeckt habe verfluche ich den Prof für die verlorene Zeit. genau das denke ich ist der Punkt! So wird es vielen gehen..viele haben nur die Lehrsprache Pascal kennengelernt und meinen deshalb sie hätten total die Ahnung von Pascal und das es nichts taugt. Aufwendige umfangreiche Prgramme wie der Altium Designer würde aber niemand in der Lehrsprache PAscal schreiben diese sind in Delphi! geschrieben. Wenn jemand von den Vorzügen von apscalredet gilt das für Turbo Pascal ab V6 oder sowas. Und nur die wenigsten die hier gegen Pascal reden, haben wirklich damit gearbeitet..wenn überhaupt mussten sie das gleiche wie Du in der Schule erleiden mit den Uraltversionen von Pascal. Dank Freepascal / Lazarus gibt es auch was für ür die GUI Programmierung am PC wo man für C nur auch den C++ Bulider oder VC++ zurückgreifen könnte als Freeware!
Gast
#5765276
x^y schrieb: > Ich kann es hier nur sinngemäß wiedergeben: Dein Fall scheint mir ein wenig zu seltsam. Kannst Du versuchen, die Originalzeilen zu finden bzw. Das Problem nachzustellen?
Gast
#5765293
Karl K. schrieb: > Ich glaub das liegt daran, dass viele Leute die C* programmieren müssen > eigentlich wissen wie scheisse das ist und wo es überall hängt, aber > halt nix anderes können oder nix anderes dürfen. Und da werden dann die > Unzulänglichkeiten als "muss so" deklariert. Auf der anderen Seite bietet C eine große Angriffsfläche. Ein relativ eindeutiger Standard, der gut untersucht Tausende von bekannten Grenzfällen provoziert, die genüsslich ausgeweidet werden können. Tausende Compiler, deren individuelle Fehler herangezogen werden können. Historisch verschiedene "Default-rechenbreiten" die nativ erlaubt sind. Die Freiheit (oder gar der Default), alle Warnungen zu ignorieren. Bei meinen ersten Schritten in C dachte ich auch: wenn der Compiler weiss, dass hier die falsche klammer-zu ist ("meinten sie }"), warum korrigiert er es nicht gleich. Aber dann bei jeder C-bash-aktiin hier zu hören: * Ja, bei Pascal-A nicht,, aber Pascal-B .... * Bei dieser Sprache mit GC, * Bei dieser Sprache mit dynamischer Speicherverwaltung, * Ich hab so viele Warnungen, ... Nur als Beispiel unused Parameter, auch wenn der Frotho ja anscheinend nicht professionell mit C arbeitet: Frotho schrieb: > bin fast erschlagen worden von unused-parameter Warnings. Das brauche > ich nicht. Jedenfalls nicht bei jedem Compilieren. Wenn ich fertig bin, Wenn ich eine Funktion implementiere,, dann weiss ich doch, welche der vorgegebenen Parameter ich bei dieser Funktion brauche. Das Interface verlangt 7, 3 davon sind nur für Option X, die hier nicht behandelt wird. Also schreib ich doch in die erste Zeile zumindest einen Kommentar, dass Parameter e, f, g obsolete sind. Und statt Kommentar dann lieber (void) e; (void) f; (void) g; Da gibt es zu keinem Zeitpunkt unnütze Warnungen. Im Gegenteil: der Compiler zeigt mir direkt an, dass ich a, b, c und noch nicht verwende.
Gast
#5765297
Karl K. schrieb: > Aber ein Werkzeug, mit dem es keinen Spass macht zu arbeiten, ist > irgendwie auch nervig. Da stimme ich zu. Dieser "Haken" ist allerdings nicht gross genug, um mich zu nerven.
Gast
#5765304
Und nochmal zu Ada und Ariane:
> Dieser Überlauf hätte durch die verwendete Programmiersprache Ada eigentlich
entdeckt und behandelt werden können.
Was ist das immer für ein Blödsinn? Ada hätte gewusst, welcher
Integer-Wert besser gewesen wäre? Z.b. klippen bei 32767? Dann wäre der
Flug korrekt weitergelaufen? Oder Ada hätte den Flug angehalten, eine
Email an die Entwickler verschickt und auf einen Patch gewartet?
Exceptions sind eine tolle Sache, vor allem wenn ein Mensch davor sitzt:
zu wenig Speicher? Besorg welchen, dann geht's weiter. Aber im autonomen
System Antworten auf unvorhergesehene Fehler und Überläufe?
Frotho schrieb: > [16 Seiten Warnungen] > Wenn ich fertig bin, ja, zum optimieren und für QS. > Aber nicht bei jedem Mal, da schwillt mir ja der Kopf. Also mit anderen Worten: Dein Nachfolger soll sich irgendwann mal darum kümmern den von Dir geerbten hässlichen Dreckscode der über Jahre hinweg unkontrolliert vergammeln gelassen wurde endlich mal aufzuräumen und verwendbar zu machen. Dir als gottgleichem Schöpfer der kryptischen Schriften welcher 5cm über dem Boden schwebt können so niedrige Arbeiten wie sauberen Code zu schreiben nicht zugemutet werden sonst würde Dir der wertvolle Kopf explodieren. Dir würd ich Beine machen, alter...
Gast
#5765340
Bernd K. schrieb:
Harsche Kritik
Aber da ist was dran.
Frotho, ich rate Deiner Firma dringend, jemandem die Zeit zu geben, alle
Warnungen zu 100% aufzuräumen und von da an ausschliesslich Code ohne
Warnungen abzuliefern. Das sollte ein hartes Pflicht-Kriterium sein.
Code, der mit Warnungen compiliert, gilt als nicht lieferbar. Wir haben
das bei uns in die Build Scripte integriert. Code mit Warnungen führt
dazu, dass kein Package (*.deb, oder *.zip) gebaut wird.
Der Nutzen überwiegt eindeutig, da bin ich absolut sicher.
Falls dein Chef da anderer Meinung ist, darf er mich gerne mal als
Consulter ausborgen, dann erkläre ich ihm das. Ich habe das schon in
drei Firmen erfolgreich durchgezogen. Schicke mir ggf. eine persönliche
Mail, dann bekommst du die Kontaktdaten meines Arbeitgebers.
Es ist halt abzuwägen ob ich penibel alle halbe stunde und nach jedem Arbeitsschritt alles(Schreibtisch und Werkzeugkiste) aufräume, täglich, wöchentlich, oder nie. Das hängt auch oft vom Zeitdruck ab. Klar das es irgendwann zeit kostet. Spätestens wenn man nichts mehr findet(länger sucht als effektiv arbeitet) oder nicht mehr durchblickt ist der Zeitgewinn der Schlamperei dahin. Spätestens dann ist es auch an der Zeit ein neues Auto zu bestellen und alles neu zu einzusortieren. ;) Also Mittwoch ist es bei mir soweit, dann kommt der neue, der alte hat gut 100Tkm. Namaste Winfried J. schrieb: > Es ist halt abzuwägen ob ich penibel alle halbe stunde und nach jedem > Arbeitsschritt alles(Schreibtisch und Werkzeugkiste) aufräume, täglich, > wöchentlich, oder nie. > > Das hängt auch oft vom Zeitdruck ab. Klar das es irgendwann zeit kostet. > Spätestens wenn man nichts mehr findet(länger sucht als effektiv > arbeitet) oder nicht mehr durchblickt ist der Zeitgewinn der Schlamperei > dahin. Spätestens dann ist es auch an der Zeit ein neues Auto zu > bestellen und alles neu zu einzusortieren. Die schnellste und PREISWERTESTE Art etwas zu tun, ist es gleich richtig zu tun. Nur mal so als Test in MikroPascal PRO for AVR ;-) program test; Var i : Integer; a : Integer; b : Integer; begin a := 30000; b := 2; i := a*b; end. Es kommt für i zuverlässig -5536 OHNE jegliche Compilerwarung raus. weil das nicht Teil dieser Diskussion ist..es geht um die Falle das in C einen Fehler verursacht, was auf den ersten Blick unverständlich ist! Was in Pascal/Delphi, Freepascal/Lazarus PAscal so funktioniert wie man es logisch erwartet gibt in C einen bösen Fehler! Das von dir genannte Beispiel ist aber für jeden sofort ersichtlich,d as es schlicht grob falsch war..klar wäre es gut wenn auch sowas nicht durch den Compiler ginge, aber es ist klar ersichtlich, selbst für nicht C Programmierer
zum Onlinecompiler https://rextester.com/l/pascal_online_compiler A. S. schrieb: > Ada hätte gewusst, welcher > Integer-Wert besser gewesen wäre? Z.b. klippen bei 32767? Dann wäre der > Flug korrekt weitergelaufen? In dem Fall - wenn ich mich recht an dazu Gelesenes erinnere - hätte die Bereichsüberschreitung dazu geführt, dass der Sensorwert als fehlerhaft gekennzeichnet wird und nicht genutzt wird. Der Flug wäre dann ohne diesen Sensorwert weitergegangen, er war redundant. Mache ich bei meiner Heizungssteuerung auch so: Ist ein Temperatursensor nicht verfügbar oder liefert offenbar unplausible Werte (Kabelbruch, Kurzschluss), wird sein Wert als ungültig verworfen und das Programm fährt mit einem Standardwert weiter. Zum Beispiel ohne Aussenfühler wird eben nicht außentemperaturgeführte Heizkurve gefahren, sondern konstante Vorlauftemperatur. Aber lustig ist: Es wird immer wieder dieses Beispiel dafür gebracht, dass Ada ja auch Fehler zulässt. Und dabei geht es in diesem Beispiel nun gerade darum, dass die Fehler mit Ada hätten vermieden werden können. Andererseits werden seit Jahren Mrd durch C-Programme vernichtet... auch sowas verursacht in Pascal einen Fehler
source.pas(13,9) Warning: range check error while evaluating constants (60000 must be between -32768 and 32767) ind D ebenfalls! wenn z.B. als Short definiert..der Int ist dort erheblich größer, zumindest gibt es mit Int keine Fehler
source_file.d(12): Error: cannot implicitly convert expression (60000) of type int to short in C kommt raus.. -5536 Fehlermeldung von C....KEINE! Thomas M. schrieb: > Dank Freepascal / Lazarus gibt es auch was für ür die GUI Programmierung > am PC wo man für C nur auch den C++ Bulider oder VC++ zurückgreifen > könnte als Freeware! Naja, es gibt schon auch noch PureBasic, was eine ordentliche und vor allem schlanke Gui hinbekommt, zumindest unter Windows. Und es gibt Qt, welches auch unter FreePascal geht. Allerdings ist das Signal-Slot-Konzept unter C so nervig, bis ich da die ganzen Slots für meine Gui definiert habe, ist das Programm unter Pascal schon fertig. Qt verwende ich nicht wegen der nervigen Lib-Verwaltung. Ich kann auf einem Kundenrechner nicht mal schnell die Qt-Libs installieren, nur weil mein Terminal die für die Gui braucht. Also ja, FreePascal ist momentan die Sprache der Wahl vom AVR über Raspberry Pi bis Windows.
Gast
#5765490
Thomas M. schrieb: > Das von dir genannte Beispiel ist aber für jeden sofort ersichtlich Auch der ursprüngliche gemeldete Fall in C war zumindest für mich sofort ersichtlich, denn ich habe gelernt, dass Numerische Literale vom Typ Integer sind, solange sie in einen Integer passen. Das ist eine simple Regel, die man sich leicht merken kann. Wer das nicht schafft, ist für den Job als Programmierer ungeeignet. Die anderen, die das als Hobby machen und darüber stolpern, fragen hier nach, bekommen ihre erklärende Antwort, und gut ist. Falk B. schrieb: > Die schnellste und PREISWERTESTE Art etwas zu tun, ist es gleich richtig > zu tun. Richtig, im Feld aber ohne Vorabkenntnis des Fehlers nicht immer realisierbar. Namaste
Gast
#5765496
Karl K. schrieb: > Andererseits werden seit Jahren Mrd durch C-Programme vernichtet... Und es werden noch viel mehr Mrd durch C verdient! Ein bisschen Verschnitt ist immer. Menschen sind unperfekt, daran können wir nicht ändern. Daher sind auch unsere Produkte unperfekt. Wer das nicht akzeptieren kann, hat ein ernsthaftes Problem mit allem.
Gast
#5765499
Karl K. schrieb: > Qt verwende ich nicht wegen der nervigen Lib-Verwaltung. Ich kann auf > einem Kundenrechner nicht mal schnell die Qt-Libs installieren, nur weil > mein Terminal die für die Gui braucht. Liefere sie doch einfach mit, im selben Verzeichnis, wo auch die *.exe liegt. Ich sehe da kein Problem. oder er verzichtet drauf, benutzt Pascal und der Kunde muss abosolut gar nicht installieren...sondern einfach nur benutzen!
Gast
#5765510
Thomas M. schrieb: > oder er verzichtet drauf, benutzt Pascal und der Kunde muss > abosolut gar > nicht installieren...sondern einfach nur benutzen! So ein Quatsch. Es muss immer die Anwendung und ihre Libraries installiert oder zumindest irgendwohin kopiert werden. Wenn du eine Anwendung statisch linkst, sind die Libraries mit in der *.exe Datei drin. Das kann C/C++ allerdings ebenso. "für mich sofort ersichtlich, denn ich habe gelernt, dass Numerische Literale vom Typ " Du hast das Problem nicht verstanden. Es geht darum das Fehler passieren und diese in C unglaublich oft unbemerkt bleiben! Wie auch an den Pascal Beispielen gezeigt, kann man das auch in Pascal schaffen, aber in D wird es schon echt schwer Es geht darum das Menschen Fehler machen! Wenn jemand schreibt "Wer das nicht schafft, ist für den Job als Programmierer ungeeignet." sollte seien Jobwahl noch mal überdenken oder wirklich nur unwichtige Programme schreiben, einem´n mit so einer Einstellung kann man nicht im KFZ Bereich oder Luftfahrt gebrauchen! Stefanus F. schrieb: > Code, der mit Warnungen compiliert, gilt als nicht lieferbar. Praktische Frage: Wie gehst Du mit sowas um? [code Rxbuf[rxwrite] := Char(tchr); // Daten in Rx Buffer Inc(rxwrite); if rxwrite >= Crxlen then begin rxwrite := 0; end;[/code] Ein Ringbuffer für den Uart Empfänger am AVR. Der Schreibzeiger rxwrite ist 1 Byte (uint8), die Buffergröße Crxlen ist 256. Gibt richtig eine Warnung: Unreachable Code. Und die if-Bedingung wird wegoptimiert. Ich will das aber dennoch drinlassen, weil Crxlen auch kleiner als 256 definiert sein kann. Ignorieren, denn der Fehler ist ja offensichtlich nicht relevant? Per #ifdef ausklammern? Der Code ist an der Stelle einfach effizient und würde durch rxwrite als uint16 nur aufgebläht. Thomas M. schrieb: > oder er verzichtet drauf, benutzt Pascal und der Kunde muss abosolut gar > nicht installieren. Oder er lernt, mit seinem Werkzeug umzugehen. Dann muss der Kunde auch bei Verwendung eines C- oder C++-Compilers nichts zusätzlich installieren. Dein Gekreische spiegelt nur Deine Ahnungslosigkeit und Deine Lernresistenz wider. "So ein Quatsch. Es muss immer die Anwendung und ihre Libraries installiert oder zumindest irgendwohin kopiert werden" Quack..starte es doch einfach vom Stick! Aber egal..wir sind damit weg vom Thema "Dein Gekreische spiegelt nur Deine Ahnungslosigkeit und Deine Lernresistenz wider." Aha, und Dieser Satz zeigt mal wieder DEiNE Unfähigkeit schlichtend als Mod zu arbeiten sondern lieber rumtrampeln wie ein Elch in Trudes Shop Und auch für Dich gilt, das gehört nicht mehr zum eigentlichen Thema. Ich wiederhole mich..Du bist hier als Mod offenbar falsch! Deine Aufgabe ist es nicht die Stimmung anzuheizen
Gast
#5765526
Karl K. schrieb: > Ist ein Temperatursensor > nicht verfügbar oder liefert offenbar unplausible Werte (Kabelbruch, > Kurzschluss), wird sein Wert als ungültig verworfen und das Programm > fährt mit einem Standardwert weiter. Zum Beispiel ohne Aussenfühler wird > eben nicht außentemperaturgeführte Heizkurve gefahren, sondern konstante > Vorlauftemperatur. Das ist richtig, und in meinem Fall auch tägliches Brot. Ein Problem wie bei Ariane 5 (https://de.wikipedia.org/wiki/Ariane_V88#Verlauf), also Overflow bei Float nach int wird bei uns praktisch immer explizit behandelt, z.B. durch Clippende Funktionen, weil man nur an genau der Stelle weiss, was man denn wirklich machen will. Mein Problem ist, dass die Verfechter von Exceptions und ADA an jeder Stelle wie selbstverständlich davon ausgehen, dass der Fehler damit adäquat behandelt worden wäre. Ich sehe in der Praxis bei uns dagegen, dass Treiberprogrammierer damit nur ihre Verantwortung abgeben und das nach 3 Folge-Exceptions (bzw. Esdkalierungen) niemand mehr verantwortlich ist, weil "das ja niemand ahnen konnte". Stefanus F. schrieb: > Menschen sind unperfekt, daran können wir nicht > ändern. Ja, das finde ich auch lustig: Wenn man auf die Probleme in C mit Typecast, Bufferüberlauf... hinweist, heisst es ja regelmäßig "Wenn man die Warnungen anschaltet, kann das nicht passieren, der Compiler weist einen darauf hin." Nur passieren diese Fehler ständig, werden von Trojanern ausgenutzt um über zu lange Strings in HTML-Adressen, angehängte Daten an Bilder und Videos... Bufferüberläufe zu provozieren und Schadcode einzuschleusen. Also entweder sind diese Programmierer, denen das passiert zu doof die Compilerwarnungen zu lesen, oder sie sind so überheblich, dass sie glaube sie ignorieren zu können. Sonst würde das ja nicht passieren. Oder?
Gast
#5765529
Thomas M. schrieb: > "Dein Gekreische spiegelt nur Deine Ahnungslosigkeit und Deine > Lernresistenz wider." Kannst du bitte die Zitierfunktion benutzen? Sonst muss man erahnen wen du meinst und man verliert den Überblick leicht. Und es entstehen falsche Zitate, siehe oben... Danke. @Thomas: Auch ein Moderator darf eine Meinung haben, und das muss nicht zwingend eine moderate sein. Dem Forum fehlt aber die Möglichkeit, auch mal ohne "Moderator" Schild auftreten zu können. er darf eine Meinung haben, aber wie er diese Äußert sollte wohl überlegt sein, da der Ton bislang eigentlich erträglich war und von recht wenigen provokationen. Aber er ist mal ieder ein Paradebeispiel wie man es NICHT macht!! Sonst ist logisch, das sich der Angegriffene rechtfertig und die ganze Diskussion aus dem Ruder läuft..sollte man als fähiger Mod wissen..wenn er aber so in C porgrammiert wie er hier moderieert..na danke,...
Gast
#5765540
Karl K. schrieb: > Praktische Frage: Wie gehst Du mit sowas um? Das macht man in C so:
Wo ist jetzt dein Problem mit "unreachable code"? Stefanus F. schrieb: > Wenn du eine > Anwendung statisch linkst, sind die Libraries mit in der *.exe Datei > drin. Das kann C/C++ allerdings ebenso. Ja, aber bei Qt darfst Du das halt nicht, wenn Du die GPL beachtest. Zumindest hab ich das so verstanden, als ich mir das damals angeschaut habe. Da muss die Qt-Lib dynamisch gelinkt und immer mitgeliefert werden oder auf dem System installiert sein. Stefanus F. schrieb: > Liefere sie doch einfach mit, im selben Verzeichnis, wo auch die *.exe > liegt. Ich sehe da kein Problem. Die exe war in dem Fall ein Uart-Terminal, welches aus einer einzigen exe besteht und vom Stick läuft, ohne irgendwas am System zu verändern. Und wenn man dann vergisst die Qt-Lib mit auf den Stick zu kopieren... sucht man halt erstmal das gute alte BrayTerm raus. Da Qt nicht zwingend erforderlich ist, geht es ohne einfacher. Dein Beispiel ist ja logisch, sinnvoll udn wohl auch üblich..nicht nur in C aber diese Konstrukt wendet man nicht für jeden Firlefanz an, und dann passiert eben so ein Fehler
Gast
#5765545
Karl K. schrieb: > Ja, aber bei Qt darfst Du das halt nicht, wenn Du die GPL beachtest. Richtig. Na und? Es ging darum, die Sprache bzw die Funktionalität des Frameworks zu kritisieren. Jetzt sind wir beim Lizenzmodell angekommen. C ist also kacke weil Qt ohne Lizenzkosten nur dynamisch gelinkt werden darf. Ernsthaft? > Und wenn man dann vergisst die Qt-Lib mit auf den Stick zu kopieren... Und wenn man vergisst zu atmen, bekommt man keine Luft mehr. Stefanus F. schrieb: > Wo ist jetzt dein Problem mit "unreachable code"? Ja Kunststück, wenn ich rxwrite als uint16 definiere geht das in Pascal auch. Ich bin aber auf dem AVR = 8-Bitter und hätte rxwrite gern als uint8. Für alle Crxlen < 256 wird rxwrite in der if genullt, für Crxlen läuft rxwrite von alleine um. Es ist ja nicht allein, dass uint16 ein Byte mehr im SRAM benötigt, alle Vergleiche und Berechnungen werden dann auch mit 16bit statt 8bit durchgeführt. Uuund: Ich müsste es kapseln, weil ein 2-Byte Zugriff durch den Interrupt unterbrochen werden kann.
Gast
#5765556
Karl K. schrieb: > Stefanus F. schrieb: >> Code, der mit Warnungen compiliert, gilt als nicht lieferbar. > > Praktische Frage: Wie gehst Du mit sowas um? > >
> > Ein Ringbuffer für den Uart Empfänger am AVR. Der Schreibzeiger rxwrite > ist 1 Byte (uint8), die Buffergröße Crxlen ist 256. Gibt richtig eine > Warnung: Unreachable Code. Und die if-Bedingung wird wegoptimiert. > > Ich will das aber dennoch drinlassen, weil Crxlen auch kleiner als 256 > definiert sein kann. > > Ignorieren, denn der Fehler ist ja offensichtlich nicht relevant? Per > #ifdef ausklammern? > > Der Code ist an der Stelle einfach effizient und würde durch rxwrite als > uint16 nur aufgebläht. Ja, das ist ein echtes Problem. Und ja, für solche Fälle haben wir nur schlechte Workarounds, #ifdefs oder Warnung lokal ausschalten. Gut, wir würden sowas in einem "spezielles" Inc verstecken, aber so wie oben, bleibt es ein Dilemma. Schaltest Du die Warnung aus, dann warnt der Compiler auch nicht, wenn ein hinzugefügter "Überlaufzähler" auch nicht incrementiert wird. Oder eine Toggle-LED zur Diagnose. Und #ifdef für den Code wäre noch übler, da redundant (unwartbar). Stefanus F. schrieb: > C ist also > kacke weil Qt ohne Lizenzkosten nur dynamisch gelinkt werden darf. Das hast Du jetzt behauptet. Ich habe nur geschrieben, dass ich Qt aus diesem Grund - und weil ich es nicht brauche - nicht verwende. Auch unter Pascal, denn da besteht genau das gleiche Problem, dass man die Qt-Libs braucht, wenn die Exe laufen soll. wieso landen solche Diskussionen eigentlich immer unter in Offtopic?
Gast
#5765634
Karl K. schrieb: > Ich bin aber auf dem AVR = 8-Bitter und hätte rxwrite gern als uint8. Na und? Mach das doch mal. Auch dann bekommst du keine unerwünschte Warnung. Ich hab's gerade versucht. Ich habe das Gefühl, dass du über Arbeitsmittel herziehst, die du gar nicht kennst.
Angehängte Dateien:
"Ich habe das Gefühl, dass du über Arbeitsmittel herziehst, die du gar nicht kennst." Du meinst wie die C Leute bei Pascal Delphi Lazarus? Die ja nur die Schulversion 1.0 kennen? Deshalb versucht man ja sachlich zu diskutieren um sich auszutauschen
Gast
#5765650
Thomas M. schrieb: > Du meinst wie die C Leute bei Pascal Delphi Lazarus? Ich kenne jedenfalls die Schulversion von Pascal, sowie Borland Pascal mit Turbo Vision und Delphi bis Windows 98. So ganz im dunklen tappe ich also nicht. Ich habe im Übrigen nicht über Pascal gemeckert. Stefanus F. schrieb: > Ich habe das Gefühl, dass du über Arbeitsmittel herziehst, die du gar > nicht kennst. Bist Du irgendwo falsch abgebogen? Es geht bei meiner Frage überhaupt nicht um C oder ob C das hier besser macht. Ich habe lediglich auf die Aussage "Projekte müssen ohne Warnungen kompilieren" gefragt, wie man mit so einem Fall umgeht. Weil ich genau der Meinung bin und gern diese Warnung weg hätte, ohne die Variablen von 8 auf 16 Bit aufzublasen. Das hat überhaupt nichts damit zu tun, ob C das besser kann. Und wenn Du mal in das Kompilat schaust, wirst Du merken, dass C hier einfach die if-Abfrage wegoptimiert, weil unreachable code. Pascal optimiert die if-Abfrage auch weg, weil unreachable code. In beiden Fällen richtig, nur das Pascal halt die Warnung schmeisst, die ich gern weg hätte. Periphär würde mich jetzt interessieren, warum C an der Stelle nicht warnt. Aber das war nicht Grund meiner Frage. Statt hier eure Zeit mit dem Streit um Kaisers Bart zu verplempern, könntet ihr euch auch in C einarbeiten - davon habt ihr auf Dauer sicherlich mehr…
Gast
#5765701
Karl K. schrieb: > Ich habe lediglich auf die Aussage "Projekte müssen ohne Warnungen > kompilieren" gefragt, wie man mit so einem Fall umgeht. > Weil ich ... gern diese Warnung weg hätte Da kommt doch jetzt schon keine Warnung! > dass C hier einfach die if-Abfrage wegoptimiert, weil unreachable code. Das ist auch gut so. Ich verstehe nicht, warum du diese Eigenschaft des Compilers jetzt plötzlich bemängelst. Wenn der Code durch andere Puffergrösse erreichbar gemacht wird, wird auch nichts weg optimiert. > Periphär würde mich jetzt interessieren, warum > C an der Stelle nicht warnt. Weil es dort nichts zu warnen gibt. An dem Code ist überhaupt nichts fragwürdiges. Wenn du erweiterte Warnungen für Stellen haben möchtest, wo der Programmierer eventuell etwas übersehen hat, dann benutze lint. In vielen Entwicklungsumgebungen ist dieses Tool bereits standardmässig integriert und aktiv. Zum Beispiel in Qt. > Periphär würde mich jetzt interessieren, warum C an der Stelle nicht > warnt. Aber das war nicht Grund meiner Frage. kann es sein, dass dir der Unterschied zwischen der Sprache und der Implementierung der Sprache nicht klar ist? meines Wissens schreibt der Standard nicht vor, wann welche Warnung auszugeben ist. Die Implementierungen stehen bei Warnungen in Konkurenz zueinander, möglichst gute und verständliche Warnungen zu geben Stefanus F. schrieb: > Da kommt doch jetzt schon keine Warnung! Auch wenn es anscheinend über Deinen Horizont geht: ES GEHT NICHT UM C! Es gibt auch noch andere Sprachen auf der Welt.
Gast
#5765757
Diskutiere mal mit dem TO, um welche Programmiersprache es hier geht. Stefanus F. schrieb: > Diskutiere mal mit dem TO, um welche Programmiersprache es hier geht. Dann bleib halt in Deiner kleinen C-Welt. NMP. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
