Само указание ключевого слова inline в декларации функции является подсказкой/предложением компилятору встроить тело функции в точке вызова. Но компилятор имеет полное право сделать по своему усмотрению. Это стандартное поведение.

Некоторые компиляторы вводят расширения (само собой нестандартные) для управления поведением компилятора. Про GCC уже сказали выше, у IAR в документации недвусмысленно сказано:

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

Что характерно - чем вопрос элементарнее, тем дискуссия более оживленная

А это всё в точности по Паркинсону ("Законы Паркинсона", занятная книжка). Там был на эту тему пример про обсуждение на совете директоров трех вопросов: 1. про приобретение какого-то очень дорогостоящего оборудования (на миллионы); 2. строительство навеса для стоянки велосипедов сотрудников; 3. сколько стаканчиков для кофе класть в кофейный автомат. По первому вопросу затраты времени 10 минут, по второму - минут 40, и по третьему - три часа. Объяснение логичное: чем проще вопрос, тем больше народу в нём разбирается. И у каждого есть мнение.

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

Ну так забейте на inline если оно настолько некритично для вашего проекта.
Кстати inline'нинье функций далеко не гарантия наиболее высокой скорости исполнения. Например, в процессорах с кеш памятью команд - бездумное инлайнинье там и сям приведет только к замедлению за счет раздувания кода при константном объеме кеш памяти.


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

Идеологически согласен.
Кстати, Вы видели в моём примере много прагм и атрибутов?
Человек спросил как это сделать - я дал однозначный рецепт.
Потом сюда приплели даже микрософтовский компилятор и кеш инструкций, хотя тема находится в подфоруме микроконтроллеры/AVR
и вопрос касался avr-gcc...

Какие Ваши предложения на сей счёт? Отказаться от использования PROGMEM, EEMEM, ISR и вообще не включать компьютер?
Атрибуты в gcc - это почти что основополагающий механизм в случае кросс-компиляции для avr.
Если Вы внимательно читали мои посты, то могли бы подметить, что я рекомендовал оставить лишь квалификатор static, ибо это и необходимо и достаточно для локальных функций.

Да static для локальных функций это просто "хороший тон", чтобы не "заси...ть" пространство имен большого проекта, а вовсе не какая-то необходимость. С одной стороны - хорошо, с другой, их не найдешь в map файле, если понадобится найти точку зависания программы. То, что static - помощь компилятору в деле инлайнинга, вопрос спорный. В одном компиляторе может так, в другом этак.

Повторюсь, я говорю о avr-gcc и о контроллерах в которых флеша всегда маловато и рассуждать о удобстве поиска "зависшей программы" мне лично и в голову не приходит. Отладка через консоль на 99 процентов решает любые непонятки, а остальное решается просмотром asm листинга если терзают сомнения в качестве компилятора или в качестве собственной черепушки - что тоже надо признать бывает:-) Это моё ИМХО.

Что-то мы уже по второму кругу пошли...

Это очень хорошо, что вы знаток avr-gcc. Но я все равно не понимаю, какое отношение имеет объявление локальной функции как static к объему flash памяти на борту. Что это дает на практике? Расскажите, поделитесь сокровенным.

В gcc, да и думаю во всех современных компиляторах, идёт однозначное встраивание статической функции если она вызывается лишь один раз и отсутствует её вызов по указателю. Также статическая функция, которая при встраивании сопоставима по сложности с загрузкой аргументов, выполнении инструкций call+ret и выгрузкой её результата, может быть встроена даже при неоднократном её вызове. Естественно баланс оптимизации сильно зависит от грамотности настроек компилятора. Вся эта оптимизация на круг даёт существенный выигрыш как по объёму так и по скорости, за что собственно и ратую.

Про все современные компиляторы, как выше упоминалось, это вовсе не факт. А раз это так устроено для AVR - намотаем на ус.

Вообще многие гуру программирования отмечают, что хорошим стилем является написание коротких функций. Компилятор сам может потом решить встраивать их или нет. Да и их тело оптимизировать проще.

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

ИМХО
Разделяется по функциональности. Например функция:
check_port_a() {
i2c_byte_read();
uart2_send_data();
}
на мой взгляд выглядит не плохо.
Что плохо бы смотрелось, это пример:
check_port_a() {
start_i2c_bit();
set_i2c_address();
set_i2c_cmd_byte();
get_i2c_byte();
stop_i2c_bit();
uart2_send_data();
}

По скорости будет примерно одинаково.

Сообщение отредактировал andron86 - Feb 19 2011, 06:13

Небольшая поправочка:
Это устроено в gcc вообще и в avr-gcc в частности.

Свет клином на gcc не сошелся. Он, конечно, не стоит на месте, но заморочек с ним все равно хватает.

Каких?