Re[11]: inline функции - C/C++

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

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

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

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

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

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

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

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

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

_>Сказочник. Если тебе понадобится изменить интерфейс функции из-за изменившегося использования, будешь ли ты оставлять эту сущность более абстрактного уровня нетронутой? Нет.

Неверно. Ответ зависит от уровня абстракции и, в конце концов, от того, какое дизайнерское решение я приму в каждом конкретном случае. Может быть оставлю нетронутой, создав рядом еще одну сущность (если она того заслуживает). Может быть оставлю нетронутой, вписав в прежнюю точку вызова самостоятельный код (т.е. избавивишись от вызова функции вообще). А может быть и изменю. Не существует однозначного ответа.

_>Потому что форму более абстрактного уровня выводят потребности более конкретного уровня.

Нет. Не выводят. А "оказывают скрытое и опосредованное влияние". Создавать абстракции строго по мере возниковения и прямо из конкретных потребностей — путь к грубым ошибкам дизайна.

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

Это просто выриант одной частной дизайнерской ошибки.

_>Мы вольны указывать абстрактному уровню, как он должен выглядеть снаружи, но мы не должны его заставлять знать что-то конкретное о нашей задаче.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.1 alpha 1 >>

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

1. Функция, реализованная в заголовке, считается имеющей модификатор 'inline'.
2. Компилироваться такая функция будет только если к ней есть обращения.
3. Если заголовок включен в несколько файлов, ошибок линковки не будет, даже если компилятор не сочтет нужным ее инлайнить.
Весь WTL реализован в h-файлах. И некоторые из них включаются в несколько .cpp-файлов. И при этом нет никаких ошибок линкера.

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

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

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

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

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

Kaa>>Конструкция
Kaa>>

Kaa>>class X { ... };
Kaa>>

Kaa>>называется определением класса. А как же без них в заголовках обойтись?

SWW>Да, разумеется. И дальше, в этом же файле вы пишите:
SWW>

SWW>X::func()
SWW>   {
SWW>   ...
SWW>   }
SWW>

SWW>Так?

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

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

привет всем

есть функция критичиская по времени исполнения(считает квадрат длинны вектора), которую я объявил 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 нужно писать только после того, как её необходимость доказал профайлер, и ни секундой раньше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted via RSDN NNTP Server 1.6 RC1

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

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

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

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

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

--

Владимир.

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

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

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

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

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

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

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

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

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

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

Posted via RSDN NNTP Server 1.6 RC1

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

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

<...>

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

Эти ошибки должен выдавать линкер.

Posted via RSDN NNTP Server 1.6 RC1

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

Теперь я с тобой согласен

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

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

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

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

Не-static не-inline функция в многократно включенном *.h файле в VC6 будет приводить к ошибке линковки LNK2005 в ста процентах случаев. Если у тебя этой ошибки не возникает, значит ты не соблюдаешь одно или несколько из вышеприведенных условий.

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

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

У меня была несколько противоположная проблема на C++Builder4. Если даже
функция не объявлялась как inline, но её реализация находилась внутри
объявления класса, то, независимо от размер функции, в код она ставлялась в
месте вызова.

(естественно в RELEASE)

Такая штука делалась, чтобы не подключать к проекту лишние cpp-молдули.

---------------------------------------------------------
СНП, Artyomov Denis. E-mail: artyomov <at> inbox.ru

Posted via RSDN NNTP Server 1.7 beta

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

AD>У меня была несколько противоположная проблема на C++Builder4. Если даже
AD>функция не объявлялась как inline, но её реализация находилась внутри
AD>объявления класса, то, независимо от размер функции, в код она ставлялась в
AD>месте вызова.

(естественно в RELEASE)

AD>Такая штука делалась, чтобы не подключать к проекту лишние cpp-молдули.

Ничего удивительного, по стандарту это эквивалентно объявлению функции как inline.

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

AD>> У меня была несколько противоположная проблема на C++Builder4. Если
AD>> даже функция не объявлялась как inline, но её реализация находилась
AD>> внутри объявления класса, то, независимо от размер функции, в код она
AD>> ставлялась в месте вызова.

(естественно в RELEASE)
f> Ничего удивительного, по стандарту это эквивалентно объявлению функции
f> как inline.

Да, но компилятор не смотрел на размер функции. В этой функции у меня
вызывались другие функции этого класса (из других — третьи), причём
все функции были inline. В результате чего код разрастался до
невообразимых размеров.

Всё это я смог побороть так: переделал клас в шаблон класса и вынес
реализацию функций из объявления, оставив их внутри *.h файла.

---------------------------------------------------------
СНП, Artyomov Denis. E-mail: artyomov <at> inbox.ru

Posted via RSDN NNTP Server 1.7 beta

