Область видимости 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]

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

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

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

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

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

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

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

[zltigo]

Что касается ссылок, то это отнюдь не для красоты. Это очень полезная конструкция языка.

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

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

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

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

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

Попробуйте ради интереса, расскажите, на чем споткнулся компилятор?

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

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

[dxp]

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

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

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

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

Ну это ничуть не лучше, чем изощрятся в странных и непрозрачных действиях с обходом реальностей ввиде незаконченных массивов

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

и тех-же лишних ненужных имен для обязательно именованных структур.

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

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

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

Для эмбеддерских целей с переходом на C++ привязка к конкретному компилятору становится заметно жестче , если конечно не писать "Hello World!" с "контроллерами светодиодов".

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

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

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

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

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

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

[zltigo]

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

function( a );
Скажите, пожалуйста, как в данном конкретном случае (С++) передается параметр 'a' по ссылке, или по значению?

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

Тут ошибся - редко на плюсах пишу - привиделось. Зато вспомнилось такое

struct aaa {
const int aa;
};

Ну очень заботливый IAR C++ компилятор ругался.

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

Речь идет не о том, декларировано наличие какого-либо ПОДМНОЖЕСТВА C++ для embedded компилятора, а в том, насколько эти усеченные реализации СОВПАДАЮТ у разных компиляторов. Я вот относительно недавно замаялся один чужой C++ проект для банального x86 править под Watcom компилятор - плюнул и Visual Studio взгромоздил.

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

О это да. По иронии судьбы мои первые сишные опыты были на C++. Только появился свежайший Turbo C++ V1.0 компилятор, свободная IBM PC/XT и... На спор с уже достаточно опытным сишным программистом наперегонки, и с выжиманием СКОРОСТИ начали писать псевдографическую оконную библиотеку для порграмматора и с дальнейшим ее развитием под терминал тестовой системы. Короче, зеленый совсем, но победил за пару недель вечерних работ тогда я . Уж больно все классически идеально все сие на плюсы ложилось. В буквальном смысле компилятор думал и делал за программиста очень многое. Потом... потом правда спустя несколько лет выжимание всего и вся для работы на 4.7MHz (не путать с гигагерцами ) XT привело к переводу ее-;t на 'C', к заметному использованию ASM...
И стал меня и 'C' в большинстве случаев очень даже устраивать.

[Сергей Борщ]

function( a );
Скажите, пожалуйста, как в данном конкретном случае (С++) передается параметр 'a' по ссылке, или по значению?

На самом деле в этой точке совершенно не важно, передается он по ссылке или по значению. Это важно внутри реализации function(), а там это известно и реализация пописана с учетом способа передачи.

[zltigo]

На самом деле в этой точке совершенно не важно....

типа совершенно не важно, изменится-ли значение 'a' после вызова этой функции??? Боюсь,что лично для меня это слишком высокий уровень пофигизма абстракции .

[Сергей Борщ]

типа совершенно не важно, изменится-ли значение 'a' после вызова этой функции???

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

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

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

[zltigo]

Передавая указатель вы получаете такую же неопределенность. Может изменить, а может и не изменить.

Ну если пуститься в схоластические рассуждения, то дело В САМОМ ФАКТЕ ВОЗМОЖНОСТИ ИЗМЕНЕНИЯ в одном случае и гарантированной НЕ возможности в другом. Делать эти два случая неразличимыми - ДУРНО. О чем я собственно и написал в начале. К тому как что-либо, в том числе и передача по ссылке, реализовано Виртом надо относится с большим вниманием.
А так, да в принципе для обеспечения более строгой работы с объектом по ссылке, нежели через указатель вещь не бесполезная. Наверное кому-то поможет, хотя с точки зрения минимализма и универсализма достаточно указателей. Причем поскольку наличие ссылок не покрывает возможности указателей, то культуру работы с указателями по любому надо в себе воспитывать. Умение уверено обращаться с указателями, делает лично для меня наличие передачи параметра по ссылке не сильно привлекательной.