Например что-то вроде этого. Программа не вылетит рантайм, потому что пользователь передал функции неверный тип а выдаст компайл тайм ошибку. Разумеется это упрощенный пример.

Это сообщение отредактировал(а) azesmcar - 4.5.2009, 19:37

магнитне бури
мысли плохо считываются

как константы обозначающие бит или битовую комбинацию.


а нет чего нибудь более  "показательного"  или "применительного" ? 



Это сообщение отредактировал(а) mes - 4.5.2009, 21:13

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

mes

Еще как вариант - перегрузка

частичная или полная специализация шаблона для типов enum


Это сообщение отредактировал(а) azesmcar - 4.5.2009, 21:46

Вот еще пример, допустим мне нужно хранить значения своего enum в векторе. Можно специализировать вектор потому что 2 бита для хранения моего enum-а мне вполне достаточно. Это может понадобится при передаче большого количества данных по сети например.


без типа такого сделать не выйдет 

ага пример с header не очень, 
так например массив, к которому не нужен динамический доступ, лучше заменить структорой,
также и для функции не вижу реального примера, когда лучше огранить enum`ом как в Вашем примере.
диапазон  намного эффективнее контролировать например так:



вот тут надо подумать - попробую подобрать задачу под такое применение.


azesmcar, спасибо за старания.  

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


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

mes


Может и понадобиться, смотря какая задача. Если заголовок какого нибудь протокола - динамический доступ наверняка будет нужен (котрольные суммы, итд, итп...)

Можно так - согласен
Эффективнее? вот тут непонятно.. О какой эффективности идет речь если мы говорим о компайл тайм проверке? 


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

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

а..видимо не заметил, прошу прощения.

но пока я не вижу, что приведенное решение хорошо справляется с задачей. 


Разумеется не о скорости, а о качестве и возможностях проверки. Последний случай (стат. проверка в шабл.), грубо говоря, к примеру, нас освобождает от запоминания того, что енумы хидера должны идти по порядку. 

Я немного доработал свой первый пример, попытался сделать его нагляднее. Получился почему-то генератор майм заголовков  
Посмотрим на этот код к примеру (не надо его критиковать  быстро написал для примера)

посмтрим что он нам дает. 
функции set_header нельзя передать неправильное значение (если не извращатся с Си стайл cast -ом и другими методами, но это не в счет). Если заменить тип на int, получится что в него можно передать все что угодно. Тогда ставим ваш STATIC_CHECK - кстати а как он выглядет взглянуть можно? В принципе можно конечно, но зачем писать то что должен сделать компилятор за вас?

Я так понимаю STATIC_CHECK это описанный у Александреску макрос? Но я не понимаю как он применителен здесь? Функция получает параметр..как будете проверять? Давайте поступим проще  
измените мой код так, чтобы он работал с int без потери безопасности

Это сообщение отредактировал(а) azesmcar - 4.5.2009, 23:27

да понял я
это было пояснение к предыдущему

видно опять невнимательно читали, или я плохо объяснял свою позицию 


для начала несколько цитат:  




Я вот даже не знаю как бы поточней выразить свою мысль.Я считаю енумы "слабыми" среди типов и их ниша именно константы (с которой они справляются очень успешно).
Ваш пример только подверждает мою позицию. Переменная e, косвенно попадающая под наше рассмотренние, нужна лишь для "переноса" константы.
Никаких операций с ней не проводится. Я подумаю, и позже постараюсь поясней выразится.

P.S.


ага из этой категории :
http://www.solarix.ru/for_developers/cpp/s...assertion.shtml

вот переписываю под int (просто для сравнения,так как Ваш пример меня в принципе устраивает, и если бы я и стал менять то не в сторону inta , a в сторорну структур )

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

http://forum.vingrad.ru/index.php?showtopi...t&p=1857876
http://forum.vingrad.ru/index.php?showtopi...t&p=1860045




Это сообщение отредактировал(а) mes - 5.5.2009, 01:12

Согласен  
енумы слабые, я не спорю, но это то что дал нам С++, не выбрасывать же на свалку нужную вещь  

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

отлично  это нам и нужно. Пример принят, а вот теперь можно уже поговорить (поспорить) о том как правильнее.
Для начала - оба варианта

и

и так, попробую привести все достоинства и недостатки этого решения

Решение с помощью STATIC_CHECK.
Недостатки

• Приходится писать лишний код
• Для каждого типа используемого енума будет сгенерирована отдельная функция
• Функция обязательно должна быть определена в заголовке (экспорт шаблонов я по понятным причинам игнорирую    )
• Стиль вызова функции изменяется на немного необычный. 
• Вызвать функцию динамически уже не получится, например итеративный вызов функции для всех заголовков будет невозможен

Достинства

• Возможность писать другие компайл-тайм проверки (типа приведенного примера)

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

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

будем не только генерировать заголовки, но и загружать их. Допустим в функции set_header не примитивное присваивание а сложные ран-тайм проверки на соответствие значения стандарту RFC, так что функция нам нужна.

Это сообщение отредактировал(а) azesmcar - 5.5.2009, 09:17

Придерживаюсь вашего мнения и поэтому перед приведением примера, сделал замечание :



абсолютно согласен, енум полезная и удобная штука.


Еще раз спасибо за дискуссию 


Да, но Ваш пример лишь косвенно затрагивает, тот случай который меня интересует, 
не типизация параметра функции енумом, чтоб ограничить набор констант, при котором переменная служит лишь для передачи константы,
Во всем остальном используется int. 
Да пример удачно справляется со своей задачей, но условие задачи несколько  вырожденное, так как изначально предполагается, что хидеры следует в порядке очередности.

Меня же интересует случай, когда нужно именно создание переменной для каких либо операций.

Вот например мой условный пример, в котором рабочая переменная int; и делать ее енумом не даст никаких преимуществ.

этот пример отражает мой взгляд на область применения enuma. 



Это сообщение отредактировал(а) mes - 5.5.2009, 10:02

да, но со структурами мы потеряем возможность итерации, что может понадобиться в рамках задачи.


И вам спасибо за грамотную и обоснованную дискуссию 


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


задачие разные бывают  

не то что не даст преимуществ  тут самое место типу инт. Так как с енумом вы даже ++ не сможете сделать.
но это уже другой пример.

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

Это сообщение отредактировал(а) azesmcar - 5.5.2009, 10:49

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


Да, с учетом всех вышеизложенных пояснений к моему взгляду . 


не потеряет 
Вот "исправленный" на скорую руку пример (хотя чего то в нем не хватает, но выполняет ту же задачу что и в приведенном Вами примеров, но без участия енума в логике. )


и из двух направлений решения задачи (с енумом и без) я склоняюсь к последнему 

Это сообщение отредактировал(а) mes - 5.5.2009, 14:07