C ++ - фатальная ошибка LNK1120: 3 нерешенных внешних, не могут найти решение [duplicate]

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

При использовании вместе с явным созданием класса, библиотека проверки возможностей Boost (BCCL) может помочь вам сгенерировать код функции шаблона в файлах cpp.

Это стандартный способ определения функций шаблона. Я думаю, что для определения шаблонов я читаю три метода. Или, возможно, 4. Каждый с плюсами и минусами.

1. Определите определение класса. Мне это совсем не нравится, потому что я считаю, что определения классов строго для справки и должны быть легко прочитаны. Однако гораздо сложнее определить шаблоны в классе, чем внешние. И не все объявления шаблонов находятся на одном уровне сложности. Этот метод также делает шаблон истинным шаблоном.
2. Определите шаблон в том же заголовке, но вне класса. Это мой любимый способ в большинстве случаев. Это упрощает определение вашего класса, шаблон остается истинным. Однако для этого требуется полное имя шаблона, которое может быть сложным. Кроме того, ваш код доступен всем. Но если вам нужно, чтобы ваш код был встроенным, это единственный способ. Вы также можете выполнить это, создав файл .INL в конце определений вашего класса.
3. Включите header.h и implementation.CPP в ваш main.CPP. Я думаю, что так оно и было. Вам не нужно будет готовить какие-либо предварительные экземпляры, они будут вести себя как настоящий шаблон. Проблема, с которой я сталкиваюсь, заключается в том, что это не естественно. Обычно мы не включаем и не ожидаем включения исходных файлов. Думаю, с тех пор как вы включили исходный файл, функции шаблона могут быть встроены.
4. Этот последний метод, который был опубликованным способом, определяет шаблоны в исходном файле, как и номер 3; но вместо того, чтобы включать исходный файл, мы предварительно создаем шаблоны для тех, которые нам понадобятся. У меня нет проблем с этим методом, и иногда это пригодится. У нас есть один большой код, он не может быть использован, поэтому просто поставьте его в файл CPP. И если мы знаем общие экземпляры, и мы можем предопределить их. Это спасает нас от написания в основном то же самое 5, 10 раз. Этот метод имеет преимущество в сохранении нашего кода. Но я не рекомендую вкладывать крошечные, регулярно используемые функции в файлы CPP. Поскольку это уменьшит производительность вашей библиотеки.

Заметьте, я не знаю о последствиях раздутого файла obj.

Ваш пример правильный, но не очень портативный. Существует также несколько более чистый синтаксис, который можно использовать (как указано в @ namespace-sid).

Предположим, что шаблонный класс является частью некоторой библиотеки, которая должна быть разделена. Должны ли компилироваться другие версии шаблонного класса? Предполагается ли разработчик библиотеки предвидеть все возможные шаблонные применения класса?

Альтернативный подход - это небольшое изменение в отношении того, что у вас есть: добавьте третий файл, являющийся файлом реализации / создания шаблона.

foo.h file

// Standard header file guards omitted

template <typename T>
class foo
{
public:
    void bar(const T& t);
};

foo.cpp file

// Always include your headers
#include "foo.h"

template <typename T>
void foo::bar(const T& t)
{
    // Do something with t
}

foo-impl.cpp file

// Yes, we include the .cpp file
#include "foo.cpp"
template class foo<int>;

caveat заключается в том, что вам нужно сообщить компилятору компилировать foo-impl.cpp вместо foo.cpp, поскольку компиляция последнего ничего не делает.

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

Это дает гораздо большую гибкость при совместном использовании шаблона для других целей.

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

Время обновления! Создайте встроенный (.inl или, возможно, любой другой) файл и просто скопируйте все свои определения в нем. Не забудьте добавить шаблон над каждой функцией (template <typename T, ...>). Теперь вместо включения файла заголовка в встроенный файл вы делаете обратное. Включите встроенный файл после объявления вашего класса (#include "file.inl").

Я действительно не знаю, почему никто не упомянул об этом. Я не вижу немедленных недостатков.