C++17: still using enums as constants? [duplicate]
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
This question already has an answer here:
Replacing constants: when to use static constexpr and inline constexpr?
2 answers
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?
c++ enums c++17
marked as duplicate by Acorn, Community♦ Feb 4 at 20:25
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
This question already has an answer here:
Replacing constants: when to use static constexpr and inline constexpr?
2 answers
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?
c++ enums c++17
marked as duplicate by Acorn, Community♦ Feb 4 at 20:25
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
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 aboutstatic
.
– Topological Sort
Feb 3 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: Shouldconst
andconstexpr
variables in headers beinline
to prevent ODR violations?
– Acorn
Feb 4 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 4 at 20:25
add a comment |
This question already has an answer here:
Replacing constants: when to use static constexpr and inline constexpr?
2 answers
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?
c++ enums c++17
This question already has an answer here:
Replacing constants: when to use static constexpr and inline constexpr?
2 answers
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?
This question already has an answer here:
Replacing constants: when to use static constexpr and inline constexpr?
2 answers
c++ enums c++17
c++ enums c++17
edited Jan 31 at 17:24
Nicol Bolas
293k34483660
293k34483660
asked Jan 31 at 17:11
Topological SortTopological Sort
1,5891432
1,5891432
marked as duplicate by Acorn, Community♦ Feb 4 at 20:25
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by Acorn, Community♦ Feb 4 at 20:25
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
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 aboutstatic
.
– Topological Sort
Feb 3 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: Shouldconst
andconstexpr
variables in headers beinline
to prevent ODR violations?
– Acorn
Feb 4 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 4 at 20:25
add a comment |
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 aboutstatic
.
– Topological Sort
Feb 3 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: Shouldconst
andconstexpr
variables in headers beinline
to prevent ODR violations?
– Acorn
Feb 4 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 4 at 20:25
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 3 at 20:59
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 3 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?– Acorn
Feb 4 at 20:03
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?– Acorn
Feb 4 at 20:03
1
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 4 at 20:25
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 4 at 20:25
add a comment |
2 Answers
2
active
oldest
votes
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).
2
I'd useconstexpr inline
, but maybe that's just me :)
– Rakete1111
Jan 31 at 17:30
1
Well whatever you get the point :P
– Lightness Races in Orbit
Jan 31 at 17:30
8
Feature abuse? In C++!? :O
– StoryTeller
Jan 31 at 18:00
3
constexpr inline const static register int
.
– Sombrero Chicken
Jan 31 at 18:02
Add in avolatile
in its a deal!
– Eljay
Jan 31 at 18:16
add a comment |
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.
For anyone reading this: strong types are explained here: fluentcpp.com/2016/12/08/strong-types-for-strong-interfaces
– Topological Sort
Feb 1 at 14:49
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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).
2
I'd useconstexpr inline
, but maybe that's just me :)
– Rakete1111
Jan 31 at 17:30
1
Well whatever you get the point :P
– Lightness Races in Orbit
Jan 31 at 17:30
8
Feature abuse? In C++!? :O
– StoryTeller
Jan 31 at 18:00
3
constexpr inline const static register int
.
– Sombrero Chicken
Jan 31 at 18:02
Add in avolatile
in its a deal!
– Eljay
Jan 31 at 18:16
add a comment |
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).
2
I'd useconstexpr inline
, but maybe that's just me :)
– Rakete1111
Jan 31 at 17:30
1
Well whatever you get the point :P
– Lightness Races in Orbit
Jan 31 at 17:30
8
Feature abuse? In C++!? :O
– StoryTeller
Jan 31 at 18:00
3
constexpr inline const static register int
.
– Sombrero Chicken
Jan 31 at 18:02
Add in avolatile
in its a deal!
– Eljay
Jan 31 at 18:16
add a comment |
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).
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).
edited Jan 31 at 17:58
answered Jan 31 at 17:28
Lightness Races in OrbitLightness Races in Orbit
296k55480820
296k55480820
2
I'd useconstexpr inline
, but maybe that's just me :)
– Rakete1111
Jan 31 at 17:30
1
Well whatever you get the point :P
– Lightness Races in Orbit
Jan 31 at 17:30
8
Feature abuse? In C++!? :O
– StoryTeller
Jan 31 at 18:00
3
constexpr inline const static register int
.
– Sombrero Chicken
Jan 31 at 18:02
Add in avolatile
in its a deal!
– Eljay
Jan 31 at 18:16
add a comment |
2
I'd useconstexpr inline
, but maybe that's just me :)
– Rakete1111
Jan 31 at 17:30
1
Well whatever you get the point :P
– Lightness Races in Orbit
Jan 31 at 17:30
8
Feature abuse? In C++!? :O
– StoryTeller
Jan 31 at 18:00
3
constexpr inline const static register int
.
– Sombrero Chicken
Jan 31 at 18:02
Add in avolatile
in its a deal!
– Eljay
Jan 31 at 18:16
2
2
I'd use
constexpr inline
, but maybe that's just me :)– Rakete1111
Jan 31 at 17:30
I'd use
constexpr inline
, but maybe that's just me :)– Rakete1111
Jan 31 at 17:30
1
1
Well whatever you get the point :P
– Lightness Races in Orbit
Jan 31 at 17:30
Well whatever you get the point :P
– Lightness Races in Orbit
Jan 31 at 17:30
8
8
Feature abuse? In C++!? :O
– StoryTeller
Jan 31 at 18:00
Feature abuse? In C++!? :O
– StoryTeller
Jan 31 at 18:00
3
3
constexpr inline const static register int
.– Sombrero Chicken
Jan 31 at 18:02
constexpr inline const static register int
.– Sombrero Chicken
Jan 31 at 18:02
Add in a
volatile
in its a deal!– Eljay
Jan 31 at 18:16
Add in a
volatile
in its a deal!– Eljay
Jan 31 at 18:16
add a comment |
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.
For anyone reading this: strong types are explained here: fluentcpp.com/2016/12/08/strong-types-for-strong-interfaces
– Topological Sort
Feb 1 at 14:49
add a comment |
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.
For anyone reading this: strong types are explained here: fluentcpp.com/2016/12/08/strong-types-for-strong-interfaces
– Topological Sort
Feb 1 at 14:49
add a comment |
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.
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.
edited Jan 31 at 20:44
answered Jan 31 at 19:26
Robert AndrzejukRobert Andrzejuk
3,15421528
3,15421528
For anyone reading this: strong types are explained here: fluentcpp.com/2016/12/08/strong-types-for-strong-interfaces
– Topological Sort
Feb 1 at 14:49
add a comment |
For anyone reading this: strong types are explained here: fluentcpp.com/2016/12/08/strong-types-for-strong-interfaces
– Topological Sort
Feb 1 at 14:49
For anyone reading this: strong types are explained here: fluentcpp.com/2016/12/08/strong-types-for-strong-interfaces
– Topological Sort
Feb 1 at 14:49
For anyone reading this: strong types are explained here: fluentcpp.com/2016/12/08/strong-types-for-strong-interfaces
– Topological Sort
Feb 1 at 14:49
add a comment |
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 3 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
andconstexpr
variables in headers beinline
to prevent ODR violations?– Acorn
Feb 4 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 4 at 20:25