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

Да, точно, не сообразил сразу (на __flash засмотрелся). Сишный компилятор выдает предупреждение.

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

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

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


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


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

У меня есть куча строчек вида
Это передача параметра по ссылке при инициализации объекта. Мне уже легче, что не нужно каждый раз крякозяблу (&) ставить "для понятности". К тому-же ее можно случайно забыть поставить и тогда вместо адреса будет передаваться непонятно что, ну а дальше результат непредсказуем.

Не будет, контроль типов никто не отменял.
P.S.
Ну а о рассуждать "понятливости" с теми, кто переменные называет OP_PP2, K_PP2.... вообще не хочется .

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

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

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

мне безразлично один Вы такой или там вас целая фирма .

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

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

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

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

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

Ну вот она ключевая фраза. А мне не нравятся статические локальные переменные. Вот почему-то не нравятся. Но я же не утверждаю, что они - зло и лишняя сущность.

Если для важно, чтобы объект не менялся, то надо и тип аргумента задавать соответствующий - с квалификатором const. Это во всех смыслах полезно - и защита от ошибок, и повышает читабельность кода. И тогда

void f(const int A& x) { ... }

совершенно ясно, что передаваемый объект не изменяется. А если без константы - то сразу подразумевается, что изменяется.

Кстати, заметил, что в С-сообществе культура использования const как-то не очень развита. Очевидно, это происходит оттого, что сами по себе константы более накладны, и вместо них предпочитают использовать макросы препроцессора.

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

Лично я использую достаточно широко, в том числе достаточно часто прикрываю const некоторые элементы структур - конечно, своеобразный костыль по сравнению с возможностями С++ .