9

I am used to using enum as constants -- they're quick to write, can be placed in .h files, and work fine.

enum {BOX_LEFT=10, BOX_TOP=50, BOX_WIDTH=100, BOX_HEIGHT=50};
enum {REASONS_I_LIKE_ENUM_AS_CONSTANTS = 3};

Is this no longer a good idea?

I see good reasons to prefer enum class (conventional enums implicitly convert to int; conventional enums export their enumerators to the surrounding scope), but those are reasons to prefer old enum in this case.

I see in a thread on static constexpr int vs old-fashioned enum that old-style enum is better because with a static constexpr member you have to declare it outside the class as well. But this is apparently no longer true in C++17, and may only apply to class members anyway.

What's the preferred way in c++17?

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
Topological Sort
  • 2,733
  • 2
  • 27
  • 54
  • Not sure how best to handle this. I have accepted an answer here. I agree that the questions are the same. This one is slightly older (2 hours!) and was answered slightly earlier (1 hour!). But I also like the winning answer on the other thread, maybe better, because it clarifies about `static`. – Topological Sort Feb 03 '19 at 20:59
  • Yeah, not sure. I actually wrote the same answer here, and a moderator deleted my answer, claiming that if the answer is the same, I should flag the question as duplicate, so I did that. See as well the other linked question in my (deleted) answer: [Should `const` and `constexpr` variables in headers be `inline` to prevent ODR violations?](https://stackoverflow.com/questions/53794625/should-const-and-constexpr-variables-in-headers-be-inline-to-prevent-odr-v) – Acorn Feb 04 '19 at 20:03
  • 1
    I just clicked on "THat solved my problem!" which it says will direct users to the other page, and prevent new answers here, which is fine. – Topological Sort Feb 04 '19 at 20:25

2 Answers2

5

This is subjective.

However, this was always an abuse of enums. You're not enumerating anything; you're just stealing the enum feature to get some unrelated with arbitrary integer values which are not intended to have their own logical "type".

That's why enum class is not appropriate here either (because, as you pointed out, enum class enforces the properties of an enum that should be there but which you do not actually want).

Since there's no longer any problem with static constexpr int, I'd use that (or constexpr inline int, or whatever it is this week).

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
0

The example that you give for using enum's can be rewritten as:

struct Point
{
    int x;
    int y;
};

struct Box
{
    Point p;

    int width;
    int height;
};

constexpr Box b = { { 1, 2 }, 3, 4 };

int f()
{
    return b.p.x;
}

Using strong types instead of int could even be a benefit.

For me this is more legible. I could even add some functions into that.

Robert Andrzejuk
  • 5,076
  • 2
  • 22
  • 31