Раньше у меня не было таких проблем. Обычно создавал группу файлов. Как правило все файлы были достаточно обособленными и я их объединял на этапе линковки. Если были групповые общие объявления, то я их делал в main, а в других объявлял как extern.

Проблема возникла в одном проекте. Он получил развитие и теперь существует в нескольких реинкарнациях с различными модификациями и процами. Тем не менее там есть очень крупные общие блоки. Столкнувшись, с проблемой поддержки - пришёл к необходимости общую часть исходников выделить в отдельные файлы/процедуры. А иначе, при внесении изменений приходилось править все проекты. Выделил и переписал, с учётом унификации.

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

Может стоит объединить переменные в глобальную структуру?

Не знаю правда ли, но я недавно прочел такую вещь:
Ален И. Голуб Правила программирования на Си и Си++
А ещё где-то он писал, что за более чем 20летнюю практику программирования он может сказать, что реально обычно требуется пять-десять действительно глобальных переменных на большой проект.
Поэтому Вам следует пересмотреть тактику проектирования модулей и, возможно всё станет куда более прозрачно.

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

Проект достаточно крупный. Переменных много. В том числе и структуры тоже есть.


В общем так обычно у меня и было. Поэтому вопрос и не возникал. А тут специфика.
Представте что модуль выполняет обработку. А-В-С. Причём часть тела модуля B является специфической для разных проектов.
Если не резать, то всё нормально, но тогда придётся поддерживать 4 разных проекта. Но часть B является незначительной по сравнению с объёмом самого проекта. Остальные части удалось формализовать. Частично пришлось переписать с прицелом на "универсальность". В результате со всеми проектами можно работать по единым правилам. А то раньше - где-то подправишь - в другом вылазит.

За книгу спасибо, попробую почитать.

Ну тут, ИМХО, кроме Вас никто не решит проблему.
Я иногда по два-три раза переписываю модули. И причиной является именно неудачное сцепление с остальными
Хотя на меня ровняться не стоит особо - я ещё относительно неопытный программист.

как вариант, объедините специфические "переменные" в группы и передавайте в исп. ф-ции указатель на них:

Попробуй-те использовать С++ !
Пишете какой-то виртуальный базовый класс-родитель, который имеет только интерфейс, никакого кода, а потом наследуете каждый конкретный модуль от базового класса и пишете свой, специфический для данного модуля код (т.е. будет класс_А, класс_Б и тд). Константы и перечисления можно запрятать в класс и никто снаружи их не будет видеть. Ну а дальше уже пишите технологию, которая через интерфейс базового класса работает с Вашими модулями. Ну и для пущей уверенности, запихать все по своим пространствам имен (namespace).

Похоже что было бы оптимально. Там и так уже практически готовая работа с объектами. Но всё равно надо переписывать, а это сейчас влом. Отладка займёт слишком много времени. Проект вылизывался года полтора, чтобы ни сучка ни задоринки.

Я просто думал, что существуют какие-то "стандартные решения" на этот случай.

Всем ответившим - спасибо.

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

Ранее тоже столкнулся с тем, что большая часть кода активно используется в нескольких проектах. Соответственно выделил ее в некоторый фреймворк. Фреймворк тоже состоит из двух частей - платформонезависимой и платформозависимой.

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

Все это написано на С++
Если будет интерес - могу выложить код

Вы хотели сказать "абстрактный базовый класс"?


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

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


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

Вобщем-то, все что вы предлагаете можно и на С реализовать, не применяя классы.
Абстрактный базовый класс? прототипы функций в .h-файле
private-секция? static структура.
Нужно несколько экземпляров одинакового модуля в рамках одного проекта? Передавайте указатель на эту структурку, преобразовав его к void*, дабы вызывающий код не лазил куда не следует (идиома pimpl).
Несколько реализаций одного базового (абстрактного) класса, в данном конктретном случае, как я понял, не нужны, но и их при желании можно реализовать с помощью структуры с набором указателей на функции.

ИМХО в данном случае это лучше, т.к. перетащить большой готовый проект с С на С++ в одно действие не выйдет.

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

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

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


Может и лучше. Но если уж оставаться на С, то и концепции С++ лучше не тащить, от них при ручной реализации будет больше проблем, чем пользы.

Это элементарно контролируется сигнатурой и/или sizeof.

И вообще меня неправильно поняли - я не предлагаю тащить в С концепции С++, а лишь провожу аналогии - это все там и так есть, просто приглядитесь повнимательнее.

Сигнатура - проверка run-tmie + занимает ресурсы.
А про sizeof - не понял как его можно применять для котнтроля типа того, что нам передали по void указателю

Так что не убедили
Нет в Си альтернативы С++ому контролю типов.

PS Откомпилируйте следующий пример Си компилятором и С++ компилятором. Почувствуйте разницу в строгости комиплятора

По теме C vs C++ извините, но.. даже отвечать не хочу. На эту тему сломано столько копий, мама негорюй. Cам я использую все варианты - С, С++ и С# в зависимости от того что считаю лучшим для конкретной задачи (остновным критерием часто оказывается наличие в распоряжении готового кода). И ни спорить ни убеждать вас я ни в чем не собираюсь.

Но на тему комента "// !!! Error in C++, Warinig in C" все же скажу "А не надо писать так, что бы оставались ворнинги, ни в С ни в С++"- вот поспорьте лучше с этим утверждением. Хотя каюсь - сам грешу

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

1. Сделали велосипед...
2. Что-то не устойчив на дороге - прикрутили ещё 2 колеса...
3. Руль тяжеловато крутится - поставили баранку...
4. Крутить педали не хочется - поставили двигатель...
...
10. На голову капает.....
...

35. Ба.... да у нас машина получилась, правда чё-то корявая...

Я, конечно, дико извиняюсь, но трудно привести пример еще более дурацкого "преимущества" , нежели Error/Warning. А если еще знать, что любым (по крайней мере я не знаю, каким нельзя) компилятором можно управлять уровнем Warning->Error. И вообще, нежели кто-то Warning-и отключает/игнорирует, то он сам себе Буратино .

Ой, у современных 'C' компиляторов вполне разумно-сбалансированый контроль типов и то, что в C++ добавили немного паранои, типа
"а чего это вы тут void * пытаетесь инициализировать char *" ни есть ни особо плохо и ни особо хорошо.
Ну с этим

соль совсем в другом месте, а именно в случае:

И

Поделитесь пожалуйста сакральными знаниями, когда const может быть ещё и volatile?

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

Что вас так удивляет? Представьте себе регистр только для чтения - регистр специальных функций (SFR) процессора: например, регистр данных приемника UART'а. Чтение из него сбрасывает флаг прерывания от приемника. Т.е. чтение надо делать обязательно. Писать нельзя. Вот вам и const volatile. Обычная вещь.

Все на столько привыкли к препроцессору, что видимо призадумались.
И я в том числе

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

Меня удивляет, что в приведённом примере был не регистр...
Да, за этот наглядный пример спасибо. А то меня как-то замкнуло на том, что const это константа и всё (т.е. её нельзя изменить и сама собой она не поменяется, а volatile тут сильно всё меняет).

Эта запись не запрещает меняться этой переменной. Она всего лишь запрещает ее менять в этой программе

А вообще - написал volatile, тк иначе компилятор оптимизировал обращение к переменной в printf

Я вот тут призадумался...
А как бы нам так объявить volatile const, чтобы получился тот-же эффект как от
#define XINTCNF2 ( *(volatile unsigned long *)(0x0B34) )

P.S. Оно то понятно, что можно привлечь линкер и соответствующую #pragma для указания адреса.
Но как-то задефайнить привычнее и проще(даже тупо по кол-ву строк на одно объявление)

Еще и переносимее, т.к. #pragma компилерозависимая

Тю Да все так же:

Ну я имел ввиду без использования препроцессора. "По правильному"

Ах простите, я не понял. В общем случае должно быть так:

В сишном исходнике (или в .h-файле) надо написать extern volatile const int VAR;

В скрипте линкера определить символ VAR=1234.

Правда для некоторых архитектур при некоторых значениях адреса и в некоторых компиляторах эффективнее будет определение через #define. Например - ARM, адреса регистров периферии , IAR 5.x.

Ну это не удивительно. Мы же не на форуме экстрасенсов

Ну с линкером да, можно и через символ...Чё-т я не подумал сразу..
Хотя, #define по-моему выглядит со всех сторон привлекательнее.