উন্নত template — variadic, fold expression, CRTP আর SFINAE

১ · বড় ছবি — template একটি compile-time কোড-কারখানা

পর্ব ২৮ আর ২৯-এ দেখেছেন, একটি template নিজে কোনো ফাংশন বা class নয়, বরং একটি ছাঁচ। আপনি largest(3, 7) ডাকলে compiler ছাঁচে T = int বসিয়ে একটি আসল ফাংশন বানায় — একে বলে instantiation. পর্ব ৩৯-এ দেখেছেন, compiler compile-এর সময়েই হিসাবও করতে পারে। আর পর্ব ৪০-এ concept দিয়ে এই ছাঁচের ওপর শর্ত বসাতে শিখেছেন।

এই তিনটি ধারণা মেলালে দাঁড়ায়: template আসলে একটি কোড-কারখানা, যা compile-এর সময় চলে। কাঁচামাল টাইপ আর compile-time মান, উৎপাদন আসল C++ কোড; চলার সময় কারখানার কোনো চিহ্ন থাকে না।

এই পর্বের কৌশলগুলো কারখানাটিকে চারটি নতুন ক্ষমতা দেয়:

এগুলো শুধু তাত্ত্বিক খেলা নয়। প্রতিদিন যে standard library ব্যবহার করেন, তার বড় অংশ এই কৌশলেই লেখা: std::tuple আর std::variant যত খুশি টাইপ রাখে variadic template দিয়ে; std::make_unique আপনার argument-গুলো constructor-এ পৌঁছে দেয় perfect forwarding দিয়ে; std::format compile-এর সময়েই যাচাই করে format string-এর প্রতিটি {}-এর সাথে argument-এর টাইপ মেলে কি না; আর std::enable_shared_from_this একটি CRTP base. ভেতরটা বুঝলে library-র error পড়তে পারবেন।

২ · variadic template গভীরে — pack, expansion-এর ছাঁচ আর sizeof...

পর্ব ২৯-এ variadic template-এর সাথে প্রথম দেখা হয়েছিল। মনে করিয়ে দিই: typename... Ts হলো টাইপের একটি parameter pack — শূন্য বা তার বেশি টাইপের ব্যাগ। const Ts&... xs হলো মানের ব্যাগ। আর sizeof...(xs) বলে ব্যাগে কয়টি জিনিস — compile-এর সময়ের একটি সংখ্যা, চলার সময়ে গোনা নয়।

এবার আসল যন্ত্রটি বুঝুন: pack expansion. ব্যাগ নিজে কোনো কাজে লাগে না; কাজে লাগে যখন আপনি তাকে “খুলে দেন”। নিয়ম হলো: ...-এর বাঁ দিকে যে expression থাকে, সেটি একটি ছাঁচ। compiler ব্যাগের প্রতিটি জিনিসের জন্য ছাঁচটি একবার করে বসায়, আর মাঝে কমা দিয়ে জোড়ে। ধরুন xs ব্যাগে তিনটি মান a, b, c:

শেষ সারিটি খেয়াল করুন: একটি ছাঁচে দুটি pack (Ts আর xs) থাকলে দুটি একসাথে, পাশাপাশি খোলে — প্রথম টাইপের সাথে প্রথম মান, দ্বিতীয়র সাথে দ্বিতীয়। তাই দুটির আকার সমান হতেই হবে। আর ... কোথায় বসছে, তাতে অর্থ পুরো বদলে যায় — দ্বিতীয় আর তৃতীয় সারি তুলনা করুন। AI-এর লেখা কোডে এই একটি বিন্দুর জায়গা ভুল হওয়া খুব সাধারণ।

C++17-এর আগে: recursion দিয়ে ব্যাগ খোলা

fold expression আসার আগে ব্যাগের প্রতিটি জিনিসের ওপর কাজ করার প্রচলিত উপায় ছিল recursion: “প্রথমটি নাও, কাজ করো, বাকি ব্যাগ দিয়ে নিজেকে আবার ডাকো।” ব্যাগ খালি হলে থামাতে একটি আলাদা “base case” লাগে। compiler একটি ডাককে কীভাবে কয়েকটি আলাদা ফাংশনে ভেঙে ফেলে, ধাপে ধাপে দেখুন:

1void print() { std::println(""); }          // base case2template <typename T, typename... Rest>3void print(const T& first, const Rest&... rest) {4    std::print("{} ", first);5    print(rest...);                         // pack expansion6}7print(1, "দুই", 3.0);

recursion-এর ধাঁচ চিনে রাখুন, কারণ পুরোনো library-র error-এ এই শিকলটিই দেখবেন — “required from print<double>, required from print<const char*, double> …”. তবে শুধু “সবার ওপর একই কাজ” করতে হলে আধুনিক উত্তর একটিই: fold expression.

৩ · fold expression — চার রকম fold, এক লাইনে লুপ

C++17-এর fold expression একটি operator দিয়ে পুরো ব্যাগকে এক expression-এ “ভাঁজ” করে। ব্যাকরণে চারটি রূপ, আর বন্ধনী বাধ্যতামূলক:

মনে রাখার সহজ উপায়: ... যেদিকে, ভাঁজ শুরু হয় সেদিক থেকে। ... বাঁয়ে থাকলে বাঁ দিকের জোড়াটি আগে হিসাব হয় (left fold). unary fold-এ শুধু ব্যাগ থাকে; binary fold-এ সাথে একটি শুরুর মান (init) — যেমন (0 + ... + xs) বা (std::cout << ... << xs). প্রায় সব binary operator চলে: + - * / && || , আর <<, তুলনা, assignment ইত্যাদি। (... + xs)-এর ভেতরে ১, ২, ৩, ৪ কীভাবে হিসাব হয়, আর বাম-ডানের পার্থক্য কখন গুরুত্বপূর্ণ, দেখুন:

1template <typename... Ts>2auto sum(Ts... xs) { return (... + xs); }34std::println("{}", sum(1, 2, 3, 4));5// (... - xs) বনাম (xs - ...) ?

খালি ব্যাগ আর comma fold

ব্যাগ খালি হলে unary fold কী দেবে? মাত্র তিনটি operator-এর জন্য উত্তর নির্দিষ্ট: && দেয় true, || দেয় false, আর কমা দেয় “কিছুই না” (void())। বাকি সব — যেমন খালি ব্যাগে (... + xs) — compile error, কারণ শূন্য জিনিসের যোগফল int-এর ০ নাকি string-এর "", compiler জানে না। সমাধান binary fold-এ একটি init দেওয়া, অথবা অন্তত একটি argument বাধ্যতামূলক করা।

সবচেয়ে কাজের fold সম্ভবত comma operator-এর fold: (f(xs), ...). এর মানে “প্রতিটি জিনিসের ওপর f চালাও, বাঁ থেকে ডানে” — অর্থাৎ লুপ। comma operator ক্রমের নিশ্চয়তা দেয়, তাই ছাপা হয় ঠিক যে ক্রমে argument দেওয়া হয়েছে। আর ((xs > 0) && ...) লিখলে “সবাই ধনাত্মক কি না”, শর্টসার্কিটসহ — প্রথম মিথ্যাতেই থামে।

এবার দুটি বাস্তব কাজ একসাথে। একটি type-safe logger, যা যত খুশি আর যেকোনো টাইপের মান নেয়; আর একটি sum_all, যা int, double, এমনকি নিজের বানানো Taka টাইপের জন্যও চলে:

#include <print>

struct Taka {                                  // amount in paisa
    long long paisa;
    Taka operator+(Taka o) const { return {paisa + o.paisa}; }
};

template <typename... Ts>
void log_line(const Ts&... xs) {
    std::print("[LOG]");
    (std::print(" {}", xs), ...);              // comma fold
    std::println(" ({} fields)", sizeof...(xs));
}
template <typename T, typename... Ts>
auto sum_all(const T& first, const Ts&... rest) {
    return (first + ... + rest);               // binary left fold
}
int main() {
    log_line("order", 1042, "taka", 350.5);
    Taka bill = sum_all(Taka{105000}, Taka{2550}, Taka{75});
    log_line(sum_all(1, 2, 3, 4), sum_all(0.5, 1.25), bill.paisa);
}

৪ · perfect forwarding, index_sequence আর একটি ছোট tuple

factory: যেমন এসেছে, তেমন পাঠাও

পর্ব ৩৬-এ perfect forwarding দেখেছেন: template-এর T&& parameter একটি forwarding reference, আর std::forward argument-কে তার মূল পরিচয়ে (lvalue হলে lvalue, temporary হলে rvalue) পাঠিয়ে দেয়। variadic template-এর সাথে মিলে এটিই make_unique-এর মতো সব factory-র হৃদয়:

template <typename T, typename... Args>
std::unique_ptr<T> make_xxx(Args&&... args) {
    return std::unique_ptr<T>(new T(std::forward<Args>(args)...));
}

std::string name = "Karim";
auto o = make_xxx<Order>(name, 3);   // name কপি হয়, 3 সরাসরি যায়; name অক্ষত

std::forward<Args>(args)... হলো ২ নম্বর অংশের টেবিলের শেষ সারি: দুটি pack জোড়ায় জোড়ায় খোলে। name একটি lvalue, তাই Args-এর প্রথম টাইপ std::string&, আর forward তাকে lvalue হিসেবেই পাঠায় — Order-এর constructor কপি নেয়, caller-এর name অক্ষত থাকে।

