#define typedefs

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • #define typedefs

      I have some classes that I like to compile into a core lib so I can use them easily in upcoming projects. My idea now is to typedef common types like e.g. Byte, Word, DWord, etc but also something like Index16 and Index32. Some of these types may be already defined in other headers ( windows.h for example ).

      What is the common strategy to do this?
      Do I have to keep some special including order?


      This is my idea at the moment:
      I have several classes in my core module ( one .h and .cpp file for each class ). Then I define one master header ( the only public header for this module ) let's call it core.h using the following structure:

      C Source Code

      1. // First we define/typedef the basic types which is done
      2. // platform dependent in seperate headers
      3. #ifdef _WIN32
      4. #include <Win32Types.h>
      5. #endif
      6. #ifdef SOMETHING_ELSE
      7. ...
      8. #endif
      9. // Define anything else
      10. // Then I include the class header of the module
      11. #include <Vector.h>
      12. #include <Matrix.h>
      13. #include <Archive.h>
      Display All


      All comments are welcome!!

      Best regards

      -Dirk
    • RE: #define typedefs

      The only problem you'll find with this solution is the amount of recompiling you'll do when you make a single change to any of the header files included in core.h.

      If your core library is basically stable, and you almost never recompile it, this is a fine way to do it. Most SDKs are arranged this way, with a very small number of #include files that #include everythig else.

      If you are still rapidly developing your library, the best thing to do is try to factor the most stable portions into the single core.h, and #include everything else as needed to minimize huge recompiles.

      One other good bit of advice - factor the public interface into their own header files. If you've designed your system well, those files won't be changing too much, they'll be smaller and easier to read, and you won't have such a horrible recompile problem.
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • Windows headers have several XXXXX_DEFINDED pre-processor macro that you could use

      #if defined(_WIN32) && defined(_HRESULT_DEFINED)

      [code]

      #endif

      The approach I use is to prefix my types with a library specific tag. It can help me spot trouble when I see a something going into my library function doesn't match the library's prefix

      gb