А может в VC есть требования к инлайновым функциям как в билдере.
например в хелпе от билдерa написано:
An inline function with an exception-specification will never be expanded inline by C++Builder.
An inline function that takes at least one parameter that is of type ’class with a destructor’ will not be expanded inline.
An inline function that returns a class with a destructor by value will not be expanded inline whenever there are variables or temporaries that need to be destructed within the return expression

Вобщем search в msdn поможет

... << RSDN@Home 1.0 beta 6a >>

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

A> У меня была несколько противоположная проблема на C++Builder4. Если
A> даже функция не объявлялась как inline, но её реализация находилась
A> внутри объявления класса, то <...>

... то это эквивалентно тому, что она была бы объявлена как inline.

Posted via RSDN NNTP Server 1.6 RC1

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

Посмотри Project Settings -> C/C++ -> Optimizations -> Inline function expantion

Вы писали:

A>привет всем

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

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

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

D>А может в VC есть требования к инлайновым функциям как в билдере.

The function or its caller is compiled with /Ob0 (the default option for debug builds).

The function and the caller use different types of exception handling (C++ exception handling in one, structured exception handling in the other).

The function has a variable argument list.

The function uses inline assembly and is not compiled with /Og, /Ox, /O1, or /O2).

Function returns an unwindable object by value and is not compiled with /GX, /EHs, or /EHa).

The function receives a copy-constructed object passed by value, when compiled with /GX, /EHs,, or /EHa.

The function is recursive and is not accompanied by #pragma(inline_recursion, on). With the pragma, recursive functions can be inlined to a default depth of eight calls. To change the inlining depth, use #pragma(inline_depth, n).

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

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

SWW>1. Функция, реализованная в заголовке, считается имеющей модификатор 'inline'.

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

SWW>2. Компилироваться такая функция будет только если к ней есть обращения.

Ничего подобного. Компилироваться такая функция всегда. "Только если к ней есть обращения" — это больше похоже на шаблоны функций. Но тут речь идет не о шаблонах.

SWW>3. Если заголовок включен в несколько файлов, ошибок линковки не будет, даже если компилятор не сочтет нужным ее инлайнить.

С inline-функциями действительно ошибок не будет. С не-inline — будет ошибка — нарушение ODR.

SWW>Весь WTL реализован в h-файлах. И некоторые из них включаются в несколько .cpp-файлов. И при этом нет никаких ошибок линкера.

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

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

SWW>1. Функция, реализованная в заголовке, считается имеющей модификатор 'inline'.
... в теле класса ... Никак не просто в заголовке.
SWW>3. Если заголовок включен в несколько файлов, ошибок линковки не будет, даже если компилятор не сочтет нужным ее инлайнить.
Если функция не объявлена inline и определна в заголовке — будет ошибка линкера о множественном определении.

