Was passiert hier: #define Addr (*(uint16_t*)&com[2])

Bastian schrieb:
> Was bedeutet der erste Stern?

Dass du ein C Handbuch brauchst. ;-)

Der linke Stern dereferenziert, der rechte macht einen Pointer aus dem 
Typ im Cast.

Richtig. Nicht empfehleswert bei Prozessoren mit alignment restrictions.

Bastian schrieb:
> Aber du verstehst sich, das für einen Anfänger so
> ein Ausdruck erst einmal schwierig ist.

Yep. C ist nichts für Ästheten, und sowas schon garnicht.

Bastian schrieb:
> Oh nein, schon wieder was zum nachlesen ;-)

Aber das findest du im C Handbuch nicht.

Bastian schrieb:
> Dachte ich mir, wohl eher im µC Datenblatt?!

In der Beschreibung des Prozessors. Wenn es nicht grad ein 8-Bit Typ 
ist, denn denen ist das üblicherweise egal.

Bastian schrieb:
> Dann wirst du das lieben:

Lass dann aber die überflüssigen Klammern und Leerzeichen weg! ;-)

1

s = *(uint16_t*)&com[4]|*(uint16_t*)&com[2]<<16;

Nur APL ist schöner:

1

life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}

Extrem Entzückter schrieb:
> Das ist Masochismus in Reinkultur.

Du bis aber leicht zu beeindrucken. Schau mal hier rein: 
http://www.ioccc.org/

Eines der harmloseren Beispiele als Anhang. Das Programm tut durchaus 
etwas sinnvolles und wird von einem (BSD) C-Compiler sauber übersetzt.

Bastian schrieb:
> nicht alles zu Null?

Weshalb? Präfix Operatoren wie *, & und Cast haben Vorrang vor <<, und 
der wiederum vor |. Einzig die Klammern vom Cast sind als integraler 
Teil ebendieses Operator unverzichtbar.

Bastian schrieb:
> Ich dachte die "neuen" Stellen werden mit Nullen aufgefüllt!?

Und? Ok, auf einem 8/16-Bitter wird es wirklich zu 0, aber das hat 
nichts mit den Klammern zu tun. Das Statement stammt offensichtlich aus 
einer 32- oder 64-Bit Umgebung.

Bastian schrieb:
> Ja, das meint ich. Was das woll soll?

Das soll heissen, dass nicht jeder Code, der für einen 32-Bit Prozessor 
geschrieben wurde, auch auf einem 16-Bitter läuft.

Bastian schrieb:
> Ich meinte, wenn ich eine 16bit-Zahl um 16 Stellen nach links
> verschiebe.
>
> Ich dachte die "neuen" Stellen werden mit Nullen aufgefüllt!?

Nein, zumindest nicht wenn sizeof(int) = 2 ist.  Dann ist's undefined 
behaviour (oder unspecified? die werf ich immer durcheinander).

Georg G. schrieb:
> Extrem Entzückter schrieb:
>> Das ist Masochismus in Reinkultur.
>
> Du bis aber leicht zu beeindrucken. Schau mal hier rein:
> http://www.ioccc.org/
>
> Eines der harmloseren Beispiele als Anhang. Das Programm tut durchaus
> etwas sinnvolles und wird von einem (BSD) C-Compiler sauber übersetzt.

Wir sind uns hoffentlich über zwei Dinge einig:

1.) Der IOCCC bringt schon ein paar geile Dinge hervor (ich mag 
besonders die Sachen von Oscar Toledo).
2.) Niemand, der noch ganz bei Trost ist, programmiert so in einem 
Industrieprojekt in dem es darum geht Geld zu verdienen.

Wegstabenverbuchsler schrieb:
> Du scheinst "bessere" Programmiersprachen zu kennenn.

Nein, das ist keine Frage der Programmiersprache. Das hier gezeigte 
Code-Beispiel ist aus verschiedenen Gründen (z.B. Prozessorabhängigkeit, 
Lesbarkeit, Wartbarkeit) einfach grottig. Man kann in jeder Sprache 
schlechten Code schreiben, auch und gerade in C. Das heißt aber nicht, 
dass man es auch tun sollte.

