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

Да. Этим вы определяете тип данных, и множество значений этого типа. Переменную этого типа вы таким образом не объявляете.


ДА



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

Под const тоже память выделяется не всегда:
будет полностью равнозначно

Только в первом случае, если где-то будет MAX_ROWS переопределено (ошибочно), то компилятор выразит свое негодование программистом, а в случае с #define сделает вид что ничего не заметил.
Это актуально для С++ и вроде актуально для С99 (для С89 вроде как нет).


могу ошибаться, но книга ОЧЕНЬ старая и там многое устарело, особенно что касается С++.

Ok. Сппсибо. Просто хотел уточнить для верности.

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

Попытка "передефайнить" MAX_ROWS заново будет выдавать предупреждение(мой компилер делает это так). Не знаю как насчёт поределения где-то после...вот этого действительно заметить не сможет. Но оно и не страшно вроде как, потому что препроцессор ещё ДО компилятора уже выполнил подстановку и подставит куда нужно циферку 2(в нашем случае)... Но спору нет. Путаница получается.

Книга может быть и старая, но вот некоторые советы в ней, кажутся мне бессмертными
В С++ пока не вникал, не знаю.....

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


Препроцессор очень злая штука (ОЧЕНЬ ЗЛАЯ!!!). Если где-то в заголовках будет написано #define MAX_ROWS 2, а потом где-то по ошибке будет написано #define MAX_ROWS 4, то может получиться очень неоднозначная ситуация, когда будете думать что должно подставлятся 2, а на самом деле будет подставлятся 4.

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

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


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

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

ООоо, а про static к константе я как-то не подумал. Щас посмотрим выделит память или не выделит :-)

http://www.onlinedisk.ru/file/239872/

А что смотреть? Если взятие адреса не происходит, то и в памяти её держать не нужно.
static const - есть правильная альтернатива define.
За исключением того, что другую константу нельзя инициализировать ей.
И ещё, очень красиво на замену define ложится безымянный enum. Вместо:используйте:Программировать надо на языке программирования, а не на языке препроцессора. ИМХО.
Конечно, есть целый класс задач, решающихся с использованием макросов (инициализация полей больших структур значениями по умолчанию например).
Но когда можно написать программу красиво и выразительно без использования директив препроцессора, то так и стоит поступать.

Однако давно хотел спросить как это так?





Комментируем
Компилю под TMS320F28335

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

а в таком простом деле он не позволяет выполнить то, что позволяет #define
Тут нужен enum. Но там, где значение выходит за границы int - enum не прокатывает и приходится использовать const и принципиально правильной назвать нельзя ни одну из альтернатив.

rezident, с Вашими рассуждениями нельзя не согласиться. Однако, немного не логично как-то. Если const уже const и его нельзя менять по определению, то почему-бы компилятору не выполнить ту-же подстановку его инициализирующего значения и просто не скомпилить код Нужно будет написать в SO/IEC, пусть правят

ЯВУ он потому и высокого уровня, что позволяет весьма просто объяснить компилятору то, что вы от него хотите. Однако компилятор это тоже программа, которая не может "домысливать" за человека и поэтому работает в рамках описанных правил и стандартов. Общеизвестно, что любая программа не умнее программиста, написавшего ее

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

Почему 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 (включая терминальный ноль).

Да, точно, не сообразил сразу (на __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 некоторые элементы структур - конечно, своеобразный костыль по сравнению с возможностями С++ .