Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Общие вопросы > приведение int к enum

Автор: itan 12.12.2006, 14:07

Вот есть у меня свой тип данных : Код enum Type {Type1 = 10, Type2 = 20, Type3 = 30 }; и есть функция, которая принимает этот тип в качестве параметра: Код void func(Type t) {     Type tNew = t;          ... } Вопрос в том - как мне можно защитить функцию func от передачи ей значений не свойственных типу Type , например таким образом: Код func(static_cast<Type>(45)) Для усложнения задачи предположим, что количество "типов" у Type может быть большим и разброс их значений существеннен.

Автор: Anikmar 12.12.2006, 14:17

Она уже защищена. При попытке вызвать функцию с параметром int будет выдано предупреждение компилятора (или ошибка, не помню точно) о несовпадении параметров или о неявном преобразовании т.е. чтобы компилилось без проблем нельзя будет писать func(0); Надо будет писать func(Type1)

Автор: JackYF 12.12.2006, 14:33

Цитата(Anikmar @  12.12.2006,  14:17 ) предупреждение  Именно, что предупреждение. Тут этого ИМХО недостаточно. Программист при желании сможет передать в функцию любое целое число. Так что фильтровать, так или иначе, придется.

Автор: Anikmar 12.12.2006, 14:42

Си чем и хорош - тут программист может творить практически все что угодно - на то он и программист, чтобы следить за собой. А в данном случае - я не уверен, что компилятор схавает значение, выходящее за пределы нумератора, хотя и не пробовал, не знаю... Чтобы полностью защищать функции - лучше работать на паскале. В Си с помощью преобразования типов - такого можно наворотить... Никакими защитами не избежать. Вообще-то я слышал о дуракоустойчивости программ по отношению к пользователям, а вот чтобы она дуракоустойчивая по отношению к программистам была... В конце концов одну проверку в функцию поставить не так уж и сложно.

Автор: Fazil6 12.12.2006, 14:50

Цитата Чтобы полностью защищать функции - лучше работать на паскале. ерунда. Лучше - это вообще ничего не делать. А вообще int автоматом не приводится к enum, а если вы взламывать будете static_cast-ом или reinterpret , то что же вы хотели? Не лгите компиллятору , иначе он будет мстить.

Автор: Anikmar 12.12.2006, 14:54

Цитата(Fazil6 @ 12.12.2006,  14:50) ерунда. Лучше - это вообще ничего не делать. Целиком и полностью с этим согласен.

Автор: UnrealMan 12.12.2006, 15:30

Цитата(JackYF @  12.12.2006,  14:33 ) Именно, что предупреждение.  Стандарт не разрешает неявное преобразование целого в перечисление. Нормальный компилятор должен выдать ошибку.

Автор: JackYF 12.12.2006, 15:38

Цитата(UnrealMan @  12.12.2006,  15:30 ) неявное А явное?

Автор: UnrealMan 12.12.2006, 16:00

Цитата(JackYF @  12.12.2006,  15:38 ) А явное? Явное разрешено: Цитата(ISO/IEC 14882:2003(E) §7.2 Enumeration declarations) An expression of arithmetic or enumeration type can be converted to an enumeration type explicitly. The value is unchanged if it is in the range of enumeration values of the enumeration type; otherwise the resulting enumeration value is unspecified.

Автор: Anikmar 12.12.2006, 16:08

C++ Builder никаких проверок не делает. Выдает предупреждение: инициализация нумератора целым числом. Вывод: C++ Builder НЕНОРМАЛЬНЫЙ компилятор!    Но если серьезно, нормальный программер на Си должен обязательно поглядывать на предупреждения, за некоторыми из них - 100% ошибка, например "Возможно некорректное присваивание" - по запаре забыл второе равно воткнуть в условие и т.п. Так что все равно смотреть надо, что пишешь. Если программер сам ручками пишет некое преобразование (MyEnumType)99999 - то ему и флаг в руки!

Автор: maxim1000 12.12.2006, 16:22

где-то встречал такой подход: вместо enum делается класс конструкторы прячутся (только копирования оставляют) зато делают несколько функций типа Код CMonth January() {     static CMonth january(1);     return january; } и пользуются в программе значениями January(), February(), ... а static_cast in в класс, по-моему, даёт ошибку...

Автор: JackYF 12.12.2006, 16:28

