На сколько я понял, если в заголовочном файле определено что-то вроде то пока не определена переменная типа 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. Навеяно прочтением книги Ален И. Голуб - Правила программирования на Си и Си++ и осознанием того, что моя программа на Си выглядит ужасно и половина возможностей языка осталась "за кадром"

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

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

Да, согласен



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



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



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

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

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

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

Ok. В следующем проекте попробуем

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

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

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

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

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



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

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

Именно поэтому я и не кинулся тут-же "включать C++"

Еще забыли enum'ы, которые в С++ являются именно перечислимым типом, в то время как в С - это просто еще один способ создания целых литералов. И обсуждаемые констатны, подход к которым в С++ куда более разумен. Да, такого рода мелкие отличия есть, и отличия эти в большинстве в лучшую сторону. Мне вообще не понятны мотивы людей, которые с упорством, достойным лучшего применения, продолжают толкать С при наличии более эффективного и уже давно стабильного "надмножества" в виде С++.

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


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




У вас большой проект, изобилующий чисто сишными феньками, которые упомянул zltigo? Вы пробовали его собирать в С++ режиме? Попробуйте ради интереса, расскажите, на чем споткнулся компилятор?

Только сделанная с C++ крайне дурно

Я бы сказал, что именно в C++ реализации, с точностью до наоборот .

Ну это ничуть не лучше, чем изощрятся в странных и непрозрачных действиях с обходом реальностей ввиде незаконченных массивов и тех-же лишних ненужных имен для обязательно именованных структур. Просто 'C99' на сегодняшний день вполне продуманный, законченный и сбалансированый язык. Для эмбеддерских целей с переходом на C++ привязка к конкретному компилятору становится заметно жестче , если конечно не писать "Hello World!" с "контроллерами светодиодов".

Естественно, что кондовый вариант скорее всего скушает. Хотя... Я тут прямо сейчас влет попробовал недавно писанный, под AVR практически буквально "контроллер светодиодов", который по идее должен был без проблем компилиться и плюсовым, но тем не менее споткнулся на
__flash char HexChars[16] = "0123456789ABCDEF";

Проблема выбора между фенечками 'C' и фенечками 'C++' Я, как уже писал, последнее время склонился к фенечкам 'C99'. Естественно, для случаев, когда идет речь именно о фенечках, а не о полезности фундаментальных отличий C++.

Потом как-нибудь попробую.
Проект не супер большой, но и не hello world и не мигалка диодами.
После компиляции .text получается размером ~150КБ (TMS320F28335)

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

Обоснуйте, пожалуйста. На примере.



Обоснуйте, пожалуйста. Тоже на примере.


Ничего не понял.


Опять не понял о чем речь. Каких ненужных имен? Что такое обязательно именованные структуры?


Который реально ничем не лучше С++. И значительно слабее в принципе.


Так было несколько лет назад (5+). Но сегодня ситуация уже совсем иная. Платформ в embedded, для которых есть С и нет С++, по пальцам можно пересчитать.



И об какое ограничеие С++ тут споткнулся компилятор?


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

Про возможности ООП. В последнем проекте пришлось разрабатывать GUI. Вообще не понимаю, как работать с GUI без возможностей наследования и полиморфизма. Как представлю, что все это пришлось бы реализовывать на голом С, так просто паника подкатывает.

Тут всего лишь более строгий контроль, который предоставляет компилятор С++. С его точки зрения - это попытка проинициализировать массив из 16 char строкой, длиной 17 char (включая терминальный ноль).