Скажите, а как решает ваше (или любое другое здесь) предложение проблему описанную Саттером:
At minimum, the programmer manually wraps the enum inside a class to get type-safety...
This solution can be close to ideal logically, but a full-blown class is not a POD and many ABIs fail to
pass small structures in registers, so turning an enum into a class for logical reasons may impose a
surprising (and sometimes significant) cost on its users.
Здравствуйте, Аноним, Вы писали:
А>Скажите, а как решает ваше (или любое другое здесь) предложение проблему описанную Саттером: А>
А>At minimum, the programmer manually wraps the enum inside a class to get type-safety...
А>This solution can be close to ideal logically, but a full-blown class is not a POD and many ABIs fail to
А>pass small structures in registers, so turning an enum into a class for logical reasons may impose a
А>surprising (and sometimes significant) cost on its users.
Здравствуйте, remark, Вы писали:
R>Если не поленюсь, запосчу ещё свою реализацию енума с возможностью связывания произвольных тегов к значениям. Это ваще крута! Такого точно ни у кого нет!
Здравствуйте, Аноним, Вы писали:
А>Скажите, а как решает ваше (или любое другое здесь) предложение проблему описанную Саттером: А>
А>At minimum, the programmer manually wraps the enum inside a class to get type-safety...
А>This solution can be close to ideal logically, but a full-blown class is not a POD and many ABIs fail to
А>pass small structures in registers, so turning an enum into a class for logical reasons may impose a
А>surprising (and sometimes significant) cost on its users.
"many ABIs fail to pass small structures in registers"
Это по большей части не проблема (на тех платфортмах, которые меня интересуют).
"full-blown class is not a POD"
Конечно, класс уже не POD, но насколько это важно? На большинстве платформ и компиляторов если класс достаточно простой, как в этом случае, с ним можно обращаться как с POD. Да, это будет за пределами поведения, гарантированного стандартом. Но на практике проблем не будет.
Здравствуйте, remark, Вы писали:
R>Наверное многие задавались вопросом — почему сделано так странно и нелогично, почему enum'ы выносят имена своих констант в окружающее пространство имён, хотя объявлены константы вроде как внутри самого enum'а?
R>Фиксим багу:
По мне, пространства имен лучше, во-первых, потому что для них, в отличие от классов, можно юзать using в разных вариантах, в зависимости от локальной обстановки (конфликты имен и т.п.):
namespace Colors { enum Color {red,green}; }
int main()
{
Colors::Color x = Colors::red; // обе квалификации нужныusing Colors::Color;
Color y = Colors::red; // нужна квалификация только redusing namespace Colors;
Color z = red; // не нужны никакие квалификации
}
А во-вторых, енум остается енумом, а не превращается в класс (т.е, например, он остается POD-ом, что часто бывает важно — многие продвинутые библиотеки применяют для подов разные оптимизации типа memcpy/memmove/memcmp, поды можно передавать во всякие printf, и т.п.)
Здравствуйте, alexeiz, Вы писали:
A>Конечно, класс уже не POD, но насколько это важно? На большинстве платформ и компиляторов если класс достаточно простой, как в этом случае, с ним можно обращаться как с POD. Да, это будет за пределами поведения, гарантированного стандартом. Но на практике проблем не будет.
Согласен, в большинстве случаев (т.е. кроме таких клинических, как программирование всяких кристаллов и т.п.) так оно и есть. Но проблема еще в сложности кода: лучшим по-моему предложение было именно здесь
, но как не сложно заметить, код класса довольно сложный (ну, или скажем объёмный), чего по понятным причинам очень бы хотелось избежать. И поэтому сделать правильный выбор между полностью правильными enum-мами, используя "костыль", или юзать все-таки структуры-обёртки.
Здравствуйте, alexeiz, Вы писали:
A>Здравствуйте, remark, Вы писали:
R>>Если не поленюсь, запосчу ещё свою реализацию енума с возможностью связывания произвольных тегов к значениям. Это ваще крута! Такого точно ни у кого нет!
A>Давай!
Здравствуйте, remark, Вы писали:
R>Наверное многие задавались вопросом — почему сделано так странно и нелогично, почему enum'ы выносят имена своих констант в окружающее пространство имён, хотя объявлены константы вроде как внутри самого enum'а?
Может все мужики уже давно знают, то я только обнурижил, что MSVC2005 позволяет писать так:
enum A {A1, A2, A3};
int main()
{
A a1 = A1;
A a2 = A::A2;
}
Хоть и с варнингом о ms-specific... который впрочем, если уж портирование не требуется, можно смело подавить.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, remark, Вы писали:
R>>Наверное многие задавались вопросом — почему сделано так странно и нелогично, почему enum'ы выносят имена своих констант в окружающее пространство имён, хотя объявлены константы вроде как внутри самого enum'а?
R>Может все мужики уже давно знают, то я только обнурижил, что MSVC2005 позволяет писать так:
R>
R>enum A {A1, A2, A3};
R>int main()
R>{
R> A a1 = A1;
R> A a2 = A::A2;
R>}
R>
R>Хоть и с варнингом о ms-specific... который впрочем, если уж портирование не требуется, можно смело подавить.
Боян
Ещё вроде с VS 6 было такое, а может и раньше.
Ну и намучились мы с этим, когда портировали код под gcc
Хотя по мне, так логичнее A::A2, нежели просто A2
R>> R>
Здравствуйте, remark, Вы писали:
R>Наверное многие задавались вопросом — почему сделано так странно и нелогично, почему enum'ы выносят имена своих констант в окружающее пространство имён, хотя объявлены константы вроде как внутри самого enum'а?
Жаль что со switch-ем нельзя сделать так как-нить(код ниже) — то есть сэмулировать enum в том виде в котором он есть скажем в C#. Потому что enum приводится к int и все:
// В условиях вашего примера
color c = ...;
switch (c)
{
case color::red: // Можноbreak;
case 3: // Запретить бы int-ы... Это было бы круто!break;
}
Как там у классиков: за изобретение 5, по предмету... +1 скажем так
Не стыдно попасть в дерьмо, стыдно в нём остаться!
