mikrocontroller.net

Forum: Offtopic [C] Böse Falle: Datentyp korrekt angegeben, falscher verwendet


Autor: 60000 (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.
void setup() {
  Serial.begin(9600);

  uint32_t i = 30000 * 2; // Das ergibt keine 60000, sondern 4294934528
  Serial.println(i);

  uint32_t i = 30000 * 2L; // Das ergibt 60000
  Serial.println(i);
}

void loop() {
}

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?

: Verschoben durch Moderator
Autor: 60000 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: 2⁵ (Gast)
Datum:

Bewertung
9 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
-31 lesenswert
nicht lesenswert
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...

Autor: Doris (Gast)
Datum:

Bewertung
-13 lesenswert
nicht lesenswert
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!

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Markus Roge (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
c-hater schrieb:
> BEVOR man es wagt, diese hochgefährlichen Sprachen zu
> benutzen

Welche Sprache nutzt du eigentlich? Nur Assembler?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Falk B. (falk)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.
uint32_t i = 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.

Autor: Frotho (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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 ^^

Autor: Veit D. (devil-elec)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

immerhin warnt die Arduino IDE vorm drohenden Overflow, sofern man die 
Warnungen einschaltet.

Ansonsten schreib das meinetwegen so.
uint32_t b = 30000; 
uint32_t c = b * 2; 
Serial.println(c);

Autor: Frotho (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Falk B. schrieb:

>
> uint32_t i = 30000L * 2;
> 
>
> Und schon geht's.
uint32_t i = 30000 * 2L;

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 ^^

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Frotho (Gast)
Datum:

Bewertung
-11 lesenswert
nicht lesenswert
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?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Falk B. (falk)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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!
uint32_t i = (uint32_t)30000 * 2;

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Frotho (Gast)
Datum:

Bewertung
-10 lesenswert
nicht lesenswert
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 ....

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: M.K. B. (mkbit)
Datum:

Bewertung
8 lesenswert
nicht lesenswert
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.

Autor: Frotho (Gast)
Datum:

Bewertung
-8 lesenswert
nicht lesenswert
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 ;-)

Autor: A. K. (prx)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
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.

Autor: Frotho (Gast)
Datum:

Bewertung
-18 lesenswert
nicht lesenswert
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

Autor: Frotho (Gast)
Datum:

Bewertung
-9 lesenswert
nicht lesenswert
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.

Autor: Jemand (Gast)
Datum:

Bewertung
12 lesenswert
nicht lesenswert
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.

Autor: foobar (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
> 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?
uint16_t x = 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.

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: M.K. B. (mkbit)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: zitter_ned_aso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum bekomme ich hier (auf meinem PC) trotzdem das richtige Ergebnis?
uint32_t x = (int16_t)30000*(int16_t)2;
printf("%u\n", x);

int16 mal int16 musste doch vom Typ her auch int16 ergeben? (und somit 
das falsche Ergebnis)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk B. (falk)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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)

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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).

: Bearbeitet durch User
Autor: leo (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: A. S. (achs)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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.

Autor: zitter_ned_aso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Weil durch %u ein implizites
>   printf("%u\n", (unsigned)x);
> drin steckt.

unsigned habe ich jetzt weggelasen.
int32_t x = (int16_t)30000*(int16_t)2;
printf("%d\n", x);

Und wieder kommt das richtige Ergebnis raus.

Falk B. schrieb:
> Nö. 16 Bit * 16 Bit sind 32 Bit.
size_t size  = sizeof((int16_t)30000*(int16_t)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).

Autor: foobar (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
> 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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frotho (Gast)
Datum:

Bewertung
-8 lesenswert
nicht lesenswert
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).

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: zitter_ned_aso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
foobar schrieb:
> Weil in C alle Berechnungen in mindestens int-Größe stattfinden

Ja, jetzt klingelt's. Danke!

Autor: foobar (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
> 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.

Autor: Frotho (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 ;)

Autor: Frotho (Gast)
Datum:

Bewertung
-10 lesenswert
nicht lesenswert
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.

Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
$ cat x.c
#include <stdio.h>
int main()
{
  int a = 10;
  printf("%f\n", a);
}
$ gcc x.c && ./x.out
x.c: In function main:
x.c:5:12: warning: format %f expects argument of type double, but argument 2 has type int [-Wformat=]
   printf("%f\n", a);
           ~^
           %d
Also wohl veraltet oder theoretisch.

leo

Autor: Frotho (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wie dem auch sei, jeder wie er mag. Die Diskussionsbeteiligung sagt 
jedenfalls, dass das Thema nicht ganz unnütz gewesen sein kann.

Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: no c tomorrow, no sorrow (Gast)
Datum:

Bewertung
-8 lesenswert
nicht lesenswert
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. :-<<<

Autor: Wilma Streit (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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! ;-)

Autor: Carl D. (jcw2)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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
int funktion( int parm1, int unbenutzt) {
       (void)unbenutzt;
  ...
}
mitteilen kann, daß das mit Wissen und Absicht passiert.

Autor: Dumdi D. (dumdidum)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Frotho schrieb:
> unused-Parameter. Warum soll ich mir da einen Kopf machen

Weil das auch ein Hinweis auf einen Fehler sein kann. Beispiel:
double reduceBillingAmount(double amount, double reduceBy)
{
  return amount-amount;
}

Hier bekommst du so eine Fehermeldung und das ist auch gut so, weil 
deine Firma sonst nach dem Deployment dieser Software pleite geht.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
A. K. schrieb:
> printf()
> GCC tut dem Programmierer den Gefallen, Formatstring und Parameter
> gegenzuchecken.

Wenn man sich eine ähnliche Funktion selbst schreibt, hat man diese 
Kontrolle leider nicht.

Beitrag #5764267 wurde von einem Moderator gelöscht.
Autor: x^y (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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
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

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.
#define APSR_N_Pos   31U 
#define APSR_N_Msk   (1UL << APSR_N_Pos)   

Nach deiner Erklärung ergibt es absolut Sinn!

Autor: x^y (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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:
extern int
my_printf (void *my_object, const char *my_format, ...)
      __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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß 😉

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk B. (falk)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-8 lesenswert
nicht lesenswert
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..

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-7 lesenswert
nicht lesenswert
Q"Aber immerhin: es ist penibel und umfassend dokumentiert, was sie
tatsächlich machen."

heheh..ja genauso...:-) Alles in C ist dokumentiert..nur das es totaler 
murks ist haben sie vergessen im Klartext zu schreiben :-)

Und manche erkennen nur das was geschrieben steht..jedes C Buch sollte 
damit anfangen das C ein riesen Problem ist..

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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!

: Bearbeitet durch User
Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: x^y (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
uint32_t f(uint32_t n)
{
   if (n >= 32U)
      return 0U;
   return 1U << n;
}

b) Signed
int32_t f(int32_t n)
{
   if ((n < 0) || (n >= 32))
      return 0;
   if (n == 31) /* shift 1 into sign bit */
      return INT32_MIN;
   return 1 << n;
}


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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
//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

Autor: Alexander M. (a_lexander)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: no c tomorrow, no sorrow (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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. :-<<<

Autor: x^y (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!") ...

Autor: no c tomorrow, no sorrow (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Emil (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Signed und unsigned

Autor: x^y (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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:
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!

Autor: x^y (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
x^y schrieb:
> Das Ergebnis von 60000 * 2 hängt

30000 * 2

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alexander M. (a_lexander)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Okay habs (glaub) verstanden...

"Standard":
30000 * 2   --> int16_t * int16_6 => int16_t

Typcast uint16_t:
(uint16_t) 30000 * 2  --> uint16_t * int16_t => uint16_t

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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.

Autor: Alexander M. (a_lexander)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Es kann so einfach sein ;) ...
Danke!

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: x^y (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:-(

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
x^y schrieb:
> Wertebereich von int16 ist von -32768 bis +32767.

Nur so nebenbei zur Zerstreuung: Zwar ist der Wertebereich von int16_t 
als -32768..+32767 definiert, der Wertebereich von int ist aber nur als 
mindestens -32767..+32767 definiert.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autor: leo (Gast)
aha..wo wäre denn die Gefahr wenn dieser Fehler behoben würde?!
Die Kompatibilität bliebe ja voll erhalten....

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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. ;-)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: leo (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
"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!

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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? ;-)

: Bearbeitet durch User
Autor: leo (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Oliver S. (oliverso)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas M. schrieb:
> geht unter Pascal fehlerfrei
> https://rextester.com/l/pascal_online_compiler

Sven P. schrieb:
> [x] Du hast das Problem exakt überhaupt nicht verstanden.


Oliver

: Bearbeitet durch User
Autor: Daniel -. (root)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Apropos Pascal: Was kommt bei
  maxint + maxint
und
  maxint * 2
raus, wenn man es auf der Wirth'schen Referenzmaschine exakt so ohne 
Optimierung berechnet?

: Bearbeitet durch User
Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Stefan (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann es sein, dass die Integer Literale in Pascal einfach einen größeren 
Typ haben?

Laut 
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c04619807 
table 2-5 ist der Datentyp von Integer Literalen Plattformabhängig.

: Bearbeitet durch User
Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: x^y (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
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.
// r0+r1: int32 + *int16
ldrh r0, [r2]
sxth r0, r0
add r0, r1

vs
// r0+r1: uint32 + *uint16
ldrh r0, [r2]
add r0, r1

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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..

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Abhandlung zum Overflow-Thema:
http://www.cs.utah.edu/~regehr/papers/overflow12.pdf

: Bearbeitet durch User
Autor: Karl K. (karl2go)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> aber secsperday = 86400 geht?

Richtig.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex D. (daum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
    uint32_t i = 30000 * 2;

Code 2:
    int a = 30000;
    int b = 2;
    uint32_t i = 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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: x^y (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
struct SEC
{
   const void* src;
   void* trg;
   size_t size;
};
// defined in linker script pointing to start of special section
extern struct SEC table[1];

void process(void)
{
   int i;
   for (i = 0; (table[i].src != NULL) && (table[i].trg != NULL); ++i)
      memcpy(table[i].trg, table[i].src, table[i].size);
}

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:
void process(void)
{
   if ((table[0].src != NULL) && (table[0].trg != NULL))
      memcpy(table[0].trg, table[0].src, table[0].size);
}

Allerdings durfte er die Schleife ja nicht einfach ignorieren. Es bleibt 
je soetwas stehen:
for (i = 0; ; ++i)
   // 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:
void process(void)
{
   if ((table[0].src != NULL) && (table[0].trg != NULL))
      for (;;)
         memcpy(table[0].trg, table[0].src, table[0].size);
}

Die Lektion daraus könnte auch lauten: Schreib den Startup Code in 
Assembler.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist C eine Hochsprache? Ich habe hier irgendwo ein Buch da werden PAscal 
und andere als solche bezeichnet, C aber eher als aufgebohrter 
Assembler...

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
dazu habe ich gerade das gefunden..
"C gilt im Vergleich zu BASIC oder PASCAL nicht als Hochsprache, sondern 
wird oft als Sprache "mittlerer Ebene" (middle-level language) 
eingestuft. "

http://c-buch.sommergut.de/Kapitel1/C-im-Vergleich-zu-anderen-Programmiersprachen.shtml


Bei D scheint es auch besser gelöst zu sein..nur in C wird gefrickelt
https://dlang.org/spec/type.html

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das ist doch Quatsch...im Grunde wissen ja alle das 
Pascal/Delphi/Lazarus  die bessere Sprache ist.
Daher gibt es da doch gar keinen Streit;-) hehe

Autor: A. K. (prx)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: K. S. (x_y)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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:
if (UART_S.bit.TXOF)
   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:
UART_S.bit.TXOF = 1;
UART_S.bit.RXOF = 1;
; load UART_S
; insert bit TXOF
; write-back UART_S
; load UART_S
; insert bit RXOF
; write-back UART_S
[code]

Soetwas in der Art wäre wünschenswert:

[code]
UART_S.bit.{.RXOF = 1, .TXOF = 1};
; load UART_S
; insert bit RXOF and TXOF
; 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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: K. S. (x_y)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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...

: Bearbeitet durch User
Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. S. (achs)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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...

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Falk B. (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
//fpc 3.0.0

program HelloWorld;
Uses sysutils;

var i : Longint;
    a : Integer;
    b : Integer;
    
begin
   a := 30000;
   b := 2;
   i := a * b;

    writeln(inttoStr(i));
end.

zum Onlinecompiler
https://rextester.com/l/pascal_online_compiler

: Bearbeitet durch User
Autor: Karl K. (karl2go)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
auch sowas verursacht in Pascal einen Fehler
  i := (30000 * 2);
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
    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!

: Bearbeitet durch User
Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
oder er verzichtet drauf, benutzt Pascal und der Kunde muss abosolut gar 
nicht installieren...sondern einfach nur benutzen!

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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!

Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

: Bearbeitet durch User
Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Oliver P. (opora)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@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.

: Bearbeitet durch User
Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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,...

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Praktische Frage: Wie gehst Du mit sowas um?

Das macht man in C so:
#define CRXLEN 256
char rxbuf[CRXLEN];
int rxwrite=0;

void writeToBuf(char c)
{
    rxbuf[rxwrite++]=c;
    if (rxwrite>=CRXLEN)
    {
        rxwrite=0;
    }
}

Wo ist jetzt dein Problem mit "unreachable code"?

Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. S. (achs)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Karl K. schrieb:
> Stefanus F. schrieb:
>> Code, der mit Warnungen compiliert, gilt als nicht lieferbar.
>
> Praktische Frage: Wie gehst Du mit sowas um?
>
>
    Rxbuf[rxwrite] := Char(tchr);  // Daten in Rx Buffer
>     Inc(rxwrite);
>     if rxwrite >= Crxlen then begin
>       rxwrite := 0;
>     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).

Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
wieso landen solche Diskussionen eigentlich immer unter in Offtopic?

Autor: Stefanus F. (stefanus)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
"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

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu U. (uhu)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Statt hier eure Zeit mit dem Streit um Kaisers Bart zu verplempern, 
könntet ihr euch auch in C einarbeiten - davon habt ihr auf Dauer 
sicherlich mehr…

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Daniel -. (root)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> 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

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diskutiere mal mit dem TO, um welche Programmiersprache es hier geht.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Diskutiere mal mit dem TO, um welche Programmiersprache es hier geht.

Dann bleib halt in Deiner kleinen C-Welt. NMP.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Dann bleib halt in Deiner kleinen C-Welt. NMP.

C füllt in meiner Welt nur einen winzig kleinen Teil aus. Ich arbeite 
ganz woanders und ich habe viele Programmiersprachen kommerziell 
eingesetzt. Da war lange Zeit auch dein geliebtes Pascal bei.

Ich liebe inzwischen eine Frau.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ich liebe inzwischen eine Frau.

Damit hast Du diese reichlich überflüssige Diskussion eigentlich sehr, 
sehr schön auf den Punkt gebracht.

Menschen sind viel wichtiger als Programmiersprachen.

Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Thomas M. schrieb:
> wieso landen solche Diskussionen eigentlich immer unter in Offtopic?

Um c-hater kalt zu stellen.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> 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.

Darfst du schon. Dein Programm muss dann halt auch unter GPL stehen, 
oder du musst eine kommerzielle Lizenz kaufen.

> 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.

Ich sehe jetzt nicht, wo das Problem liegt, wenn in dem Verzeichnis 
neben dem Programm noch ein paar Libs liegen.

Stefanus F. schrieb:
> Diskutiere mal mit dem TO, um welche Programmiersprache es hier geht.

Der Betreff beginnt mit dem Namen der Sprache, um die es geht.

Rufus Τ. F. schrieb:
> Stefanus F. schrieb:
>> Ich liebe inzwischen eine Frau.
>
> Damit hast Du diese reichlich überflüssige Diskussion eigentlich sehr,
> sehr schön auf den Punkt gebracht.
>
> Menschen sind viel wichtiger als Programmiersprachen.

Allerdings ist ist der Zweck dieses Forums nicht die Diskussion über 
Menschen.

: Bearbeitet durch User
Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
findet eigentlich noch jemand das jemand mal den Mod melden sollte?!
Wieso landet so ein Thema bitte in Forum: Offtopic??
Die Kompetenz als Moderator sollte hier doch stark angezweifelt 
werden...

Autor: Karl K. (karl2go)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Thomas M. schrieb:
> Die Kompetenz als Moderator sollte hier doch stark angezweifelt
> werden...

Lass mich raten: Du bist neu hier im Forum?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Thomas M. schrieb:
> findet eigentlich noch jemand das jemand mal den Mod melden sollte?

Was denkst du, wer den Thread dorthin verschoben hat? Die mutmassliche 
Begründung wurde auch schon genannt.

Autor: Mark B. (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas M. schrieb:
> findet eigentlich noch jemand das jemand mal den Mod melden sollte?!
> Wieso landet so ein Thema bitte in Forum: Offtopic??
> Die Kompetenz als Moderator sollte hier doch stark angezweifelt
> werden...

Das macht man, um einen Thread "elegant" für nicht angemeldete Benutzer 
zu sperren.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und wenn Kritik am Moderator geübt wird..damit es nicht eskaliert..er 
wird es nie lernen...und da wundert er sich über den Uensurheini

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Über den Zensurheini wundert sich niemand mehr, ausser er selbst. Dass 
der Mann krank ist und Hilfe benötigt, ist mehr als offensichtlich.

Autor: Le X. (lex_91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Och ne, müsst ihr den Programmiersprachen-Kleinkrieg unbedingt am 
Sonntag führen?
Das wär die perfekte Zwischendurchlektüre für die Arbeit gewesen.
Hoffentlich gibts den Thread morgen noch.

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Thomas M. schrieb:
> "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?

PASCAL ist eine reine Lehrsprache, unter diesem Namen gibt es gar keine 
Implementierung für den produktiven Einsatz. Die kanonische PASCAL 
Implementierung für den produktiven Einsatz ist Turbo-Pascal und das war 
ein Rohrkrepierer, weil es einzig auf einer Plattform (x86) und unter 
einem Betriebssystem (Win/DOS) verfügbar war [1]. Delphi ist der 
(glücklose) Nachfolger von Turbo-Pascal. Lazarus ist gar keine 
Programmiersprache, sondern eine IDE rund um Free Pascal. Letzteres ist 
die eine, leider viel zu spät erschienene Implementierung von Pascal, 
die plattformübergreifend verwendbar wäre (wenn man es haben wöllte).

Ich habe im Lauf meiner Programmierer-Karriere auch mal eine Zeit mit 
Turbo-Pascal verbracht und muß sagen, daß es für seine Zeit wirklich 
fortschrittlich war. OK, der Compiler hat schrottigen Code erzeugt. 
Dafür war er rattenschnell. Und die IDE hat gepaßt. Und es gab Libraries 
für alles Wichtige. Und der Turbo-Debugger war richtig(!) Klasse.

Trotzdem hing man an der bek(n)ackten Segmentierung des x86 fest und 
konnte entweder >64KB Code oder Datenstrukturen >64KB haben (aber 
nicht beides). Und auf (damals) fetter Hardware mit 64MB RAM oder mehr 
lief das Dingens gar nicht. Windows übrigens auch nicht. Da war es AIX 
(Rechnerraum II auf dem Campus gesponsort von IBM) oder HP-UX. Und 
später Linux. Und die einzige Programmiersprache, die da out-of-the-box 
lief, und sogar noch überall den gleichen Quellcode akzeptierte, war C. 
Das war ein riesiger FORTSCHRITT gegenüber Turbo-Pascal.

Also erzähl mir nichts davon, wer hier nicht über den Tellerrand 
schauen kann. Oh. Und wenn dir C nicht paßt, dann verwende halt eine der 
Alternativen. Java (stinkt). C# (Monokultur, wie weiland TP). Oder 
meinetwegen Ada, Erlang, Lisp, Rust. Ist ja nicht so, daß es keine 
Auswahl gäbe.

Aber hör auf damit, anderen Leuten die Werkzeuge madig zu machen, deren 
Verwendung du nicht beherrschst.


[1] ja, ok. TP 3.0 hatte ich auch mal eine Weile unter den Fingern. Auf 
einem BC5120 und CP/A. Auch ein dead-end. Immerhin mußte man sich keine 
Gedanken um ein Speichermodell machen, denn der Adreßraum war nur 
64KB. Code und Daten.

: Bearbeitet durch User
Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> C# (Monokultur, wie weiland TP)

C# gibts auch unter Linux.

Autor: Percy N. (vox_bovi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Axel S. schrieb:
>> C# (Monokultur, wie weiland TP)
>
> C# gibts auch unter Linux.

Delphi gab es dafür auch, hieß nur anders.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Delphi ist der
> (glücklose) Nachfolger von Turbo-Pascal.

Möööp. Delphi ist die Entwicklungsumgebung von Borland für ObjectPascal. 
Emberacado hätte nur gerne, dass die Sprache auch Delphi heisst.

> ... Free Pascal. Letzteres ist
> die eine, leider viel zu spät erschienene Implementierung von Pascal

1994: 2GB Daten verwalten
1998: Win32-Unterstützung
2000: FreeBSD-Unterstützung
2003: Linux-Unterstützung
2004: MacOS-Unterstützung

Ich gebe ja zu, leider ist FreePascal die ganzen Jahre auch an mir 
vorbeigegangen. Aber zu behaupten, es wäre "leider viel zu spät 
erschienen" - nur weil es keine Z4 Implementierung gab...

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Autor: Axel S. (a-za-z0-9)
dafür das Pascal eine reine Lehrsprache ist, ist der Altiumdesigner aber 
recht erfolgreich damit geschrieben..und Damals Nero oder der 
Totalcommander etc pp..
Delphi/Pascal gibts natürlich auf unter Linux..sowohl vom Emercadeo als 
auch von Freepascal.
Niemand bestreitet das damals Borland den Übergang zu Windows vermasselt 
hatte..aber das ist schon ewig her, seit dem hat sich viel geändert.

Lol..wer macht den C madig?  Es ist halt ein totaler Krampf..das ist 
Fakt.
Wieso fühlst Du dich deshalb persönlich angegriffen?
Man kann doch sagen das man es auch selber Kacke findet, aber es einige 
Vorteile für dich bietet, die es für dich unverzichtbar machen.
Das gilt aber für sehr viele andere nicht..für die überwiegt einfach der 
Stinkfaktor.
Du magst ja offenbar auch kein Pascal ..so what?! deshalb kann man sich 
dennoch über Unzulänglichkeiten einzelner Sprachen ärgern und wie 
bereits von anderen erwähnt, hat C etliche davon, und ja, sicher wirst 
Du auch in Pascal welche finden, aber halt andere!
Und vieles von dem was Du an Pascal bemängelst gilt heute doch gar nicht 
mehr.
C hatte damals auch noch erheblich mehr Unzulänglichkeiten als heute, 
die auch nach und nach ausgebügelt wurden..wo ist also das 
Problem..beide Sprachen haben sich entwickelt, PAscal deutlich mehr, da 
es aber auch mehr aufzuholen hatte..gilt vieles von den damaligen 
Erfahrungen nicht mehr

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> OK, der Compiler hat schrottigen Code erzeugt. Dafür war er rattenschnell.

Und genau das war bei uns in der Schule damals wichtig, denn die 
Computer dort hatten keine Festplatte. Man musste zuerst DOS booten, 
dann die Diskette A mit Pascal und Diskette B mit den eigenen 
Quelltexten einlegen.

bei dieser HW war wichtig, dass man danach die DOS Diskette nicht mehr 
oft benötigte und dass der Compiler schnell ist, sonst war die 
Doppelstunde vorbei, bevor man etwas zustande brachte. Zu dieser zeit 
hatte auch kaum jemand einen PC zu hause um es dort vorzubereiten bzw. 
nachzuarbeiten.

Will sagen: Für die damalige Zeit war Turbo Pascal die bestmögliche 
Wahl.

Autor: Karl K. (karl2go)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Und genau das war bei uns in der Schule damals wichtig, denn die
> Computer dort hatten keine Festplatte...

Haha, Opa erzählt vom Krieg... Ich kenn das zwar auch noch so vom Amiga, 
aber ich würde das AmigaBasic jetzt nicht zur Grundlage meiner Bewertung 
von Programmiersprachen machen.

Die aktuelle Lazarus+FPC Stable ist 3.3GB groß, inklusive der Sourcen 
und halt Crosscompiler für Linux und Linux Arm, Android.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas M. schrieb:
> Wieso landet so ein Thema bitte in Forum: Offtopic??

Wegen genau diesem Glaubenskrieg.

So endest es immer...
Fruchtlos.

Küchenpsychologie:

Zwei diametral gegensätzliche Möglichkeiten, es gibt!

Erstens:
Man regt sich über die Unzulänglichkeiten von irgendwas/irgendwem auf, 
was man nutzen muss. Aber da es keine Alternative dazu gibt, 
wird/erscheint man krank.
Siehe C-Hater.

Zweitens:
Man arrangiert sich damit. z.B. in dem man sich das Zeugs schön redet. 
Dieses ermöglicht ein zufriedenes/gesundes Leben, und eine erfolgreiche 
Arbeit damit.


Das ist die Wahl: Krank oder gesund.
Die Entscheidung findet im Kopf statt.
Bei jedem einzelnen.
Und ja, Selbstkonditionierung ist eine menschliche Eigenschaft.


Das alles geht auch ganz ohne Priester.

----------------

Thomas M. schrieb:
> Es ist halt ein totaler Krampf..das ist Fakt.

Kennst du das Lied: Youtube-Video "Jürgen von der Lippe - Guten Morgen, liebe Sorgen - 1987 - Donnerlippchen" ?
Das zeigt den richtigen Umgang mit Problemen.

Oder auch Hazel Brugger, hat die GEZ mal verwertet:
Youtube-Video "Hazel Brugger: Rundfunkbeitrag - Die Anstalt vom 22. Mai 2018 | ZDF"

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Man arrangiert sich damit. z.B. in dem man sich das Zeugs schön redet.
> Dieses ermöglicht ein zufriedenes/gesundes Leben, und eine erfolgreiche
> Arbeit damit.

Nope. Schönreden ermöglicht gerade kein erfolgreiches Arbeiten, weil man 
auf dem ineffizienten Kram hängenbleibt.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was hat derf Glaubenskrieg damit zu tun?!
Schau dir dei Diskussion mal an..das Thema wurde sachlich aund 
ausführlich ebsprochen erst als es durch war wurden noch nebenbei 
Gespräche geführt..das hat aber nicht dem dem Rest des Threads zu 
tun..Es ist mir völlig unverständlich wie manche Mods heir agieren 
dürfen

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Karl K. schrieb:
> Nope. Schönreden ermöglicht gerade kein erfolgreiches Arbeiten, weil man
> auf dem ineffizienten Kram hängenbleibt.

Wenn man die freie Auswahl hat...
Aber das ist halt nicht immer gegeben.

Arduino Liebhaber werden sich auf C++ konzentrieren müssen.
Die meisten anderen µC Programmierer werden auf C angewiesen sein.
Die beiden Sprachen bieten eine breite Codebasis für µC.

Assembler mal außen vor. Denn es ist weder portabel, noch frei von 
Fußangeln.
Die anderen Sprachen sind einfach nur Exoten auf µC.


-----

Wenn man keinen Einfluss auf die Umstände hat, kann man nur an der 
eigenen Einstellung arbeiten.

Und genau diese Einstellung entscheidet, ob man dabei gesund bleibt, und 
erfolgreich damit arbeitet.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas M. schrieb:
> Schau dir dei Diskussion mal an..das Thema wurde sachlich aund
> ausführlich ebsprochen

Deine Wahrnehmung ist, gelinde gesagt, getrübt.

Autor: Karl K. (karl2go)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Arduino Liebhaber werden sich auf C++ konzentrieren müssen.

Im FreePascal Forum sind ne Menge Arduino Liebhaber, die Arduino mit 
Pascal programmieren. Tellerrand.

Arduino Fanboy D. schrieb:
> Die anderen Sprachen sind einfach nur Exoten auf µC.

Ach? Ist das so? Weil Du nur noch Bascom kennst?

Von Ada bis MicroPython gibts da mehr, als Du sinnvoll ausprobieren 
kannst.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas M. schrieb:
> Es ist mir völlig unverständlich wie manche Mods heir agieren
> dürfen

Nana, Du bist noch nicht lange hier, oder? Das ist doch harmlos, im 
Raspberry Forum wärst Du schon rausgeflogen, wenn Du was gegen die 
Lieblingsprogrammiersprache des Mods gesagt hättest. BTDT, zweimal.

Autor: Le X. (lex_91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Von Ada bis MicroPython gibts da mehr, als Du sinnvoll ausprobieren
> kannst.

... und sind Exoten bzw. werden nur für Nischenanwendungen eingesetzt.
Aber ja, geben tut es sie und funktionieren tun die, in ihrer jeweiligen 
Domäne, wohl auch gut.

: Bearbeitet durch User
Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Le X. schrieb:
> ... und sind Exoten bzw. werden nur für Nischenanwendungen eingesetzt.

Nur weil Dir nicht jeder auf die Nase bindet, dass er nicht C einsetzt?

Autor: Le X. (lex_91)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Karl K. schrieb:
> Nur weil Dir nicht jeder auf die Nase bindet, dass er nicht C einsetzt?

Ich werd mich an deinen Fanboy-Diskussionen nicht beteiligen.
Ich habe keine emotionale Beziehung zu irgendeiner Programmiersprache, 
ich verdien damit lediglich mein Geld.

Freu dich doch einfach dass du ein Exot bist, sei stolz drauf.
Mainstream bzw. Industriestandard kann jeder ;-)

: Bearbeitet durch User
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Thomas M. schrieb:
> auch sowas verursacht in Pascal einen Fehler
> 2);source.pas(13,9) Warning: range check error while evaluating
> constants

Warnung, nicht Fehler.

> in C kommt raus..
> -5536
> Fehlermeldung von C....KEINE!

Alle gängigen C-Compiler können ebenfalls eine Warnung erzeugen. 
Außerdem hat das Ein- oder Ausschalten der Warnungen nichts mit der 
Sprache an sich zu tun, es ist eine Eigenschaft der jeweiligen Toolchain 
und der Konfiguration des jeweiligen Builds.

Du tust Deiner Sache überhaupt keinen Gefallen (das Gegenteil ist der 
Fall) wenn man den Eindruck gewinnt daß Du auf solche lächerlichen 
Nebelkerzen zurückgreifen mußt um irgendein ein Pro-Argument für Pascal 
(oder Contra-Argument gegen C) vorbringen zu können, der Blödsinn da 
oben ist einfach zu durchschauen und jede Oma kann ihn entkräften und 
ist überhaupt kein Argument für oder gegen irgendwas.

Wenn Du ernstzunehmende Argumente vorbringen willst mußt Du die 
wirklichen Unterschiede der jeweiligen Sprachen und deren Vor- oder 
Nachteile herausarbeiten, dazu muß man aber weitaus tiefer graben (oder 
die einschlägige Literatur zu dem Thema studieren) und das was man dabei 
hervorholt muß man selber verstehen und klar definieren und abgrenzen 
können, nicht mit solchem oberflächlichen Wischiwaschi-Blödsinn 
herumwedeln wie die Default-Warneinstellungen irgendeines konkreten 
Compilers, das sagt absolut nichts über die Eigenschaften der Sprache 
aus.

: Bearbeitet durch User
Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
sorry..genau DAS ist nicht Wischi Waschi..oder an den HAren herbei 
gezogen!
Eine klare Fehlermeldung zu gar keiner Fehlermeldung IST!! berechtigte 
Kritik

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Thomas M. schrieb:
> Eine klare Fehlermeldung zu gar keiner Fehlermeldung IST!! berechtigte
> Kritik

Beide Compiler erzeugen keinen Fehler sondern sie erzeugen beide 
eine klare Warnung. Was sagt dieser Umstand jetzt nochmal konkret über 
den Unterschied zwischen den beiden Sprachen aus?

: Bearbeitet durch User
Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
eben NICHT!!
in C kommt keine Warnung,d a kommt absolut nichts..darum geht es hier 
Seitenweise!!
PACAL gibt aber eine Warnung...Fehlermeldung ist kackegal..es geht 
daraum das Du auf einen Schnitzer hingewisen wirst..wie Du das jetzt 
bezeichnen willst  ist albern darüber zu diskutieren.
C lässt es durchgehen und gibt ein falsches Ergebnis, Pascal warnt vor 
einem zu großen Wert der einen Fehler verursachen wird.
Schau die Quellcode Beispiele hat,..ist alles Seitenlang durchgekaut.
Und wenn Du BEIDE Compiler so einstellt das bei eienr Warnung nicht 
compiliet wird..
Gibt PASCAL auf eine FEHLERMELDUNG und C NICHTS ausser einen BUG!!
So zufrieden?!

: Bearbeitet durch User
Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas M. schrieb:
> Lol..wer macht den C madig?  Es ist halt ein totaler Krampf..

Damit beantwortest du deine Frage gleich selbst.

> das ist Fakt.

Nein, es ist deine Meinung. Viele halten ihre eigene Meinung für Fakten, 
weil sie es nicht schaffen, diese beiden Dinge sauber auseinander zu 
halten.
Das ist kritisch, weil diejenigen damit implizit jegliche andere Meinung 
für ungültig erklären.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas M. schrieb:
> C lässt es durchgehen und gibt ein falsches Ergebnis, Pascal warnt

Weder C noch Pascal tun irgendwas. Sie sind lediglich Sprachen, 
abstrakte Definitionen von Grammatik und Syntax, niedergeschrieben auf 
irgendeinem Papier.

Konkrete Compiler tun etwas und die gängigen Compiler für C die man 
heutzutage benutzt können da genauso eine Warnung anzeigen wie Dein 
Pascal-Compiler. Und bei beiden Compilern kann man die ganzen Warnungen 
auch alle ausschalten und ignorieren. Kein Unterschied.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Thomas M. schrieb:
> eben NICHT!!
> in C kommt keine Warnung,d a kommt absolut nichts..darum geht es hier
> Seitenweise!!

Du willst es nicht begreifen? Nicht "in C", sondern bei deinem 
Compiler mit deinen Compiler-Einstellungen kommt keine Warnung. C 
verbietet Warnungen nicht!
Bei mir warnt der Compiler da. Willst du jetzt behaupten, es sei deshalb 
kein C-Compiler?

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Ach? Ist das so? Weil Du nur noch Bascom kennst?
>
> Von Ada bis MicroPython gibts da mehr, als Du sinnvoll ausprobieren
> kannst.

Statt Argumente, persönliche Anmache.

Ich sachs ja: So werden Glaubenskriege geführt.
Priestertum...

Le X. schrieb:
> Ich habe keine emotionale Beziehung zu irgendeiner Programmiersprache,
> ich verdien damit lediglich mein Geld.
Das halte ich für eine wesentlich gesündere Einstellung.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
@Rolf M
"Du willst es nicht begreifen?"
Nö, Du willst es nicht akzeptieren..Es waren die Warnmeldungen 
eingeschaltet in C!!
"Bei mir warnt der Compiler da. Willst du jetzt behaupten, es sei 
deshalb
kein C-Compiler?"


HAst Du meine Links/Codebeispiele eigentlich gesehen?!?
In 3 verschiedenen C Compilern passiert absolut nichts!
In d und Pascal schon!

Anstatt nur rumzuposaunen das stimmt nicht,  nenne doch deinen Compiler 
ganz einfach, vielleicht kann das dann jemand bestätigen oder 
verneinen...
Aber in meinem Link kannst Du online 3 C Compiler testen mit einem 
Klick! und alle 3 scheitern.
Wenn Du jetzt einen hast der das macht..toll...dann zeigt das ein mal 
mehr ein Problem von C ..das die Compilerwahl je nach Fehler pures Glück 
ist, ob es der richtige ist...
Unter anderen war der ach so hochgelobte gcc dabei und MS Visual C

Bei Pascal gibt es nur den defacto Standard Delphi/Freepascal. Beide 
melden es.

Du wirst doch zugeben müssen das es schon blöd ist, das es pures Glück 
ist, wo was gemeldet wird und so nicht.
Ansonsten gäbe es ja diese Kritik nicht.
Und wenn das jetzt NACHTRÄGLICH in Deiner Oberfläche implementiert 
ist..schön..aber wir reden hiervon üblichen C Compilern nicht von Guis 
oder extra Tools die sich jemand geschrieben hat um solche Fehler zu 
finden..es geht darum was beim Standard gemeldet wird und was nicht


Noch besser, zeig doch mal Deinen kompletten Code, damit man es mal copy 
PAste testen kann oder Dir sagen kann, was bei Deinem Beispiel falsch 
ist

: Bearbeitet durch User
Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
ich habs gerade noch mal so ausprobiert..nun gehts ohne Fehler und ohne 
Fehlermeldung?!
Sowohl im Rextester als auch in Codeblocks?
Was mache ich denn jetzt plötzlich falsch?
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

int main()
{
    uint16_t i = 30000 * 2;
    printf("%d",i);
    return 0;
}

Ergebnis: 60000

: Bearbeitet durch User
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Thomas M. schrieb:
> Was mache ich denn jetzt plötzlich falsch?

Du hast immer noch nicht kapiert, was die Ursache des "Problems" ist.

Der Datentyp "int", der vom Compiler für Berechnungen verwendet wird, 
ist je nach Compiler unterschiedlich groß.

Und wenn Du einen Compiler verwendest, der für 32-Bit-Maschinen gedacht 
ist (wie es ein Compiler für den PC oder auch einen ARM ist), dann ist 
ein "int" ein 32-Bit-Datentyp, und die Berechnung liefert keinen 
Überlauf.

Bei einem Compiler für 16-Bit-Maschinen (oder 8-Bit-Maschinen) aber ist 
"int" ein 16-Bit-Datentyp, und es gibt einen Überlauf.

Das ist elementares C und steht in den ersten Kapiteln jedes 
tauglichen Buches über die Sprache drin, und wird in den ersten Wochen 
der Erstsemestervorlesung gelehrt.

--

Ich fände es schön, wenn Du, bevor Du weiter Dinge kritisierst, die Du 
nicht verstehst, weil Du Dich nicht mit ihnen beschäftigen möchtest, Dir 
vielleicht erst mal das nötige Grundlagenwissen aneignen würdest.

Denn das fehlt Dir. Dafür aber bist Du sehr laut.


Und wenn Du keine Lust hast, Dir Wissen anzueignen, dann halte Dich doch 
bitte einfach aus Diskussionen über das entsprechende Thema herasu. Das 
regt Dich weniger auf, und es stört andere nicht.

Ich beispielsweise habe von Ballett echt gar keine Ahnung, und äußere 
mich dazu nicht. Auch über Fußball wirst Du von mir keine Kommentare 
hören, denn das interessiert mich nicht die Bohne.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-9 lesenswert
nicht lesenswert
"Rufus Τ. F. (rufus) (Moderator)"
"Du hast immer noch nicht kapiert"
Achte auf Deinen Ton Du Vogel!


es geht nun aber auch unter Rextestert Du....!!
Offensichtlich hast Du es nicht gerafft..entweder vorher oder Du 
erkennst den Fehler im Beispiel jetzt nicht..wie auch immer!

Oder eines meiner Beispiele vorher war falsch, deshalb diskutiert mna, 
was Du offenbar nicht schnallst!

Denn wenn das erste Beispiel von mir schon falsch gewesen wäre, wäre die 
ganze Diskussion für die Katz! Verstehst Du?!


Vielleicht sollte ich Dich mal WIEDER beim Forenbetreiber melden!

: Bearbeitet durch User
Autor: Walter K. (vril1959)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Thomas M. schrieb:
> Sowohl im Rextester als auch in Codeblocks?


... Rufus hat eigentlich schon alles geschrieben!

Welche Entwicklungsumgebung Du nun für das Erlernen der Basics
nutzt - ist auch vollkommen egal!

Kompiliere und Linke zuerst mal nativ auf Ebene der Kommandozeile - dann 
bekommst Du ein Gefühl dafür, was eigentlich wie passiert - und bringst 
Verständnisprobleme von Datentypen und Castings nicht mit "CodeBlocks" 
in Verbindung.

Autor: Thomas M. (thomasmopunkt)
Datum:

Bewertung
-10 lesenswert
nicht lesenswert
viel blabla..aber keine Erklärung dafür was an den vorherigen Beispielen 
anders war, die ja ebenfalls im Rextester getestet wurden!

Wenn nicht alle nur labern würden sondern codebeispiele zegien würden 
udn alle die mal eben im onlinecompiler testen könnten, wäre der ganze C 
vs Pascal Kleinkrieg vielleicht schon längst friedlich beendet.

Aber hier kommt immer nur Gelaber teilweise mit völlig falschen 
Erklärungen weil der Threat schon so lang geworden ist, das viele gar 
nicht mehr die ganzen Vergleiche udn Beispiele kennen

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Thomas M. schrieb:
> Achte auf Deinen Ton Du Vogel!
>
> es geht nun aber auch unter Rextestert Du....!!

Diese Kombination liest Du Dir bitte nochmal durch.

Thomas M. schrieb:
> Aber hier kommt immer nur Gelaber

Nein. Ich wiederhole es: Du weigerst Dich, Dich mit dem Gesagten 
auseinanderzusetzen.

Das ist bei Dir schon pathologisch.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Thomas M. schrieb:
> Es ist halt ein totaler Krampf
> das ist Fakt.

Ich glaube Dir, dass diese Eigenschaft für Dich sehr ärgerlich ist. Für 
mich ist das lediglich eine Eigenschaft die ich berücksichtigen muss und 
kann.

Ich benutze trotzdem C in meinen Elektronik freiwillig. Ich habe gar 
keine Lust, mich dort mit anderen Programmiersprachen auseinander zu 
setzen, obwohl ich viele andere kennengelernt habe und mir durchaus 
dessen bewusst bin, dass C ein alter hässlicher Opa ist.

Sogar in meinen Hobbyprojekten für Linux/Windows Desktop bevorzuge ich 
C++.

Das liegt nicht daran, dass ich von C am meisten Ahnung hätte. Mein 
beruflich fundiertes KnowHow liegt stattdessen bei Java.