Программер, пишущий код, должен максимально защитить свой код от неправильных входных параметров. Объявлять, что параметр должен передаваться только так и никак иначе - это не выход. Гораздо безопаснее все-таки внутри функции отсеивать неправильные значения. Цитата(Anikmar @  12.12.2006,  16:08 ) Если программер сам ручками пишет некое преобразование (MyEnumType)99999 - то ему и флаг в руки!  Писать код желательно с расчетом на то, что результирующий программист будет делать с приведенным интерфейсом что угодно. ИМХО пиши проверки. Хотя бы в дебаг-версии..., или с какой-нибудь другой условной компиляцией...

Автор: UnrealMan 12.12.2006, 16:57

Цитата(Anikmar @  12.12.2006,  16:08 ) Вывод: C++ Builder НЕНОРМАЛЬНЫЙ компилятор!   Именно так! Всё, что не разрешено стандартом, запрещено. Разработчик компилятора не вправе пороть отсебятину, в частности – расширять множество неявных преобразований, перечисленных в стандарте C++ (а возможность неявного преобразования целого в перечисление там нигде не указана). Например, если мы сделаем перегрузку: Код enum En { en_val = 1 }; void Func(...) { cout<<"..."<<endl; } void Func(En) { cout<<"En"<<endl; } при вызове Func(1) по стандарту обязана вызваться функция с эллипсисом. А ежели в программе, сгенеренной компилятором, вызывается вторая функция (и компилятор ещё смеет сыпать тут своими дурацкими предупреждениями – мол, посмотрите, какие умные вам разработчики компилятора попались: авторы стандарта им в подмётки не годятся), то место такому компилятору в топке.

Автор: JackYF 12.12.2006, 17:07

Цитата(UnrealMan @  12.12.2006,  16:57 ) Разработчик компилятора не вправе пороть отсебятину Так-то оно так, но: 1) как минимум разработчики компиляторов GCC, MSVC, BCC порят отсебятину (каждый свою). 2) во всех этих компиляторах возможно включение опции типа "Ansi компиляция", которая отменяет все эти самые навороты и перевороты.

Автор: Anikmar 12.12.2006, 17:11

На счет приведенного примера перегрузки (оставляю свое мнение на подобный код при себе) - мне стало интересно. В Билдере срабатывает функция (...) Хотя я ожидал, что комп запутается.

Автор: JackYF 12.12.2006, 17:21

Цитата(Anikmar @  12.12.2006,  17:11 ) В Билдере срабатывает функция (...) Как именно ты еще при этом вызываешь? С явным преобразованием или без?

Автор: Anikmar 12.12.2006, 17:25

Вызываю Func(1) - без явного, как и требовалось в примере

Автор: JackYF 12.12.2006, 17:26

Anikmar, тогда можно локально поздравить Билдер

Автор: UnrealMan 12.12.2006, 19:05

Цитата(JackYF @  12.12.2006,  17:07 ) как минимум разработчики компиляторов GCC, MSVC, BCC порят отсебятину (каждый свою). Насчёт gcc я хотел бы посмотреть примерчики (мне пока только пару багов удалось обнаружить, не считая отсутствия поддержки экспорта шаблонов :-) ). Цитата(Anikmar @  12.12.2006,  17:11 ) оставляю свое мнение на подобный код при себе В метапрограммировании подобный код используется в порядке вещей :-) Цитата(Anikmar @  12.12.2006,  17:11 ) В Билдере срабатывает функция (...) А, ну тогда предупреждение в случае без перегрузки в общем-то сойдёт :-) Кстати, чего Builder (какой он у тебя версии?) выведет вот тут? Код enum En { en_zero = 0, en_two = 2 }; const int i_zero = en_zero; void Func1(...) { cout<<"Func1(...)"<<endl; } void Func1(bool) { cout<<"Func1(bool)"<<endl; } void Func2(...) { cout<<"Func2(...)"<<endl; } void Func2(int *) { cout<<"Func2(int *)"<<endl; } int main() {     En en = en_two;     Func1(en);     Func2(en_zero);     Func2(en_zero*1);     Func2(en_zero*0);     Func2(i_zero); }

Автор: JackYF 12.12.2006, 19:57

Цитата(UnrealMan @  12.12.2006,  19:05 ) Насчёт gcc я хотел бы посмотреть примерчики Как тебе строчки: Код int n; n = some_int_func(); char buf[n]; // ... и поехали дальше.

Автор: Anikmar 12.12.2006, 20:51

На предложенный код, мой Билдер (6 версия) показал следующее: enum En { en_zero = 0, en_two = 2 }; const int i_zero = en_zero; void Func1(...) { cout<<"Func1(...)"<<endl; } void Func1(bool) { cout<<"Func1(bool)"<<endl; } void Func2(...) { cout<<"Func2(...)"<<endl; } void Func2(int *) { cout<<"Func2(int *)"<<endl; } int main() {     En en = en_two;     Func1(en);               // Вызывается (bool)     Func2(en_zero);      // Вызывается (int*)     Func2(en_zero*1);  // Вызывается (...)     Func2(en_zero*0);  // Вызывается (...)     Func2(i_zero);         // Вызывается (...) } Касаемо стандартов и нарушений стандартов - лично я считаю, что явного нарушения стандарта в том, что неявное преобразование целого к нумератору не вызывает именно ошибки, а только предупреждение - оправдано.  Думаю это связано с архитектурой визуального программирования - очень много свойств хранится в виде int, а грузится в свойства типа "нумератор" - если бы там были ошибки, то сложно было расширять систему (лично мое мнение). А по поводу расширения стандарта - никакой боле-менее серьезный (а особенно красивый) проект не будет компилироваться в разных средах просто так - все равно поработать с ним придется. Если человек пишет достаточно большую систему на VC ну никак он ее не перенесет на Builder просто так на уровне исходников. Либо он не должен пользоваться практически никакими прелестями VC На чистом стандарте можно писать небольшие модули с узкоспециализированными задачами (например, сложную математику). Как только лезешь в украшательства проекта (а это сейчас не последнее место заниемает в программерстве) то волей неволей начинаешь пользоваться расширениями стандарта, которые имеются у конкретного компилятора. Не берусь судить - нормально это или нет, но принять как данность придется...

Автор: UnrealMan 12.12.2006, 22:08

Главное, чтоб корректно написанная на чистом C++ программа работала так, как предписывает ей работать стандарт. Если это не выполняется, то компилятор однозначно плох (насколько – зависит от характера и количества расхождений). Ну а расширения, делающие из некорректно составленной (с т.з. чистого C++) программы корректную (для данного компилятора) – эт, в принципе, вещь допустимая. Хотя я сомневаюсь, что вот такая некорректно составленная программа Код struct B; struct A {     A() { cout<<"A()"<<endl; }     A(const B &) { cout<<"A(B)"<<endl; } }; struct B {     operator A() const { cout<<"B::operator A()"<<endl; return A(); } }; int main() {     B b;     A a = b; // MinGW-3.4.4: вызывается конструктор A(const B &)     // хотя здесь неоднозначность } в MinGW работает благодаря какому-то целенаправленно созданному расширению, учитывая что следующая программа Код struct B; struct A {     A() { cout<<"A()"<<endl; }     A(B &) { cout<<"A(B)"<<endl; } }; struct B {     operator A() { cout<<"B::operator A()"<<endl; return A(); } }; int main() {     B b;     A a = b; // MinGW-3.4.4: error: conversion from `B' to `A' is ambiguous } уже не компилируется :-) Цитата(JackYF @  12.12.2006,  19:57 ) Как тебе строчки: А, ну да, чего-то такое припоминаю :-) У такого объекта ещё тип какой-то странный, и для него typeid неприменим. Цитата(Anikmar @  12.12.2006,  20:51 ) Func1(en);               // Вызывается (bool) Func2(en_zero);      // Вызывается (int*) Func2(en_zero*1);  // Вызывается (...) Func2(en_zero*0);  // Вызывается (...) Func2(i_zero);         // Вызывается (...) Ты точно ничего не перепутал? :-)) Должно быть: Код Func1(en);               // Вызывается (bool) Func2(en_zero);      // Вызывается (...) Func2(en_zero*1);  // Вызывается (int *) Func2(en_zero*0);  // Вызывается (int *) Func2(i_zero);         // Вызывается (int *)

Автор: Anikmar 12.12.2006, 22:42

Нет, ничего не перепутал - у меня выдало так

Автор: UnrealMan 13.12.2006, 12:54

Цитата(Anikmar @  12.12.2006,  22:42 ) у меня выдало так  Я от билдера ожидал чего угодно, но только не такое :-) Ибо поступать с точностью до наоборот в отношении константного нуля интегрального и перечислительного типа – это высший пилотаж :-)

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)