// file1.h

class A{
static void Test1();
}

// file1.cpp
inline void A::Test1()
{
// todo something...
}

//file2.cpp
#include "file1.h"

int main()
{
  A::Test1(); // error LNK2001: unresolved external 
              //symbol "public: static void __cdecl   A::Test1"

  return 0;
}

Как правильно обьявить inline функцию?

Ее надо объявить и определить в file1.h.

MS>Как правильно обьявить inline функцию?
Инлайновые функции должны определяться во всех единицах трансляции. Кстати, не вижу смысла в твоем случае объявлять ее инлайн.

остальной код я вырезал

V>Кстати, не вижу смысла в твоем случае объявлять ее инлайн.

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

MS>>Как правильно обьявить inline функцию?
V>Инлайновые функции должны определяться во всех единицах трансляции, в которых они используются.

You will always get what you always got
  If you always do  what you always did

V>>Инлайновые функции должны определяться во всех единицах трансляции, в которых они используются.
Буквоед Хотя по сути, конечно, верное замечание.

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

???
моя inline функция пишет в файл номер строки и название файла...

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

ЕК>Вообще inline — умирающая конструкция. Поскольку она по определению — лишь совет компилятору. Компилятор не обязан делать её действительно подставляемой, а с другой стороны может сделать подставляемой функцию, не описанную как inline.

Немного не тот случай. Если функции определить в разных единицах трансляции — они не смогут встроится, какой бы умный ни был компилятор. А если просто включить определние функции в .h-файл, добавляя определение в сpp-файл, то му получим ошибку линкера.
Отсюда необходимость ключевого слова инлайн.

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

V>>>Инлайновые функции должны определяться во всех единицах трансляции, в которых они используются.
V>Буквоед :))) Хотя по сути, конечно, верное замечание.

Ну сам представь, какой ужас, если из-за того, что ты используешь в двух единицах трансляции инлайновую функцию, ты должен поместить ее реализацию во все оставшиеся 15412 единицы трансляции :)

You will always get what you always got
  If you always do  what you always did

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

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

MS>моя inline функция пишет в файл номер строки и название файла...

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

Евгений Коробко wrote:

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

--
Александр Насонов,
Независимый консультант и разработчик ПО
alnsn-mycop@yandex.ru (для более быстрого ответа удалите -мусор из адреса)

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

V> Если функции определить в разных единицах трансляции — они не смогут
V> встроится, какой бы умный ни был компилятор.

Это умел делать компилятор от IBM. Сейчас это умеют делать компиляторы от
Intel (IPO) и Microsoft (Whole Program Optimization).

Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это умел делать компилятор от IBM. Сейчас это умеют делать компиляторы от
ПК>Intel (IPO) и Microsoft (Whole Program Optimization).
Ух ты! А как им это удается? Компиляторы же вроде как парсят каждый cpp-файл отдельно?

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

ПК>> Это умел делать компилятор от IBM. Сейчас это умеют делать компиляторы
ПК>> от Intel (IPO) и Microsoft (Whole Program Optimization).

V> Ух ты! А как им это удается? Компиляторы же вроде как парсят каждый
V> cpp-файл отдельно?

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

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

V>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>Это умел делать компилятор от IBM. Сейчас это умеют делать компиляторы от
ПК>>Intel (IPO) и Microsoft (Whole Program Optimization).
V>Ух ты! А как им это удается? Компиляторы же вроде как парсят каждый cpp-файл отдельно?

VC в режиме глобальной оптимизации генерирует в объектный файл не процессоро-специфичный код, а код на промежуточном языке. Дальше линкер собирает вместе всё это хозяйство, он получает доступ к телам всех функций и уже решает, встраивать/не встраивать, ну и выполняет два уровня оптимизации -- на промежуточном коде и при генерации машинного кода.
А вообще, на эту тему была большая статья Саттера в CUJ.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы