В одном файле определено перечисление:

enum ms {ONE, TWO} State;

Как в другом файле можно обратиться к State?

компилятор ругается на 

extern enum State ;

или

extern ms State;

state.h:

state.cpp:

main.cpp:

Riddik

ему должен быть известен тип, обяви тип enum ms {ONE, TWO} в заголовочном файле, иклудь в обоих юнитах. А дальше экстерном - как обычно.

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

PS: нужно #include "state.h"

a еще лучше (имхо) объявлять переменные не  enum типа,  а простого целочисленного.
А енумы использовать как набор констант (для сравнения или присваивания).   

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

Большое спасибо всем 

Почему нельзя создать два enum c различными именами, но частично одинаковым содержимым?

zim22

Потому что члены перечисления входят в то пространство имен, в котором было обявлено само перечисление.


в вашем примере имя А фигурирует в обоих перечислениях и если написать
std::cout << (int)A;
будет неоднозначность - какую именно выводить.
Можно сделать так

и кстати мне кажется что так и надо использовать перечисления 

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

поддерживаю   

Эээ... Ну и как мне теперь создать переменную типа этого енума?!

Любитель

Если нужно создавать - тогда перечисление нужно именовать разумеется


пространство имен этому никак не препятствует

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

Любитель,  А можно узнать хоть одно преимущество, которое дается при создании переменнной типа енум ?
я, к сожалению,  вижу только недостатки. 

P.S. чтоб не подумали, что я противник енумов, повторюсь -
я стороник такого подхода :



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

mes, проверка на этапе компиляции.

Кстати, enum используется в шаблонном программировании для превращения чисел в типы (у Александреску написано), но тут уже без переменных собственно.

правильно
а все указатели объявлять типа void*
нахрена нам контроль типов - мыж сами умные

которая подводит в неподходящий момент :

  

употребление в шаблонах отдельная тема.


насчет void* Вы не по адресу - я стороник типизации.
Но, наверно, я не сталкивался с такими задачами, когда мне нужен был именно контроль по enum-типу и  при  этом хватало бы гарантий которые он дает.
(старался типобезопасность обеспечить через более "надежные" типы).
Обычно enum использую для битовых комбинаций флагов, и в таком случае от злоупотребления енумов получаю лишь лишнюю писанину:

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



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

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

Это сообщение отредактировал(а) 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

mes, а чем в таком случае bool лучше чем int? В С++ слабое разделение типов зачастую (в плане разрешения неявного преобразования). Дело здесь в первую очередь не в функциональных возможностях, а в читаемости кода  Я так думаю...

Есть прога, которая всё время крутит различные циклы. Циклы эти разные и между ними нужно переключаться время от времени. Я, конечно, новичок ещё тот, но лучше перечисления в этом случае ничего не вижу:

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


а ..мне казалось речь шла об этом

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

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



    

  

Спасибо всем (особенно azesmcar), за то что помогли расставить мне мысли по полочкам. 
Для себя я на данном этапе с этим вопросом разобрался.

Вот альтернативный  условный вариант (для опыта)

разницу между этим вариантом и с кейз думаю показывать не требуется 

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

паттерн state поможет 

mes, 
azesmcar, 

спасибо, учту   

Есть еще 2 преимущества у переменной типа enum, правда они оба чисто human factor.
1) Использование enum в определении переменно явно показывает намерения автора
2) При использовании enum переменной дебагер может показывать для ее значений осмысленные идентификаторы (в любом случае это лучше, чем голые цифры)
Область - support & development

Вот это основной фактор. Всё остальное - частные случаи