Use of all-caps macro-style names for enum members collides with macros

[ogrant]

Hi,

The Type enum defined in format.h uses all uppercase names for its members which easily collides with macro names, especially as those names are commonly used by C libraries:

  enum Type {
    NONE, NAMED_ARG,
    // Integer types should go first,
    INT, UINT, LONG_LONG, ULONG_LONG, BOOL, CHAR, LAST_INTEGER_TYPE = CHAR,
    // followed by floating-point types.
    DOUBLE, LONG_DOUBLE, LAST_NUMERIC_TYPE = LONG_DOUBLE,
    CSTRING, STRING, WSTRING, POINTER, CUSTOM
  };

Great library btw.

Thanks,

O.

[vitaut]

Did you have a collision with any specific name? Normally it's easy to fix this by ordering includes but I'm open to changing some names if there are collisions with a widely used C library.

[t-b]

@vitaut Are these constants for users? If not I'd rather either convert them to enum class if you are targeting C++11 or put them into a detail namespace.

[vitaut]

@t-b They are already in the internal namespace, but the question here is collision with global macros.

[LarsGullik]

I see collisions as well, up until now I have modified locally the names to have a FMT_ prefix.
In particular LONG_LONG has been a culprit. (I sent a patch that fixes it in the way that we have done internally, you might want to do something else.)

[ogrant]

Sorry for not getting back to you earlier.

I think in this particular case, it was ruby.h, which is probably not very popular.

But independently from that, I would humbly argue that giving C++ enums all caps names, especially one as common as LONG_LONG which is used in many C libs is just asking for trouble. I would suggest moving to a more C++ naming convension (eName or kName), or basically anything else than all caps.

[vitaut]

Fixed in 8ed264f.

[ogrant]

Thanks!