Есть ли C ++ библиотека для создания сильных Enums?

Question

В идеале я хотел бы, чтобы следующие примеры работали, но я думаю, что некоторые из них не могут быть реализованы в C ++.

{
  typedef StrongEnum<Red=0, Green=1, Blue=2> Color; // not a C++ syntax
  Color c = Color::Red;  // static const 
  Color d;  //error: default constructor is private 
  Color d = c;
  Color e = Color::OfInt(5); // ifdef DEBUG - Runtime error: Enum out of range 

  int sum = 0;

  // I do have these macros, but separate for each enum - FOREACH_COLOR(c)
  FOREACH_ENUM (Color c) { 
    sum += c.ToInt ();
  }

  ArrayMap<Color, string> map;  // Internally this is const size array, possible
  map [Color::Red] = "red";     // because Color have static const Limit = 3 inisde. 

  // Advanced: EnumPair does bitpacking.
  // currently I implement it manually for every pair of Enum's I need.
  typedef EnumPair <door=Color, window=Color> ColorPair; // I guess I can't get this, can I?
  ColorPair pair (door = Color::Red, window = Color::Green); // I guess I can't give the labels here or one line above, can I?
  Color w = pair.window;
  Color w = pair.window ();
}

Я часто их использую, и сейчас пишу каждый с нуля. Я знаю, что полное общее решение - это мечта, поэтому я приветствую любые частичные решения. Может быть, кто-то создал библиотеку или генератор кода?

Обновление 1:

Это и это вопросы, связанные. Я расследую, какие проблемы можно решить с их помощью.

Answer 1

Вот что я понял:

#include <cstdio>
#include <string>
#include <map>

namespace Color
{
    typedef enum
    {
        Red = 0,
        Green = 1,
        Blue = 2
    } Color;

    Color colors[] = {Red, Green, Blue}; // same order as above,
                                         //to preserve index.

    //int colors_len = sizeof(colors)/sizeof(Color);
    // (if you want to check for valid values)

    static inline Color OfInt(int value)
    {
        // if(value >= colors_len) do error thing;
        return colors[value];
    }
}

int main()
{
    Color::Color c = Color::Red;

    printf("%d,", c);

    c = Color::OfInt(1);

    printf("%d,", c);

    c = Color::Blue;

    printf("%d\n", c);

    std::map<Color::Color, std::string> map;

    map[Color::Red] = "red";

    return 0;
}

По крайней мере, у вас есть то поведение, которое вы хотели. Вам не хватает того, что вам нужно?

Он компилируется с g ++ 4.3.3 и, кажется, работает нормально.

Я сделал объект пространства имен, чтобы перевести перечисления в другую область. (чтобы красный не забрали и т. д.) Может быть, вы можете разбить его на что-то, что вы могли бы использовать? :)

Если вы хотите, чтобы Color :: Color находился вне этого пространства имен, вы можете сделать:

typedef Color::Color ColorEnum;

Но имя Color, к сожалению, занято пространством имен.

Answer 2

Я также ненавижу фактическую реализацию перечислений в C ++.

• Автоматическое преобразование в целочисленные типы
• Проверка значения отсутствует: выполняется проверка свободного диапазона, чтобы определить, соответствует ли значение целочисленному типу, выбранному для его хранения
• Сериализация: сериализация как int является болезненной> вам нужно сохранить старые значения, даже если они больше не используются, и вы должны добавлять новые значения только в конце
• Итерация невозможна, вам нужно переопределить операторы

Я закончил тем, что свернул свой собственный шаблон, чтобы попробовать и автоматизировать, но на данный момент он не полностью удовлетворяет (особенно потому, что он требует специализации шаблона для каждого перечисления и поэтому не может использоваться для перечислений, вложенных в класс / struct: /)

Во всяком случае, идея, которую я использовал, была:

• Статическая карта для хранения значений и их «значения сериализации» (в моем случае это простая строка, потому что я не очень ценю пространство и предпочитаю удобочитаемость)
• Класс для переноса, который просто содержит итератор на карте, а end означает неинициализированное / недопустимое значение.

На данный момент я использовал «истинное» перечисление, но из того, что вы сказали, я мог бы подумать о наличии статических экземпляров ... хотя это накладывает еще одну нагрузку на автора перечисления ...