Conversion between enum and string in C++ class header

Question

I have the following redundant-feeling design to convert between enums and strings regarding a class that stores enums. The approach doesn't scale if there are more enums and in any event, less-redundant code is also better.

Questions

1. If there will be more enums, would it be possible to avoid defining two explicit conversion functions per enum type and device a system where the caller sees just one (i.e. convert) or two different function names (i.e. convertto/convertfrom for all the enums, not just per enum type)? Perhaps using some kind deduction magic with auto and decltype? It looks like ambiguity sets in since only the return value can be used to separate the different functions overloads (even if done with function templates).

2. Is the following design of separating the conversion functions and putting them to an anonymous namespace good design (I've thought about putting the conversion functions to a file, say conversions.incl and including it)?

The idea would be make the multiple (i.e. more enums than the one presented here) conversions as implicit as possible

The conversions would be used like this:

random.cpp

string token_string = "none"; //In reality this will be externally, user, generated.
some_class_instance->set_type(enum_conversion(token_string));
token_string = enum_conversion(some_class_instance->get_type());

And to present one enum and related conversions (but there could be more):

some_class.h

class some_class
{
    public:
         enum class enum_type
         {
             none   = 0,
             type1  = 1,
             type2  = 2
         }

     void set_type(enum_type);
     enum_type get_type() const;

   private:
       enum_type type_;
};

namespace
{
    std::array<std::pair<std::string, some_class::enume_type>, 3> type_map;

    bool initialize_map()
    {
       type_map[0] = std::make_pair("none", some_class::enum_type::none);
       type_map[1] = std::make_pair("type1", some_class::enum_type::type1);
       type_map[2] = std::make_pair("type2", some_class::enum_type::type2);
    }

    bool initialization_result = initialize_map();

    some_class::enum_type enum_conversion(std::string const& enum_type)
    {
        for(auto val: type_map)
        {
            if(val.first == enum_type)
            {
                return val.second;
            }
        }

        return type_map[0].second;
    }

    std::string enum_conversion(some_class::enum_type enum_type)
    {
        for(auto val: type_map)
        {
            if(val.second == enum_type)
            {
                return val.first;
            }
        }

        return type_parameter_map[0].first;
    }
}

Answer 1

I would use some template logic to achieve the affect in a more scalable way:

#include <iostream>
#include <sstream>
#include <string>
#include <algorithm>

// This is the type that will hold all the strings.
// Each enumeration type will declare its own specialization.
// Any enum that does not have a specialization will generate a compiler error
// indicating that there is no definition of this variable (as there should be
// be no definition of a generic version).
template<typename T>
struct enumStrings
{
    static char const* data[];
};

// This is a utility type.
// Created automatically. Should not be used directly.
template<typename T>
struct enumRefHolder
{
    T& enumVal;
    enumRefHolder(T& enumVal): enumVal(enumVal) {}
};
template<typename T>
struct enumConstRefHolder
{
    T const& enumVal;
    enumConstRefHolder(T const& enumVal): enumVal(enumVal) {}
};

// The next two functions do the actual work of reading/writing an
// enum as a string.
template<typename T>
std::ostream& operator<<(std::ostream& str, enumConstRefHolder<T> const& data)
{
   return str << enumStrings<T>::data[data.enumVal];
}

template<typename T>
std::istream& operator>>(std::istream& str, enumRefHolder<T> const& data)
{
    std::string value;
    str >> value;

    // These two can be made easier to read in C++11
    // using std::begin() and std::end()
    //  
    static auto begin  = std::begin(enumStrings<T>::data);
    static auto end    = std::end(enumStrings<T>::data);

    auto find   = std::find(begin, end, value);
    if (find != end)
    {   
        data.enumVal = static_cast<T>(std::distance(begin, find));
    }   
    return str;
}


// This is the public interface:
// use the ability of function to deduce their template type without
// being explicitly told to create the correct type of enumRefHolder<T>
template<typename T>
enumConstRefHolder<T>  enumToString(T const& e) {return enumConstRefHolder<T>(e);}

template<typename T>
enumRefHolder<T>       enumFromString(T& e)     {return enumRefHolder<T>(e);}

Then you can use it like this:

// Define Enum Like this
enum X {Hi, Lo};
// Then you just need to define their string values.
template<> char const* enumStrings<X>::data[] = {"Hi", "Lo"};

int main()
{
    X   a=Hi;

    std::cout << enumToString(a) << "\n";

    std::stringstream line("Lo");
    line >> enumFromString(a);

    std::cout << "A: " << a << " : " << enumToString(a) << "\n";
}

Answer 2

In most cases, the requirement of converting between c++ enumeration and string representation arises from interfacing to another program that does not understand your enumeration declarations. Often this other program will be a SQL database.

Hence I would go for a code generator to ensure consistency over the whole system.

The code generator could walk the whole database catalog and create an enumeration c-header and corresponding string arrays for everything in the database that could potentially carry enumeration semantics. Writing such a generator is less then a days work.

Note that this approach does not only free you from writing the string part. It also frees you from writing the enumeration definition altogether.

Answer 3

Here is a template class that enables writing and reading enum class members as strings. It is a simplification of Loki Astari's design. It avoids the need for helper functions, as suggested by Veski, by using the enable_if<> and is_enum<> templates.

The idea is to replace template <T> with

template <typename T,
    typename std::enable_if<std::is_enum<T>::value>::type* = nullptr>

The consequence is that the operator<<() and operator>>() templates are only instantiated for enums (because of the Substitution Failure Is Not An Error (SFINAE) principle). Then the helper classes enumConstRefHolder and enumRefHolder, and the functions enumToString() and enumFromString(), are no longer needed.

In addition to recognizing an enum member by a string (normalized to be all capital letters), the code recognizes its integer representation. (For the example below, both "FaST" and "1" will be read as Family::FAST.)

EnumIO.h:

#ifndef ENUMIO_H_
#define ENUMIO_H_

#include <algorithm>
#include <ios>
#include <iostream>
#include <sstream>
#include <vector>

// A template class that enables writing and reading enum class
// members as strings.
//
// Author:  Bradley Plohr (2017-05-12)
//
// Note:  The idea to keep the enum names as a static member in a
// template comes from Loki Astari:
//
// https://codereview.stackexchange.com/questions/14309
//         /conversion-between-enum-and-string-in-c-class-header
//
// Usage example:
//
// Enums.h:
// -------
// #ifndef ENUMS_H_
// #define ENUMS_H_
//
// enum class Family { SLOW, FAST };
//
// TODO:  other enum classes
//
// #endif /* ENUMS_H_ */
//
//
// Enums.cc:
// --------
// #include "Enums.h"
// #include "EnumIO.h"
// #include <string>
// #include <vector>
//
// template <>
// const std::vector<std::string>& EnumIO<Family>::enum_names()
// {
//      static std::vector<std::string> enum_names_({ "SLOW", "FAST" });
//      return enum_names_;
// }
//
// TODO:  enum names for other enum classes
//
//
// t_EnumIO.cc:
// -----------
// #include "EnumIO.h"
// #include "Enums.h"
// #include <iostream>
//
// int
// main()
// {
//     Family family;
//
//     family = Family::SLOW;
//     std::cout << family << std::endl;
//
//     std::cin >> family;
//     std::cout << family << std::endl;
//
//     return 0;
// }
//
// For the input
//
//     fAsT
//
// the output is
//
//     SLOW
//     FAST

template <typename T>
class EnumIO
{
public:
    static const std::vector<std::string>& enum_names();
};

template <typename T,
        typename std::enable_if<std::is_enum<T>::value>::type* = nullptr>
std::ostream&
operator<<(std::ostream& os, const T& t)
{
    os << EnumIO<T>::enum_names().at(static_cast<int>(t));

    return os;
}

static std::string
toUpper(const std::string& input)
{
    std::string copy(input);
    std::transform(copy.cbegin(), copy.cend(), copy.begin(),
            [](const unsigned char i) { return std::toupper(i); });

    return copy;
}

template <typename T,
        typename std::enable_if<std::is_enum<T>::value>::type* = nullptr>
std::istream&
operator>>(std::istream& is, T& t)
{
    std::string input;
    is >> input;
    if (is.fail())
        return is;
    input = toUpper(input);

    // check for a match with a name
    int i = 0;
    for (auto name : EnumIO<T>::enum_names()) {
        if (toUpper(name) == input) {
            // Here we assume that the integer representation of
            // the enum class is the default.  If the enum class
            // members are assigned other integers, this code
            // must be extended by consulting a vector containing
            // the assigned integers.
            t = static_cast<T>(i);

            return is;
        }
        ++i;
    }

    // check for a match with an integer
    int n = static_cast<int>(EnumIO<T>::enum_names().size());
    std::istringstream iss(input);
    int value;
    iss >> value;
    if (not iss.fail() && 0 <= value && value < n) {
        t = static_cast<T>(value); // See the comment above.
        return is;
    }

    is.setstate(std::ios::failbit);

    return is;
}

#endif /* ENUMIO_H_ */

Answer 4

If you have large enumerations, you might find that linear search in an array is inefficient. There's also a real risk of accidentally omitting one or more of the mappings.

I solved this a different way by writing the enum→string conversion as a switch (with compiler warnings to indicate a missed case), and then generating a string→enum std::map when it's first required:

std::string to_string(some_class::enum_type e) {
    switch (e) {
    // you might want to use a macro to get matching labels and strings
    case some_class::enum_type::none: return "none";
    case some_class::enum_type::type1: return "type1";
    case some_class::enum_type::type2: return "type2";
    // N.B. no 'default', or GCC won't warn about missing case
    }
    // invalid value
    return {};
}

some_class::enum_type from_string(const std::string& s) {
    static auto const m = invert(some_class::enum_type::none,
                                 some_class::enum_type::type2,
                                 to_string);
    auto it = m.find(s);
    return it == m.end() ? some_class::enum_type::none : *it;
}

template<typename T, typename R>
std::map<R,T> invert(T first, T last, R(*forward_func)(T))
{
    if (first > last) std::swap(first, last);

    std::map<R,T> m;
    for (int i = first;  i <= last;  ++i)  {
        T t = T(i);
        R r = to_string(t);
        m[r] = t;
        // Or: if (!m.insert_or_assign[t].second)
        //         log_warning(m[r] and t both map to r);
    };
    return m;
}

To make from_string() into a template, you'll want some sort of enum_traits<T> to specify the 'first' and 'last' values and the default value to return if the string isn't found (your unit tests can use these limits when checking that every enum maps back to itself).

You might also need to help the compiler select the correct overload of to_string(); alternatively, you should be able to inline it into invert(). In my case, some of the enums I inherited had more than one mapping to/from string, depending on the context, so calling them all to_string wasn't an option for me.

Answer 5

A good start.
But you need to templatize your functions and the type_map by the enum to make the design extensible. That is a simple change so I will not focus on that.

About the only other thing is that you search when doing a conversion in either direction. By choosing the appropriate container to hold the information you can do a quick lookup in one direction (though not in both without some fancier than normal containers).

Otherwise I quite like it.

It's not the style I would have chosen - see my alternative answer.

Answer 6

If I customise my enum like hi = 10, low = 20, it gives me en error ..

Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)

// Define Enum Like this
enum X {Hi = 10, Lo = 20};
// Then you just need to define their string values.
template<> char const* enumStrings<X>::data[] = {"Hi", "Lo"};