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

Причем ошибка пропадает, если заменить структуру на отдельные char или передвинуть эти объявления в другие файлы

Что это может быть? Час потратил, передвигая структуру с места на место - никакой закономерности не обнаружил, то она есть, то нет

Кому не лень, посмотрите у себя, может на другой версии этого глюка нет?
Обкоцанный (но с ошибкой) проект прилагаю. От машины не зависит: и на работе, и дома одинаково.
Ошибка возникает в файле gsm.c на структуре GSM_Rx

Это не вдруг

Объявления лучше делать именно в том модуле, где переменные/структуры инициализируются/используются. В остальных модулях их нужно просто externнить.
Исходники просмотрел "по диагонали". Замечание такое. Пользуйтесь активнее условной компиляцией. Например, если бы вы содержимое хедера gsm.h обрамили так

То было бы проще externить эту структуру. Достаточно проincludeть gsm.h непосредственно уже в исходник.
К тому же я обычно пользуюсь typedefом, в т.ч. для того, чтобы было удобнее объявлять и externить структуры.
Ведь проще один раз написать

А потом проincludeть этот хедер и знай объявляй себе эти структуры

и/или


P.S. гы пока я писал ответ, zltigo уже пример с конкретными изменениями предложил.

Все-таки, предложеный вами typedef - это не решение вопроса, а обходной путь. Через typedef все работает. Я вообще typedef применяю только тогда, когда нужно структуру применить несколько раз. В случае уникальной структуры предпочитаю явные определения. Иначе, для того, чтобы посмотреть на члены структуры, приходится лезть лишний раз в хедер. Зачем мне лишняя вложенность, только ухудшает понимабельность. А в этом конкретном случае я решил свести несколько отдельных char в структуру только исходя из эстетических соображений По стандарту Си мой вариант написания совершенно легален.

Это дельное замечание, буду применять. Раньше писал небольшие проекты, ограничивался несколькими файлами в проекте: main.c; modules.c; isr.c; memory.c; defines.h - все было без проблем. Сейчас проект побольше. А когда в файле больше нескольких тысяч строк, уже неудобно, решил начать делить проект ещё и по периферии. Вот и возникла по-первости такая каша

to All: Спасибо за участие, с вашей помощью разобрался, дело в следующем. ИАР не всегда дозволяет в одном модуле наличие собственно определения переменной и определение её как extern. Примеры:

Это проходит без ошибок:


А на явное определение struct или union ругается:


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

Можно и без typedef, это совершенно не принципиально (см. приложение). Но
1. структуры надо описывать просто, однозначно и в одном месте.
2. нет ни одной причины не использовать typedef везде, где это возможно.

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

Правильно.

Ну почему же, или причина которую я привел не причина?

Дело вкуса и привычки (и главное, лени )


Такое тоже применяю, мне такая форма нравится даже больше, чем typedef

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

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

Причина ну никак не относится к использованию или неиспользованию typedef. Или я чего-то совсем не понимаю.

Да, похоже мы одни и те же слова воспринимаем по-разному. Я имею ввиду след: если стандарт в конкретном случае разрешает не применять typedef и я считаю, что так будет наглядней, то нет никаких причин его использовать. Короче, тоже дело вкуса, спорить не о чем

Со всем этим согласен. Но почему тогда это недопустимо по отношению к структурам, описанным в явном виде:

Я не вижу логики в действиях компилятора. Или он начинает и в случае extern выделять память?

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

Для начала я не вижу логики в действиях программиста дважды определившего одну и ту-же структуру. Дальнейшие логические построения, рассуждения и толкования должен-ли 'extern' служить решающим указанием компилятору для того, что-бы считать это нагромождение разумным, меня с практической точки зрения совершенно не интересуют. Однако, поведение любого компилятора молча глотающего подобные выражения сочту совершенно неправильным.

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

Насчет контроля типов тут много копей сломано. Но я в этом вопросе так и не разобрался. Вот вы говорили:
Тут хотя случай без #define, но похоже. Чем все-таки будет отличаться обработка структур CCC и DDD? И там и там структура, и там и там ее обрабатывает компилятор:
Кстати, если бы был #define, то после него все равно явное описание типа обрабатывалось бы компилятором.

Вот Сергей Борщ в том обсуждении сказал: "Поэтому надо больше читать тематической литературы. Разница есть."
А я никак не могу найти ту "техническую литературу", где этот вопрос освящен. Например у Кернигана и Ричи (2-е изд) применение typedef никак не связывается с улучшенным (добавочным) контролем типов:

И все... Так где об этом можно почитать? Гуру, дайте ссылку

Ооооо! Кипячусь совсем не так . В данном случае я совершенно спокоен, не спокоен, я буду, например, тогда, когда мой заказчик потребует не пользоваться typedef

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

