Function Definition of Class Template

Programming Language & Its Applications — Generic Programming and Exception Handling, NEC licence examination syllabus (Nepal Engineering Council).

Function Definition of Class Template

Defining member functions outside the class body — the verbose syntax, and why templates must live in headers.

🌍 Where this lives: this topic explains something you have certainly noticed: why <vector> is 3,000 lines of header with no matching .cpp, and why including a few STL headers turns a 20-line program into a 400 KB binary and a two-second compile. Templates cannot be compiled separately, so every template definition ships as source. That single constraint shapes how all C++ libraries are distributed — header-only libraries like Eigen, nlohmann/json and fmt exist because templates force the issue. Search "why template implementation must be in header" and "C++20 modules template", the second being the long-awaited fix.

The out-of-class syntax

Inside the class body, nothing special is needed: template <typename T> class Stack { T data[100]; int top; public: bool empty() const { return top == -1; } /* inline */ }; Outside, EVERY definition needs the template header AND the fully-qualified class name WITH its parameters: template <typename T> ← repeat the parameter list bool Stack<T>::push(const T &v) { ^^^^^^^^ the class name INCLUDES <T> if (top >= 99) return false; data[++top] = v; return true; } BREAKING IT DOWN, piece by piece: template <typename T> the parameter list, again bool return type Stack<T> the class, WITH arguments ::push the member name (const T &v) parameters — T is in scope here COMMON ERRORS: bool Stack::push(const T &v) ✗ missing <T> error: invalid use of template-name 'Stack' without an argument list template <typename U> ✗ name mismatch is bool Stack<U>::push(const U &v) legal but confusing (this compiles — the parameter name is arbitrary — but always match the declaration for readability) bool Stack<T>::push(const T &v) ✗ missing template<> error: 'T' was not declared in this scope MULTIPLE PARAMETERS repeat all of them: template <typename K, typename V> void Map<K,V>::insert(const K &k, const V &v) { ... } NON-TYPE PARAMETERS too: template <typename T, int N> T Array<T,N>::sum() const { ... } A NESTED TYPE needs `typename` when it depends on T: template <typename T> typename Stack<T>::iterator Stack<T>::begin() { ... } ^^^^^^^^ required: the compiler cannot know that Stack<T>::iterator is a TYPE and not a static member, because T is not yet known.

out_of_class.cpp

#include <iostream>
#include <string>
#include <stdexcept>

template <typename T, int CAP = 8>
class Queue {
    T      data[CAP];
    int    front, rear, count;

public:
    /* declarations only */
    Queue();
    bool enqueue(const T &v);
    bool dequeue(T &out);
    const T& peek() const;
    void print(const char *tag) const;

    /* small ones stay inline */
    bool empty() const { return count == 0; }
    bool full()  const { return count == CAP; }
    int  size()  const { return count; }

    /* a nested type, used below */
    using value_type = T;
};

/* ---- definitions: note the repeated template header ---- */

template <typename T, int CAP>
Queue<T,CAP>::Queue() : front(0), rear(-1), count(0) {}

template <typename T, int CAP>
bool Queue<T,CAP>::enqueue(const T &v) {
    if (full()) return false;
    rear = (rear + 1) % CAP;        /* circular buffer */
    data[rear] = v;
    ++count;
    return true;
}

template <typename T, int CAP>
bool Queue<T,CAP>::dequeue(T &out) {
    if (empty()) return false;
    out = data[front];
    front = (front + 1) % CAP;
    --count;
    return true;
}

template <typename T, int CAP>
const T& Queue<T,CAP>::peek() const {
    if (empty()) throw std::out_of_range("queue is empty");
    return data[front];
}

template <typename T, int CAP>
void Queue<T,CAP>::print(const char *tag) const {
    std::cout << "  " << tag << " [" << count << "/" << CAP << "]: ";
    for (int i = 0; i < count; i++)
        std::cout << data[(front + i) % CAP] << " ";
    std::cout << "\n";
}

int main() {
    Queue<int,5> q;
    for (int i = 1; i <= 5; i++) q.enqueue(i * 11);
    q.print("filled");
    std::cout << "  enqueue when full: "
              << (q.enqueue(99) ? "ok" : "REJECTED") << "\n";

    int v;
    q.dequeue(v); q.dequeue(v);
    q.print("after 2 dequeues");
    std::cout << "  last dequeued " << v
              << ", front is now " << q.peek() << "\n";

    /* the circular buffer WRAPS — indices reuse slot 0,1 */
    q.enqueue(66); q.enqueue(77);
    q.print("after 2 more enqueues (wrapped)");

    Queue<std::string,3> qs;
    qs.enqueue("Ram"); qs.enqueue("Sita");
    qs.print("strings");

    Queue<int,5>::value_type x = 7;   /* nested type alias */
    std::cout << "  value_type works: " << x << "\n";

    Queue<int,2> e;
    try { e.peek(); }
    catch (const std::out_of_range &ex) {
        std::cout << "  caught: " << ex.what() << "\n";
    }
    return 0;
}
Output:
  filled [5/5]: 11 22 33 44 55
  enqueue when full: REJECTED
  after 2 dequeues [3/5]: 33 44 55
  last dequeued 22, front is now 33
  after 2 more enqueues (wrapped) [5/5]: 33 44 55 66 77
  strings [2/3]: Ram Sita
  value_type works: 7
  caught: queue is empty

Tracing the circular buffer, which is what makes this queue O(1) at both ends: CAP = 5, slots 0..4 after 5 enqueues: front=0 rear=4 count=5 slot: 0 1 2 3 4 data: 11 22 33 44 55 after 2 dequeues: front=2 rear=4 count=3 data: 11 22 33 44 55 ^front ^rear slots 0 and 1 are now FREE but not shifted after 2 enqueues: rear wraps (4+1)%5 = 0, then 1 slot: 0 1 2 3 4 data: 66 77 33 44 55 ^rear ^front reading front..front+count-1 modulo 5 gives 33 44 55 66 77 ✔ WHY MODULO INSTEAD OF SHIFTING: shifting on dequeue: move n−1 elements → O(n) per dequeue circular indices : two integer updates → O(1) For a queue processing a million messages the difference is a million operations versus roughly 10¹² — the reason every real queue implementation is circular. The dequeue also shows why `out` is a reference parameter: the function must return BOTH a success flag and a value. std::optional<T> is the modern alternative.

Notice the definitions repeat template <typename T, int CAP> five times. That verbosity is why most template classes define everything inside the class body — not laziness, but a real readability trade-off. The out-of-class form earns its keep only for long function bodies, where separating declaration from definition makes the class summary readable at a glance.

Why templates cannot be split into a .cpp file

THE ATTEMPT that every C++ programmer makes once: // stack.h template <typename T> class Stack { T data[100]; int top; public: Stack(); bool push(const T&); }; // stack.cpp #include "stack.h" template <typename T> Stack<T>::Stack() : top(-1) {} template <typename T> bool Stack<T>::push(const T &v) { ... } // main.cpp #include "stack.h" int main() { Stack<int> s; s.push(5); } RESULT: undefined reference to `Stack<int>::Stack()' undefined reference to `Stack<int>::push(int const&)' → a LINKER error, not a compiler error WHY. Each .cpp is compiled independently: compiling stack.cpp: sees the template definitions, but NOBODY asked for Stack<int>, so it generates NO code at all compiling main.cpp: sees only the DECLARATIONS, so it emits calls to Stack<int>::push and trusts the linker to find them linking: nothing generated Stack<int> → undefined reference The compiler must see the DEFINITION at the point of INSTANTIATION. Separate compilation makes that impossible. THREE SOLUTIONS: 1. HEADER-ONLY (what everyone does) put all definitions in the .h — either inside the class body or after it, in the same file. 2. INCLUDE THE .cpp AT THE END OF THE .h // stack.h template <typename T> class Stack { ... }; #include "stack.tpp" ← convention: .tpp or .ipp Cosmetically separates them while still giving the compiler everything. Eigen and many libraries do this. 3. EXPLICIT INSTANTIATION — force the types you support // stack.cpp template class Stack<int>; template class Stack<double>; template class Stack<std::string>; Now stack.cpp generates code for exactly those three, and they link. Any OTHER type still fails. Useful when you want to hide the implementation or cut compile times, at the cost of a fixed type list. THE COST OF HEADER-ONLY: · every .cpp including the header recompiles the template · a template used in 50 files is parsed 50 times · that is why large C++ projects have long build times, and why -ftime-report and precompiled headers exist C++20 MODULES finally fix this: a module interface is compiled ONCE into a binary artefact that other translation units import, templates included.

explicit_inst.cpp

#include <iostream>
#include <string>

/* Simulating the three-file setup in one file.
   In a real project this class body is stack.h ... */
template <typename T>
class Box {
    T value;
public:
    Box(const T &v);
    T get() const;
    void set(const T &v);
};

/* ... and these definitions are stack.tpp or stack.cpp */
template <typename T> Box<T>::Box(const T &v) : value(v) {}
template <typename T> T Box<T>::get() const { return value; }
template <typename T> void Box<T>::set(const T &v) { value = v; }

/* EXPLICIT INSTANTIATION: generate code for these NOW.
   If the definitions lived in a separate .cpp, these three
   lines are what would make Box<int> etc. linkable. */
template class Box<int>;
template class Box<double>;
template class Box<std::string>;

