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;
}







9
















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?










share|improve this 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 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








  • 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


















9
















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?










share|improve this 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 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








  • 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














9












9








9


3







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?










share|improve this question

















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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








  • 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











  • 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





    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












2 Answers
2






active

oldest

votes


















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).






share|improve this answer





















  • 2





    I'd use constexpr 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 a volatile in its a deal!

    – Eljay
    Jan 31 at 18:16



















1














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.






share|improve this answer


























  • 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


















2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









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).






share|improve this answer





















  • 2





    I'd use constexpr 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 a volatile in its a deal!

    – Eljay
    Jan 31 at 18:16
















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).






share|improve this answer





















  • 2





    I'd use constexpr 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 a volatile in its a deal!

    – Eljay
    Jan 31 at 18:16














5












5








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).






share|improve this answer















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).







share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 31 at 17:58

























answered Jan 31 at 17:28









Lightness Races in OrbitLightness Races in Orbit

296k55480820




296k55480820








  • 2





    I'd use constexpr 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 a volatile in its a deal!

    – Eljay
    Jan 31 at 18:16














  • 2





    I'd use constexpr 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 a volatile 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













1














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.






share|improve this answer


























  • 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
















1














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.






share|improve this answer


























  • 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














1












1








1







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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








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



















  • 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



Popular posts from this blog

If I really need a card on my start hand, how many mulligans make sense? [duplicate]

Alcedinidae

Can an atomic nucleus contain both particles and antiparticles? [duplicate]