Unbekannte Bezeichnung einer Variable

[Martin45461 (Gast)]

Hallo,
hab grad probleme ein Programm zu verstehen.

int FindCommand(char *cmd)
{
   int i=0;
   
   for (i=0; i<NUM_COMMANDS; i++) {
       if (stricmp(&RS232_Commands[i][0], cmd)==0)
         return(i);
   }
   
}

Also ich weiß das hier die gespeicherten Strings vom 2DArray mit dem von 
cmd verglichen werden und alle treffer werden dann in return geschickt.


Nur was hat der Stern in char *cmd für eine bedeutung ?
*cmd, ist das auch ein Array ?.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Martin45461 schrieb:
> *cmd, ist das auch ein Array
* bedeutet in C Pointer oder Zeiger
Was das ist, das findest du in absolut jedem C-Grundlagenbuch...
http://de.wikibooks.org/wiki/C-Programmierung:_Zeiger

[Karl H. (kbuchegg)]

Martin45461 schrieb:

> Also ich weiß das hier die gespeicherten Strings vom 2DArray mit dem von
> cmd verglichen werden und alle treffer werden dann in return geschickt.

Nein,
Der ERSTE Treffer bildet den Rückgabewert. Alle Treffer würde anders 
gehen.

> Nur was hat der Stern in char *cmd für eine bedeutung ?

Es bedeutet vor allen Dingen, dass du ganz dringend ein C-Buch brauchst.

> *cmd, ist das auch ein Array ?.

Es ist ein Pointer.
Arrays werden in C vom Aufrufer zur Funktion so "übergeben", dass der 
Aufrufer die Startadresse des Arrays zur Funktion übergibt. Der bekommt 
sie dann in Form eines Pointers zur Verwendung.

Der Array-Pointer Dualismus und wie er sich auf das Sprachdesign 
auswirkt und benutzt wird, ist ein wesentlicher und wichtiger Punkt der 
Programmiersprache C. Er findet sich in einem 200 seitigen Buch erstmals 
ungefähr auf Seite 30 und wird das ganze restliche Buch hindurch 
benutzt. Insbesondere sind Pointer im Allgemeinen und Array-Pointer 
Dualismus im speziellen das Rückgrat bei Funktions-Argumentübergaben, 
Stringverarbeitung und dynamischer Speicherallokierung.
Daher: Du brauchst ein Buch! Denn wenn dir weder Pointer noch dieser 
Dualismus nichts sagen, bzw. du nicht weist welche Konsequenzen die 
haben, dann möchte ich nicht wissen, was du sonst noch so alles von C 
nicht weißt. Zumal Pointer, zumindest in dieser Form als 
Argumentübergabe bei Arrays, in jedem anständigen C-Programm welches 
komplexer als "Hello World" ist, praktisch unvermeidbar sind. Irgendwo 
steckt immer ein Pointer.

[Yalu X. (yalu) (Moderator)]

Um den Array-Charakter hervorzuheben, könntest du auch schreiben:

int FindCommand(char cmd[])

Die Bedeutung ist aber exakt die gleiche wie in deinem Beispiel. Karl
Heinz hat bereits geschrieben, warum.

[Udo S. (urschmitt)]

Ich muss mich Lothar und Karl Heinz ganz entschieden anschliessen.
Programmieren ist nicht try and error, sondern man muss die Grundlagen 
LERNEN! Mit einem Buch.

Martin45461 schrieb:
> und alle treffer werden dann in return geschickt.
Zeigt weitere massive Defizite. Man kann nichts in Return "schicken", 
denn return ist keine Queue, oder Postannahmestelle. Ausserdem hat die 
Funktion nicht mehrere ("Alle Treffer") sondern genau einen. Danach 
beendet sich die Funktion indem sie den Index des getroffenen 
Arrayelements zurückgibt.

[Ralph (Gast)]

Martin45461 schrieb:
> for (i=0; i<NUM_COMMANDS; i++) {
>        if (stricmp(&RS232_Commands[i][0], cmd)==0)
>          return(i);
>    }

Also auf diese Art eine Schleife abzubrechen ist nicht gerade schön.

Sollte der Code mit Analyse Tools/Regeln wie zb MISRA geprüft werden, 
wird dies eine Fehlermeldung erzeugen.

Das geht schöner und ist dabei nicht mal viel Aufwand.

int FindCommand(char *cmd)
{
   int i=0;
   int a=0;
   
   for (i=0; (i<NUM_COMMANDS)&&(a=0) ; i++) 
   {
       if (stricmp(&RS232_Commands[i][0], cmd)==0)
      {
          a = i;      
      }
   }
   return(a);
}

[Kaj (Gast)]

Udo Schmitt schrieb:
> man muss die Grundlagen
> LERNEN! Mit einem Buch.
Oder einem Studium, einer Ausblidung oder sonst wie ;)

Grüße

