Extraneous typedefs in PosChengband

[Therem Harth]

With 1.0.21:

$ make -f makefile.linux 
gcc -Wall -O2 -fno-strength-reduce -pipe -g -D"USE_X11" -D"USE_GCU" -I/usr/X11R6/include   -c -o archaeologist.o archaeologist.c
In file included from angband.h:57:0,
                 from archaeologist.c:5:
fear.h:4:29: error: redefinition of typedef ‘monster_type’
types.h:589:29: note: previous declaration of ‘monster_type’ was here
In file included from angband.h:58:0,
                 from archaeologist.c:5:
equip.h:71:16: error: redefinition of typedef ‘object_p’
externs.h:1325:16: note: previous declaration of ‘object_p’ was here
make: *** [archaeologist.o] Error 1

There are unnecessary typedefs in fear.h (line 4), equip.h (71), and bldg.c (3296 IIRC) that will prevent the game from compiling (at least on Linux). Removing those extra typedefs makes it compile normally.

Note BTW that this is 32-bit Linux, not 64. I'm also using a custom GrSecurity kernel, though I don't think that matters in this case.

[chris]

Originally Posted by Therem Harth

With 1.0.21:

$ make -f makefile.linux 
gcc -Wall -O2 -fno-strength-reduce -pipe -g -D"USE_X11" -D"USE_GCU" -I/usr/X11R6/include   -c -o archaeologist.o archaeologist.c
In file included from angband.h:57:0,
                 from archaeologist.c:5:
fear.h:4:29: error: redefinition of typedef ‘monster_type’
types.h:589:29: note: previous declaration of ‘monster_type’ was here
In file included from angband.h:58:0,
                 from archaeologist.c:5:
equip.h:71:16: error: redefinition of typedef ‘object_p’
externs.h:1325:16: note: previous declaration of ‘object_p’ was here
make: *** [archaeologist.o] Error 1

There are unnecessary typedefs in fear.h (line 4), equip.h (71), and bldg.c (3296 IIRC) that will prevent the game from compiling (at least on Linux). Removing those extra typedefs makes it compile normally.

Note BTW that this is 32-bit Linux, not 64. I'm also using a custom GrSecurity kernel, though I don't think that matters in this case.

Odd. It works without a hitch for me on latest Linux Mint (64-bit) using gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2. You haven't made any changes to makefile.linux have you?

I'm not near my Windows box at the moment, and will move the extra typedefs next chance I get.

[chris]

Can somebody give me some help with C programming? I'm not a C programmer by trade and am curious what might be the best practice for achieving a modular design in C. Here is a hypothetical example where there are two modules, foo and bar, and a client that consumes foo. Module foo depends on bar, but client does not care about that part of the api, or if client does, perhaps client only needs to use bar's types in an abstract way.

My best guess at how to achieve this is as follows (Note foo.h does not include bar.h):

/* bar.h */
...
struct bar_s { ... };
typedef struct bar_s bar_t;
...

/* foo.h */
...
struct bar_s;
struct foo_s {
  ...
  struct bar_s *bar;
  ...
};

typedef struct foo_s foo_t;

void foo_api1(struct bar_s *bar, ...);
void foo_api2(void);
...
foo_t *foo_alloc(void);
void foo_free(foo_t *foo);
...

/* client.c */
#include "foo.h"

...
void f(void)
{
  foo_api2();
  ...
}

However, I don't see a way to avoid the "struct bar_s *" syntax and use the "bar_t *" syntax instead, if multiple identical typedefs are illegal.

Thanks in advance!

And yes, non-C programmers probably have no business maintaining Angband variants

[AnonymousHero]

If I'm understanding you correctly, then adding a "foo_fwd.h" file containing

struct foo;
typedef *foo foo_ptr_t;

and having both "foo.h" and "bar.h" include that file instead of doing typedef themselves should be ok AFAICS.

... but then I don't have a compiler at hand and I'm more used to C++, so YMMV. The "_fwd" thing is definitely a convention from C++, more specifically the Boost library is where I first encountered it.

Also, I may have mixed up my foo's and bar's relative to your example, but I hope you get the gist of it.

[chris]

Originally Posted by AnonymousHero

If I'm understanding you correctly, then adding a "foo_fwd.h" file containing

struct foo;
typedef *foo foo_ptr_t;

and having both "foo.h" and "bar.h" include that file instead of doing typedef themselves should be ok AFAICS.

... but then I don't have a compiler at hand and I'm more used to C++, so YMMV. The "_fwd" thing is definitely a convention from C++, more specifically the Boost library is where I first encountered it.

Also, I may have mixed up my foo's and bar's relative to your example, but I hope you get the gist of it.

Yeah, I thought of that approach but I personally don't like it

I'd rather the entire module interface be in a single header file, and would rather not add lots of tiny header files. I guess my question is what is idiomatic in C for this situation.

[AnonymousHero]

Well, you don't have to add lots of files. You can always do a single types_fwd.h which contains all the forward decls + typedefs.

AFAIK there are no other solutions unless you want to get really dirty with #ifdef's... but even the C crowd is shying away from preprocessor hacks these days, so...

[takkaria]

I think both a. foo.h including bar.h and b. using

struct bar_s

instead of

bar_t

are idiomatic; I've seen both of them used in different places. There's a POSIX interface (I don't remember which one) that uses an opaque struct and of course C itself uses the typedef for FILE *, and anything that wants to use that has to include stdio.h. It's a matter of taste in the end.

[AnonymousHero]

That's a good point. My excuse is that I was trying to answer the "question asked" instead of "what are you trying to achieve?".

I agree with Takkaria that just consistently using "struct X" is actually the best way to handle this kind of thing. (Again, because of C++, actually. There are various situations where a plain type is ambiguous.)

[chris]

Thanks for the feedback. I think I prefer the "struct bar_s" to the "bar_t" approach ...