SWW>Весь WTL реализован в h-файлах. И некоторые из них включаются в несколько .cpp-файлов. И при этом нет никаких ошибок линкера.
Что тут удивительного7 Она же TL — Template Library. Для функций-шаблонов "ODR несколько ослаблено", т.е. позволяет упускать inline даже при определении шаблона в заголоваочном файле. Для объsxys[? не шаблонных, функций — это не так.

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

SWW>>Весь WTL реализован в h-файлах. И некоторые из них включаются в несколько .cpp-файлов. И при этом нет никаких ошибок линкера.
Kaa>Что тут удивительного7 Она же TL — Template Library. Для функций-шаблонов "ODR несколько ослаблено", т.е. позволяет упускать inline даже при определении шаблона в заголоваочном файле. Для объsxys[? не шаблонных, функций — это не так.

Как понять "упускать inline"? Если функция шаблонная, то это вовсе не значит, что она подставляемая.

SWW>>1. Функция, реализованная в заголовке, считается имеющей модификатор 'inline'.

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

7.1.2
...
3 A function defined within a class definition is an inline function.

SWW>>1. Функция, реализованная в заголовке, считается имеющей модификатор 'inline'.

D>возможно, ты путаешь с функциями, реализованными внутри определения класса.

А что, есть люди, которые пишут реализацию функции вне определения класса, но в том же h-файле?

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

SWW>А что, есть люди, которые пишут реализацию функции вне определения класса, но в том же h-файле?

Я, например.

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

SWW>>>...И при этом нет никаких ошибок линкера.
Kaa>>Что тут удивительного7 Она же TL — Template Library. Для функций-шаблонов "ODR несколько ослаблено", т.е. позволяет упускать inline даже при определении шаблона в заголоваочном файле. Для объявлений нешаблонных, функций — это не так.

ДА>Как понять "упускать inline"? Если функция шаблонная, то это вовсе не значит, что она подставляемая.

Я отвечал на выделенный фрагмент.

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

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

SWW>А что, есть люди, которые пишут реализацию функции вне определения класса, но в том же h-файле?
Да, есть. Более того, их большое количество.

SWW>>А что, есть люди, которые пишут реализацию функции вне определения класса, но в том же h-файле?

AVK>Я, например.

Э-ээ... Даже не знаю, что и сказать... А я, наивный, всегда считал что в заголовке не должно быть определений — только объявления... А не смущает ругань компилятора о невозможности создания precompiled header'а?

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

SWW> А не смущает ругань компилятора о невозможности создания precompiled header'а?

Это как?

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

SWW>А я, наивный, всегда считал что в заголовке не должно быть определений — только объявления...
Конструкция

class X { ... };

называется определением класса. А как же без них в заголовках обойтись?

Объявление — это

class X;

Kaa>Конструкция
Kaa>

Kaa>class X { ... };
Kaa>

Kaa>называется определением класса. А как же без них в заголовках обойтись?

Да, разумеется. И дальше, в этом же файле вы пишите:

X::func()
   {
   ...
   }

Так?

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

SWW>И дальше, в этом же файле вы пишите:
SWW>

inline X::func()
SWW>   {
SWW>   ...
SWW>   }
SWW>

SWW>Так?

Да.

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

Также, т.к. код в моем случае должен поддержживаться VC6, внутри тела класса всегда пишутся все шаблонные функции-члены, но это исключение, налагаемое компилятором.

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

SWW>>>1. Функция, реализованная в заголовке, считается имеющей модификатор 'inline'.

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

SWW>7.1.2
SWW>...
SWW>3 A function defined within a class definition is an inline function.

А это здесь к чему? Перевожу цитату из стандарта: "Функция, определенная в определении класса, является inline-функцией". А теперь твои слова: "Функция, реализованная в заголовке, считается имеющей модификатор 'inline'". Разницы не замечаешь?

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

SWW>>>1. Функция, реализованная в заголовке, считается имеющей модификатор 'inline'.

D>>возможно, ты путаешь с функциями, реализованными внутри определения класса.

SWW>А что, есть люди, которые пишут реализацию функции вне определения класса, но в том же h-файле?

А в чем проблема? Разумеется, есть.

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

SWW>>>А что, есть люди, которые пишут реализацию функции вне определения класса, но в том же h-файле?

AVK>>Я, например.

SWW>Э-ээ... Даже не знаю, что и сказать... А я, наивный, всегда считал что в заголовке не должно быть определений — только объявления...

Это совершенно не верно. В заголовках всегда были, есть и будут присутствовать определения. Только надо помнить, какие определения можно помещать в заголовок, а какие нельзя.

SWW>А не смущает ругань компилятора о невозможности создания precompiled header'а?

Ы? Нет, разумеется, не смущает. Ибо нет никакой ругани.

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

АТ>Ы? Нет, разумеется, не смущает. Ибо нет никакой ругани.
На 99% уверен у него билдер

... << RSDN@Home 1.1 alpha 1 >>

АТ>>Ы? Нет, разумеется, не смущает. Ибо нет никакой ругани.
WH>На 99% уверен у него билдер

Ты почти угадал. Эту ругань я видел на билдере лет 5 назад. С тех пор я перешел на VC, но никогда не пытался в h-файле помещать определения функций или переменных, считая это недопустимым (хотя бы потому, что этот файл нельзя будет включать в нексолько cpp-файлов). И когда в этом флейме писали о "функциях, реализованных в заголовке", я (а также, вероятно, skyline) считал, что речь идет о функциях, реализованных в определении класса.

	От:	Андрей Тарасевич
	Дата:	23.07.03 17:15
	Оценка:	92 (9) +2 -1

	От:	Андрей Тарасевич
	Дата:	23.07.03 20:36
	Оценка:	44 (3) +2

	От:	Андрей Тарасевич
	Дата:	23.07.03 19:05
	Оценка:	16 (2) +1

	От:	WolfHound
	Дата:	23.07.03 18:27
	Оценка:	1 (1) +1

	От:	SWW
	Дата:	29.07.03 07:47
	Оценка:	-2

	От:	Anton V. Kolotaev
	Дата:	23.07.03 16:04
	Оценка:

	От:	Павел Кузнецов
	Дата:	23.07.03 18:42
	Оценка:

От:	_vovin	http://www.pragmatic-architect.com
Дата:	23.07.03 18:48
Оценка:

От:	Dmitriev Sergey	http://dmi3s.blogspot.com/
Дата:	28.07.03 16:23
Оценка:

От:	Kaa	http://blog.meta.ua/users/kaa/
Дата:	29.07.03 07:25
Оценка:

	От:	Другой Аноним
	Дата:	29.07.03 08:08
	Оценка:

	От:	ArtDenis
	Дата:	24.07.03 03:28
	Оценка:

	От:	folk
	Дата:	24.07.03 03:36
	Оценка:

	От:	ArtDenis
	Дата:	24.07.03 03:44
	Оценка:

	От:	darth
	Дата:	24.07.03 06:38
	Оценка: