Problem mit typedef und enum

[Michael S. (stroggi)]

Hi zusammen,

ich habe in der header-Datei "gcode_handler.h" zwei enums definiert, 
welche ich mit typedef zu den Typen "gcode_handler_type_t" und 
"gcode_handler_state_t" definiere. Wenn ich diese nun in dieser 
header-Daei oder in der zugehörigen C-Datei verwende, dann kann ich die 
Bezeichner einwandfrei als Typen verwenden.
Nun möchte ich die Bezeichner "gcode_handler_type_t" und 
"gcode_handler_state_t" aber auch in einer anderen header- und C-Datei 
verwenden allerdings spuckt der Compiler dann folgendes aus:

Error  6  expected ')' before 'type'  H:\...\command_buffer.h  10  55
Error  5  expected specifier-qualifier-list before 'gcode_handler_type_t'  H:\...\command_buffer.h  5  5

Inhalt von gcode_handler.h:

 1:  enum gcode_handler_type_t_ {
 2:    GCODE_TYPE_IMMEDIATE,
 3:    GCODE_TYPE_SEQUENTIAL,
 4:    GCODE_TYPE_UNDEFINED
 5:  };
 6:  typedef enum gcode_handler_type_t_ gcode_handler_type_t;
 7:
 8:  enum gcode_handler_state_t_ {
 9:    GCODE_STATE_NEW,
10:     GCODE_STATE_RUNNING,
11:    GCODE_STATE_STOPED,
12:    GCODE_STATE_UNDEFINED
13:  };
14:  typedef enum gcode_handler_state_t_ gcode_handler_state_t;
15:
16:  /* initialize*/
17:  void gcode_handler_init();
18:  
19:  gcode_handler_type_t gcode_handler_classify(gcode_cmd_t *gcode_cmd);

Inhalt von command_buffer.h

 1:  #include "gcode_handler.h"
 2:  typedef struct {
 3:    uint8_t                       empty;
 4:    message_buffer_msg_source_t   source;
 5:    gcode_handler_type_t          type;
 6:    gcode_handler_state_t         state;
 7:    gcode_cmd_t                   gcode_cmd;
 8:  } command_buffer_cmd_t;
 9:
10:  uint8_t command_buffer_getNext(gcode_handler_type_t type, gcode_handler_state_t state, command_buffer_cmd_t *cmd);

Ich verwende als Entwicklungsumgebung das AVR Studio 5 (Version 5.1.208) 
mit der AvrGCC Version 5.1.0.0

Vielleicht kann mir jemand von euch bei dem Problem helfen.

Viele Grüße
Stroggi

[Stefan E. (sternst)]

Und wo kommt message_buffer_msg_source_t her?

[Michael S. (stroggi)]

Das ist ein enum, der in einer anderen Datei "message_buffer.h" 
definiert wird:

  enum message_buffer_msg_source_t_ {
    MSG_SOURCE_TTYS0,         // serial interface
    MSG_SOURCE_TTYEXTDISPLAY, // interface of the graphic-display-card
    MSG_SOURCE_TTYINTDISPLAY, // interface of the hd44780-display
    MSG_SOURCE_SYSTEM         // internal message
  };
  typedef enum message_buffer_msg_source_t_ message_buffer_msg_source_t;

Also im Prinzip das gleiche Problem, aber das wird (noch) nicht 
angezeigt.

[Stefan E. (sternst)]

Michael Strosche schrieb:
> Also im Prinzip das gleiche Problem, aber das wird (noch) nicht
> angezeigt.

Nein, DAS ist das Problem, was obige Fehlermeldung auslöst. In der steht 
doch auch, das bereits vor dem Auftauchen von 'gcode_handler_type_t' ein 
Problem aufgetaucht ist.

[Durchblick (Gast)]

Erster Tipp: Fasse die typedef und enum Deklaration zusammen. Das ist 
übersichtlicher.
Zweiter Tipp: Hänge die vollständigen Dateien an, damit die 
Zeilennummern passen.

[Fabian O. (xfr)]

Falls es Dir noch nicht klar ist: Du musst message_buffer.h in 
command_buffer.h inkludieren.

[Michael S. (stroggi)]

