ABI compatibility preservation with C++11 `enum class`
This is pretty much the same question as Does adding enumerators into enum break ABI?, but with enum class
introduced by C++11.
For what I understand by this page I can simply have a stable ABI by defining an underlying type for my enumerative:
enum class Foo : uint32_t
{
x, y, z
}
I would say this works fine, as for instance something like
enum class Foo : uint8_t { x = 257 }
Will not compile. This implies that the compiler is no longer silently changing the size of my enumerative, thus I don't end up in breaking binary compatibility.
Am I correct?
c++ c++11 binary-compatibility
|
show 1 more comment
This is pretty much the same question as Does adding enumerators into enum break ABI?, but with enum class
introduced by C++11.
For what I understand by this page I can simply have a stable ABI by defining an underlying type for my enumerative:
enum class Foo : uint32_t
{
x, y, z
}
I would say this works fine, as for instance something like
enum class Foo : uint8_t { x = 257 }
Will not compile. This implies that the compiler is no longer silently changing the size of my enumerative, thus I don't end up in breaking binary compatibility.
Am I correct?
c++ c++11 binary-compatibility
Are you implicitly assuming that the added enum values are always appended at the end of the list?
– Frank
Nov 19 '18 at 20:49
The question feels a little narrower than the title suggests.
– Shafik Yaghmour
Nov 20 '18 at 4:27
@Frank, I'm not implicitly assuming that, but if I got it correctly, having an enumerative with a big value helps the compiler in deciding what backing type to use. If we provide explicitly a backing integral type, we will ask the compiler of use a specific size for our enumerative, hence achieving binary compatibility (well, if we don't change the order of enum values, of course)
– Dacav
Nov 20 '18 at 12:41
@ShafikYaghmour, Yeah, maybe you're right. I'll rename that into…
– Dacav
Nov 20 '18 at 12:41
It was implementation-defined before, it still is when you don't specify the underlying type explicitly. The only requirement is that it is big enough to represent the enumerator values. Which is why the second snippet failed. If you need to guarantee binary compatibility then it does depend on what your compiler did previously. Seeing a 32-bit type work is certainly not unusual. That will almost certainly still work when you don't specify it.
– Hans Passant
Nov 20 '18 at 13:11
|
show 1 more comment
This is pretty much the same question as Does adding enumerators into enum break ABI?, but with enum class
introduced by C++11.
For what I understand by this page I can simply have a stable ABI by defining an underlying type for my enumerative:
enum class Foo : uint32_t
{
x, y, z
}
I would say this works fine, as for instance something like
enum class Foo : uint8_t { x = 257 }
Will not compile. This implies that the compiler is no longer silently changing the size of my enumerative, thus I don't end up in breaking binary compatibility.
Am I correct?
c++ c++11 binary-compatibility
This is pretty much the same question as Does adding enumerators into enum break ABI?, but with enum class
introduced by C++11.
For what I understand by this page I can simply have a stable ABI by defining an underlying type for my enumerative:
enum class Foo : uint32_t
{
x, y, z
}
I would say this works fine, as for instance something like
enum class Foo : uint8_t { x = 257 }
Will not compile. This implies that the compiler is no longer silently changing the size of my enumerative, thus I don't end up in breaking binary compatibility.
Am I correct?
c++ c++11 binary-compatibility
c++ c++11 binary-compatibility
edited Nov 20 '18 at 13:06
Dacav
asked Nov 19 '18 at 19:45
DacavDacav
7,02144469
7,02144469
Are you implicitly assuming that the added enum values are always appended at the end of the list?
– Frank
Nov 19 '18 at 20:49
The question feels a little narrower than the title suggests.
– Shafik Yaghmour
Nov 20 '18 at 4:27
@Frank, I'm not implicitly assuming that, but if I got it correctly, having an enumerative with a big value helps the compiler in deciding what backing type to use. If we provide explicitly a backing integral type, we will ask the compiler of use a specific size for our enumerative, hence achieving binary compatibility (well, if we don't change the order of enum values, of course)
– Dacav
Nov 20 '18 at 12:41
@ShafikYaghmour, Yeah, maybe you're right. I'll rename that into…
– Dacav
Nov 20 '18 at 12:41
It was implementation-defined before, it still is when you don't specify the underlying type explicitly. The only requirement is that it is big enough to represent the enumerator values. Which is why the second snippet failed. If you need to guarantee binary compatibility then it does depend on what your compiler did previously. Seeing a 32-bit type work is certainly not unusual. That will almost certainly still work when you don't specify it.
– Hans Passant
Nov 20 '18 at 13:11
|
show 1 more comment
Are you implicitly assuming that the added enum values are always appended at the end of the list?
– Frank
Nov 19 '18 at 20:49
The question feels a little narrower than the title suggests.
– Shafik Yaghmour
Nov 20 '18 at 4:27
@Frank, I'm not implicitly assuming that, but if I got it correctly, having an enumerative with a big value helps the compiler in deciding what backing type to use. If we provide explicitly a backing integral type, we will ask the compiler of use a specific size for our enumerative, hence achieving binary compatibility (well, if we don't change the order of enum values, of course)
– Dacav
Nov 20 '18 at 12:41
@ShafikYaghmour, Yeah, maybe you're right. I'll rename that into…
– Dacav
Nov 20 '18 at 12:41
It was implementation-defined before, it still is when you don't specify the underlying type explicitly. The only requirement is that it is big enough to represent the enumerator values. Which is why the second snippet failed. If you need to guarantee binary compatibility then it does depend on what your compiler did previously. Seeing a 32-bit type work is certainly not unusual. That will almost certainly still work when you don't specify it.
– Hans Passant
Nov 20 '18 at 13:11
Are you implicitly assuming that the added enum values are always appended at the end of the list?
– Frank
Nov 19 '18 at 20:49
Are you implicitly assuming that the added enum values are always appended at the end of the list?
– Frank
Nov 19 '18 at 20:49
The question feels a little narrower than the title suggests.
– Shafik Yaghmour
Nov 20 '18 at 4:27
The question feels a little narrower than the title suggests.
– Shafik Yaghmour
Nov 20 '18 at 4:27
@Frank, I'm not implicitly assuming that, but if I got it correctly, having an enumerative with a big value helps the compiler in deciding what backing type to use. If we provide explicitly a backing integral type, we will ask the compiler of use a specific size for our enumerative, hence achieving binary compatibility (well, if we don't change the order of enum values, of course)
– Dacav
Nov 20 '18 at 12:41
@Frank, I'm not implicitly assuming that, but if I got it correctly, having an enumerative with a big value helps the compiler in deciding what backing type to use. If we provide explicitly a backing integral type, we will ask the compiler of use a specific size for our enumerative, hence achieving binary compatibility (well, if we don't change the order of enum values, of course)
– Dacav
Nov 20 '18 at 12:41
@ShafikYaghmour, Yeah, maybe you're right. I'll rename that into…
– Dacav
Nov 20 '18 at 12:41
@ShafikYaghmour, Yeah, maybe you're right. I'll rename that into…
– Dacav
Nov 20 '18 at 12:41
It was implementation-defined before, it still is when you don't specify the underlying type explicitly. The only requirement is that it is big enough to represent the enumerator values. Which is why the second snippet failed. If you need to guarantee binary compatibility then it does depend on what your compiler did previously. Seeing a 32-bit type work is certainly not unusual. That will almost certainly still work when you don't specify it.
– Hans Passant
Nov 20 '18 at 13:11
It was implementation-defined before, it still is when you don't specify the underlying type explicitly. The only requirement is that it is big enough to represent the enumerator values. Which is why the second snippet failed. If you need to guarantee binary compatibility then it does depend on what your compiler did previously. Seeing a 32-bit type work is certainly not unusual. That will almost certainly still work when you don't specify it.
– Hans Passant
Nov 20 '18 at 13:11
|
show 1 more comment
2 Answers
2
active
oldest
votes
I believe the accepted answer to the referenced question answers most of the issues with respect to ABI compatibility. I could repeat it here but I don't see much value there.
To address you specific question about C++11 scoped enumerations your example:
enum class Foo : uint8_t { x = 257 }
is ill-formed since it requires a narrowing conversion, the implementation is required to provide a diagnostic but it may compile if the implementation only makes it warning for example. As you ask, the compiler won't silently change the size of underlying type.
We can see this from the draft C++ standard dcl.enump5:
Each enumeration defines a type that is different from all other types. Each enumeration also has an underlying type. The underlying type can be explicitly specified using an enum-base. For a scoped enumeration type, the underlying type is int if it is not explicitly specified. In both of these cases, the underlying type is said to be fixed. Following the closing brace of an enum-specifier, each enumerator has the type of its enumeration. If the underlying type is fixed, the type of each enumerator prior to the closing brace is the underlying type and the constant-expression in the enumerator-definition shall be a converted constant expression of the underlying type. If the underlying type is not fixed, the type of each enumerator prior to the closing brace is determined as follows: ...
and converted constant expression forbid narrowing conversion, from expr.constp5:
A converted constant expression of type T is an expression, implicitly converted to type T, where the converted expression is a constant expression and the implicit conversion sequence contains only
...
- integral conversions other than narrowing conversions,
...
1
This does not answer the question, which is about ABI.
– rubenvb
Nov 20 '18 at 6:21
Well, the answer is not about ABI, but it is possibly relevant: if the implementation only raises a warning, could it be that the compiler will allow me to break binary compatibility, should I use a value outside the ranges of my enum type?
– Dacav
Nov 20 '18 at 12:46
@rubenvb - Well, if as the OP put it "the compiler no longer silently changes the underlying type", one can conclude the ABI will stay the same.
– StoryTeller
Nov 20 '18 at 12:47
@rubenvb I don't see the value of repeating the accepted answer to the referenced question. I feel like the real question is quite narrow and I have addressed that. I updated my answer to reflect that more explicitly.
– Shafik Yaghmour
Nov 21 '18 at 2:22
add a comment |
OP here.
I found out, and I think it would be relevant to mention, that C++11 has this nice std::underlying_type.
I think it can be used, together with is_same
and
static assertions, to create some guards against unexpected changes of ABI due to enumeratives.
I think (but I didn't try) that this is especially relevant if one is working with some library, and a pre-existing enumerative is not specifying an underlying type.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53381626%2fabi-compatibility-preservation-with-c11-enum-class%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I believe the accepted answer to the referenced question answers most of the issues with respect to ABI compatibility. I could repeat it here but I don't see much value there.
To address you specific question about C++11 scoped enumerations your example:
enum class Foo : uint8_t { x = 257 }
is ill-formed since it requires a narrowing conversion, the implementation is required to provide a diagnostic but it may compile if the implementation only makes it warning for example. As you ask, the compiler won't silently change the size of underlying type.
We can see this from the draft C++ standard dcl.enump5:
Each enumeration defines a type that is different from all other types. Each enumeration also has an underlying type. The underlying type can be explicitly specified using an enum-base. For a scoped enumeration type, the underlying type is int if it is not explicitly specified. In both of these cases, the underlying type is said to be fixed. Following the closing brace of an enum-specifier, each enumerator has the type of its enumeration. If the underlying type is fixed, the type of each enumerator prior to the closing brace is the underlying type and the constant-expression in the enumerator-definition shall be a converted constant expression of the underlying type. If the underlying type is not fixed, the type of each enumerator prior to the closing brace is determined as follows: ...
and converted constant expression forbid narrowing conversion, from expr.constp5:
A converted constant expression of type T is an expression, implicitly converted to type T, where the converted expression is a constant expression and the implicit conversion sequence contains only
...
- integral conversions other than narrowing conversions,
...
1
This does not answer the question, which is about ABI.
– rubenvb
Nov 20 '18 at 6:21
Well, the answer is not about ABI, but it is possibly relevant: if the implementation only raises a warning, could it be that the compiler will allow me to break binary compatibility, should I use a value outside the ranges of my enum type?
– Dacav
Nov 20 '18 at 12:46
@rubenvb - Well, if as the OP put it "the compiler no longer silently changes the underlying type", one can conclude the ABI will stay the same.
– StoryTeller
Nov 20 '18 at 12:47
@rubenvb I don't see the value of repeating the accepted answer to the referenced question. I feel like the real question is quite narrow and I have addressed that. I updated my answer to reflect that more explicitly.
– Shafik Yaghmour
Nov 21 '18 at 2:22
add a comment |
I believe the accepted answer to the referenced question answers most of the issues with respect to ABI compatibility. I could repeat it here but I don't see much value there.
To address you specific question about C++11 scoped enumerations your example:
enum class Foo : uint8_t { x = 257 }
is ill-formed since it requires a narrowing conversion, the implementation is required to provide a diagnostic but it may compile if the implementation only makes it warning for example. As you ask, the compiler won't silently change the size of underlying type.
We can see this from the draft C++ standard dcl.enump5:
Each enumeration defines a type that is different from all other types. Each enumeration also has an underlying type. The underlying type can be explicitly specified using an enum-base. For a scoped enumeration type, the underlying type is int if it is not explicitly specified. In both of these cases, the underlying type is said to be fixed. Following the closing brace of an enum-specifier, each enumerator has the type of its enumeration. If the underlying type is fixed, the type of each enumerator prior to the closing brace is the underlying type and the constant-expression in the enumerator-definition shall be a converted constant expression of the underlying type. If the underlying type is not fixed, the type of each enumerator prior to the closing brace is determined as follows: ...
and converted constant expression forbid narrowing conversion, from expr.constp5:
A converted constant expression of type T is an expression, implicitly converted to type T, where the converted expression is a constant expression and the implicit conversion sequence contains only
...
- integral conversions other than narrowing conversions,
...
1
This does not answer the question, which is about ABI.
– rubenvb
Nov 20 '18 at 6:21
Well, the answer is not about ABI, but it is possibly relevant: if the implementation only raises a warning, could it be that the compiler will allow me to break binary compatibility, should I use a value outside the ranges of my enum type?
– Dacav
Nov 20 '18 at 12:46
@rubenvb - Well, if as the OP put it "the compiler no longer silently changes the underlying type", one can conclude the ABI will stay the same.
– StoryTeller
Nov 20 '18 at 12:47
@rubenvb I don't see the value of repeating the accepted answer to the referenced question. I feel like the real question is quite narrow and I have addressed that. I updated my answer to reflect that more explicitly.
– Shafik Yaghmour
Nov 21 '18 at 2:22
add a comment |
I believe the accepted answer to the referenced question answers most of the issues with respect to ABI compatibility. I could repeat it here but I don't see much value there.
To address you specific question about C++11 scoped enumerations your example:
enum class Foo : uint8_t { x = 257 }
is ill-formed since it requires a narrowing conversion, the implementation is required to provide a diagnostic but it may compile if the implementation only makes it warning for example. As you ask, the compiler won't silently change the size of underlying type.
We can see this from the draft C++ standard dcl.enump5:
Each enumeration defines a type that is different from all other types. Each enumeration also has an underlying type. The underlying type can be explicitly specified using an enum-base. For a scoped enumeration type, the underlying type is int if it is not explicitly specified. In both of these cases, the underlying type is said to be fixed. Following the closing brace of an enum-specifier, each enumerator has the type of its enumeration. If the underlying type is fixed, the type of each enumerator prior to the closing brace is the underlying type and the constant-expression in the enumerator-definition shall be a converted constant expression of the underlying type. If the underlying type is not fixed, the type of each enumerator prior to the closing brace is determined as follows: ...
and converted constant expression forbid narrowing conversion, from expr.constp5:
A converted constant expression of type T is an expression, implicitly converted to type T, where the converted expression is a constant expression and the implicit conversion sequence contains only
...
- integral conversions other than narrowing conversions,
...
I believe the accepted answer to the referenced question answers most of the issues with respect to ABI compatibility. I could repeat it here but I don't see much value there.
To address you specific question about C++11 scoped enumerations your example:
enum class Foo : uint8_t { x = 257 }
is ill-formed since it requires a narrowing conversion, the implementation is required to provide a diagnostic but it may compile if the implementation only makes it warning for example. As you ask, the compiler won't silently change the size of underlying type.
We can see this from the draft C++ standard dcl.enump5:
Each enumeration defines a type that is different from all other types. Each enumeration also has an underlying type. The underlying type can be explicitly specified using an enum-base. For a scoped enumeration type, the underlying type is int if it is not explicitly specified. In both of these cases, the underlying type is said to be fixed. Following the closing brace of an enum-specifier, each enumerator has the type of its enumeration. If the underlying type is fixed, the type of each enumerator prior to the closing brace is the underlying type and the constant-expression in the enumerator-definition shall be a converted constant expression of the underlying type. If the underlying type is not fixed, the type of each enumerator prior to the closing brace is determined as follows: ...
and converted constant expression forbid narrowing conversion, from expr.constp5:
A converted constant expression of type T is an expression, implicitly converted to type T, where the converted expression is a constant expression and the implicit conversion sequence contains only
...
- integral conversions other than narrowing conversions,
...
edited Nov 21 '18 at 2:20
answered Nov 20 '18 at 3:47
Shafik YaghmourShafik Yaghmour
126k23324537
126k23324537
1
This does not answer the question, which is about ABI.
– rubenvb
Nov 20 '18 at 6:21
Well, the answer is not about ABI, but it is possibly relevant: if the implementation only raises a warning, could it be that the compiler will allow me to break binary compatibility, should I use a value outside the ranges of my enum type?
– Dacav
Nov 20 '18 at 12:46
@rubenvb - Well, if as the OP put it "the compiler no longer silently changes the underlying type", one can conclude the ABI will stay the same.
– StoryTeller
Nov 20 '18 at 12:47
@rubenvb I don't see the value of repeating the accepted answer to the referenced question. I feel like the real question is quite narrow and I have addressed that. I updated my answer to reflect that more explicitly.
– Shafik Yaghmour
Nov 21 '18 at 2:22
add a comment |
1
This does not answer the question, which is about ABI.
– rubenvb
Nov 20 '18 at 6:21
Well, the answer is not about ABI, but it is possibly relevant: if the implementation only raises a warning, could it be that the compiler will allow me to break binary compatibility, should I use a value outside the ranges of my enum type?
– Dacav
Nov 20 '18 at 12:46
@rubenvb - Well, if as the OP put it "the compiler no longer silently changes the underlying type", one can conclude the ABI will stay the same.
– StoryTeller
Nov 20 '18 at 12:47
@rubenvb I don't see the value of repeating the accepted answer to the referenced question. I feel like the real question is quite narrow and I have addressed that. I updated my answer to reflect that more explicitly.
– Shafik Yaghmour
Nov 21 '18 at 2:22
1
1
This does not answer the question, which is about ABI.
– rubenvb
Nov 20 '18 at 6:21
This does not answer the question, which is about ABI.
– rubenvb
Nov 20 '18 at 6:21
Well, the answer is not about ABI, but it is possibly relevant: if the implementation only raises a warning, could it be that the compiler will allow me to break binary compatibility, should I use a value outside the ranges of my enum type?
– Dacav
Nov 20 '18 at 12:46
Well, the answer is not about ABI, but it is possibly relevant: if the implementation only raises a warning, could it be that the compiler will allow me to break binary compatibility, should I use a value outside the ranges of my enum type?
– Dacav
Nov 20 '18 at 12:46
@rubenvb - Well, if as the OP put it "the compiler no longer silently changes the underlying type", one can conclude the ABI will stay the same.
– StoryTeller
Nov 20 '18 at 12:47
@rubenvb - Well, if as the OP put it "the compiler no longer silently changes the underlying type", one can conclude the ABI will stay the same.
– StoryTeller
Nov 20 '18 at 12:47
@rubenvb I don't see the value of repeating the accepted answer to the referenced question. I feel like the real question is quite narrow and I have addressed that. I updated my answer to reflect that more explicitly.
– Shafik Yaghmour
Nov 21 '18 at 2:22
@rubenvb I don't see the value of repeating the accepted answer to the referenced question. I feel like the real question is quite narrow and I have addressed that. I updated my answer to reflect that more explicitly.
– Shafik Yaghmour
Nov 21 '18 at 2:22
add a comment |
OP here.
I found out, and I think it would be relevant to mention, that C++11 has this nice std::underlying_type.
I think it can be used, together with is_same
and
static assertions, to create some guards against unexpected changes of ABI due to enumeratives.
I think (but I didn't try) that this is especially relevant if one is working with some library, and a pre-existing enumerative is not specifying an underlying type.
add a comment |
OP here.
I found out, and I think it would be relevant to mention, that C++11 has this nice std::underlying_type.
I think it can be used, together with is_same
and
static assertions, to create some guards against unexpected changes of ABI due to enumeratives.
I think (but I didn't try) that this is especially relevant if one is working with some library, and a pre-existing enumerative is not specifying an underlying type.
add a comment |
OP here.
I found out, and I think it would be relevant to mention, that C++11 has this nice std::underlying_type.
I think it can be used, together with is_same
and
static assertions, to create some guards against unexpected changes of ABI due to enumeratives.
I think (but I didn't try) that this is especially relevant if one is working with some library, and a pre-existing enumerative is not specifying an underlying type.
OP here.
I found out, and I think it would be relevant to mention, that C++11 has this nice std::underlying_type.
I think it can be used, together with is_same
and
static assertions, to create some guards against unexpected changes of ABI due to enumeratives.
I think (but I didn't try) that this is especially relevant if one is working with some library, and a pre-existing enumerative is not specifying an underlying type.
answered Nov 22 '18 at 8:41
DacavDacav
7,02144469
7,02144469
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53381626%2fabi-compatibility-preservation-with-c11-enum-class%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Are you implicitly assuming that the added enum values are always appended at the end of the list?
– Frank
Nov 19 '18 at 20:49
The question feels a little narrower than the title suggests.
– Shafik Yaghmour
Nov 20 '18 at 4:27
@Frank, I'm not implicitly assuming that, but if I got it correctly, having an enumerative with a big value helps the compiler in deciding what backing type to use. If we provide explicitly a backing integral type, we will ask the compiler of use a specific size for our enumerative, hence achieving binary compatibility (well, if we don't change the order of enum values, of course)
– Dacav
Nov 20 '18 at 12:41
@ShafikYaghmour, Yeah, maybe you're right. I'll rename that into…
– Dacav
Nov 20 '18 at 12:41
It was implementation-defined before, it still is when you don't specify the underlying type explicitly. The only requirement is that it is big enough to represent the enumerator values. Which is why the second snippet failed. If you need to guarantee binary compatibility then it does depend on what your compiler did previously. Seeing a 32-bit type work is certainly not unusual. That will almost certainly still work when you don't specify it.
– Hans Passant
Nov 20 '18 at 13:11