Спасибо, князь. Вы настоящий дворянин. И программист.
-
- Теперь я допишу то, что я по некоторым причинам не дописал вчера. На первый взгляд нам не удалось решить вопрос с уникальностью мест модификации/вызова. Как я заметил по обсуждениям выше есть желание сделать это место уникальным хотя бы на уровне линковки. Я хочу показать, что здесь неверен сам подход по обретению такого контроля. Что мы имеем исходя из исходных условий? Мы имеем некий spaghetti (или просто неструктурированный) код, который не контролируем до такой RxTx(1728 знак., 08.05.2020 10:24)
- В отдельном модуле (.c) определить переменную как, например, int x.
В хидерах определить как extern const int x. Переменная будет
читаема, но не записываема. Для изменения переменной в том же
отдельном модуле, где определена переменная, сделать специальную
функцию и разместить её декларацию в хидерах. Преимущество перед
твоим методом: доступ на чтение более легковесный (чтение ячейки
памяти, вместо вызова функции). Работает только в C, или нужно
добавлять extern "C" fk0(49 знак., 08.05.2020 01:20)
- только в хидере еще в #ifdef обернуть желательно. Типо такого: LightElf(86 знак., 08.05.2020 10:21)
- GCC: error: conflicting type qualifiers for 'x' - NAUT(08.05.2020 09:30)
- +1, безусловно это решение более легковесное. У каждого решения есть свои плюсы и минусы. - RxTx(08.05.2020 09:18)
- Меня терзают смутные сомнения... il-2(760 знак., 08.05.2020 08:09)
- А ты не включай, или сделай #ifdef как LightElf выше показал. А то ошибка действительно будет. В гарвардской архитектуре (где код нужно генерировать другой) такое может не заработать. А может и заработать. Hitech-C для PIC18 в рантайме по адресу определял как к переменной обращаться (не в compile time). Только обращаться нужно было бы через указатель. А линкер не ругнется: в C (в отличие от C++) тип в имя не кодируется и линкеру ничего о типе не известно. - fk0(08.05.2020 11:56)