Наверное, я дурак - я много учился на своих, а не на чужих ошибках . Посему ссылок у меня нет. Чувство языка есть, писать могу, а ссылок нет . Книгу, что-ли написать? и ссылаться. Единственно, что меня несколько оправдывает, так это то, что на момент достижения мною приличного уровня программирования Интернета, считайте еще не было . Диалап по модему 2400/NONE на LatNet, по знакомству, с возможностью (чудо!) поползать по FTP это уже позже - год 91-92....

P.S.
Кстати, попробовал четыре наиболее используемых мной компилятора, рад сообщить, что мое мнение совпало с мнением их создателей .

Вопрос, вынесенный мною в тему топика, я уже для себя прояснил, спасибо. Просто мне показалось, что вы раньше делали упор на то, что применение typedef при определении структур улучшает именно контроль типов, а не удобство использования структуры. Если я не прав, поправьте меня.

Сейчас у меня в процессе разговора на первый план вышел другой вопрос, который я пытался задать в предыдущем посте, но видимо неудачно. Это тот старый вопрос с #define. Вот он еще раз (о ужас ):

В чем же все-таки проявляется эта разница в плане контроля типов? Разве в случае с #define, после работы препроцессора не происходит такая-же обработка компилятором? А то получается, что контроль типов производится только при наличии typedef. И объявление:

лучше, чем (после препроцессора):


Пока что я слышал от всех только общие рассуждения: "#define и typedef по разному обрабатываются ", "Дурной стиль без всякой на то надобности да и еще с побочными эффектами" и т.д. Но никто не дал ссылку или разъяснил почему это так в деталях.
Поделитесь, pls, своими знаниями, своим опытом. Приведите хоть один пример, где это дает ошибку. А то я уже запуган , озираюсь в поисках опасностей, но нигде их не вижу.
Я ответ не знаю, и пока не могу найти ответ на него в первоисточниках, вот и хочу порасспрашивать знающих людей. Думаю, это еще многих может просветить.


p.s. Кстати, у вас были намного лучшие условия в плане интернета: я периодический доступ (пару раз в неделю на пару часов) получил только году в 98, а постоянный доступ на работе (с жуткими ограничениями) только в конце 2000

И то и другое.
lint не приходилось в помощь компилятору использовать? misra?

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

От Вас жду хоть один пример "вредности" typedef.

Ну, хорошо, будем считать, что я удовлетворился, все равно нюансов от вас не добьешся

Про lint и misra слышал, но не применял, видимо поэтому у меня и возникают все эти вопросы. Хотя, как я понимаю, это больше нужно для переносимости кода а не для контроля типов.

Пример с #define, наконец разобрал. Там это как-то неочевидно расписано. Мне нужно подробно, как для тупого студента Да, действительно, в частных случаях возможны ошибки.

Про "вредность" typedef я не говорил, я говорил только о снижении читабельности кода при сокрытии определений структур за typedef. Больше у меня к этому оператору претензий нет. Но это вопрос пристрастий.

to rezident: просмотрел ваши документы, но нужного мне не нашел. Это хорошие наставления по стилю правописания на Си, а я хотел почитать более углубленно про применение typedef и его влияние на улучшение ситуации с контролем типов.

Всем спасибо, прошу и других высказать свое мнение и привести реальные примеры, а то похоже наш модератор задавил остальных своим автортиетом

Это не я! Невиноватый я! Честное слово, это не я придумал typedef !!! Это отцы основатели ввели такую ненужную штуку и так задавили все последующие комитеты по С и С++ своим, понимаешь, авторитетом, что эти комитеты до сих пор этот пережиток прошлого "снижающий читабельность кода" не запретили. Может голосование устроим в поддержку отмены?
Нежели еще примеры нужны, то подсказываю - области видимости typedef можно ограничить, а #define - нет - ну не разбирается препроцессор в языковых структурах...
А как насчет:
typedef unsigned char xbuff_t[X_SIZE];


Не сколько для портируемости, сколько для много более жесткого контроля исходного текста с точки зрения возможных недопониманий компиляторами. Для серьезных применений достаточно часто требуют, хотя та-же MISRA это полный мрак . Хотя для общего представления рекомендую разок прогнать.


Ну не скрывает сам typedef никакие определения структур. Совсем не скрывает. Третий раз повторяю - посмотрите второй пример правки Вашего исходника - ну нет там уже никаких typedef, а структуры по Вашему утверждению "cкрыты".

Любите вы загадки задавать! Конечно, такое определение типа при помощи #define не слепить.
Но я мыслю попроще, и это как раз тот пример, как я не буду писать, потому что:
"снижается читабельность кода при сокрытии определений реальных объектов за typedef" (ИМХО)
Я предпочитаю написать в пять раз длиннее, но понятней для меня. А чтобы понять ваш пример, мне пришлось голову поломать. Смысл я понял, но необходимость в такой записи - нет. Тупой прямой код понятней и ошибки точно так же выявляет:
Удивило, а почему предупреждение, а не ошибка?

Впрочем, о чем это я : "На вкус и цвет товарища нет".

Попробуйте под разными компиляторами (и под C++), попробуйте как это будет работать когда все разнесено по разным файлам. Попробуйте оценить "удобство" "прямого" кода, кода в одном файле
Вы написали:
unsigned char bufB[3];
а в другом соответственно:
extern unsigned char bufB[3]; - удобно за собой эту троечку таскать? Даже если она через #define где-то там в третьем месте определена? А ошибиться написав extern unsigned char bufB[5], или bufB[Y_SIZE] вместо X_SIZE?

Так понятия наши меняются со временем. Полагаю, что Вы не родились с врожденным пониманием арифметики, но абсолютно уверен, что потом "поняли" и на данный момент никаких проблем не испытываете .

P.S.
Подкинуть еще "загадок" про typedef?
Можно и к понимабельности перейти, например, хотелось-бы увидеть, как выглядит прототип такой функции:

в более понятной для Вас форме.

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


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


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

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

Учебников давно не читал , все больше "опыт" , так-что кусочек из реального исходника.

И больно стукнет прямо в лоб . Лучше заранее подготовится пока все просто .
Да и в простых вещах, например, при дополнении атрибутами const, volatile можно нарваться на совсем ненужные сюрпризы.

Да, наверное, вы как всегда правы


Дык я об этом и пишу, только в более мягкой форме. И еще: зачем же я все эти разговоры завел? Получил бы ответ на свой первоначальный вопрос - и шмыг в свою норку - дальше копать, не разбираясь, а может я копаю не так или не туда Я вот и пытаюсь "заранее подготовится пока все просто" и можно это сделать "мимоходом", с минимумом трудозатрат и максимумом пользы


Если не трудно, не ради "разговор поддержать", а ради "заранее подготовится", можете привести примеры проблем или кратко описать их?

Я не стадаю манией величия, посему прав далеко не всегда, правда "выступать" стараюсь в случаях, когда есть уверенность близкая к абсолютной .

Дык, зачем-же я все эти разговоры продолжаю - чувствую, что "лед тронулся" . Есть и еще тайный умысел - может когда поработать вместе придется .

Можно, вот иллюстрация к помянутому:

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

ОК, понятно. Это когда от перестановки слагаемых начинает меняться сумма

По ходу вопрос, может я и гоню....

Не получается обьявить тип структуры в которой этот тип и используется.



Error[Pe020]: identifier "blc_t" is undefined

Так сделать невозможно - какой размер будет иметь структура, если она вмещает саму себя? Рекурсия-с!
А если указатель на эту структуру, то так:

Ну, во-первых, вы пытаетесь применить тип, который вы еще не объявили (только находитесь в процессе объявления).

А во-вторых, даже если бы вам компилятор это разрешил делать, у вас получилась бы рекурсия. Подумайте, что при этом получится: бесконечная вложенность, фракталы. Боюсь, вам памяти не хватит

Сорри это я опечатался естественно там указатель.



Не работает.




так работает

Какие проблемы? Естественно нельзя использовать тип, до его определения, но проблем-то и нет:

Спс, помогло

Совершенно обыденный прием, например, менеджер памяти - Меmory Control Block содержит указатели на аналогичные блоки в цепочке.

Проверял в C++ (GCC 4.1.2) - там работало. Для С наверное надо делать так:или как написал zltigoУказатели - да. Получаем связанные списки. В исходном вопросе внутри структуры была сама эта же структура

Чтобы не плодить темы решил написать здесь.
Подскажите пожалуйста, вроде Си позволяет описать структуру и объявить указатель на эту структуру

например


И затем обращаться к членам структуры как



Но в результате присваивание происходит не корректно.

Если делать использовать



И затем обращаться к членам структуры как


То все нормально...

Что я делаю не так?

Забыли выделить память под структуру и присвоить указателю адрес выделенного участка? Покажите инициализацию pFlag.

Вот двеструктуры:

struct TErr
{
volatile bool Already;
volatile bool Unknown;
};
struct TErr* pErr;

struct TFlag
{
volatile bool No;
volatile bool Ok;
};
struct TFlag* pFlag;


Стоит изменить один элемент структуры, то происходит изменение элемента в другой структуре

Ну у Вас опять же выделено место только под указатели на структуры, а сами структуры где?
Надо примерно так:

В таком случае Вы создаёте место под сами структуры и их адреса передаёте указателям.
В Вашем предыдущем случае указатели были проинициализированы нулями по умолчанию и указывали на одно и то же место.

IgorKossak,

Да, точно. Глюканул. Всё работает.