Наверное многие задавались вопросом — почему сделано так странно и нелогично, почему enum'ы выносят имена своих констант в окружающее пространство имён, хотя объявлены константы вроде как внутри самого enum'а?

Фиксим багу:

struct prio
{
    enum type
    {
        low, normal, high
    };
    type v;
    prio(type v) : v(v) {}
    operator type () const {return v;}
};

Теперь можно писать так:

void f(prio& p)
{
    p = prio::high;
}

int main()
{
    prio p = prio::low;
    f(p);
}

Получается, как будто prio — это enum, и он оставил свои константы внутри себя, а не вынес их.

Естественно сразу чешутся руки сделать для этого дела хелпер. Делаем:

template<typename def>
struct right_enum : def
{
    typedef typename def::type type;
    type v;
    right_enum(type v) : v(v) {}
    operator type () const {return v;}
};

Теперь правильный enum записывается так:

struct color_def
{
    enum type
    {
        red, green, blue
    };
};

typedef right_enum<color_def> color;

Используем по прежнему:

void f(color p)
{
    p = color::green;
}

int main()
{
    color p = color::red;
    f(p);
}

Делаем правильные C++ enum'ы

Здравствуйте, remark, Вы писали:

[]

Все это уже было на DDJ. Ну или похожее

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, remark, Вы писали:

КЛ>[]

КЛ>Все это уже было на DDJ. Ну или похожее

что такое DDJ?

Здравствуйте, Константин Л., Вы писали:

КЛ>Все это уже было на DDJ. Ну или похожее

Если ты имеешь в виду то, что Саттер писал про strong enum, то там всё-таки другое.

Здравствуйте, kvser, Вы писали:

K>Здравствуйте, Константин Л., Вы писали:

КЛ>>Здравствуйте, remark, Вы писали:

КЛ>>[]

КЛ>>Все это уже было на DDJ. Ну или похожее

K>что такое DDJ?

http://www.ddj.com/cpp/184401797

Здравствуйте, remark, Вы писали:

R>Наверное многие задавались вопросом — почему сделано так странно и нелогично, почему enum'ы выносят имена своих констант в окружающее пространство имён, хотя объявлены константы вроде как внутри самого enum'а?

R>Фиксим багу:

а так, не!?! слишком просто !?!

namespace color
{
enum type
{
red, green, blue
};
}

Здравствуйте, remark, Вы писали:

R>Здравствуйте, Константин Л., Вы писали:

КЛ>>Все это уже было на DDJ. Ну или похожее

R>Если ты имеешь в виду то, что Саттер писал про strong enum, то там всё-таки другое.

это
http://www.ddj.com/cpp/184401797
?

R>

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, remark, Вы писали:

R>>Наверное многие задавались вопросом — почему сделано так странно и нелогично, почему enum'ы выносят имена своих констант в окружающее пространство имён, хотя объявлены константы вроде как внутри самого enum'а?

R>>Фиксим багу:

А>а так, не!?! слишком просто !?!

А>namespace color
А>{
А> enum type
А> {
А> red, green, blue
А> };
А>}

Тогда вместо типа придётся писать color::type
Одну ножку подпилил, зато другая стала длиннее

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, remark, Вы писали:

R>>Наверное многие задавались вопросом — почему сделано так странно и нелогично, почему enum'ы выносят имена своих констант в окружающее пространство имён, хотя объявлены константы вроде как внутри самого enum'а?

R>>Фиксим багу:

А>а так, не!?! слишком просто !?!

А>namespace color
А>{
А> enum type
А> {
А> red, green, blue
А> };
А>}

весь юмор я думаю заключается вот в этом

int main()
{
    prio p = prio::low;
    f(p);
}

Это уже получаются даже правильные С++0х enum'ы

Добавляем типизацию низлежащего типа:

template<typename def, typename inner = def::type>
struct right_enum : def
{
    typedef typename def::type type;
    typedef typename inner inner;
    inner v;
    right_enum(type v) : v(static_cast<type>(v)) {}
    operator inner () const {return v;}
};

Теперь можно писать так:

typedef right_enum<color_def> color;

А можно и так:

typedef right_enum<color_def, unsigned char> color;

Соответственно теперь можно брать корректный sizeof, и при неявном приведении к нехорошему типу будет варнинг.

typedef right_enum<color_def, uint64_t> color;

int main()
{
    size_t s = sizeof(color); // 8
    color c = color::red;
    uint64_t u = c;
    int i = c; // conversion from 'unsigned __int64' to 'int', possible loss of data
}

