Extraneous typedefs in PosChengband

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Therem Harth
    Knight
    • Jan 2008
    • 926

    Extraneous typedefs in PosChengband

    With 1.0.21:

    Code:
    $ 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
    PosChengband Maintainer
    • Jan 2008
    • 702

    #2
    Originally posted by Therem Harth
    With 1.0.21:

    Code:
    $ 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.

    Comment

    • chris
      PosChengband Maintainer
      • Jan 2008
      • 702

      #3
      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):
      Code:
      /* 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

      Comment

      • AnonymousHero
        Veteran
        • Jun 2007
        • 1393

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

        Code:
        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.

        Comment

        • chris
          PosChengband Maintainer
          • Jan 2008
          • 702

          #5
          Originally posted by AnonymousHero
          If I'm understanding you correctly, then adding a "foo_fwd.h" file containing

          Code:
          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.

          Comment

          • AnonymousHero
            Veteran
            • Jun 2007
            • 1393

            #6
            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...

            Comment

            • takkaria
              Veteran
              • Apr 2007
              • 1951

              #7
              I think both a. foo.h including bar.h and b. using
              Code:
              struct bar_s
              instead of
              Code:
              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.
              takkaria whispers something about options. -more-

              Comment

              • AnonymousHero
                Veteran
                • Jun 2007
                • 1393

                #8
                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.)

                Comment

                • chris
                  PosChengband Maintainer
                  • Jan 2008
                  • 702

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

                  Comment

                  Working...
                  😀
                  😂
                  🥰
                  😘
                  🤢
                  😎
                  😞
                  😡
                  👍
                  👎