Practice of having a "Common" header [closed]

Question

By common I don't mean utility, I mean a header that holds enums that multiple types want to use, etc.

For example, if multiple types can have a Color, which is an enum, you'd want to make that available. Some people would say to put it into the class that it "fits best with", but this can create header dependency issues.

I really dislike creating a header that contains things like this, because it seems like it makes the code more complex. I'm looking for other's thoughts on what techniques they employ when they run into a situation like this. If they use a "Common" header, etc.

Answer 1

I always use a Common.h file that almost never changes and contains definitions that are extremely likely to be needed in virtually all files. I think it increases productivity so that you don't have to open another .cpp file and copy the list of all the headers you know you'll definitely need.

For example, here are two excerpts from my Common.h:

typedef unsigned char uint8;
typedef signed char int8;
typedef unsigned char uint08;
typedef signed char int08;
typedef unsigned short uint16;
typedef signed short int16;
typedef unsigned int uint32;
typedef signed int int32;
typedef unsigned long long uint64;
typedef signed long long int64;
typedef const char cchar;
typedef const bool cbool;
typedef char Byte;

#ifdef ASSERT
/* Re-defining assert */
#undef ASSERT
#endif

#ifdef DEBUG
#ifndef ASSERTIONS
#define ASSERTIONS
#endif
#endif

#define ASSERT_ALWAYS(Expression)   if (!(Expression)) FatalError(ErrorInfo("Assertion Failure", #Expression, FUNCTION_NAME, __FILE__, __LINE__))

#ifdef ASSERTIONS
#ifdef DEBUG
#define ASSERT(Expression)   ASSERT_ALWAYS(Expression)
#else
#define ASSERT(Expression)   if (!(Expression)) ErrorLog("[Release Assertions]: The following assertion failed: " # Expression)
#endif
#else
#define ASSERT(Expression)
#endif

Answer 2

Common header is ok as long as there are only a few people working on your project. Once you have 20+ people editing that file and merging changes back and forth, you start to have a nightmare.

Perhaps an alternative would be to have a color.h or a common/color.h file, which would enforce some structure on your files.