Область видимости enum, C Опции

[sigmaN]

На сколько я понял, если в заголовочном файле определено что-то вроде

Код

enum packetTypes{ IDPacket, BlockPacket };

то пока не определена переменная типа packetTypes - никакой памяти никуда выделяться не будет? Т.е. это почти то-же, что и typedef, только объявили множество. ?
Также верно следующее:
1. Определить переменную(в .c/.h файле) так: enum packetTypes packetType; можно только при условии include того заголовочного файле, в котором определен packetTypes
2. В любом другом файле, в котором не было include заголовочного - я никаким образом не смогу добраться до packetTypes.
3. Под enum не выделяется память(в отличие от const).
4. Глобальная переменная, определенная как enum packetTypes packetType; может быть видна из другого файла посредством extern enum packetTypes packetType; при условии, что include сделан( и,таким образом packetTypes определен)
5. Можно ли определить static enum packetTypes packetType; и ограничить область видимости переменной одним файлом?(не вижу причин, почему это может не работать. Но всё-же спрошу)
6. тип enum предполагается int. Как в Си изменить его, скажем, на unsigned int или long?

Правильно ли я мыслю? Какие из этих утверждений верны, какие нет?

А ещё всегда хотелось иметь под рукой первоисточник. Стандарт Си(какой там щас актуален).
Если можно тоже ссылочку.

Спасибо.

P.S. Навеяно прочтением книги Ален И. Голуб - Правила программирования на Си и Си++ и осознанием того, что моя программа на Си выглядит ужасно и половина возможностей языка осталась "за кадром"

[dxp]

Никак. Размер элемента enum всегда равен int

А разве это не implementation defined?

На сколько я знаю,

Код

const unsigned char MAX_ROWS = 2;

делает следующее:
Создаёт переменную с указанным типом и именем и инициализирует её указанным значением. Так-же, компилятор при этом внимательно следит, чтобы этой переменной ничего не присваивали и ругается, если обнаруживает такую ситуацию. Т.е. память выделяется.

В С компилятор обязан выделять под константы, объявленные указанным способом, память, т.к. по умолчанию глобальные объекты имеют внешнее связывание - т.е. на них могут быть ссылки из других единиц компиляции. В С++ константы по умолчанию имеют внутреннее связывание - т.е. область видимости такого объекта - scope данной единицы компиляции (файла), и любой вменяемый компилятор не будет под такие объекты выделять память.

Конечно, можно заставить компилятор выделить память путем взятия адреса константы либо объявив ее как extern - в последнем случае эта константа явно указана как имеющая внешнее связывание, что приводит ситуацию к той, что в С. И наоборот, в С можно привести поведение константы к С++ному - для этого надо объявить константу как static - это будет ++ная константа. Попробуйте объявить свою константу так.

[Dima_G]

А разве это не implementation defined?

Да, согласен

6.7.2.2 Enumeration specifiers

Each enumerated type shall be compatible with char, a signed integer type, or an
unsigned integer type. The choice of type is implementation-defined,108) but shall be
capable of representing the values of all the members of the enumeration. The
enumerated type is incomplete until after the } that terminates the list of enumerator
declarations.

(ISO/IEC 9899:TC2 Committee Draft — May 6, 2005)

Почему Linux пишут на Си и не включат режим C++?

P.S. т.е. я Ваш ответ принял. Мне просто интересно.

В ядре - политика Торвальдса (ИМХО - зря). Не любит он плюсы.

Linux creator Linus Torvalds joined in to explain:
"In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

"The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."

http://www.opennet.ru/openforum/vsluhforumID9/8226.html

А в юзерспейсе - полно приложений на ++;

[dxp]

В ядре - политика Торвальдса (ИМХО - зря). Не любит он плюсы.

http://www.opennet.ru/openforum/vsluhforumID9/8226.html

Да, попадались эти "доводы". Мракобесие, имхо. При всем уважении, дяденька, по ходу, не понимает плюсов. А непонимание порождает боязнь, т.к. вещь кажется неуправляемой.

2SigmaN: включите режим ++, ничего там страшного нет. Пишите как обычно. Используйте только те средства, которые освоили. И это вполне комфортный и безопасный путь. С++ не заставляет сразу использовать исключения, множественное наследование, темплейты и ООП. Все это используется в соответствии с задачей. И не бойтесь пробовать. Компилятор С++ в CCS, насколько помню, вполне приличный.

[zltigo]

2SigmaN: включите режим ++, ничего там страшного нет. Пишите как обычно.

Если программа не далеко ушла от "Hello World", то разницы не почувствует. Дальше, дальше все не так благостно . На многие плюсы плюсового компилятора найдутся и свои весьма заметные минусы . Использовать плюсовый компилятор для компиляции "сишных" исходников не самая хорошая идея, хотя раньше сам много лет так делал.

[Dima_G]

Если программа не далеко ушла от "Hello World", то разницы не почувствует. Дальше, дальше все не так благостно . На многие плюсы плюсового компилятора найдутся и свои весьма заметные минусы . Использовать плюсовый компилятор для компиляции "сишных" исходников не самая хорошая идея, хотя раньше сам много лет так делал.

А Вы можете привести примеры минусов С++ комиплятора для Си исходников?

[zltigo]

А Вы можете привести примеры минусов С++ комиплятора для Си исходников?

На вскидку - incomplete types, неименованные структуры и union-ы, упоминание имени volatile переменной не является причиной обратиться к ней, другой размер литерала, передача параметра по ссылке добавленная для пущей "красоты" мешается, много разных мелочей, типа различия в определениях NULL.
Возьмите любую программу приличного размера и просто компильните - различия увидите сами. После появления компиляторов следующих C99 желание пользоваться С++ для компиляции сишных исходников у меня заметно уменьшилось и постепенно сошло на нет. Каждому свое.

[Dima_G]

На вскидку - incomplete types, неименованные структуры и union-ы, упоминание имени volatile переменной не является причиной обратиться к ней, другой размер литерала, передача параметра по ссылке добавленная для пущей "красоты" мешается, много разных мелочей, типа различия в определениях NULL.
Возьмите любую программу приличного размера и просто компильните - различия увидите сами. После появления компиляторов следующих C99 желание пользоваться С++ для компиляции сишных исходников у меня заметно уменьшилось и постепенно сошло на нет. Каждому свое.

Ну в принципе да: С и С++ - это разные языки (впрочем, я так понял, что dxp имел в виду не компиляцию имеющихся сишных исходников, а ведение проекта с нуля, используя некоторые удобства С++, но программируя в си стиле).

А можно поподробнее про "упоминание имени volatile переменной не является причиной обратиться к ней" - довольно часто использую в своих проектах на С++ код вида

Код

volatile DWORD* dwReg_ = reinterpret_cast<DWORD*> (SOME_REGISTER)
*dwReg_ = ...

а как я понял из ваших слов, в этом случае возможно "необращение" к регистру SOME_REGISTER

[zltigo]

а как я понял из ваших слов, в этом случае возможно "необращение" к регистру SOME_REGISTER

Нет не в этом, а в этом:

Код

*dwReg_;