inline

я отрицаю.

 

И...

 

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

 

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

 

впрочем, спорить я тоже не буду, каждый др@чит как хочет.

 

Согласен, и с первым и со вторым \

По первому, Глобально - да. В больших проектах, особенно в проектах, где работают несколько человек, 100% ДА! Я тоже за ограничение области видимости!
А в частном случае, например в полностью самописном, коротком и линейном коде, это может быть абсолютно не принципиально.
Все дело в задаче, от нее будет зависеть реализация.

Про глобальные переменные, я так, в принципе . Надежность то не изменится, если писать правильно!

 

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

 

У меня тоже есть привычки, и это не глобальные переменные.
Но весь спор прошел с этого:

А.. потом слово за слово...

 

А я согласен, 3/4 темы можно безболезненно поудалять.
Паровозику всё равно на наши измышлизмы.

 

Не надо ничего удалять. Когда я ещё соберу такую отличную компанию и в одном месте? Даже картавить перестал.

 

У меня если переменная глобальная, то она обязательно volatile. А раз она такая, значит без нее уже совсем никак.

 

Хто? О_О

 

А, ня понял. Все функции в *.h файле будут инлайниться несмотря ни на что? Ну т.е. если я хочу гибкости в решении, то функцию необходимо определять в вызывающем её файле. А перегрузка функций на Сях невозможна. Ммммдаааааааааа....делаааааааааааааааа
Как тут не сказать словами Кошака

(с) Кошак

 

Да из *.h-ника все будет нормально подключаться, и даже инлайнится.
И код не разрастется, а может даже уменьшиться.
Просто нужно думать, что и как работает!

Это как раз хороший пример того, что если не думать, и тупо включать *.h-ники, во все файлы - код может увеличиться.
Но это же не наш метод, мы же думаем !
Я же показал, и так и так, код одинакового размера.

Каждый модификатор делает свое дело. Но нужно понимать, и ставить правильный модификатор! Тогда траблов не будет!

 

Да опять все не тау. Определяя функцию в заголовочном файле, к ней надо приставлять квалификатор inline. Вопрос в чем - смогёт компилятор такую функцию НЕ_ИНЛАЙНИТЬ или нет?

 

Смогёт. inline - это рекомендация и не более.

 

Подолю-ка маслица в уголёк и кину всё в огонь.....
Не буду говорить за все компиляторы, но данная ветка про AVR и официально поставляемый компилятор -- это компилятор из семейства GCC (для тех кто не в курсе -- GNU Compiler Collection -- семейство разных компиляторов, а не только компилятор языков C и C++).
Так вот для компилятора avr-gcc (равно как и для avr-g++) абсолютно по баробану какое расширение будет у файла, который нужно скомпилировать -- *.c, *.cpp, да хоть '*.my_cool_source_cpp_file'. Для него (компилятора) главное содержимое (правда тут стоит оговориться, что при не стандартных расширениях компилятору нужно будет сказать, что внутри файла находится код языка 'c', или 'c++', или какого другого). То же самое касается препроцессора -- директивы '#include' -- в них то же можно писать всякую хрень, гдавное чтобы эта "хрень" была доступна в виде файла с исходниками того языка, который собирается компилировать компилятор.
А все эти расширения *.c, *.cpp, *.h, *.hpp и т.п. -- это условность, придуманая пользователями языка 'C' и в последствии 'C++' для облегчения своей жизни ввиду слабой развитости данных языков в былые времена (да и сейчас они не особо-то развиты).
Поэтому хотите включать файлы с исходниками типа '#include "my_super.cpp"' -- да включайте, пожалуйста. Хотите писать исходники внутри *.h-файлов -- да, наздоровье. Если не будет проблем с синтаксисом -- компилятор схавает. Главное понимать "что я делаю и к чему это в последствии приведёт".

PS: для Паровоза -- если не хочешь удивлятся типа -- "ну в симуляторе для меня было шоком, когда выполнение программы вылетело из цикла, сделало декремент переменной перед циклом и обратно нырнуло в цикл" -- попробуй дизасемблировать бинарник своей программы и понять, что и как там (особенно если бинарник был собран с оптимизацией). Тогда ни какого шока не будет. Особенно это актуально в контексте языка 'C' (да и его наследника 'C++') в виду их через Ж... придуманного синтаксиса.

 

но ведь где-то прописано (в файле проекта?), что вот этот файл заголовочный, а этот - с файл?

 

Вот это - абсолютно правильно!!!

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

 

Если рассматривать конкретный вид проекта, например Atmel Studio, то IDE, работающая с такими проектами, скорее всего определяет какой файл заголовочный, а какой с исходными текстами. Но это особенность той или иной IDE и к компилятору отношения может не иметь.
Сам же компилятор (оговорюсь, что речь идёт о GCC) при этом не различает -- заголовочный это файл или файл с исходниками. Для компилятора, все подсунутые ему для сборки файлы, это файлы с исходниками (не зависимо от расширения).