[Helmut H. (helmuth)]

Ralph schrieb:
> Das geht schöner und ist dabei nicht mal viel Aufwand.
Was ist wenn bei i==0 ein Treffer erkannt wird?

 (i<NUM_COMMANDS)&&(a=0) ; i++)

Das a=0 ist Absicht und MISRA-konform?

[Karl H. (kbuchegg)]

Ralph schrieb:

> Das geht schöner

Na ja.
Du zeigst eigentlich nur, dass Schönheit etwas sehr subjektives ist.

Bei so kurzen und in wenigen Sekunden durschaubaren Funktionen habe ich 
persönlich eigentlich kein Problem, wenn da ein return in einer Schleife 
sitzt, dessen Funktionsweise unmittelbar ersichtlich und auch einfach 
logisch begründbar ist. Das ist für mich einfacher als jede 
Hilfskonstruktion mit diversen Flags, die ihrerseits wieder weitere 
Angriffspunkte für Flüchtigkeitsfehler bieten.

Ich hab eher ein Problem mit dem fehlenden return in der 
Originalfunktion, wenn das Kommando nicht gefunden wurde. Aber das wird 
ihm dann der Compiler schon sagen.

[chester (Gast)]

Ralph schrieb:
> Das geht schöner
aber deine Funktion liefert das letzte Vorkommen des gefundenen Strings,
die ursprüngliche Funktion das erste Vorkommen.

[Ralph (Gast)]

Helmut H. schrieb:
> i<NUM_COMMANDS)&&(a=0) ; i++)
> Das a=0 ist Absicht und MISRA-konform?

neee vertipselung muss "==" sein

chester schrieb:
> aber deine Funktion liefert das letzte Vorkommen des gefundenen Strings,
> die ursprüngliche Funktion das erste Vorkommen.

nein, ebenfalls die erste, da die Schleife mit a != 0 abgebrochen wird.

Karl Heinz schrieb:
> Bei so kurzen und in wenigen Sekunden durschaubaren Funktionen habe ich
> persönlich eigentlich kein Problem, wenn da ein return in einer Schleife
> sitzt, dessen Funktionsweise unmittelbar ersichtlich und auch einfach
> logisch begründbar ist. Das ist für mich einfacher als jede
> Hilfskonstruktion mit diversen Flags, die ihrerseits wieder weitere
> Angriffspunkte für Flüchtigkeitsfehler bieten.

Ja und nein.
Bei einer so einfachen Funktion ist es auch so überschaubar.
Aber wenn man sich das so angewöhnt wird es schwer mit komplexeren 
Funktionen.

Einfacher ist es sich von Anfang an eine solche klare Schreibweise 
anzugewöhnen. Das erleichtert später das Leben wenn die Software mal 
umfangreicher wird.
Und soooo viel mehr Aufwand ist das nu wirklich nicht.

[Ralph (Gast)]

Karl Heinz schrieb:
> Ich hab eher ein Problem mit dem fehlenden return in der
> Originalfunktion, wenn das Kommando nicht gefunden wurde. Aber das wird
> ihm dann der Compiler schon sagen.

Jetzt wo du es sagst, hab ich das doch glatt übersehen.

Das ist halt eine der Gefahren wenn man "return" Anweisungen überall im 
Code verteilt statt diese sauber am Ende der Funktion zu setzen.
Das bedingt allerdings eine zusätzliche (lokale) Variable.

[Karl H. (kbuchegg)]

Ralph schrieb:

> Ja und nein.
> Bei einer so einfachen Funktion ist es auch so überschaubar.
> Aber wenn man sich das so angewöhnt wird es schwer mit komplexeren
> Funktionen.

Du sagst es.
Eine Regel ohne Rücksicht auf Verluste in allen Situationen anzuwenden, 
geht meistens in die Hose.

> Einfacher ist es sich von Anfang an eine solche klare Schreibweise
> anzugewöhnen.

Du hast noch nie Funktionen geschrieben, die tatsächlich im Vorfeld vor 
der eigentlichen Arbeit einen Haufen Vorbedingungen abprüfen müssen? Da 
wimmelt es dann von ineinander geschachtelten if oder so einer Technik

void foo()
{
  int rc = TRUE;

  if( bedingung )
    rc = FALSE;

  if( !rc && bedingung2 )
    rc = FALSE;

  if( !rc && noch was anderes )
    rc = FALSE;

  if( !rc )
  {
    bearbeite die eigentliche AUfgabe
  }
}

was daran jetzt einfacher und klarer sein soll, als vorzeitige Ausstiege 
mittels return, erschliesst sich mir nicht.

Diese allgemein anerkannten Regeln sind nicht in Stein gemeisselt mit 
Blitzschlag, wenn man dagegen verstösst. Es sind Leitlinien, die man im 
Einzelfall je nach Situation auch schon mal ignorieren darf und kann.