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.
1
voidsetup(){
2
Serial.begin(9600);
3
4
uint32_ti=30000*2;// Das ergibt keine 60000, sondern 4294934528
5
Serial.println(i);
6
7
uint32_ti=30000*2L;// Das ergibt 60000
8
Serial.println(i);
9
}
10
11
voidloop(){
12
}
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?
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.
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.
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.
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...
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!
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.
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.
1
uint32_ti=30000L*2;
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.
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 ^^
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 ^^
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.
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?
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!
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.
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.
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 ....
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.
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.
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.
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
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.
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.
> 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?
1
uint16_tx=3.3*1000;
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.
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.
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).
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
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.
A. K. schrieb:> Weil durch %u ein implizites> printf("%u\n", (unsigned)x);> drin steckt.
unsigned habe ich jetzt weggelasen.
1
int32_tx=(int16_t)30000*(int16_t)2;
2
printf("%d\n",x);
Und wieder kommt das richtige Ergebnis raus.
Falk B. schrieb:> Nö. 16 Bit * 16 Bit sind 32 Bit.
1
size_tsize=sizeof((int16_t)30000*(int16_t)2);
2
printf("x: %zd\n",size);
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).
> 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
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.
> 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.
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 ;)
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.
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.
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.
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
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. :-<<<
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
1
intfunktion(intparm1,intunbenutzt){
2
(void)unbenutzt;
3
...
4
}
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.
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.
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
1
int f(int n)
2
{
3
return 1 << n;
4
}
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
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.
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.
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.
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:
1
externint
2
my_printf(void*my_object,constchar*my_format,...)
3
__attribute__((format(printf,2,3)));
> 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.
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..
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..
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.
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
1
uint32_t f(uint32_t n)
2
{
3
if (n >= 32U)
4
return 0U;
5
return 1U << n;
6
}
b) Signed
1
int32_t f(int32_t n)
2
{
3
if ((n < 0) || (n >= 32))
4
return 0;
5
if (n == 31) /* shift 1 into sign bit */
6
return INT32_MIN;
7
return 1 << n;
8
}
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.
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?
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. :-<<<
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!") ...
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?
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:
1
uint32_t i = 30000 * 2;
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!
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.
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.
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.
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.
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?
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.
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. ;-)
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.
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.
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.
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? ;-)
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
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
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
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
1
The fact that unsigned arithmetic doesn't model the behavior of a simple integer, but is instead defined by the standard to model modular arithmetic (wrapping around on overflow/underflow), means that a significant class of bugs cannot be diagnosed by the compiler. In other cases, the defined behavior impedes optimization.
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.
@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..
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
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.
1
TYPEi,n=parameter,sum=0;
2
for(i=n;i<n+10;++i)
3
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.
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.
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.
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:
1
uint32_ti=30000*2;
Code 2:
1
inta=30000;
2
intb=2;
3
uint32_ti=a*b;
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
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:
1
struct SEC
2
{
3
const void* src;
4
void* trg;
5
size_t size;
6
};
7
// defined in linker script pointing to start of special section
8
extern struct SEC table[1];
9
10
void process(void)
11
{
12
int i;
13
for (i = 0; (table[i].src != NULL) && (table[i].trg != NULL); ++i)
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:
1
void process(void)
2
{
3
if ((table[0].src != NULL) && (table[0].trg != NULL))
Allerdings durfte er die Schleife ja nicht einfach ignorieren. Es bleibt
je soetwas stehen:
1
for (i = 0; ; ++i)
2
// something
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:
1
void process(void)
2
{
3
if ((table[0].src != NULL) && (table[0].trg != NULL))
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...
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.
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:
1
if (UART_S.bit.TXOF)
2
UART_S.bit.TXOF = 1; // clear overflow
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:
1
UART_S.bit.TXOF = 1;
2
UART_S.bit.RXOF = 1;
1
; load UART_S
2
; insert bit TXOF
3
; write-back UART_S
4
; load UART_S
5
; insert bit RXOF
6
; write-back UART_S
7
[code]
8
9
Soetwas in der Art wäre wünschenswert:
10
11
[code]
12
UART_S.bit.{.RXOF = 1, .TXOF = 1};
1
; load UART_S
2
; insert bit RXOF and TXOF
3
; write-back UART_S
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.
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!
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?
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.
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.
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...
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
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...
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
1
i=30000*2;
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.
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
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.
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.
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
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?
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,...
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
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.
Karl K. schrieb:> Stefanus F. schrieb:>> Code, der mit Warnungen compiliert, gilt als nicht lieferbar.>> Praktische Frage: Wie gehst Du mit sowas um?>>
1
Rxbuf[rxwrite] := Char(tchr); // Daten in Rx Buffer
2
> Inc(rxwrite);
3
> if rxwrite >= Crxlen then begin
4
> rxwrite := 0;
5
> end;
>> 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.
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.
"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
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.
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.
Thread beobachten
Seitenaufteilung abschalten