> Welches wäre denn
> deine bevorzugte Programmier-Sprache, welche automatisch (oder mit
> entsprechenden Befehl) selbiges auf die gegebene Datenstruktur ausführt?

Code wird immer noch nach Anforderungen entwickelt. Die richtige Frage 
lautet daher: Was ist eine sinnvolle Anforderung, die bei sauberer 
Programmierung zu einem Code-Beispiel wie dem oben gezeigten führt?

Und schon wird die Luft ganz dünn. ;-)

Mark Brandis schrieb:
> 2.) Niemand, der noch ganz bei Trost ist, programmiert so in einem
> Industrieprojekt in dem es darum geht Geld zu verdienen.

So wie im IOCCC sicher nicht, das bedient ja auch eher die künstlerische 
Ader. Das Beispiel des Threaderöffners schockiert mich ehrlich gesagt 
nicht mal im Ansatz - dazu wühlt man sich durch zuviel C/C++-Code und 
hat häufig nicht den Zeitrahmen, das sauberer z.B. über Unions zu lösen. 
Gerade bei einer großen Codebasis kommst du dann beim Refactoren vom 
Hundersten ins Tausendste.

> Wegstabenverbuchsler schrieb:
>> Du scheinst "bessere" Programmiersprachen zu kennenn.
>
> Nein, das ist keine Frage der Programmiersprache. Das hier gezeigte
> Code-Beispiel ist aus verschiedenen Gründen (z.B. Prozessorabhängigkeit,
> Lesbarkeit, Wartbarkeit) einfach grottig. Man kann in jeder Sprache
> schlechten Code schreiben, auch und gerade in C. Das heißt aber nicht,
> dass man es auch tun sollte.

Glaube ich nur begrenzt. Ich behaupte, dass die Designer einer 
Programmiersprache sehr wohl und sehr deutlich durch die Grammatik den 
Programmierstil der Programmierer beinflussen! Eine moderne Sprache 
stellt sich sicher auf die Mehrzahl ihrer Programmierer ein und schließt 
alleine durch ihre Sprachgrammatik bereits Fehler aus.

Beispiel: die notwendige Implementierung von virtuellen Destruktoren in 
rein virtuellen (abstrakten) Klassen bei C++ ist so ein Fehler, der mich 
so einige Memleaks in der Vergangenheit gekostet hat - bloß weil der 
Compiler einen automatischen nicht-virtuellen Destruktor für das 
Interface gebaut hat und somit der Destruktor der Ableitung nicht 
aufgerufen wurde... macht Java oder C-Gartenzaun (C#) mittels eigenem 
Schlüsselwort besser.

>> Welches wäre denn
>> deine bevorzugte Programmier-Sprache, welche automatisch (oder mit
>> entsprechenden Befehl) selbiges auf die gegebene Datenstruktur ausführt?
>
> Code wird immer noch nach Anforderungen entwickelt. Die richtige Frage
> lautet daher: Was ist eine sinnvolle Anforderung, die bei sauberer
> Programmierung zu einem Code-Beispiel wie dem oben gezeigten führt?
>
> Und schon wird die Luft ganz dünn. ;-)

Nicht immer ist eine Anforderung, dass der Code lesbar ist. Gerade bei 
Schnittstellen, deren interne Funktion nicht leicht ertestbar sein 
sollen, entsteht mitunter übler Code. Oder aber wenn ein Feature schon 
vorgestern fertig sein musste, der Programmierer aber erst heute davon 
erfährt... :)

Weiteres Beispiel: Constraints! Wenn du also jemanden hast, der dir 
keine Requirements spezifiziert, sondern praktisch das Design vorgibt 
(z.B. durch Fremdcode), an den du dich halten musst, so sind das 
Constraints für dich.
Und dann argumentier mal bitte von wegen Qualitäten usw. wenn das 
Projekt seitens des Herstellers höchstens noch Wartungsaufwand generiert 
und daher nur die gröbsten Bugs gefixt werden...

Und die ultimative Antwort auf Frage nach der Anforderung, die solchen 
Code generiert: nicht '42', sondern das kleine, unscheinbare Wort 
'Termindruck'...