int main() {
    Box<int>         a(42);
    Box<double>      b(3.14);
    Box<std::string> c("Nepal");

    std::cout << "  " << a.get() << " " << b.get()
              << " " << c.get() << "\n";
    a.set(99); c.set("Kathmandu");
    std::cout << "  " << a.get() << " " << c.get() << "\n";

    /* Box<char> still works HERE because the definitions
       are visible in this file. Move them to a .cpp and
       Box<char> would fail to link. */
    Box<char> d('X');
    std::cout << "  Box<char> = " << d.get() << "\n";
    return 0;
}
Output:
  42 3.14 Nepal
  99 Kathmandu
  Box<char> = X

Worked example — specialising one member for one type

member_spec.cpp

#include <iostream>
#include <string>
#include <cstring>

template <typename T>
class Container {
    T   items[10];
    int n;
public:
    Container() : n(0) {}
    void add(const T &v) { if (n < 10) items[n++] = v; }
    int  count() const { return n; }

    /* the generic implementation */
    bool contains(const T &key) const;
    void describe() const;
};

template <typename T>
bool Container<T>::contains(const T &key) const {
    for (int i = 0; i < n; i++) if (items[i] == key) return true;
    return false;
}

template <typename T>
void Container<T>::describe() const {
    std::cout << "  generic container of " << n << " items: ";
    for (int i = 0; i < n; i++) std::cout << items[i] << " ";
    std::cout << "\n";
}

/* SPECIALISE ONE MEMBER for const char*, where == compares
   ADDRESSES and would be wrong. Note: no template<typename T>
   header — the type is fixed, so it is template<> */
template <>
bool Container<const char*>::contains(const char *const &key) const {
    for (int i = 0; i < n; i++)
        if (std::strcmp(items[i], key) == 0) return true;
    return false;
}

template <>
void Container<const char*>::describe() const {
    std::cout << "  C-string container of " << n << ": ";
    for (int i = 0; i < n; i++) std::cout << "\"" << items[i] << "\" ";
    std::cout << "\n";
}

int main() {
    std::cout << std::boolalpha;

    Container<int> ci;
    ci.add(10); ci.add(20); ci.add(30);
    ci.describe();
    std::cout << "  contains(20)? " << ci.contains(20) << "\n";
    std::cout << "  contains(99)? " << ci.contains(99) << "\n";

    Container<const char*> cs;
    cs.add("Ram"); cs.add("Sita");
    cs.describe();

    /* a DIFFERENT buffer holding the same text — the
       generic == would compare pointers and say false */
    char buf[10]; std::strcpy(buf, "Sita");
    std::cout << "  contains(other \"Sita\" buffer)? "
              << cs.contains(buf) << "  (strcmp, correct)\n";
    std::cout << "  contains(\"Hari\")? "
              << cs.contains("Hari") << "\n";
    return 0;
}
Output:
  generic container of 3 items: 10 20 30
  contains(20)? true
  contains(99)? false
  C-string container of 2: "Ram" "Sita"
  contains(other "Sita" buffer)? true  (strcmp, correct)
  contains("Hari")? false

Three syntax points from that specialisation: 1. `template <>` with EMPTY brackets, not `template <typename T>`. The type is fixed, so there is nothing left to parameterise. 2. The class name carries the concrete type: Container<const char*>::contains, not Container<T>::. 3. The parameter type is written as `const char *const &` — a reference to a const pointer to const char. That is what `const T&` becomes when T is `const char*`. Getting this wrong is the usual reason a member specialisation fails to match: error: template-id 'contains<>' for '...' does not match any template declaration WHY SPECIALISE A MEMBER RATHER THAN THE WHOLE CLASS: Specialising the class would mean rewriting add(), count() and everything else. Member specialisation changes only the one function that is wrong for this type, and inherits the rest. That is the pattern std::hash uses: one generic template plus a specialisation per type that needs different hashing.

🌍 Go further: the header-only constraint has real engineering consequences that whole tools exist to manage. Precompiled headers parse your heaviest includes once and reuse the result. ccache caches compilation output so unchanged files are not recompiled. The pimpl idiom hides implementations behind an opaque pointer so headers stay thin. And -ftime-trace in Clang produces a flame graph showing exactly which template instantiations are eating your build time — running it once on a real project is genuinely eye-opening. Search "clang ftime-trace template instantiation".

💡 Exam angle: write an out-of-class member definition correctly from memory — template <typename T> then ReturnType ClassName<T>::member(...). Forgetting either the template header or the <T> on the class name is the standard error to be able to name. The high-value question is why template definitions must appear in the header: the compiler needs the definition at the point of instantiation, so separate compilation produces undefined-reference linker errors — and be ready to give explicit instantiation (template class Box<int>;) as the workaround.

Syllabus points

Defining member functions of a class template

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.