привет всем

есть функция критичиская по времени исполнения(считает квадрат длинны вектора), которую я объявил inline,
в полученном коде функция не подставляется, а вызывается
использовал VC 6.0 смотрел DEBUG и RELEASE, пробовал объявлять __forceinline.
всеравно не подставилась

Как это сделать?

A>использовал VC 6.0 смотрел DEBUG и RELEASE, пробовал объявлять __forceinline.

А в DEBUG она и не подставится.

A>всеравно не подставилась
А если и в релизе не подставилась, то тут уж ничего не поделаешь. Пробуй функцию как-то переписать

Здравствуйте, Аноним, Вы писали:

inline — то твоя смиренная просьба, не более того.
Компилятор имеет право её игнорировать.
А вообще, если хочешь оптимизировать, то поработай с профайлом.
К тому же, inline нужно писать только после того, как её необходимость доказал профайлер, и ни секундой раньше.

Здравствуйте, skyline, Вы писали:

S>К тому же, inline нужно писать только после того, как её необходимость доказал профайлер, и ни секундой раньше.

Нет. inline стоит писать, чтобы не ловить "symbol ,,, is already defined". Просто у меня все обычно определяется в хедерах.

Здравствуйте, aparat, Вы писали:

A>есть функция критичиская по времени исполнения(считает квадрат длинны вектора), которую я объявил inline,
A>в полученном коде функция не подставляется, а вызывается
A>использовал VC 6.0 смотрел DEBUG и RELEASE, пробовал объявлять __forceinline.
A>всеравно не подставилась

Покажи код функции. '__forceinline' должно подставлять, кроме уж совсем безнадежных случаев.

Здравствуйте, Anton V. Kolotaev

AVK>Нет. inline стоит писать, чтобы не ловить "symbol ,,, is already defined". Просто у меня все обычно определяется в хедерах.
Какая связь между этим сообщением и inline.
При чем тут заголовки?

Здравствуйте, skyline, Вы писали:


AVK>Нет. inline стоит писать, чтобы не ловить "symbol ,,, is already defined". Просто у меня все обычно определяется в хедерах.

S>Какая связь между этим сообщением и inline.
S>При чем тут заголовки?

Я просто опровергнул следующее утверждение:

S>К тому же, inline нужно писать только после того, как её необходимость доказал профайлер, и ни секундой раньше.

Здравствуйте, skyline, Вы писали:

S>К тому же, inline нужно писать только после того, как её необходимость доказал профайлер, и ни секундой раньше.

Ни в коем случае. В общем случае правильная функция — сущность более абстрактного уровня, чем вызывающий ее код. Другими словами, функция обладает более высокой степенью универсальности, чем вызывающий ее код. Расставление спецификаторов 'inline' на основе анализа профайла — это ни что иное как попытка "подгонки" более абстрактного кода под более конкретный. Это, в общем случае, — серъезная дизайнерская ошибка и делать этого не следует. Это примерно то же самое как если бы создатели стандартной библиотеки языка С++ специально "заточили" бы ее под программу бухучета, создаваемую в тот момент женой одного из членов комитета по стандартизации.

Расставление спецификаторов 'inline', как и любых других собственных атрибутов функции, должно делаться на основе анализа только самой функции, но не на основе анализа вызывающего ее кода.

Разумеется, на практике из любого правила бывают исключения. Например, зачастую в программах можно встретить функции, которые не обладают более абстрактной функцональностью, чем вызывающий их код. Такие функции обычно вызникают в результате бездумного "выдирания" части кода из некоторой "большой" функции и помещения его в отдельную функцию (обычно с большим числом параметров и либо запутанным, либо бессодержательным именем). Такие функции могут возникать, например, в случаях, когда программист увидел в программе повторяющийся участок кода и не долго думая решил чисто механически выделить его в отдельную функцию. Или когда программист решил подразбить функцию на несколько более мелких функций для того, чтобы удовлетворить какому-нибудь глупому стилистическому правилу, типа "не создавать функций, код которых не помещается в экран", и сделал это не совсем разумно. Такие функции не реализуют никаких осмысленных абстракций, и обычно являются локальными для одной единицы трансляции (т.е. объявлены как static). Вот их-то можно и пообъявлять inline на основе анализа профайла, если есть желание. Но по моему мнению таких функций не стоит создавать вообще.

Но тем не менее твое заявление в той категоричной форме, в которой оно процитировано выше, совершенно не верно.

Здравствуйте, Anton V. Kolotaev,

AVK>Я просто опровергнул следующее утверждение:

Это утверждение Саттера.
Он много говорит об этом, и заканцивает следующими правилами оптимизации
1 Не оптимизируй
2 См 1
Поясни пожалуйста свои аргументы.

Здравствуйте, skyline, Вы писали:

AVK>>Я просто опровергнул следующее утверждение:

S>Это утверждение Саттера.

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

Здравствуйте, Андрей Тарасевич, Вы писали:

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

Здравствуйте, Андрей Тарасевич

Полностью согласен с принципом Декарта "Всё подвергай сомнению", но в данном случае утверждение в книги обоснованно.
А ещё я тебе ответил в другом разделе

Здравствуйте, skyline, Вы писали:

S>Это утверждение Саттера.
S>Он много говорит об этом, и заканцивает следующими правилами оптимизации
S>1 Не оптимизируй
S>2 См 1
Правильно говорит. По этому я не пишу inline да и вобще о нем не вспоминаю. Компилятору виднее где inline, а где нет.(VC++7.1 очень глазастый)
S>Поясни пожалуйста свои аргументы.
А что тут не понятного? Если реализовать функцию в зголовке и не пометить ее inline то словишь ошибку линкера.

Здравствуйте, WolfHound

? Если реализовать функцию в зголовке и не пометить ее inline то словишь ошибку линкера.

На каком компиляторе?
Мой VC 6 так не делает

Здравствуйте, skyline, Вы писали:

WH> Если реализовать функцию в зголовке и не пометить ее inline то словишь ошибку линкера.

s> На каком компиляторе? Мой VC 6 так не делает

Делает. Включи заголовок в несколько .cpp-файлов.

Здравствуйте, Андрей Тарасевич, Вы писали:

АТ>Здравствуйте, skyline, Вы писали:

S>>К тому же, inline нужно писать только после того, как её необходимость доказал профайлер, и ни секундой раньше.

АТ>Ни в коем случае. В общем случае правильная функция — сущность более абстрактного уровня, чем вызывающий ее код.
[...]

Сказочник. Если тебе понадобится изменить интерфейс функции из-за изменившегося использования, будешь ли ты оставлять эту сущность более абстрактного уровня нетронутой? Нет. Потому что форму более абстрактного уровня выводят потребности более конкретного уровня.
Это просто есть такое дизайнерское решение, что нельзя явно обращаться к менее абстрактному уровню, чтобы не ограничивать варианты использования решения.
Мы вольны указывать абстрактному уровню, как он должен выглядеть снаружи, но мы не должны его заставлять знать что-то конкретное о нашей задаче.
Два разных понятия, которые путать не стоит.

--

Владимир.

Здравствуйте, _vovin

Согласен — не всегда функция — понятие абстрактное, но её часто хочется такой сделать. А вообще, это я отвечал на предыдущий ответ.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Здравствуйте, skyline, Вы писали:

WH>> Если реализовать функцию в зголовке и не пометить ее inline то словишь ошибку линкера.

s>> На каком компиляторе? Мой VC 6 так не делает

ПК>Делает. Включи заголовок в несколько .cpp-файлов.
Написал функцию длинную функцию в *.h, включил её во многие файлы, там её по вызывал — уровень предупреждения — максимальный, и ни чего. VC 6 sp 5

Здравствуйте, skyline, Вы писали:

S>Во первых, компилятор может сам убрать модификатор inline, во вторых, сам его установить, и это его личное дело,

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

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

S>причем компиляторы это часто делают лучше среднего программиста, о подобном свойстве компиляторов любит писать К. Касперски.

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

S>Во вторых, есть случаи, когда использование inline ведет к замедлению работы программы, а профайлу легче найти функцию, которая не inline, а её надо сделать inline, чем найти inline, коя таковой быть не должна.

Поэтому для профилирования inline обычно отключают. Полностью или выборочно.

S>А в третьих, как ты сам говоришь, функция – более абстрактное понятие, чем вызывающий её код, и её надо писать в расчете на много случаев использования, а inline – не панацея, и она не всегда прибавляет быстродействие.

А никто и не требует от inline безусловного увеличения быстродействия. Модификатор inline — это просто способ, при помощи котрого пользователь выражет свое отношение к некоторой функции, как бы декларируя окружающим свою оценку к соотношению оверхеда, порождаемого данной функцией, и выполняемой ею полезной работы (как с точки зрения размера кода, так и с точки зрения затрачиваемого времени). Это в некотором абстрактном смысле чем-то похоже на модификатор 'const' — практически любую программу можно написать и без него, но это совсем не означает, что он бесполезен.

Здравствуйте, _vovin, Вы писали:

v> Сказочник. Если тебе понадобится изменить интерфейс функции <...>