এখানে দুটি ভুল খুব সাধারণ। প্রথমটি forward ভুলে যাওয়া: new T(args...) লিখলে সব argument lvalue হয়ে যায় (নাম থাকলেই lvalue), ফলে temporary-ও কপি হয়, আর move-only টাইপে compile error. দ্বিতীয়টি আরও বিপজ্জনক: একই argument দুবার forward করা। temporary string দিলে প্রথম forward-এই string-টি move হয়ে খালি হয়, দ্বিতীয়বার যায় একটি moved-from খালি string. gcc-head-এ এমন একটি কোড চালিয়ে আমরা দেখেছি: কোনো warning নেই, আর দ্বিতীয় object-এর নাম ফাঁকা — [Rahim] []. নিয়ম: প্রতিটি argument একবারই forward করুন, আর সেটি হোক শেষ ব্যবহার।

std::index_sequence আর std::apply — tuple-এর প্রতিটি ঘরে কাজ

একটি std::tuple<int, const char*, double>-এর প্রতিটি ঘর ছাপাতে চান। tuple-এর ঘরে ঢোকার উপায় std::get<0>(t), std::get<1>(t) — সংখ্যাটি compile-time-এ জানা থাকতে হবে, লুপের i চলবে না। তাহলে লুপ ছাড়া ০, ১, ২ কোথা থেকে আসবে? উত্তর: সংখ্যার একটি parameter pack. std::index_sequence<0, 1, 2> একটি খালি টাইপ, যার একমাত্র কাজ ০, ১, ২ সংখ্যাগুলো টাইপের ভেতরে বয়ে নেওয়া। ফাংশন সেটি parameter হিসেবে নিলে compiler সংখ্যাগুলো একটি pack-এ deduce করে, আর তখন pack expansion চলে:

template <typename Tuple, std::size_t... I>
void print_tuple_impl(const Tuple& t, std::index_sequence<I...>) {
    ((std::print("{}{}", I == 0 ? "" : ", ", std::get<I>(t))), ...);
    std::println("");
}
template <typename... Ts>
void print_tuple(const std::tuple<Ts...>& t) {
    print_tuple_impl(t, std::index_sequence_for<Ts...>{});   // <0, 1, 2>
}

print_tuple(std::make_tuple(1042, "Rahim", 350.5));   // 1042, Rahim, 350.5

নিজের কোডে এর দরকার খুব কম, কারণ standard library কাজটি একটি তৈরি ফাংশনে ভরে দিয়েছে: C++17-এর std::apply. std::apply(f, t) tuple-এর ঘরগুলো খুলে f-কে আলাদা আলাদা argument হিসেবে দেয় — ভেতরে ঠিক উপরের index_sequence-কৌশল। একটি generic lambda (পর্ব ৩৪) আর একটি fold মিলিয়ে উপরের পুরো কাজ এক লাইনে:

std::apply([](const auto&... xs) { (std::print("{} ", xs), ...); }, t);

variadic class template — একটি ছোট tuple-এর ভাবনা

std::tuple নিজে কীভাবে লেখা? একটি সরল ধারণা (আসল বাস্তবায়ন আরও জটিল): খালি ব্যাগের জন্য একটি খালি struct, আর “প্রথম টাইপ + বাকি ব্যাগ”-এর জন্য একটি struct, যা বাকি ব্যাগের tuple থেকে inherit করে আর নিজে প্রথম মানটি রাখে:

template <typename... Ts> struct TinyTuple;          // শুধু ঘোষণা
template <> struct TinyTuple<> {};                     // খালি ব্যাগ: থামো

template <typename Head, typename... Tail>
struct TinyTuple<Head, Tail...> : TinyTuple<Tail...> {
    Head value;
    TinyTuple(Head h, Tail... t) : TinyTuple<Tail...>(t...), value(h) {}
};
// TinyTuple<int, double, char>  →  ভেতরে int, তার base-এ double, তার base-এ char

এটি ২ নম্বর অংশের recursion-ই, শুধু ফাংশনের বদলে টাইপে: পর্ব ২৯-এর partial specialization দিয়ে “প্রথম আর বাকি” ভাগ, প্রতিটি স্তরে একটি মান।

template template parameter — এক ঝলক

কখনো parameter হিসেবে একটি টাইপ নয়, একটি template দিতে চান — “কোন container, তা caller ঠিক করবে”:

template <template <typename...> class Container, typename T>
Container<T> make_filled(int n, const T& v) { return Container<T>(n, v); }

auto v = make_filled<std::vector>(3, 7);   // std::vector<int>{7, 7, 7}
auto d = make_filled<std::deque>(2, 1.5);  // std::deque<double>

এখানে Container একটি template template parameter: caller লেখে std::vector, std::vector<int> নয় — বাকি টাইপ ফাংশন নিজে বসায়। policy-based design-এ এটি দেখবেন; দৈনন্দিন কোডে কম।

৫ · CRTP — virtual ছাড়া polymorphism

পর্ব ২৫-এ virtual ফাংশন দিয়ে polymorphism দেখেছেন: base class-এর pointer দিয়ে area() ডাকলে চলার সময় vtable দেখে ঠিক derived-এর ফাংশন চলে। এর দাম: প্রতিটি object-এ একটি লুকানো vptr, প্রতিটি ডাকে একটি পরোক্ষ লাফ, আর সাধারণত inline হয় না। কিন্তু অনেক ক্ষেত্রে compile-এর সময়েই জানা থাকে কোন টাইপ — তাহলে চলার সময় খোঁজাখুঁজি কেন?

CRTP (Curiously Recurring Template Pattern — “অদ্ভুতভাবে ফিরে আসা template-এর ধাঁচ”) এই প্রশ্নের একটি উত্তর। কৌশলটি প্রথম দেখায় অদ্ভুত: derived class নিজেকেই base-এর template argument হিসেবে দেয় — struct Circle : Shape<Circle>. তাতে base জানে তার derived কে, আর static_cast দিয়ে নিজেকে derived-এ রূপান্তর করে সরাসরি derived-এর ফাংশন ডাকতে পারে:

#include <print>

template <typename Derived>
struct Shape {                                    // CRTP base
    double area() const {                         // static dispatch
        return static_cast<const Derived&>(*this).area_impl();
    }
};
struct Circle : Shape<Circle> {
    double r;
    explicit Circle(double radius) : r(radius) {}
    double area_impl() const { return 3.14159 * r * r; }
};
struct Rect : Shape<Rect> {
    double w, h;
    Rect(double width, double height) : w(width), h(height) {}
    double area_impl() const { return w * h; }
};
template <typename D>
void show(const char* label, const Shape<D>& s) { std::println("{}: {:.2f}", label, s.area()); }
static_assert(sizeof(Circle) == sizeof(double));  // no vptr inside
int main() { show("circle", Circle{2.0}); show("rect", Rect{3.0, 4.5}); }

compiler এই ডাক কীভাবে সমাধান করে, ধাপে ধাপে:

show("circle", Circle{2.0});

Circle-এর base হলো Shape<Circle>
→ const Shape<D>& মেলাতে D = Circle
→ show<Circle> তৈরি হলো

double Shape<Circle>::area() const {
    return static_cast<const Circle&>(*this).area_impl();
}
// Derived শব্দটির জায়গায় এখন আসল নাম Circle

*this-এর টাইপ: const Shape<Circle>&
static_cast → const Circle&

base থেকে derived-এ static_cast:
টাইপ compile-এর সময় জানা, কোনো খরচ নেই।
(object সত্যিই Circle না হলে UB — তাই নিয়ম মানা জরুরি)

Circle::area_impl() → 3.14159 * r * r

optimizer প্রায়ই পুরো শিকলটি গলিয়ে দেয়:
show → area → area_impl  ⇒  একটি গুণ
আউটপুট: circle: 12.57

s.area()  →  object-এর vptr পড়ো
          →  vtable থেকে area-র ঠিকানা
          →  পরোক্ষ ডাক (সাধারণত inline নয়)

CRTP:  কোনো vptr নেই, কোনো খোঁজ নেই
দাম:   প্রতিটি D-এর জন্য আলাদা show<D>;
       Circle আর Rect এক vector-এ রাখা যায় না

mixin — একবার লিখুন, অনেক class-এ মেশান

CRTP-র দ্বিতীয় বড় ব্যবহার mixin: base class এমন সুবিধা দেয়, যা derived-এর কোনো কাজের ওপর ভিত্তি করে তৈরি। দুটি পরিচিত উদাহরণ:

// ১. Comparable: শুধু < দিন, বাকি তুলনা বিনামূল্যে
template <typename D>
struct Comparable {
    friend bool operator>(const D& a, const D& b)  { return b < a; }
    friend bool operator<=(const D& a, const D& b) { return !(b < a); }
    friend bool operator>=(const D& a, const D& b) { return !(a < b); }
};
struct Marks : Comparable<Marks> {
    int v;
    friend bool operator<(const Marks& a, const Marks& b) { return a.v < b.v; }
};

// ২. প্রতিটি টাইপের জন্য আলাদা গণনা: কয়টি object এখন বেঁচে আছে
template <typename T>
struct Counted {
    static inline int alive = 0;
    Counted() { ++alive; }
    Counted(const Counted&) { ++alive; }
    ~Counted() { --alive; }
};
struct Order : Counted<Order> {};
struct Rider : Counted<Rider> {};
// Order a, b; Rider r;  →  Counted<Order>::alive == 2, Counted<Rider>::alive == 1

দ্বিতীয় উদাহরণে CRTP-র “জাদু”টি একটু অন্য রকম: base-এর ভেতরে T ব্যবহারই হয়নি! তবু Counted<Order> আর Counted<Rider> দুটি আলাদা টাইপ, তাই প্রতিটির নিজস্ব alive — পর্ব ২৯-এ দেখেছেন, প্রতিটি instantiation-এর static member আলাদা। একটি সাধারণ Counted base থাকলে সব টাইপ মিলিয়ে একটিই গণনা হতো। (copy constructor-এ ++alive না দিলে কপি করা object গোনা হতো না, অথচ destructor-এ কমত — গণনা ঋণাত্মক হয়ে যেত। mixin-এও Rule of 0/3/5 ভুলবেন না।)

প্রথম উদাহরণটি C++20-এর আগে খুব প্রচলিত ছিল — Boost.Operators নামে এর একটি পূর্ণ library-ও আছে। আজ পর্ব ২৩-এর operator<=> একটি লাইনে ছয়টি তুলনাই দেয়, তাই নতুন কোডে এর দরকার নেই — কিন্তু ধারণাটি থেকে যায়: base class derived-এর সামর্থ্যের ওপর নতুন সামর্থ্য গড়ে, virtual ছাড়াই। C++20-এর std::ranges::view_interface<D> ঠিক এভাবে আপনার view-কে empty(), front() ইত্যাদি দেয়।

একটি সতর্কতা: “CRTP দ্রুত” — এই দাবি সব জায়গায় সত্য নয়। আধুনিক compiler প্রায়ই virtual ডাকও সরাসরি করে ফেলে, যখন টাইপ নিশ্চিত জানা থাকে (devirtualization). CRTP-র আসল জায়গা হলো খুব ছোট, লাখো বার ডাকা ফাংশন (গণিত library, game engine-এর ভেতরের লুপ), বা mixin. মাপুন আগে, তারপর বদলান (পর্ব ৫২)।

৬ · deducing this — C++23-এর সহজ CRTP

CRTP কাজ করে, কিন্তু তার ব্যাকরণ ভারী: base-কে template বানাও, derived-কে নিজের নাম পাঠাতে মনে রাখো, প্রতিটি জায়গায় static_cast<const Derived&>(*this) লেখো। C++23 এর একটি সহজ বিকল্প দিয়েছে: deducing this, আনুষ্ঠানিক নাম explicit object parameter. member function-এর প্রথম parameter হিসেবে this লিখে object-টিকে একটি সাধারণ, deduce করা parameter হিসেবে নেওয়া যায়:

struct ShapeBase {                         // কোনো template নেই!
    void report(this const auto& self) {   // self-এর টাইপ deduce হয়
        std::println("area {:.1f}", self.area_impl());
    }
};
struct Square : ShapeBase {
    double s;
    double area_impl() const { return s * s; }
};

Square q; q.s = 3;
q.report();          // self = const Square&  →  area 9.0

q.report() ডাকলে self deduce হয় const Square& — base-এর ফাংশন হলেও, আসল object-এর টাইপে। তাই self.area_impl() সরাসরি Square-এর ফাংশন ডাকে। CRTP-র মতোই static dispatch, কিন্তু base template নয়, derived-কে নিজের নাম পাঠাতে হয় না, cast নেই — ভুল নাম দিয়ে UB ঘটানোর সুযোগও নেই। আমরা gcc-head-এ -std=c++2b দিয়ে কোডটি চালিয়ে দেখেছি; GCC 14, Clang 18 আর MSVC-র সাম্প্রতিক সংস্করণ এটি সমর্থন করে।

এর আরেকটি লাভ: const আর non-const দুটি সংস্করণ একবার this auto&& self লিখেই সামলানো যায়। তবে সব CRTP এতে বদলায় না: Counted-এর মতো mixin, যেখানে প্রতিটি টাইপের জন্য আলাদা static data চাই, এখনো CRTP দিয়েই লিখতে হয় — deducing this ফাংশনকে template বানায়, class-কে নয়।

৭ · type trait আর SFINAE — concept-এর আগের যুগে overload বাছাই

type trait: টাইপ সম্পর্কে compile-time প্রশ্ন

<type_traits> header-এ শতাধিক ছোট template আছে, যাদের বলে type trait. প্রতিটি একটি টাইপ সম্পর্কে একটি প্রশ্নের উত্তর দেয়, বা একটি টাইপ থেকে আরেকটি টাইপ বানায় — সব compile-এর সময়:

_v আর _t শেষাংশ C++14/17-এর সংক্ষেপ: std::is_integral_v<T> মানে std::is_integral<T>::value, আর std::conditional_t<...> মানে typename std::conditional<...>::type. ভেতরে এরা পর্ব ২৯-এর specialization দিয়ে লেখা — যেমন primary template-এ value = false, আর int, long ইত্যাদির specialization-এ value = true. শেষ সারির enable_if অদ্ভুত: শর্ত মিথ্যা হলে সে ইচ্ছা করে “ভাঙা” — তার ভেতরে type নামে কিছুই থাকে না। এই অদ্ভুততাই পুরো একটি যুগের কৌশল।

SFINAE: substitution ব্যর্থ হলে error নয়