So. Hier dann mal die entsprechenden Dateien. Die confg.h hab ich 
beschnitten!

Error  6  expected ')' before 'type'  H:\...\command_buffer.h  32  55
Error  5  expected specifier-qualifier-list before 'gcode_handler_type_t'  H:\...\command_buffer.h  22  5

Viele Grüße
Stroggi

[Stefan E. (sternst)]

Michael Strosche schrieb:
> So. Hier dann mal die entsprechenden Dateien.

Klasse, der echte Code ist in Bezug auf die Include-Logik also ganz 
anders, als dein Code im OP. Das zeigt mal wieder schön, wie sinnvoll es 
ist, Phantasie-Code zu posten statt dem Echten.

Wenn config.h inkludiert wird, wird dort command_buffer.h VOR 
gcode_handler.h eingebunden, also sind dort dann die Sachen aus 
gcode_handler.h noch nicht bekannt.

[Michael S. (stroggi)]

Schön und gut, aber wenn es so eine simple das vor dem Sache wär, dann 
hätt ich bestimmt net hier gefragt, sondern wär selbst drauf gekommen. 
Ich hab das eben nochmal in allen Kombinationen ausprobiert und von 0 an 
neu compilieren lassen. Der Fehler bleibt der selbe.

[Stefan E. (sternst)]

Michael Strosche schrieb:
> Schön und gut, aber wenn es so eine simple das vor dem Sache wär, dann
> hätt ich bestimmt net hier gefragt, sondern wär selbst drauf gekommen.

Wie sieht überhaupt die C-Datei aus, bei deren Übersetzen der Fehler 
kommt? Wird dort direkt einer der spezifischen Header eingebunden, oder 
nur config.h (daraus ergeben sich unterschiedliche Reihenfolgen)? Was 
wird dort sonst noch eingebunden? Ist überhaupt uint8_t dort bekannt?

Ich habe jedenfalls keine große Lust mehr auf Raten.

[Fabian O. (xfr)]

Tu Dir einen Gefallen und inkludiere in den h-Dateien einfach genau das, 
was darin benötigt wird anstatt sämtliche h-Dateien in eine config.h zu 
packen.

[Michael S. (stroggi)]

In den C-Dateien wird der dazugehörige header mit eingebunden. Also zur 
command_buffer.c gehört die command_buffer.h. Sonst wird dort nix 
eingebunden. Über die config.h in den entsprechenden header-dateien ist 
der Rest dann bekannt.
uint8_t ist natürlich bekannt, da in der config.h alle relevanten header 
(  avr/io.h, <stdint.h>, <string.h>, <avr/interrupt.h>, <util/delay.h>, 
<math.h>) VOR allem anderen eingebunden werden.

Des Weiteren habe ich meine Gründe den Code nicht vollständig zu posten, 
da die Logik hinter dem ganzen closed source ist (bzw. sein wird)!

[Stefan E. (sternst)]

Michael Strosche schrieb:
> In den C-Dateien wird der dazugehörige header mit eingebunden. Also zur
> command_buffer.c gehört die command_buffer.h. Sonst wird dort nix
> eingebunden. Über die config.h in den entsprechenden header-dateien ist
> der Rest dann bekannt.

Womit du wieder eine wichtige Information ausgelassen hättest, nämlich 
bei welcher C-Datei denn nun der Fehler kommt. Ein letztes Raten von 
mir: es ist gcode_handler.c. Wenn du das mal schrittweise durchgehst, 
wirst du feststellen, dass dort command_buffer.h immer vor 
gcode_handler.h bearbeitet wird, egal welche Reihenfolge du in config.h 
angibst.

[Michael S. (stroggi)]

Ich hab jetzt in allen c-files die benötigten header inkludiert und aus 
der config verbannt. Seltsamerweise funktionierts jetzt ohne Fehler.

[Stefan E. (sternst)]

Michael Strosche schrieb:
> Ich hab jetzt in allen c-files die benötigten header inkludiert und aus
> der config verbannt. Seltsamerweise funktionierts jetzt ohne Fehler.

Weil jetzt in gcode_handler.c command_buffer.h nicht mehr inkludiert 
wird (und damit natürlich auch nicht mehr in der falschen Reihenfolge 
bezüglich gcode_handler.h).