Forum: PC-Programmierung [C] enum nicht erkannt


von pictoman (Gast)


Lesenswert?

Hallo,

ich bin doof.
1
/* header.h */
2
enum{
3
 A,
4
 B
5
};
1
/* prog.c */
2
3
long getDingsBums();
4
5
main(){
6
  if ( A == getDingsBums )
7
    return 1;
8
  return 0;

1.) prog.c kennt die enums nicht.
2.) enum nix long.

Du schlau? Du machen gut?

von Rene H. (Gast)


Lesenswert?

Das ist jetzt aber nicht Dein ernst? Formuliere das bitte nochmals 
anständig. Ok?

von Daniel A. (daniel-a)


Lesenswert?

pictoman schrieb:
> ich bin doof.

Da kann ich dir nur zustimmen, das fängt damit an, dass du versuchst ein 
Enum mit einer Funktion zu vergleichen, geht damit weiter das du die 
Funktionsdeklaration nicht in den header schreibst, für das Enum viel zu 
generische Namen nimmst und in prog.c das 'include "header.h"' fehlt, 
und endet damit, das bei der Main die schliessende geschweifte Klammer 
fehlt.

Aber immerhin ist die Einrückung gut und du hast Codetags (wenn auch die 
falschen) verwendet, das ist schon mal mehr als man hier manchmal sonst 
so sieht.

Jetzt musst du noch etwas an deinen Schreibkünsten und deinem 
Selbstwertgefühl arbeiten, und viel viel üben, dann wirst du irgendwann 
vielleicht sogar ein ganz ordentlicher Programmierer.

Edit: Du solltest auch noch ein int vor das main schreiben

: Bearbeitet durch User
von pictoman (Gast)


Lesenswert?

Hallo,

ich bin die Lehrerin von pictoman.
Ich habe ihn ermutigt hier zu schreiben. Seine Sprachfähigkeiten sollten 
ausreichend sein.
Es kann nicht sein, dass sich eine elitäre Klasse über eine 
vermeintliche Bildungssprache abgrenzt. Teilt euer Wissen mit allen 
Menschen!
Nur auf dem untersten Niveau sind wir alle gleich.

von Kaj (Gast)


Lesenswert?

pictoman schrieb:
> Hallo,
> ich bin doof.
Hallo doof, wie gehts?

von pictoman (Gast)


Lesenswert?

Also gut, bleiben wir nochmal ernst :)


getDingsBums() gibt mir etwas vom Typ long zurück (leider nicht 
änderbar). Die möglichen Rückgabewerte sind allerdings begrenzt, weshalb 
ich ENUM verwenden wollte.

Der Rückgabewert soll dann in ein SWITCH-CASE verglichen werden.

Sollte ich vielleicht ein TYPECAST machen? Ist das elegant?
1
if ( A == (my_t) getDingsBums() )

von Daniel A. (daniel-a)


Lesenswert?

Wenn es um ein switch case geht würde ich so vorgehen: (alles 
ungetestet)
1
/* header.h */
2
3
enum dingsbumbs {
4
  DINGS_BLUE,
5
  DINGS_RED,
6
  DINGS_COUNT,
7
  DINGS_INVALID = -1
8
};
9
10
long getDingsBums( void );
1
/* prog.c */
2
#include "header.h"
3
4
int main(){
5
6
  enum dingsbumbs dings;
7
  {
8
    unsigned long tmp = getDingsBums();
9
    dings = tmp < DINGS_COUNT ? tmp : DINGS_INVALID;
10
  }
11
12
  switch( dings ){
13
    case DINGS_BLUE:
14
      return 1;
15
    default:
16
      return 0;
17
  }
18
19
}

: Bearbeitet durch User
von pictoman (Gast)


Lesenswert?

Danke, so war das gedacht.

Dieses Konstrukt ist mir unbekannt. Kannst du dazu etwas sagen?
1
  enum dingsbumbs dings;
2
  {
3
    unsigned long tmp = getDingsBums();
4
    dings = tmp < DINGS_COUNT ? tmp : DINGS_INVALID;
5
  }
Haben die Scope-Klammern etwas zu bedeuten, oder hast du die nur zur 
Übersicht gesetzt?
Wie darf ich das 'tmp < DINGS_COUNT' verstehen? Ist das nicht ein 
bisschen instabil, oder ist DINGS_COUNT wirklich immer das kleinste 
Enumerierte?