overload resolution-এর সময় compiler প্রতিটি template প্রার্থীর ঘোষণায় deduce করা টাইপ বসিয়ে দেখে (substitution). বসাতে গিয়ে যদি একটি অবৈধ টাইপ তৈরি হয় — যেমন enable_if<false, int>::type, যা নেই — তাহলে সেটি error নয়; প্রার্থীটি শুধু তালিকা থেকে চুপচাপ বাদ পড়ে। এই নিয়মের নাম SFINAE — Substitution Failure Is Not An Error. নিয়মটি কেন এসেছিল, তার ইতিহাস পর্ব ৪০-এর ভাবনার প্রশ্ন ০৩-এ আছে। এখানে দেখুন কৌশলটি কীভাবে কাজ করে। একটি to_string_any, যা সংখ্যাকে std::to_string দিয়ে আর লেখার মতো জিনিসকে সরাসরি string বানায় — C++17-এর SFINAE রীতিতে:

// C++17: SFINAE দিয়ে দুটি overload
template <typename T, std::enable_if_t<std::is_arithmetic_v<T>, int> = 0>
std::string to_string_any(const T& x) { return std::to_string(x); }

template <typename T, std::enable_if_t<std::is_convertible_v<const T&, std::string>, int> = 0>
std::string to_string_any(const T& x) { return std::string(x); }

to_string_any(42);     // "42"  — প্রথমটি টিকে থাকে, দ্বিতীয়টি বাদ
to_string_any("hi");   // "hi"  — প্রথমটি বাদ, দ্বিতীয়টি টিকে থাকে

শর্তটি লুকিয়ে আছে একটি নামহীন template parameter-এ: std::enable_if_t<শর্ত, int> = 0. শর্ত সত্য হলে এটি দাঁড়ায় int = 0 — একটি নিরীহ, অব্যবহৃত parameter. মিথ্যা হলে টাইপটিই নেই, substitution ব্যর্থ, প্রার্থী বাদ। (পর্ব ৪০-এর AI অংশে দেখেছেন, typename = enable_if_t<...> রূপে দুটি overload লিখলে compiler “একই template দুবার” বলে আপত্তি করে; int = 0 রূপটি সেই ফাঁদ এড়ায়।) একটি অসমর্থিত টাইপ — std::vector<int> — দিলে কী হয়, আর একই overload set concept দিয়ে লিখলে কী বদলায়, ধাপে ধাপে:

ক: template <T, enable_if_t<is_arithmetic_v<T>, int> = 0>
খ: template <T, enable_if_t<is_convertible_v<const T&, string>, int> = 0>

to_string_any(v);
→ দুজনেরই T = std::vector<int> (deduction সফল)

is_arithmetic_v<vector<int>>      → false
enable_if_t<false, int>            → enable_if<false,int>::type
                                     ... এমন কিছু নেই!
substitution failure → error নয়
→ ক চুপচাপ বাদ

is_convertible_v<const vector<int>&, string> → false
enable_if_t<false, int> → টাইপ নেই
→ খ-ও চুপচাপ বাদ

প্রার্থী-তালিকা এখন খালি

error: no matching function for call to
       'to_string_any(std::vector<int>&)'
  • there are 2 candidates
    • candidate 1: 'template<class T, typename
      std::enable_if<is_arithmetic_v<T>, int>::type
      <anonymous> > std::string to_string_any(const T&)'
      • template argument deduction/substitution failed:
        • error: no type named 'type' in
          'struct std::enable_if<false, int>'
    • candidate 2: ... (একই কথা)

template <typename T> requires std::is_arithmetic_v<T>  ...
template <std::convertible_to<std::string> T>          ...

error: no matching function for call to
       'to_string_any(std::vector<int>&)'
    • candidate 1: ... requires is_arithmetic_v<T> ...
      • constraints not satisfied
        • the expression 'is_arithmetic_v<T>
          [with T = std::vector<int>]' evaluated to 'false'

template <typename T>
std::string bad(const T& x) { return std::to_string(x); }
//                          ^ শরীরে ভুল — ঘোষণায় নয়

bad(v);   // প্রার্থী বাদ পড়ে না!
          // শরীর instantiate হয় → hard error,
          // to_string-এর সব overload-এর লম্বা তালিকা

৮ · একই কাজ তিনভাবে — SFINAE, if constexpr আর concept

এবার একটি পূর্ণ overload set নিন: to_string_any সংখ্যা, লেখা, আর যেসব object-এর নিজের to_string() member আছে — তিন রকম টাইপের জন্য। একই আচরণ তিনভাবে লেখা, পাশাপাশি:

template <typename T, typename = void>
struct has_to_string : std::false_type {};
template <typename T>
struct has_to_string<T, std::void_t<decltype(std::declval<const T&>().to_string())>>
    : std::true_type {};

template <typename T, std::enable_if_t<std::is_arithmetic_v<T>, int> = 0>
std::string to_string_any(const T& x) { return std::to_string(x); }

template <typename T, std::enable_if_t<std::is_convertible_v<const T&, std::string>, int> = 0>
std::string to_string_any(const T& x) { return std::string(x); }

template <typename T, std::enable_if_t<has_to_string<T>::value, int> = 0>
std::string to_string_any(const T& x) { return x.to_string(); }

template <typename T>
std::string to_string_any(const T& x) {
    if constexpr (std::is_arithmetic_v<T>)
        return std::to_string(x);
    else if constexpr (std::is_convertible_v<const T&, std::string>)
        return std::string(x);
    else if constexpr (requires { x.to_string(); })      // C++20 requires
        return x.to_string();
    else
        static_assert(false, "to_string_any: unsupported type");   // C++23
}

template <typename T>
concept HasToString = requires(const T& x) {
    { x.to_string() } -> std::convertible_to<std::string>;
};

template <typename T> requires std::is_arithmetic_v<T>
std::string to_string_any(const T& x) { return std::to_string(x); }

std::string to_string_any(const std::convertible_to<std::string> auto& x) { return std::string(x); }

std::string to_string_any(const HasToString auto& x) { return x.to_string(); }

কোনটি কখন? একটি সরল নিয়ম: নতুন কোডে SFINAE নয়। শাখাগুলো ছোট আর একই কাজের অংশ হলে if constexpr; আলাদা টাইপের জন্য আলাদা আচরণ, যা ভবিষ্যতে বাড়বে — concept-যুক্ত overload. SFINAE পড়তে পারা দরকার, কারণ C++20-এর আগের বিপুল কোড আর যেসব library এখনো C++17 সমর্থন করে, সেখানে এটিই আছে। কিন্তু লেখার জন্য আজ এটি প্রায় কখনো সেরা উত্তর নয়।

template দিয়ে compile-time হিসাব বনাম constexpr

C++11-এর আগে compile-time-এ হিসাব করার একমাত্র উপায় ছিল template-কে পুনরাবৃত্তি করানো — যাকে বলে template metaprogramming:

// পুরোনো পথ: template-এর recursion
template <unsigned N> struct Factorial { static const unsigned long value = N * Factorial<N - 1>::value; };
template <>           struct Factorial<0> { static const unsigned long value = 1; };
static_assert(Factorial<10>::value == 3628800);

// আধুনিক পথ (পর্ব ৩৯): সাধারণ লুপ, compile-এর সময়েই চলে
constexpr unsigned long factorial(unsigned n) {
    unsigned long r = 1;
    for (unsigned i = 2; i <= n; ++i) r *= i;
    return r;
}
static_assert(factorial(10) == 3628800);

দুটিই compile-এর সময় ৩৬২৮৮০০ বের করে। কিন্তু প্রথমটিতে প্রতিটি N-এর জন্য একটি আলাদা struct instantiate হয় (Factorial<10>, <9>, … <0>), লুপের বদলে recursion, if-এর বদলে specialization — একটি পুরো ভাষা, যা কখনো ভাষা হিসেবে নকশা করা হয়নি। দ্বিতীয়টি সাধারণ C++, যা চলার সময়েও ডাকা যায় আর debug করা যায়। মান নিয়ে হিসাব হলে constexpr; শুধু টাইপ নিয়ে কাজ হলে (যেমন “এই টাইপের তালিকায় int আছে কি?”) template আর trait. এই বিভাজনই আধুনিক নিয়ম।

error কেন লম্বা, আর concept কতটা ছোট করে

template-এর error লম্বা হয় তিন কারণে। প্রথমত, ভুলটি ধরা পড়ে instantiation-এর গভীরে, আর compiler পুরো পথটি দেখায় — “required from … required from …”. দ্বিতীয়ত, overload resolution ব্যর্থ হলে compiler প্রতিটি প্রার্থী কেন মেলেনি, তা আলাদা করে বলে — আর standard library-তে একটি operator-এর প্রার্থী ডজনখানেক। তৃতীয়ত, টাইপের নাম নিজেই বিশাল: std::string আসলে std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >. একটি বাস্তব পরীক্ষা: শর্তহীন sum_all-এ একটি vector দিলে gcc-head কী বলে (ছাঁটা):

std::vector<int> v{1, 2};
auto s = sum_all(1, v, 3);

prog.cc: In instantiation of 'auto sum_all(const T&, const Ts& ...)
  [with T = int; Ts = {std::vector<int, std::allocator<int> >, int}]':
prog.cc:11:21:   required from here
prog.cc:6:19: error: no match for 'operator+' (operand types are
  'const int' and 'const std::vector<int>')
    6 |     return (first + ... + rest);
  • there are 14 candidates
    • candidate 1: 'template<class _Iterator> constexpr
      std::reverse_iterator<_IteratorL> std::operator+(...)'
      • template argument deduction/substitution failed:
        •   'const std::vector<int>' is not derived from
            'const std::reverse_iterator<_IteratorL>'
    • candidate 2: ... move_iterator ...
    • candidate 3: ... basic_string ...
    ... (মোট ১৪টি প্রার্থী, পুরো বার্তা ১৩০ লাইনের বেশি)