Sicher, wenn eine Firma mit schlechtem Code leben will, der soll sie 
dies tun. Dann soll sie sich aber auch gefälligst nicht beschweren, wenn 
das Ergänzen von neuer Funktionalität länger dauert und somit teurer 
ist.

Mark Brandis schrieb:
> Sicher, wenn eine Firma mit schlechtem Code leben will, der soll
> sie dies tun. Dann soll sie sich aber auch gefälligst nicht beschweren,
> wenn das Ergänzen von neuer Funktionalität länger dauert und somit teurer
> ist.

Na, dann erzeugen neue Funktionen neue Aufwände und die kann man 
bekanntlich besser abrechnen... man wundert sich dann aber später darum, 
warum die Zeitschätzungen für neue Projekte immer vollkommen (deutlich > 
Faktor 2) daneben liegen...

Das Lustige daran: in der Janus-köpfigen Firmenwelt ist doch die 
Time-To-Market oft das entscheidende Merkmal. Nach draußen groß auf 
Qualität machen, aber dem Softwareentwickler nicht wirklich die Zeit 
geben, wirklich eine qualitativ hochwertige Codebasis zu schaffen (z.B 
wegen irgendwelcher anderen Projekte). Diesen Luxus hat man nicht immer. 
Da schreibste halt erstmal so, dass es überhaupt funktioniert, bis du 
irgendwann mal Zeit findest, das ordentlich zu machen.

Weitere Behauptung von mir: Programmierer, die nie ranzigen Code 
geschrieben haben, warten bzw. erweitern oder auch nur verstehen 
mussten, sollten sich sehr glücklich schätzen... denn es gibt immer 
Code, der noch schlechter ist...

Johann L. schrieb:
> Dann ist's undefined behaviour
> (oder unspecified? die werf ich immer durcheinander).

Undefined. Ist auch besser so, denn verschiedene Implementierungen der 
gleichen Architektur verhalten sich dabei u.U. unterschiedlich.

A. K. schrieb:
> Undefined.

Darf ich widersprechen? K&R, Seite 189, Linkshift: "vacated bits are 
0-filled", Rightshift: 0-fill wenn unsigned, nur bei signed ist es 
undefiniert (0 oder das Vorzeichenbit).

Wäre es wirklich immer undefiniert, würden Bitoperationen wie "x |= (1 
<< BITPOS) nicht funktionieren. Und die findet man ja wohl zu hauf.

Georg G. schrieb:
> A. K. schrieb:
>> Undefined.
>
> Darf ich widersprechen? K&R, Seite 189, Linkshift: "vacated bits are
> 0-filled", Rightshift: 0-fill wenn unsigned, nur bei signed ist es
> undefiniert (0 oder das Vorzeichenbit).

Darum gehts nicht.
Es geht darum, was passieren soll, wenn man um mehr Bits shifted, als 
der Datentyp groß ist.
Und das ist undefined. Ich kann mich an einen Fall erinnern, in dem das 
links Shiften eines 16 Bit Wertes um 16 Bits zu keiner Veränderung des 
Wertes geführt hat.

Georg G. schrieb:
> Darf ich widersprechen?

Nein. Es ging um die Frage, was bei N >= #Bits passiert.

Da arbeitete beispielsweise der 8086 noch Modulo 256, die Nachfolger 
aber Modulo 32 (bzw. 64 bei 64-Bit Operationen). Bei N=33 gibts also 
recht verschiedene Ergebnisse.

Falk Schilling schrieb:
> nicht den Zeitrahmen, das sauberer z.B. über Unions zu lösen.

Union ist ohnehin kaum „sauberer“.

Sauber wäre es, mit einer Inline-Funktion die Bytes einzeln zu
schieben und zu addieren (oder zu verODERn).

Für den hier genannten Zweck (das Rauspopeln der Adresse aus dem
Bytehaufen erfolgt ja nur für ein printf(), also zu Debugzwecken)
ist das ein pragmatischer Ansatz, den man durchaus wählen kann.
Es fehlt eigentlich nur ein

1

#undef Addr

 direkt nach der
Benutzung, damit niemand auf die Idee käme, den Makro anderweitig
zu missbrauchen.