In einer anderen Datei möchte ich einen ENUM-Wert als Parameter 
übergeben. Wieder ist der Parametertyp mit long vorgegeben.
Passt das so?
1
/* p2.c */
2
3
void foo( long dong);
4
5
int main(){
6
7
  enum dingsbums dings;
8
  {
9
    foo( (long) DINGS_BLUE );
10
  }
11
}

von Daniel A. (daniel-a)


Lesenswert?

pictoman schrieb:
> Haben die Scope-Klammern etwas zu bedeuten, oder hast du die nur zur
> Übersicht gesetzt?

Die Scope-Klammern sind nur da, damit tmp nur in dem durch die Klammern 
begrenzten Bereich vorhanden ist. Ansonsten erfüllen sie keinen Zweck.

pictoman schrieb:
> Wie darf ich das 'tmp < DINGS_COUNT' verstehen? Ist das nicht ein
> bisschen instabil, oder ist DINGS_COUNT wirklich immer das kleinste
> Enumerierte?

Grundsätzlich können numerische werte wie int, long oder enumtypen 
einander direkt zugewiesen werden, aber dessen Wertebereich kann sich 
unterscheiden, wodurch soetwas zu einem Integeroverflow führen könnte.

Bei einem Enum ist das erste Element, sofern nicht explizit ein wert 
festgelegt wird, 0. Jeder anderer enum-Wert ist der Vorhergehende plus 
1, sofern nicht explizit ein wert festgelegt wird.

Solange also den Enum werten vor DINGS_COUNT kein Wert zugewiesen wird 
ist der wert von DINGS_COUNT die Anzahl der vorhergehenden enum werte.

Mit der Zuweisung an eine unsigned long variable habe ich 
sichergestellt, dass der Wertebereich von tmp nicht verkleinert wird, 
aber auch keine negativen Zahlen enthält, somit ist jeder Wert von tmp, 
der nicht im enum dingsbumbs enthalten ist, grösser oder gleich 
DINGS_COUNT, und alle anderen somit kleiner als DINGS_COUNT.

pictoman schrieb:
> In einer anderen Datei möchte ich einen enum-Wert als Parameter
> übergeben.

Das kann man direkt machen, es ist eher unwarscheinlich, dass das der 
Wertebereich eines long kleiner als der eines enums ist:
1
void foo( long dong );
2
3
int main(){
4
  foo( DINGS_BLUE );
5
}

Theoretisch könnte man noch mit static_assert überprüfen, ob der 
grösste wert des Enum in ein long passt, aber ich glaube nicht das das 
je irgendjemand gemacht hat.

: Bearbeitet durch User
von pictoman (Gast)


Lesenswert?

Ich habe noch das Problem, dass die C-Datei die enum-Werte nicht kennt, 
die im Header definiert wurden.
1
/* header.h */
2
3
enum dingsbumbs {
4
  DINGS_BLUE,
5
  DINGS_RED,
6
  DINGS_COUNT,
7
  DINGS_INVALID = -1
8
};
1
/* prog.c */
2
#include header.h
3
4
foo ( DINGS_BLUE ); // ERR: could not be resolved

von Daniel A. (daniel-a)


Lesenswert?


von pictoman (Gast)


Lesenswert?

Nee, in der echten Datei ist das schon richtig.
(Ich denke, das falsche Include meintest du)
1
/* prog.c */
2
#include "header.h"
3
4
foo ( DINGS_BLUE ); // ERR: could not be resolved
Error bleibt aber bestehen.

von Daniel A. (daniel-a)


Lesenswert?

Wie ist denn die volständige fehlermeldung? Könnte es sein das die ist, 
dass das Symbol foo nicht aufgelöst wird? In dem fall wäre es ein Linker 
fehler, der dadurch entsteht, das das Objectfile oder die Library oder 
das C-File das die Funktion enthält, und das, welches sie nutzt, beim 
Linkbefehl nicht zusammengelinkt werden.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

pictoman schrieb:
> Error bleibt aber bestehen.

Und die Fehlermeldung über der Zeile "ERR: could not be resolved"?

Fange bei den Fehlermeldungen oben an und nicht am Ende.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.