Всегда раздражали стандартные enum'ы как минимум двумя вещами :
Первая вещь:

// ONE, TWO, THREE попадают в область видимости, такую же как у MyEnum, а не скрываются внутри (как это сделано в яве). Имеем проблему: при создании какого-нибудь енума с элементами вроде LEFT, RIGHT, DOWN, UP в очень общем хедере рискуем, что такие имена могут быть нечаянно перекрыты в пользовательском коде. Есть два Выхода:
1) Добавление префиксов
, что утомляет.

2) Сокрыте в нэймспейсе
, что делает использование не очень удобным, заставляя оперировать двумя именами Directions и DirectionsT. Конечно же нэймспейс может быть более общим,  включающим тот код, который использует этот enum, но не всегда хочется его создавать.

Вторая вещь:

Иногда хочется не допустить, чтоб кто-нибудь мог присвоить енуму значение не из первоначального списка инициализации.




Предлагается следующее решение:




И его использование:




Правда вот, не знаю, поддерживается ли __VA_ARGS__ всеми компиляторами. Нужно будет глянуть в стандарте...

Замечания и критика приветствуются.

пардон за      
бедный enum. досталось ему.

 а если написать так, то что неудобно?


Добавлено через 6 минут и 14 секунд

Цитата(SaDFromSpb @  8.10.2008,  16:09 )

MyEnumStrict mes = MyEnumStrict::BIG;   //   mes =

  не пойму и чего это мне название переменной такое знакомое ?!   

до принятия нового стандарта не так уж и много осталось - там энамы уже нормальные

Получается
Directions::Enum dir = Directions::LEFT;
Неудобно.


Круто! Всё лень его изучить. Значит, не одному мне старые енумы не нравились.....  

Добавлено через 6 минут и 3 секунды
Хотя, я думаю, еще во многих консервативных конторах, вроде моей, будут долго отторгать новый стнадарт, мотивируя это требованием, чтоб создаваемый код на старых клиентских платформах собирался....

Это сообщение отредактировал(а) SaDFromSpb - 8.10.2008, 17:16

это как  нету ?




A зачем T на конце  ? весь вид портит ..

Добавлено через 3 минуты и 18 секунд

а с этим согласен. )

Это я не заметил. Я свое предыдущее сообщение отредактировал.

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


если я захочу, я забью любое значение в любое место памяти, так что защищаться от этого нет смысла
если человек пишет MyEnum me = static_cast<MyEnum>(20)
значит он знает, что он делает (а если нет, то надо бить по рукам)


Это сообщение отредактировал(а) korian - 8.10.2008, 20:28

Не хочу здесь об этом =). Да. В принципе, можно всегда делать енумы внутри классов... Правда, бывает, что целая группа классов равноправно разделяет какой-то енум, но это данному подходу - не преграда. =)



А че, спецификаторами доступа в классах тоже не пользуешься, что ли?
А вообще это менее важный аспект из двух.

если сильно захотеть, то можно ив private переменную записать. Сломать можно все, что хочешь. Вопрос только в смысле этих действий.

а в какой класс ты запихаешь enum Color, если он используется в трети классов программы?

C++ не удобства, а язык с возможностями
А то как писать enum -  это стиль программирования, поэтому это не недостаток!!!
В С++ есть более плохие вещи которые распространяются на ошибка в самом языке.
Пример: Все знаю что к закрытым полям класса нельзя получить доступ не из этого класса, но также при необходимости все получают!!!!

это все пиши есчё((((

1. запихнуть его в неймспейс со всей этой третей частью
2. скорее всего из всей этой третей части, есть класс, которому этот колор нужен больше всего, а остальные его используют, т.к. работают с этим объектом.