error-টি আসে template-এর শরীরের ভেতর থেকে (লাইন ৬), আর বেশিরভাগ লাইন reverse_iterator বা basic_string-এর এমন operator নিয়ে, যার সাথে আপনার কাজের কোনো সম্পর্ক নেই। এবার একই ফাংশনে একটি concept বসান:

template <typename T, typename... Ts>
concept Summable = requires(const T& first, const Ts&... rest) {
    (first + ... + rest);                       // requires expression-এ fold
};
template <typename T, typename... Ts>
    requires Summable<T, Ts...>
auto sum_all(const T& first, const Ts&... rest) { return (first + ... + rest); }

prog.cc:16:21: error: no matching function for call to
  'sum_all(int, std::vector<int>&, int)'
  • there is 1 candidate
    • candidate 1: ... requires Summable<T, Ts ...> ...
      • constraints not satisfied
        • required for the satisfaction of 'Summable<T, Ts ...>'
          [with T = int; Ts = {std::vector<int, std::allocator<int> >, int}]
        • the required expression '...' is invalid
(পুরো বার্তা প্রায় ৪০ লাইন)

error এখন ডাকার লাইনে (লাইন ১৬), একটি প্রার্থী, একটি শর্তের নাম, আর কোন টাইপগুলো দিয়ে শর্ত ভাঙল। শরীরের ভেতরের operator+-এর চৌদ্দজন প্রার্থীর কথা একবারও নেই, কারণ শরীর কখনো instantiate হয়নি। দৈর্ঘ্য প্রায় তিন ভাগের এক ভাগ, আর তথ্য অনেক বেশি কাজের। (নির্দিষ্ট লাইনসংখ্যা compiler-এর সংস্করণে বদলায়; পার্থক্যের ধরনটি বদলায় না।)

compile-সময় আর code bloat

প্রতিটি নতুন টাইপের সমাহারে নতুন instantiation: log_line-কে দশটি আলাদা argument-তালিকায় ডাকলে দশটি আলাদা ফাংশন। এতে compile-সময় বাড়ে (template-ভারী header প্রতিটি .cpp ফাইলে আবার পার্স হয়), আর binary-ও বড় হতে পারে — যাকে বলে code bloat. প্রতিকার: recursion-এর বদলে fold, template-এর শুধু টাইপ-নির্ভর অংশটুকু template রাখা, আর পর্ব ৪৩-এর modules.

কখন এগুলো লিখবেন না

• একটি-দুটি টাইপের জন্য: দুটি সাধারণ overload variadic-এর চেয়ে পড়তে সহজ।
• চলার সময়ে টাইপ ঠিক হলে: ব্যবহারকারী মেনু থেকে বেছে নেবেন কোন shape — virtual বা std::variant (পর্ব ৩৮), CRTP নয়।
• “ভবিষ্যতে লাগতে পারে” ভেবে: আজ যে generic-তা কেউ চায়নি, তার জন্য আজই জটিলতার দাম দেবেন না।
• দলের দক্ষতা না মিললে: যে কোড দলের বাকিরা ঠিক করতে পারবেন না, তা আপনার ছুটির দিনে ভাঙবে। template-কৌশল library-র ভেতরে লুকিয়ে রাখুন, ব্যবহারকারীর মুখে দিন একটি সরল interface.
• constexpr বা concept যেখানে যথেষ্ট: মানের হিসাবে constexpr ফাংশন, শর্তে concept, শাখায় if constexpr.

৯ · AI-এর যুগে — অতি-চালাক template চেনা

AI টুলের প্রশিক্ষণের ডেটায় পুরোনো Boost-ধাঁচের চতুর কোড প্রচুর, তাই একটি সাধারণ অনুরোধেও এরা প্রায়ই কাজের তুলনায় অনেক জটিল template-কোড দেয়। আপনার কাজ বিচার করা, এর সরল রূপ আছে কি না। সাধারণ ভুলগুলো:

AI-এর template-কোড যাচাইয়ের চেকলিস্ট

• প্রতিটি template-কৌশলের জন্য জিজ্ঞেস করেছি: সাধারণ ফাংশন, overload, constexpr বা if constexpr দিয়ে কি চলত?
• নতুন কোডে enable_if বা void_t নেই; শর্ত concept বা requires দিয়ে লেখা
• pack খোলা হয়েছে fold দিয়ে; ...-এর জায়গা ঠিক (f(xs)... নাকি f(xs...)) মিলিয়ে দেখেছি
• Args&&... থাকলে প্রতিটি argument ঠিক একবার std::forward হয়েছে
• খালি pack আর এক argument-এর ক্ষেত্র নিজে compile করে দেখেছি
• একটি ভুল টাইপ দিয়ে ডেকে error-এর দৈর্ঘ্য দেখেছি; লম্বা হলে শর্ত ঘোষণায় সরিয়েছি
• CRTP থাকলে প্রতিটি derived নিজের নামই base-এ দিয়েছে (Rect : Shape<Rect>)