Здравствуйте, remark, Вы писали:

R>Фиксим багу:
а какю?
Чему мешают enum'ы в том виде, в каком они уже есть?

Здравствуйте, Erop, Вы писали:
R>>Фиксим багу:
E>а какю?
E>Чему мешают enum'ы в том виде, в каком они уже есть?
Засоряют пространство имен ?

Здравствуйте, Erop, Вы писали:

R>>Фиксим багу:
E>а какю?
E>Чему мешают enum'ы в том виде, в каком они уже есть?

Уважаемый Ероп, ты читать-то умешь? Было ясно сказано, какую багу и сказано, чем именно они мешают. Потрудись прочесть еще раз.

Здравствуйте, McSeem2, Вы писали:

MS>Уважаемый Ероп, ты читать-то умешь? Было ясно сказано, какую багу и сказано, чем именно они мешают. Потрудись прочесть еще раз.

А ты сомневаешься?
Про взаимовежливость ты скорее всего слыхал, то есть саботируешь сознательно...

Но ты наверное про это: " почему enum'ы выносят имена своих констант в окружающее пространство имён, хотя объявлены константы вроде как внутри самого enum'а?" Да?
Так вот, ИМХО, вопрос "почему" описанием проблемы не является...

Потрудитесь объяснить в чём состоят проблемы...
И почему нельзя обойтись просто namespaces?

А можно задать вопрос?
А стоит ли то, что сделано таких костылей?
Перечисление всегда глобально внутри какогото namespace, кстати оно обычно только там и используется.
В конце концов можно завести просто класс статический, эмулирующий перечисление — по моему гораздо проще будет, нежели такие навороты :D

Ктож потом листинг то такой будет?
Не, фиг с ним, кто будет, что он про тебя думать будет? :D

А так идея интересная...

P.S. Я тоже любил делать вставки на ASMе в CPP ))

Здравствуйте, Erop, Вы писали:

E>Потрудитесь объяснить в чём состоят проблемы...

Одинаковые имена в разных енумах конфликтуют.

E>И почему нельзя обойтись просто namespaces?

И это тоже уже объяснялось. 1. Где я возьму namespace внутри класса? 2. Зачем мне писать nanespace::enum_type вместо enum_type?
И хватит об этом.

Здравствуйте, McSeem2, Вы писали:

E>>Потрудитесь объяснить в чём состоят проблемы...
MS>Одинаковые имена в разных енумах конфликтуют.
Ну я, например, обычно делаю так:

enum MySuperColours {
    MSC_SuperRed,
    MSC_SuperGreen,
    MSC_SuperBlue };

И вообще стараюсь избегать ненужных enums в глобальных пространствах имеён.

E>>И почему нельзя обойтись просто namespaces?

MS>И это тоже уже объяснялось.
Где объяснялось? Кем? Кому и когда? До 06.09 12:37 или после?...

MS>1. Где я возьму namespace внутри класса?
А у тебя в классах обычно так много enums что они конфликтуют?
Ну тогда, конечно, trick от remark'а тебе наверное поможет. Хотя я бы на рефакторинг поставил всё же.

MS>2. Зачем мне писать nanespace::enum_type вместо enum_type?
Конечно color::red писать есть зачем, а definitions::red незачем. Понимаю.

MS>И хватит об этом.
Да. Хватит.
В целом я согласен, например, с этим оратором

Автор: ionicman
Дата: 06.09.07

Здравствуйте, McSeem2, Вы писали:
MS>Одинаковые имена в разных енумах конфликтуют.

E>>И почему нельзя обойтись просто namespaces?

MS>И это тоже уже объяснялось. 1. Где я возьму namespace внутри класса?
У тебя уже и внутри класса "Одинаковые имена в разных енумах конфликтуют"??? Ха-ха-ха! Это ж умудриться надо! Чтобы внутри одного класса разные енумы именами пересеклись. Да вам, батенька, доктор, пфу, рефакторинг нужен!
MS> Зачем мне писать nanespace::enum_type вместо enum_type?
Действительно, зачем?

Здравствуйте, remark, Вы писали:

R>Наверное многие задавались вопросом — почему сделано так странно и нелогично, почему enum'ы выносят имена своих констант в окружающее пространство имён, хотя объявлены константы вроде как внутри самого enum'а?

А если серьёзно, то у меня лично к перечислениям только одна претензия -- их нельзя расширять.
А всё остальное мешает меньше, чем всякие tricks направленные на лечение этих "проблем"