ABI compatibility preservation with C++11 `enum class`












2















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?










share|improve this question

























  • 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
















2















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?










share|improve this question

























  • 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














2












2








2








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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



















  • 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












2 Answers
2






active

oldest

votes


















1














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,


...







share|improve this answer





















  • 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



















0














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.






share|improve this answer























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


    }
    });














    draft saved

    draft discarded


















    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









    1














    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,


    ...







    share|improve this answer





















    • 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














    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,


    ...







    share|improve this answer





















    • 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








    1







    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,


    ...







    share|improve this answer















    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,


    ...








    share|improve this answer














    share|improve this answer



    share|improve this answer








    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














    • 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













    0














    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.






    share|improve this answer




























      0














      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.






      share|improve this answer


























        0












        0








        0







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 22 '18 at 8:41









        DacavDacav

        7,02144469




        7,02144469






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

            How to change which sound is reproduced for terminal bell?

            Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents