Q:

error: expected identifier before '=' token

I am trying to compile a library.
class ROCKETCORE_API Property
{
public:
enum Unit
{
    UNKNOWN = 1 << 0,

    KEYWORD = 1 << 1,           // generic keyword; fetch as < int >

    STRING = 1 << 2,            // generic string; fetch as < String >

    // Absolute values.
    NUMBER = 1 << 3,            // number unsuffixed; fetch as < float >
    PX = 1 << 4,                // number suffixed by 'px'; fetch as < float >
    COLOUR = 1 << 5,            // colour; fetch as < Colourb >
    ABSOLUTE_UNIT = NUMBER | PX | COLOUR,

    // Relative values.
    EM = 1 << 6,                // number suffixed by 'em'; fetch as < float >
    PERCENT = 1 << 7,           // number suffixed by '%'; fetch as < float >
    RELATIVE_UNIT = EM | PERCENT,

    // Values based on pixels-per-inch.
    IN = 1 << 8,                //<<----LINE 66----- number suffixed by 'in'; fetch as < float >
    CM = 1 << 9,                // number suffixed by 'cm'; fetch as < float >
    MM = 1 << 10,               // number suffixed by 'mm'; fetch as < float >
    PT = 1 << 11,               // number suffixed by 'pt'; fetch as < float >
    PC = 1 << 12,               // number suffixed by 'pc'; fetch as < float >
    PPI_UNIT = IN | CM | MM | PT | PC
};

Error output is:
Property.h:66:6: error: expected identifier before '=' token
Property.h:66:6: error: expected '}' before '=' token
Property.h:66:6: error: expected unqualified-id before '=' token

And there are other errors which I believe caused by this enum not being defined correctly.
Any idea why this happens?
Using MinGW 4.7.2 with Eclipse.

A:

A typical problem in such cases is a conflict with some macro name defined in some header you included. In your case that would be IN, which in some implementations (MS?) is used as a macro for designating input parameters in functions.
A good idea would be to give your enum constants a prefix, like UNIT_UNKNOWN instead of just UNKNOWN. Alternatively, you can do #undef IN after including all "system" headers, but this approach can easily end up being very "high maintenance". A better idea would be, again, to avoid using short all-caps identifiers.

