Не собирается проект с шаблонным классом: "undefined reference"

@EricJForster · Регистрация: 10.06.2016

Студворк — интернет-сервис помощи студентам

Подскажите пожалуйста, не собирается проект. Пишет "undefined reference to Unit::Set()" и такое же про Unit::Get();

Unit.h

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#ifndef UNIT_H
#define UNIT_H
 
 
template<class Type> class Unit
{
    public:
        Unit() {}
        Type Get();
        void Set(Type n);
    private:
        Type data;
};
 
#endif // UNIT_H

Unit.cpp

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
#include "Unit.h"
 
template<class Type>
void Unit<Type>::Set(Type n)
{
    data = n;
}
 
template<class Type>
Type Unit<Type>::Get()
{
    return data;
}

main.cpp

C++
1
2
3
4
5
6
7
8
9
10
11
#include <iostream>
#include "Unit.h"
 
int main()
{
    Unit<int> unit;
    unit.Set(5);
    std::cout << unit.Get();
 
    return 0;
}

nd2 · 25.08.2016, 18:30

Содержимое .cpp помести в .h.

@EricJForster · 25.08.2016, 19:55 **[ТС]**

Сообщение от nd2

Содержимое .cpp помести в .h.

а тогда вообще зачем выносить определение методов класса в отдельный файл?

nd2 · 25.08.2016, 21:19

Сообщение от EricJForster

а тогда вообще зачем выносить определение методов класса в отдельный файл?

Для шаблонов не нужно выносить (шаблоны - это не определения), для не шаблонов нужно выносить.

@HelicopterK52 · 26.08.2016, 18:26

Сообщение от EricJForster

а тогда вообще зачем выносить определение методов класса в отдельный файл?

Всё для того, чтобы поиметь пользу от раздельной компиляции.
Суть проста - разные единицы трансляции ничего не знают друг о друге.
Компилятор стряпает код, и отдает его линковщику, а тот уже решает, какие определения и откуда брать.
Возьмём нешаблонную функцию (для простоты):

C++
1
2
3
4
5
6
7
//func.h
#ifndef MY_PROJECT_FUNC_H
#define MY_PROJECT_FUNC_H
 
void foo();//Объявляем foo
 
#endif //MY_PROJECT_FUNC_H

C++
1
2
3
4
5
6
7
//func.cpp
#include "func.h"
#include <iostream>
void foo()
{
   std::cout << "foo" << std::endl;
}

C++
1
2
3
4
5
6
7
//main.cpp
#include "func.h"
 
int main()
{
   foo();//используем функцию
}

Скомпилируем main.cpp: g++ main.cpp -c -o main.o.
Получили файл main.o. Как видим, никаких ошибок нет (ключик -c как раз "сказал" компилятору, что нужно только скомпилировать в объектник и нет необходимости вызывать линковщик).
В данном случае компилятору для сборки достаточно наличия объявления.
Скомпилируем и второй файл: g++ func.cpp -c -o func.o
И здесь всё нормально. Теперь соберем всё это.
Использовать также будем g++, он сам знает как вызвать линковщик (чтобы не морочить Вам голову всякими ld).
g++ -o main main.o func.o
Всё собралось. Запускаем: ./main, всё отлично, всё работает.
Теперь поменяем main.cpp, например, так:

C++
1
2
3
4
5
6
7
8
//main.cpp
#include "func.h"
 
int main()
{
    foo();
    foo();
}

Скомпилируем main.cpp: g++ -c -o main.o main.cpp.
Соберем в бинарник: g++ -o main main.o func.o.
Всё хорошо. Но ведь мы не компилировали func.cpp снова.
Мы лишь скомпилировали main.cpp и потом слинковали с уже имеющимся func.o.
То есть мы не тратили 100500 часов на сборку других библиотек из-за того, что поменяли main.cpp.
Нам достаточно было скомпилировать только измененные части.

А теперь про undefined reference. Возьмем эти же файлы и попробуем собрать таким образом: g++ -o main main.cpp.
Получили undefined reference. Почему?
Всё дело в том, что у компилятора при компилировании main.cpp есть объявление foo, которого ему достаточно для того, чтобы проверить правильность использования этого самого имени foo.
Искать где этот foo расположен будет уже линковщик.
Но линковщик тоже не знает где эту foo искать, ведь мы ему не указали на func.o.
Поэтому он сообщает нам, что возникла такая-то вот ошибка.
Если мы ему укажем func.o, то всё будет хорошо: g++ -o main main.cpp func.o.
При этом заметьте, что func.cpp вообще уже нигде не засвечен у нас.
В func.o есть нужное нам определение функции foo, так что линковщик смог его найти.
А теперь к шаблонам.

Сначала рассмотрим случай, когда у нас нет func.cpp:

C++
1
2
3
4
5
6
7
8
9
10
//func.h
#ifndef MY_PROJECT_FUNC_H
#define MY_PROJECT_FUNC_H
 
template<typename T>
void foo()
{
}
 
#endif //MY_PROJECT_FUNC_H

C++
1
2
3
4
5
6
7
8
//main.cpp
#include "func.h"
 
int main()
{
    foo<int>();
    foo<double>();
}

Соберем: g++ -o main main.cpp. Всё нормально.
В данном случае foo - не функция, это шаблон функции.
По данному шаблону компилятор может построить код.
При использовании foo: foo<int>(); компилятор генерирует код функции на основании данного шаблона (инстанцирование), где T - тип int.
Для foo<double>(); - аналогично, только T - double.
А теперь добавим func.cpp и вынесем туда реализацию foo:

C++
1
2
3
4
5
6
7
8
//func.h
#ifndef MY_PROJECT_FUNC_H
#define MY_PROJECT_FUNC_H
 
template<typename T>
void foo();
 
#endif //MY_PROJECT_FUNC_H

C++
1
2
3
4
5
6
7
//func.cpp
#include "func.h"
 
template<typename T>
void foo()
{
}

Собираем: g++ -o main main.cpp и получаем undefined reference.
Почему? Потому что у нас есть объявление foo, но нет определения, поэтому компилятор не может инстанцировать функцию (сгенерировать на основании шаблона), компилятор лишь сопоставил использование - всё в порядке и отдал объектник линковщику, а линковщик не может найти реализацию, ведь он не знает где её искать.
Ну ок, соберем так: g++ -o main main.cpp func.cpp и снова undefined reference.
Почему, ведь мы указали где реализация?
А вот теперь здесь в игру снова вступает раздельная компиляция.
main.cpp скомпилирована, func.cpp - тоже. Друг о друге они ничего не знают.
В main.cpp использование foo, но в func.cpp на самом деле нет инстанцирований этого шаблона.
Почему его нет? Оно в func.cpp нигде не использовалось, поэтому компилятор не стал инстанцировать шаблон.
То есть, если шаблон с неким набором аргументов шаблона не используется, то компилятор не будет генерировать код для шаблона с заданным набором аргументов.
Как быть? А давайте "заставим" компилятор в func.cpp сгенерировать код. Как? А просто где-то используем foo<тип>, например:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
//func.cpp
#include "func.h"
 
 
template<typename T>
void foo()
{
}
 
 
void bar()
{
    foo<int>();
    foo<double>();
}

Собираем: g++ -o main main.cpp func.cpp.
Всё собралось и работает. Почему?
В func.cpp появилась функция bar,
в которой используется foo<int> и foo<double>,
и в данной единице трансляции имеется определение шаблона,
а значит компилятор будет инстанцировать шаблон
и теперь в func.cpp есть нужные определения и линкер может их найти.
Т.е. задача выполнена - мы заставили компилятор инстанцировать шаблон.
Но для этого нам пришлось использовать другую не шаблонную функцию.
Но есть и более адекватное решение - явное инстанцирование.
Явное инстанцирование заставляет компилятор инстанцировать шаблон с данным набором аргументов.
Изменим func.cpp

C++
1
2
3
4
5
6
7
8
9
10
11
12
//func.cpp
#include "func.h"
 
 
template<typename T>
void foo()
{
}
 
 
template void foo<int>();//Явное инстанцирование шаблона foo с параметром int
template void foo<double>();

Собираем: g++ -o main main.cpp func.cpp.
Всё хорошо, всё собралось.
Но, стоит добавить в main, например foo<char>();,
как мы снова получим undefined reference,
ведь у нас компилятор не генерировал код для данного набора аргументов (char).
То есть мы можем вынести реализацию шаблона в .cpp,
но при этом нужно будет как-то инстанцировать шаблон для нужных наборов аргументов.

Если нужно, могу продолжить изыскания на данную тематику, сейчас просто некогда.

Добавлено через 5 минут
Перечитал. Препод из меня будет хреновый.

@hoggy · 26.08.2016, 21:42

Сообщение от HelicopterK52

Если нужно, могу продолжить изыскания на данную тематику

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

так что материал может быть весьма полезным.

Сообщение от HelicopterK52

Перечитал. Препод из меня будет хреновый

а по моему, все достаточно наглядно и понятно получилось.

@HelicopterK52 · 26.08.2016, 22:01

Сообщение от hoggy

а по моему, все достаточно наглядно и понятно получилось.

Это потому что мы уже "в теме".

@TheCalligrapher · 14.04.2020, 21:54

Сообщение от HelicopterK52

Но есть и более адекватное решение - явное инстанцирование.
Явное инстанцирование заставляет компилятор инстанцировать шаблон с данным набором аргументов.

К этому можно добавить, что все определения явных инстанцирований, которые вы делаете в .cpp файле можно также дополнить объявлениями явных инстанцирований в .h файле при помощи ключевого слова extern. Для функций это выглядит как

C++
1
extern template void foo<double>();

а для классов как

C++
1
extern template class MyClass<double>;

Это повышает эффективность компиляции больших проектов, использующих явное инстанцирование. Опять же - это лишь "оптимизатор процесса компиляции". Код будет правильно собираться и без таких объявлений.

Новые блоги и статьи Все статьи Все блоги /
Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .
Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025	Расскажи мне о Мире, бродяга kumehtar 12.11.2025 — Расскажи мне о Мире, бродяга, Ты же видел моря и метели. Как сменялись короны и стяги, Как эпохи стрелою летели. - Этот мир — это крылья и горы, Снег и пламя, любовь и тревоги, И бескрайние. . .

nd2 3438 / 2817 / 1249 Регистрация: 29.01.2016 Сообщений: 9,427
	25.08.2016, 18:30
	Содержимое .cpp помести в .h. 1

Не собирается проект с шаблонным классом: "undefined reference"

Решение