Шаблоны и заголовки

1. Как работает шаблон: чертёж, а не функция

До этого момента курса мы жили по довольно уютному правилу: «объявление — в заголовок, реализация — в .cpp». И это правило действительно хорошее: меньше перекомпиляций, меньше мусора в интерфейсе, меньше шансов создать “комбайн” из #include <everything>.

Но шаблоны — как тот коллега, который приходит в офис и говорит: «А давайте всё по‑другому, но это для вашего же блага». Смешно, но факт: в C++ есть реальные сложности, завязанные на видимость function templates и эффекты, которые возникают при поиске имён.

Чтобы не провалиться в теорию (она будет позже), берём ровно одно практическое правило и учимся жить по нему.

Шаблон (template) — это не «ещё одна функция». Это скорее чертёж функции, по которому компилятор может сделать конкретную версию под нужный тип. То есть шаблон — это инструкция компилятору: «Когда встретишь использование, подставь тип и собери тело».

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

Самый маленький пример шаблона (и да, это тот самый “квадрат”, который пережил не одно поколение студентов):

// square.hpp
#pragma once

template <typename T>
T square(T x) {
    return x * x;
}

И использование:

#include <iostream>
#include "square.hpp"

int main() {
    std::cout << square(5) << '\n';    // 25
    std::cout << square(2.5) << '\n';  // 6.25
}

Выглядит как функция, но на самом деле это “фабрика функций”.

2. Правило: тело шаблона видно в месте использования

Сейчас будет формулировка, которую стоит выписать на бумажку и положить рядом с клавиатурой (рядом с наклейкой “не забудь ;”):

Правило: определение (тело) шаблона должно быть видно в месте, где этот шаблон используется.

Почему так? Потому что в момент использования компилятор может впервые понять, какие именно типы подставлять. А раз подстановка происходит здесь же, то и тело нужно здесь же.

Полезная ментальная картинка:

flowchart TD
    A["main.cpp увидел square(5)"] --> B[нужно собрать square
 
  ]
    B --> C{видно ли тело шаблона?}
    C -- да --> D[компилятор генерирует код]
    C -- нет --> E[не из чего генерировать: ошибка]

 

Это — вся лекция в одной блок‑схеме. Дальше мы просто “приземлим” её на файлы.

4. Где хранить реализацию: .hpp и .tpp/.inl

Антипример: объявили в .hpp, определили в .cpp

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

Представим, что у нас есть учебное консольное приложение TaskTracker (мы ведём список задач). В нём мы хотим маленькую утилиту: проверить, что значение попадает в диапазон (например, пункт меню от 1 до 5).

Мы создаём заголовок с объявлением:

// range.hpp
#pragma once

template <typename T>
bool in_range(T x, T lo, T hi); // только объявление

А реализацию — в .cpp:

// range.cpp
#include "range.hpp"

template <typename T>
bool in_range(T x, T lo, T hi) {
    return lo <= x && x <= hi;
}

И используем в main.cpp:

#include <iostream>
#include "range.hpp"

int main() {
    std::cout << in_range(3, 1, 5) << '\n'; // хотим 1 (true)
}

На уровне человеческой логики всё выглядит идеально: “ну вот же .cpp, вот же реализация”. Но компилятор мыслит иначе: он компилирует main.cpp отдельно и в этот момент должен собрать in_range<int>. А тела нет — оно в другом .cpp, который компилируется отдельно, и “телепатическую связь” компилятору не завезли.

Результат: ошибка сборки (она может выглядеть по‑разному в зависимости от компилятора/IDE), но суть одна: шаблон не может быть инстанцирован, потому что нет определения там, где его пытаются использовать.

Правильный вариант: шаблон целиком в заголовке

Теперь делаем так, как требует правило: кладём определение шаблона туда, где оно будет видно при #include. То есть — в .hpp.

Вот рабочий вариант:

// range.hpp
#pragma once

namespace app::util {

template <typename T>
bool in_range(T x, T lo, T hi) {
    return lo <= x && x <= hi;
}

} // namespace app::util

И использование в нашем main.cpp:

#include <iostream>
#include "range.hpp"

int main() {
    const int choice = 3;
    std::cout << app::util::in_range(choice, 1, 5) << '\n'; // 1
}

Здесь компилятор счастлив: когда он компилирует main.cpp, он видит и объявление, и тело in_range, поэтому может “собрать” версию in_range<int>.

Самодостаточность заголовка

С шаблонами самодостаточность заголовка становится строже. Если тело шаблона использует какой-то тип/функцию, нужный #include должен быть в этом же заголовке, а не “где-то раньше подключили”.

Например, если бы in_range работал со строками и вы использовали std::string, то <string> должен был бы быть подключён в range.hpp.

Как не превращать .hpp в простыню: .tpp / .inl

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

Частый паттерн (чисто организационный):

• range.hpp — интерфейс + подключение реализации
• range.tpp (или range.inl) — тела шаблонов

Пример range.hpp:

// range.hpp
#pragma once

namespace app::util {
template <typename T>
bool in_range(T x, T lo, T hi);
}

#include "range.tpp" // важно: подключаем реализацию

Пример range.tpp:

// range.tpp
#pragma once

namespace app::util {

template <typename T>
bool in_range(T x, T lo, T hi) {
    return lo <= x && x <= hi;
}

} // namespace app::util

Смысл простой: физически реализация лежит в отдельном файле, но логически она остаётся “видимой” через #include. Правило дня соблюдено.

5. Практика: проверка меню в TaskTracker

Теперь сделаем небольшой шаг в сторону практики (без превращения лекции в “домашку”). Пусть в нашем приложении есть меню: 1 — добавить задачу, 2 — показать список, 3 — удалить, 4 — выход. Мы хотим проверять ввод и не позволять, скажем, пункт 42.

Мини-кусок кода (идея понятна даже без полной программы):

#include <iostream>
#include "range.hpp"

int main() {
    int choice = 0;
    std::cin >> choice;

    if (!app::util::in_range(choice, 1, 4)) {
        std::cout << "Нет такого пункта меню\n";
    }
}

Заметьте, мы не делаем ничего “шаблонного” в main.cpp. Шаблонность — внутри in_range. Это хороший стиль: main должен быть простым, а утилиты — переиспользуемыми.

Если хочется ещё одну аналогию, то шаблон — это как рецепт блюда, где ингредиент “мясо” не уточнён. Пока вы не пришли на кухню и не сказали “готовим с курицей”, рецепт остаётся “общим”.

Место использования — это момент, когда вы говорите: “Окей, сегодня курица”. И вот тут повар (компилятор) должен иметь на руках полный рецепт. Если у него есть только заголовок “Сделай что-то вкусное”, а сам рецепт в другом городе (в .cpp), то ужин будет… скажем так, концептуальным.

6. Типичные ошибки

Ошибка №1: попытка спрятать тело шаблона в .cpp “как обычную функцию”.
Это самая частая ловушка: привычка из мира не-шаблонных функций. У обычной функции компилятору достаточно объявления, а реализацию можно положить в .cpp. У шаблона — нет: компилятор должен видеть тело там, где он генерирует конкретную версию. Если забыть про это, проект начинает “ломаться не сразу”, а в тот момент, когда шаблон впервые реально используется.

Ошибка №2: шаблонный заголовок не самодостаточен и “случайно компилируется”.
С шаблонами транзитивные зависимости особенно коварны. Сегодня у вас где-то раньше подключили <string> — и всё работает. Завтра вы поменяли порядок #include (или другой файл подключил ваш заголовок первым) — и внезапно “std::string не найден”. Лечится дисциплиной: если тип/функция нужна в определении, подключайте её в этом же .hpp.

Ошибка №3: using namespace ...; в заголовке с шаблонами.
Заголовок подключают многие файлы, и если он внезапно “подмешал” имена в глобальное пространство, последствия будут странными и иногда очень смешными (но смеяться будете не вы, а компилятор). В шаблонных заголовках это ещё опаснее, потому что они часто подключаются “везде”.

Ошибка №4: слишком “умный” шаблон как часть базового утилитарного слоя.
Появляется соблазн сделать “универсальную мегавещь”: шаблон на шаблоне, плюс decltype(auto), плюс хитрые приёмы. На этом этапе курса это почти всегда снижает читаемость сильнее, чем даёт пользы. Сегодняшний смысл шаблонов — не мощь, а понимание правила размещения кода. Всё остальное мы осознанно оставляем на будущие дни.

Ошибка №5: забыли, что шаблон компилируется “в месте использования”, и получили ошибки там, где их не ждёте.
Это психологически неприятный момент: вы правите утилиту в range.hpp, а ошибки вылезают в пяти разных .cpp. Это нормально: эти .cpp инстанцируют ваш шаблон. Поэтому шаблонные заголовки особенно требуют аккуратности и минимальных зависимостей.