was macht diese C-Zeile

[flyingwolf (Gast)]

Hi.
Was machen diese Zeilen?


if (cmd->cmd == CMD_ABORT)
{
if (cmd->status!=STATUS_MOB_AVAILABLE)
...

[Rufus T. Firefly (Gast)]

Das sind zwei Vergleichsoperationen.

cmd ist ein Pointer auf eine Struktur, die Elemente namens cmd (wie
praktisch!) und status enthält.

Die erste Zeile vergleicht das Strukturelement cmd mit dem Wert(?), der
#definierten Konstanten (wäre aufgrund der Großschreibung naheliegend)
CMD_ABORT.

Die zweite Zeile enthält eine öffnende geschweifte Klammer.

Die dritte Zeile vergleicht das Strukturelement status mit der
(vermutlich auch) #definierten Konstanten STATUS_MOB_AVAILABLE. Dabei
wird der auf das if-Statement folgende Block ausgeführt, wenn die
Bedingung unwahr ist (!= ist nicht gleich, während das == der ersten
Zeile gleich ist.

Literaturempfehlung:

Kernighan&Ritchie, Programmieren in C, zweite Auflage, Hanser Verlag

[flyingwolf (Gast)]

@Rufus
Danke.
Mal sehen ob ich es richtig vertanden haben
cmd enthält etwas, was "cmd" heißt und etwas, das "status" heißt,
also sozusagen zwei Variablen in einer?
Und um an den Inhalt von "status" in "cmd" ranzukommen, bedarf es
eines "->"?

[Rufus T. Firefly (Gast)]

.
  "cmd enthält etwas, was "cmd" heißt und etwas, das
  "status" heißt, also sozusagen zwei Variablen in einer?"

Ja. Das nennt man eine Struktur. Und nein, "cmd" enthält das nicht,
sondern zeigt darauf. "cmd" ist ein Pointer.

Ein Beispiel:

  struct
  {
    int cmd;
    int status;
  } *cmd;


  "Und um an den Inhalt von "status" in "cmd" ranzukommen,
  bedarf es eines "->"?"


Da cmd ein Pointer ist, muss man ihn deferenzieren, und das geschieht
mit dem -> operator.

Wirklich beknackt ist hier die Namensvergabe; sowohl den Pointer als
auch ein Strukturelement mit dem gleichen Namen zu belegen, das ist
ziemlich dämlich.

[OldBug (Gast)]

...nur ums vollständig zu machen:

/* Struktur als neuen Typen anlegen */
typedef struct
info_s
{
  int cmd;
  int status;
} info_t;

/* sysinfo definieren */
info_t sysinfo;

int
main(void)
{
  info_t *pInfo = &sysinfo;        /* Pointer anlegen & init.    */

  pInfo->cmd = CMD_START;          /* Zugriff mit pointer-deref  */
  sysinfo.status = STATUS_IDLE;    /* Zugriff ohne pointer-deref */

  return 0;
}

[Jörg Wunsch (Gast)]

»foo->bar« ist übrigens die Kurzform für »(*foo).bar«.  Da man diese
Form sehr häufig braucht und die sonst notwendige Klammerung recht
umständlich ist, haben die C-Autoren dafür einen eigenen Operator
erfunden.

[flyingwolf (Gast)]

Herzlichen Dank Euch allen.

>>Wirklich beknackt ist hier die Namensvergabe; sowohl den Pointer als
>>auch ein Strukturelement mit dem gleichen Namen zu belegen, das ist
>>ziemlich dämlich.

Naja, das ist dann wohl auch der Grund dafür, dass es nicht so recht
funktioniert und ich diesen Müll auseinanderklambüsern muss um etwas
daraus zu schustern dass funktioniert.

[KoF (Gast)]

tja, ob mein ein prog "müll" ist, liegt immer im auge des
betrachters!

denk dran, das software eins der komplexesten gebilde ist, das der
mensch erschaffen hat! für ein prog gibt es meist nur eine lösung, aber
unendlich viele möglichkeiten, diese lösung zu erreichen.

schonmal einen code eines mathematikers, eines physikers oder eines
"nur" programmierers? alle benutzen die selbe sprache, alle lösungen
funktionieren, aber die programme haben eben bis auf die sprache und
das ergebnis nichts gemeinsam!!!

naja... und "müll" kann man ein prog eventuell nennen, wenn es voll
von symantischen fehlern ist. das würde dann auf ein frickelwerk
deuten, das nicht wirklich gut durchgeplant ist.

[Rufus T. Firefly (Gast)]

Nun, ein strukturierter oder wenigstens halbwegs konsistenter Umgang mit
Bezeichnern ist schon ein wichtiges Kriterium bei der
Softwareentwicklung.

Das oben zitierte Beispiel (Verwendung des Bezeichners "cmd")
rechtfertigt zumindest eine hochgezogene Augenbraue bei der Lektüre des
Quelltextes.

Meinst Du "syntaktische" oder "semantische" Fehler?

[Daniel (Gast)]

Hallo,

ich gebe dann auch noch kurz meinen Senf dazu ;-) :

"Beim Programmieren muss man immer darauf achten, dass man den Code
für den Menschen schreibt - den Code für die Maschine schreibt der
Compiler !"

Das stammt nicht von mir, aber ich denke es ist der richtige Weg.
Selbst einen gut optimierten Code kann man so schreiben, dass er lesbar
ist und nicht einfach nur aussieht wie ein modernes Kunstwerk -
faszinierend anzusehen und den meisten Menschen unverständlich.

Ein Beispiel : In meinem aktuellen Projekt (FAT12/16/32) gibt es eine
Struktur mit dem Namen "FATInfo" diese hat dann die Elemente (z.B.)
"ui16SectorsPerCluster". Das ist bestimmt mehr Tiparbeit, als wenn
ich es "FI2.SpC" genannt hätte, aber ist ungemein besser lesbar.
Aus einem "guten Code" erkennt der Leser die Intention bei der Lösung
eines Problems (was auch Optimierungen angeht - diese kann man auch so
darlegen, das sie nicht ausschauen wie ein Dschungel).

Zum Thema "Müll"-Programme : Das sind alle Programme, wo man nach 2
Wochen selbst nicht mehr weiß, was man sich dabei gedacht hat. Die kann
dann nämlich kein Mensch mehr brauchen - was wiederum das Kennzeichen
von Müll ist :-).

MfG, Daniel.

[flyingwolf (Gast)]

Ich bitte das Wort "Müll" nicht überzubewerten. Der Programmierer hat
sich bestimmt viel Mühe gegeben, sein Bestes gegeben, viel viel mehr
erreicht als ich und kann bestimmt viel besser programmieren, als
ich...
Das ich mir damit die Karten lege liegt daran, dass ich nicht
programmieren kann. Somit ist der Ausdruck "Müll" bitte als
Verärgerung über meine Unfähigkeit zu verstehen.