Вот есть у меня свой тип данных :

и есть функция, которая принимает этот тип в качестве параметра:

Вопрос в том - как мне можно защитить функцию func от передачи ей значений не свойственных типу Type , например таким образом:

Для усложнения задачи предположим, что количество "типов" у Type может быть большим и разброс их значений существеннен.

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

Именно, что предупреждение. Тут этого ИМХО недостаточно.

Программист при желании сможет передать в функцию любое целое число.
Так что фильтровать, так или иначе, придется.

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

А в данном случае - я не уверен, что компилятор схавает значение, выходящее за пределы нумератора, хотя и не пробовал, не знаю...

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

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

В конце концов одну проверку в функцию поставить не так уж и сложно.

ерунда. Лучше - это вообще ничего не делать.

А вообще int автоматом не приводится к enum, а если вы взламывать будете static_cast-ом или reinterpret , то что же вы хотели?

Не лгите компиллятору , иначе он будет мстить.





Это сообщение отредактировал(а) Fazil6 - 12.12.2006, 14:51

Целиком и полностью с этим согласен.

Стандарт не разрешает неявное преобразование целого в перечисление. Нормальный компилятор должен выдать ошибку.

А явное?

Явное разрешено:

C++ Builder никаких проверок не делает. Выдает предупреждение: инициализация нумератора целым числом.

Вывод:
C++ Builder НЕНОРМАЛЬНЫЙ компилятор!   

Но если серьезно, нормальный программер на Си должен обязательно поглядывать на предупреждения, за некоторыми из них - 100% ошибка, например "Возможно некорректное присваивание" - по запаре забыл второе равно воткнуть в условие и т.п.

Так что все равно смотреть надо, что пишешь.

Если программер сам ручками пишет некое преобразование (MyEnumType)99999 - то ему и флаг в руки!

где-то встречал такой подход:
вместо enum делается класс
конструкторы прячутся (только копирования оставляют)
зато делают несколько функций типа

и пользуются в программе значениями January(), February(), ...
а static_cast in в класс, по-моему, даёт ошибку...

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

Гораздо безопаснее все-таки внутри функции отсеивать неправильные значения.



Писать код желательно с расчетом на то, что результирующий программист будет делать с приведенным интерфейсом что угодно.
ИМХО пиши проверки. Хотя бы в дебаг-версии..., или с какой-нибудь другой условной компиляцией...

Именно так! Всё, что не разрешено стандартом, запрещено. Разработчик компилятора не вправе пороть отсебятину, в частности – расширять множество неявных преобразований, перечисленных в стандарте C++ (а возможность неявного преобразования целого в перечисление там нигде не указана).

Например, если мы сделаем перегрузку:


при вызове Func(1) по стандарту обязана вызваться функция с эллипсисом. А ежели в программе, сгенеренной компилятором, вызывается вторая функция (и компилятор ещё смеет сыпать тут своими дурацкими предупреждениями – мол, посмотрите, какие умные вам разработчики компилятора попались: авторы стандарта им в подмётки не годятся), то место такому компилятору в топке.

Так-то оно так, но:

1) как минимум разработчики компиляторов GCC, MSVC, BCC порят отсебятину (каждый свою).
2) во всех этих компиляторах возможно включение опции типа "Ansi компиляция", которая отменяет все эти самые навороты и перевороты.

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

Хотя я ожидал, что комп запутается.