Discussing approaches for converting Enum to String

Question

I need to convert the ENUM to a respective string value for which I came up with two approaches and I'm trying to see why would a second approach be better than the first one if even in terms of performance and practicality?

Both approaches work. The second requires additional work of having to create an array of struct whereas the first approach merely uses a switch case with hardcoded string values of the corresponding enum.

First approach

enum class Num : uint32_t
{
    One,
    Two,
    Three
};

string EnumToStr(Num num)
{
    switch (num)
    {
        case Num::One:
            return "One";
            break;
        
        case Num::Two:
            return "Two";
            break;
        
        case Num::Three:
            return "Three";
            break;
        
        
        default:
            return "";
    }
}

int main() 
{
    cout << EnumToStr(Num::One) << endl; // ONE
    return 0;
}

---

Second Approach

#define ENTRY(x) {x, #x}

enum class Num : uint32_t
{
    One,
    Two,
    Three,
    MAX
};


struct Lookup
{
    Num num;
    std::string_view str;
};

constexpr static Lookup table[] =
{
    ENTRY(Num::One),
    ENTRY(Num::Two),
    ENTRY(Num::Three)
};

string_view GetStr(Num num)
{
    uint32_t entryIndex = static_cast<uint32_t>(num);
    uint32_t maxNum = static_cast<uint32_t>(Num::MAX);
    
    if (entryIndex < 0 || entryIndex > maxNum)
    {
        return "";
    }
    return table[entryIndex].str;
}

int main() 
{
    cout << GetStr(Num::One) << endl;   // Num::ONE
    return 0;
}

An additional thought that #define ENTRY(x) {x, #x} may be not a recommended approach in C++. Are there better ways around it?

Edit:

The following is what I came up with for the memory consumption for respective functions. It seems the second approach consumes more owing to the struct table in particular.

Second Approach:

• Looking at the asm, GetStr() consumes (0x401147- 0x401120)+1 = 40 bytes
• sizeof(table) = 72 bytes
• total = 72 + 40 = 112 bytes

First Approach:

• Looking at the asm, SwitchCase() consumes (0x40116d- 0x401120)+1 = 78 bytes

However, doing the following resulted in Second Approach consuming lesser bytes than the First:

• If const char * is used instead of string_view

• Adding more enum entries

