Есть ли смысл тут использовать inline-функцию? Видел частенько такое в коде, но разве такая функция «распакуется» во что-то? Если да, то каким образом, _name ведь приватный член? :-)
inline в теле класса не пишут, ибо наличие реализации тут же подразумевает инлайн. Но с современными компиляторами явно что-либо помечать inline не нужно, т.к. это игнорируется.
В машинном коде нет понятия "приватный член", это абстракция для удобства программиста, которая никак не выражается в сгенерированном компилятором коде. (А вот в C# это не так)
Толстый Лорри , inline в теле класса пишут, т.к. это хорошее пояснение качества функции. И const в параметрах и возвращаемых значениях функций тоже пишут, т.к. это важное пояснение качества функции.
И не важно, игнорируются эти слова компилятором или нет, код должен быть понятным и содержать документацию в себе.
Иные утверждения - от лени и слабой культуры.
Иными словами, не стоит быть таким категоричным. :)
Какого качества? Что это короткая функция и может часто вызываться? Это должно быть очевидно из кода тут же рядом, а если не очевидно - не стоит вообще считать ее потенциально встраиваемой.
Код нужно уметь писать понятными, чтобы не спасаться подобными "комментариями".
Приватный или нет, это важно лишь на уровне проверки исходного кода. Оптимизатор же должен только выдать код, результат которого во время выполнения будет идентичен ожидаемому. Есть ли смысл? Gcc сам сделает inline столь короткого метода во время компиляции, если увидит его реализацию, но полагаю может возникнуть конфликт во время линковки, если один и тот же метод без inline будет подключаться к нескольким файлам. MSVC сам оптимизирует этот участок во время линковки даже если компилятор не видел реализации соответствующего метода.
Приватныe пeрeмeнныe - для программиста. Дажe ошибки выдаются в стилe - нeльзя использовать ххх так как он приватный. Это значит про пeрeмeнную компилятор знаeт.
Любой мeтод class{method(...)} внутри компилятора выглядит так: method(class *instance, type1 var1,...). Поэтому заинлайнится как instance->_name
Смысл использовать это слово нeт. Eсли тeло функции ужe написано в хeдeрe, то мeтод ужe инлайнится. Поэтому эта запись выглядит как масло масляноe.
И нe надо дeлать за компиляторы их работу. Лучшe eсли они сами рeшат нужeн инлайн или нeт.
SibVektor: варианты 1) это библиотeка под широкий спектр компиляторов (в том числе под дрeвниe или кондовыe)
2) это гайдлайн, доставшийся в наследство от пeрвых вeрсий библиотeки
3) это автогeнeрeнный код
Вот конкретно тут нет смысла. Компилятор с большой вероятностью сам заинлайнит эту функцию. Вообще ключевое слово inline имеет только одно верное использование в современных реалиях: для функций (обычных или специализаций) объявленных и определённых в заголовочных файлах, в случае если файл исходников отсутствует или там нет реализации функции.
Но если объявить функцию инлайновой в заголовочном, а реализацию перенести в cpp файл, то компилятор выдаст ошибку что не может найти реализацию, стоит убрать inline и всё прекрасно находится, как и прекрасно находится при inline, но когда тело функции перенесено в заголовочный. Это коммент на ваше последнее "или" :)