{gcc12.1 + O3} 166 bytes of First Approach vs 96 bytes of Second Approach (#bytes are calculated at the bottom comments)

So with more enum entries, does the Second Approach outperform the First Approach?

Is this one way of determining the performance of functions?

Answer 1

Another way to solve this problem is by using X macros. These allow you to define the list of enum names and their values exactly once, and then create both the enum type and the reverse mapping from that list. For example:

#define NUM_LIST \
    X(One, 1) \
    X(Two, 2) \
    X(FourtyTwo, 42)

enum class Num: uint32_t
{
    #define X(name, value) name = value,
    NUM_LIST
    #undef X
};

string EnumToStr(Num num)
{
    switch (num)
    {
        #define X(name, value) case Num::name: return #name;
        NUM_LIST
        #undef X
    default:
        return {};
    }
}

Once you have written this, then adding a new enum value only requires you to add a line to the definition of NUM_LIST.

Answer 2

The const char * approach that you tested is the most performant way to do it, and it is more size efficient than using either std::string_view or std::string, if you are not using the features of string_view or string there is no reason to add the overhead involved.

The Lookup struct you are creating in the second method isn't necessary for a number of reasons, the first is that the code never uses the Num portion of the struct, the second is that you could use std::pair instead.

To answer your comment, yes, because it is an O(1) lookup. This is a size versus speed trade off, however, the executable size of the function will remain the same no matter how large the enum or the array of const char * grow, the executable size of the switch statement will grow with each new case statement. Each new case statement will add a delay the possible solution.

About Deduplicator's comment, prefer std::cout << "\n"; over std::cout <<std::endl; for performance reasons, std::endl calls fflush() which makes a system call, generally this isn't necessary.

Answer 3

I'm going to ignore all the asm considerations because the compiled code will change based on (among other factors):

• the compiler
• the compiler version
• the compiler flags used
• optimizations
• inlining
• caching
• the operating system
• all the other code in the program

In either approach, the compiler could inline everything so that the only space taken up is by the strings themselves. In fact, that's exactly what happens. These two approaches actually result in the same asm when you use the simplest code for both approaches.

First approach:

C++ code:

#include <cstdint>

enum class Num : uint32_t
{
    One,
    Two,
    Three
};

const char* EnumToStr(Num num)
{
    switch (num)
    {
        case Num::One:   return "One";
        case Num::Two:   return "Two";
        case Num::Three: return "Three";
    }
}

asm (godbolt link):

EnumToStr(Num):
        mov     edi, edi
        mov     rax, QWORD PTR CSWTCH.1[0+rdi*8]
        ret
.LC0:
        .string "One"
.LC1:
        .string "Two"
.LC2:
        .string "Three"
CSWTCH.1:
        .quad   .LC0
        .quad   .LC1
        .quad   .LC2

Second approach:

C++:

#include <cstdint>

enum class Num : uint32_t
{
    One,
    Two,
    Three,
};

constexpr static const char* table[] =
{
    "One",
    "Two",
    "Three"
};

const char* GetStr(Num num)
{
    return table[static_cast<uint32_t>(num)];
}

asm (godbolt link):

GetStr(Num):
        mov     edi, edi
        mov     rax, QWORD PTR table[0+rdi*8]
        ret
.LC0:
        .string "One"
.LC1:
        .string "Two"
.LC2:
        .string "Three"
table:
        .quad   .LC0
        .quad   .LC1
        .quad   .LC2

Both approaches are converted to an array lookup. The only difference is the name of the array. So, the only question is what code is easiest to read, write, and understand. The question of whether to return const char*, std::string_view, or std::string depends on how you expect the function to be used. If I had to guess, std::string_view is probably best since it is lightweight (consisting of two pointers) and interacts naturally with std::string.

Even including the checks for valid enums results in the same asm:

• Approach 1 with a default case
• Approach 2 with an array bounds check

Scoped enums

The purpose of enum class is to create named constants with no implicit conversions to or from the underlying integer type. This allows you to simplify your code because you don't have to handle out-of-bounds values. The only way to get undefined values of Num is to use static_cast<Num>, and all uses of static_cast deserve close scrutiny due to the loss of type information.

First approach

This approach is the simplest and the one I like better. It doesn't need any other data besides the function itself. The compiler will generate the lookup table, so why write it yourself? Also, the compiler will help you keep the function and the enum synchronized.

Since a break after a return is unreachable, we can make this function more compact.

string EnumToStr(Num num)
{
    switch (num)
    {
        case Num::One:   return "One";
        case Num::Two:   return "Two";
        case Num::Three: return "Three";
        default:         return "";
    }
}

The default: case here is unreachable and not necessary, but not all compilers will allow the switch statement without a default: to compile without warnings. The default: case does protect against accidentally skipping Num values, since returning an empty string should have visible consequences in your program. If you ever delete entries from Num the compiler will tell you that, for example, Num::Two is no longer defined.

Second approach

Keeping in mind the purpose of scoped enums, the following check is unnecessary:

    uint32_t entryIndex = static_cast<uint32_t>(num);
    uint32_t maxNum = static_cast<uint32_t>(Num::MAX);
    
    if (entryIndex < 0 || entryIndex > maxNum)
    {
        return "";
    }

The only way the conditional could evaluate to false is if somebody writes auto x = static_cast<Num>(42); GetStr(x);. The check for valid conversions should happen at the point of the static_cast, so the check inside GetStr() and the entry Num::MAX should be deleted. Also, the fact that you cast to an unsigned integer means the entryIndex < 0 check cannot return false.

string_view GetStr(Num num)
{
    return table[static_cast<uint32_t>(num)].str;
}

There's another problem with this. Your second approach includes an extra entry in the enum: Num::MAX. This has a value of 3 and is an out-of-bounds index for table. Even the function with the check would have allowed a call of GetStr(Num::MAX) to access the table with an invalid index. The check should have been if(entryIndex >= maxNum) { return ""; }.

Since you only care about the string representation, I don't see why the Lookup struct has the Num value. It's less typing (and one less function macro) to represent the table as

constexpr static const char* table[] =
{
    "Num::One",
    "Num::Two",
    "Num::Three"
};

Now, the GetStr() function can look like this:

string_view GetStr(Num num)
{
    return table[static_cast<uint32_t>(num)];
}

The downside of this approach is that you have less protection if you don't keep the table and the Num enum synchronized. If you have fewer entries in table than Num, your program will at-best crash after trying to access data beyond the end of the array. If you have more entries in table than Num, then those extra entries uselessly take up space in the program. This is why I prefer the first approach.