concepts — template-এর শর্ত, পড়ার মতো চুক্তি

১ · সমস্যাটা আগে — অলিখিত চুক্তি আর পঞ্চাশ লাইনের error

পর্ব ২৮-এ largest নামের একটি function template লিখেছিলেন। তার শরীরে ছিল a < b, তাই T-কে < দিয়ে তুলনা করা যেতেই হবে — কিন্তু এই শর্ত কোথাও লেখা ছিল না। শর্তটি লুকিয়ে ছিল কোডের ভেতরে। যে টাইপে < নেই, তা দিলে compiler template-এর ভেতরে ঢুকে, অর্ধেক কাজ করে, তারপর আটকে যায়। আর error দেয় সেই লাইনে, যেটি আপনি লেখেননি।

ছোট template-এ এটি সহনীয়। কিন্তু standard library-র গভীর template-এ একই ভুল ভয়ংকর রূপ নেয়। ধরুন আপনি একটি std::list সাজাতে পুরোনো std::sort ডাকলেন। std::sort চায় random access — যেকোনো ঘরে সরাসরি লাফ দেওয়ার ক্ষমতা — যা linked list দিতে পারে না। g++ যা বলে, তার একটি ছোট করা রূপ:

std::list<int> marks{70, 45, 90};
std::sort(marks.begin(), marks.end());

In file included from /usr/include/c++/14/algorithm:61,
                 from main.cpp:1:
/usr/include/c++/14/bits/stl_algo.h: In instantiation of
  'void std::__sort(_RandomAccessIterator, _RandomAccessIterator, _Compare)
   [with _RandomAccessIterator = std::_List_iterator<int>; ...]':
/usr/include/c++/14/bits/stl_algo.h:...:   required from 'void std::sort(...)'
main.cpp:6:   required from here
/usr/include/c++/14/bits/stl_algo.h:...: error: no match for 'operator-'
  (operand types are 'std::_List_iterator<int>' and 'std::_List_iterator<int>')
 ...  |               std::__lg(__last - __first) * 2,
note: candidate: 'template<class _IteratorL, class _IteratorR> ... operator-(
      const std::reverse_iterator<_IteratorL>&, ...)'
note:   template argument deduction/substitution failed:
note:   'std::_List_iterator<int>' is not derived from
        'const std::reverse_iterator<_IteratorL>'
note: candidate: 'template<class _Iterator> ... operator-(
      const std::move_iterator<_IteratorL>&, ...)'
... (আরও কয়েক ডজন note — প্রতিটি সম্ভাব্য operator- কেন মেলেনি)

বার্তাটি পড়ে দেখুন। কোথাও লেখা নেই “list-কে std::sort দিয়ে সাজানো যায় না”। আছে __lg, __last - __first, reverse_iterator — library-র ভেতরের এমন সব নাম, যা আপনি কখনো লেখেননি। আসল কারণটি আপনাকে নিজেকেই খুঁজে বের করতে হবে: list-এর iterator-এ বিয়োগ চলে না, তাই random access নেই। পুরো বার্তা সহজেই পঞ্চাশ লাইন ছাড়িয়ে যায়। নতুনরা এখানেই template-কে ভয় পেতে শুরু করেন।

C++20 এই তালিকা লেখার ব্যবস্থা দিয়েছে: concept. একই কাজ নতুন std::ranges::sort দিয়ে করলে, যার শর্ত concept দিয়ে লেখা, error শুরু হয় ডাকার লাইনেই, আর বলে দেয় কোন শর্ত মেলেনি:

std::ranges::sort(marks);

main.cpp:6: error: no match for call to '(const std::ranges::__sort_fn) (std::list<int>&)'
note: candidate: ... requires random_access_range<_Range> && sortable<...>
note: constraints not satisfied
note: the required expression 'std::ranges::begin(...) + n' is invalid ...
      required for the satisfaction of 'random_access_iterator<...>'
(সংক্ষেপে)

এখনো নিখুঁত নয়, কিন্তু চাবি-শব্দটি এখন চোখের সামনে: random_access_range — শর্তটি মেলেনি। list-এর জন্য সঠিক পথ হলো তার নিজের marks.sort(), পর্ব ৩০-এ যেমন দেখেছেন।

২ · standard library-র তৈরি concept — আগে এগুলো চিনুন

নিজের concept লেখার আগে জেনে নিন, standard library কী কী তৈরি করে রেখেছে। বেশিরভাগ দৈনন্দিন শর্তের জন্য নতুন কিছু লিখতেই হয় না। header <concepts>-এর সবচেয়ে কাজের কয়েকটি:

তালিকায় একটি চমক খেয়াল করুন: bool আর char দুটিই std::integral. C++-এর চোখে এরা পূর্ণসংখ্যার টাইপ। তাই “শুধু সংখ্যা চাই” লিখতে গিয়ে শুধু std::integral বসালে true + true-এর গড়ও compile হয়ে যাবে। এমন ক্ষেত্রে শর্ত মেলাতে হয় — ৫ নম্বর অংশে দেখবেন।

আরেকটি সূক্ষ্মতা: std::invocable আর std::predicate-এর প্রথম টাইপটি callable, বাকিগুলো তাকে যে argument দিয়ে ডাকা হবে তাদের টাইপ। std::predicate<F, int> মানে “F-কে একটি int দিয়ে ডাকা যায়, আর ফলটিকে সত্য-মিথ্যা হিসেবে পরীক্ষা করা যায়”। পর্ব ৩৩-এর std::count_if-এ যে predicate দিয়েছিলেন, ranges সংস্করণে ঠিক এই concept দিয়ে তাকে যাচাই করা হয়।

ranges-এর concept

পর্ব ৩৫-এর ranges লাইব্রেরি পুরোটাই concept-এর ওপর দাঁড়িয়ে। std::ranges::range<R> মানে R-এর ওপর begin আর end ডাকা যায় — অর্থাৎ range-for দিয়ে হাঁটা যায়। তার ওপর ধাপে ধাপে কড়া শর্ত: input_range (একবার পড়া যায়), forward_range (বারবার পড়া যায়), bidirectional_range (পেছনেও যাওয়া যায়), আর random_access_range (যেকোনো ঘরে সরাসরি লাফ)। প্রতিটি আগেরটির সব শর্ত মেনে আরও কিছু চায় — পর্ব ৩২-এর iterator category-র সিঁড়ি, এখন compiler-এর পড়ার মতো রূপে। std::vector সিঁড়ির সবচেয়ে ওপরে, std::list bidirectional পর্যন্ত। তাই std::ranges::sort vector নেয়, list নেয় না।

ডাকার সময় compiler কীভাবে একটি concept-এর সাথে ডাকটি মেলায়, ধাপে ধাপে দেখুন। এখানে Number একটি নিজের লেখা concept (৫ নম্বর অংশে এর পুরো কোড): “পূর্ণসংখ্যা বা দশমিক সংখ্যা”।

1template <Number T>2double average(const std::vector<T>& v);34average(std::vector{70, 85, 90});5average(std::vector<std::string>{"a"});

৩ · শর্ত বসানোর চারটি উপায়

একটি template-এ concept বসানোর চারটি লেখার রীতি আছে। চারটিই একই কাজ করে; পার্থক্য শুধু কোথায় লেখা হয় আর কতটা জটিল শর্ত লেখা যায়। ধরুন শর্ত হলো “T একটি পূর্ণসংখ্যার টাইপ”:

#include <concepts>

// ১. template parameter-এর জায়গায় concept-এর নাম
template <std::integral T>
T half(T x) { return x / 2; }

// ২. requires clause: template-এর ঠিক পরে
template <typename T>
    requires std::integral<T>
T half2(T x) { return x / 2; }

// ৩. trailing requires: ফাংশনের ঘোষণার শেষে
template <typename T>
T half3(T x) requires std::integral<T> { return x / 2; }

// ৪. abbreviated: parameter-এর টাইপে "concept auto"
auto half4(std::integral auto x) { return x / 2; }

প্রথম রীতিতে concept-এর নামটি typename-এর জায়গায় বসে। একে বলে type constraint. পড়তে সবচেয়ে সহজ: “T একটি integral টাইপ”। যখন শর্ত একটিমাত্র concept আর একটিমাত্র টাইপ নিয়ে, তখন এটিই প্রথম পছন্দ।

দ্বিতীয় রীতি requires clause — পর্ব ২৮-এ এক ঝলক দেখেছিলেন। requires-এর পরে যেকোনো compile-time সত্য-মিথ্যা শর্ত লেখা যায়, && আর || দিয়ে মিলিয়ে: requires std::integral<T> || std::floating_point<T>. যখন শর্তে একাধিক concept বা একাধিক টাইপের সম্পর্ক থাকে (requires std::convertible_to<A, B>), তখন এটি কাজে লাগে।

তৃতীয় রীতি trailing requires clause — শর্ত ফাংশনের ঘোষণার শেষে, parameter-এর তালিকার পরে। এর বিশেষ সুবিধা: শর্তে parameter-এর নাম ব্যবহার করা যায়। আরেকটি জায়গায় এটি অপরিহার্য — class template-এর ভেতরের সাধারণ member function-এ, যার নিজের কোনো template parameter নেই। যেমন একটি Box<T>-এর void print() const requires Printable<T>; — print আছে শুধু তখনই, যখন T ছাপানো যায়।

চতুর্থ রীতি পর্ব ২৮-এর abbreviated function template-এর শর্তযুক্ত রূপ: std::integral auto x. লিখতে সবচেয়ে ছোট। মনে রাখুন, শর্তহীন auto-র মতোই প্রতিটি concept auto parameter একটি আলাদা template parameter. “দুটি argument একই টাইপের” — এই সম্পর্ক বোঝাতে প্রথম বা দ্বিতীয় রীতিতে ফিরে যান। আর এই রূপটি ভ্যারিয়েবলেও চলে: std::integral auto n = count(); — count() পূর্ণসংখ্যা না দিলে compile error. এটি AI-এর লেখা কোডে টাইপ সম্পর্কে নিজের ধারণা পরীক্ষার একটি সস্তা উপায়।

৪ · নিজের concept লেখা — requires expression

standard concept যখন আপনার চাহিদা বলতে পারে না — যেমন “যার area() নামে একটি কাজ আছে” — তখন নিজের concept লিখুন। গঠনটি সরল:

template <typename T>
concept নাম = শর্ত;          // শর্ত: compile-time-এ true বা false

শর্তটি অন্য concept-এর মিশ্রণ হতে পারে (std::integral<T> || std::floating_point<T>), অথবা একটি requires expression — concept লেখার আসল যন্ত্র। requires expression দেখতে একটি ফাংশনের মতো: বন্ধনীতে কাল্পনিক parameter, আর ধনুর্বন্ধনীর ভেতরে শর্তের তালিকা। কিন্তু এর ভেতরের কোড কখনো চলে না। compiler শুধু দেখে, লেখাগুলো বৈধ C++ কি না। চার রকম শর্ত লেখা যায়:

compound requirement-এ তীর চিহ্নের পরে একটি concept বসে, কিন্তু তার প্রথম টাইপটি লেখা হয় না — compiler নিজে বসিয়ে দেয় ধনুর্বন্ধনীর expression-এর টাইপ। -> std::convertible_to<double> আসলে পড়া হয় std::convertible_to<(area()-র টাইপ), double> হিসেবে। চারটি একসাথে একটি concept-এ রেখে একটি টাইপের ওপর লাইন ধরে ধরে হিসাব করে দেখুন:

1template <typename T>2concept SmallShape = requires(const T& s) {3    s.area();                                    // simple4    typename T::unit;                            // type5    { s.area() } -> std::convertible_to<double>; // compound6    requires sizeof(T) <= 16;                    // nested7};89struct Tile { using unit = int; int w, h; int area() const { return w * h; } };

এবার একটি পূর্ণ প্রোগ্রাম। একটি Shape concept, যা চায় area() double-এর মতো কিছু ফেরত দেবে আর name() একটি লেখা দেবে। দুটি struct — কোনো base class নেই, কোনো virtual নেই — শুধু কাজগুলো আছে:

#include <concepts>
#include <print>
#include <string_view>

template <typename T>
concept Shape = requires(const T& s) {
    { s.area() } -> std::convertible_to<double>;
    { s.name() } -> std::convertible_to<std::string_view>;
};
struct Circle {                       // no base class, no virtual
    double r;
    double area() const { return 3.14 * r * r; }
    std::string_view name() const { return "circle"; }
};
struct Rect {
    double w, h;
    double area() const { return w * h; }
    std::string_view name() const { return "rect"; }
};
void report(const Shape auto& s) { std::println("{}: {:.2f}", s.name(), s.area()); }
static_assert(Shape<Circle> && Shape<Rect> && !Shape<int>);
int main() { report(Circle{2.0}); report(Rect{3.0, 4.5}); }

আরও দুটি বাস্তব concept: logging আর payment

ধরুন আপনি একটি logging ফাংশন লিখছেন, যা যেকোনো ছাপার মতো মান log-এ লেখে। “ছাপার মতো” মানে std::ostream-এ << দিয়ে পাঠানো যায়:

#include <concepts>
#include <ostream>

template <typename T>
concept Printable = requires(std::ostream& os, const T& x) {
    { os << x } -> std::same_as<std::ostream&>;
};

void log_info(std::ostream& out, const Printable auto& value) {
    out << "[INFO] " << value << '\n';
}

লক্ষ করুন, এখানে std::same_as নেওয়া হয়েছে, কারণ <<-কে chain করতে (out << a << b) ফলটি ঠিক সেই stream-এর reference হওয়া চাই। আর একটি কথা: C++23 থেকে <format>-এ std::formattable নামে তৈরি concept আছে — “std::format দিয়ে ছাপানো যায়”। আপনার logger যদি std::println ব্যবহার করে, তাহলে নিজের Printable না লিখে সেটিই নিন।

দ্বিতীয় উদাহরণ একটি দোকানের checkout. টাকা নেওয়ার কাজ করতে পারে মোবাইল ওয়ালেট, কার্ড, বা পরীক্ষার জন্য একটি নকল gateway. checkout-এর শুধু একটি জিনিস দরকার: charge(int) নামে একটি কাজ, যা সফল হলো কি না জানায়।

template <typename P>
concept PaymentGateway = requires(P& p, int taka) {
    { p.charge(taka) } -> std::convertible_to<bool>;
};

template <PaymentGateway P>
bool checkout(P& gateway, int taka) {
    if (taka <= 0) return false;
    return gateway.charge(taka);
}

struct MobileWallet { bool charge(int taka); };   // আসল লেনদেন
struct FakeGateway  { bool charge(int) { return true; } };  // টেস্টের জন্য

টেস্টে FakeGateway, আসল দোকানে MobileWallet — checkout-এর কোড একটুও বদলায় না, আর কোনো virtual ডাকও নেই। কেউ ভুল করে এমন একটি টাইপ দিলে যার charge নেই, বা যার charge একটি string নেয়, error আসবে checkout ডাকার লাইনেই: “PaymentGateway শর্ত মেলেনি”।

৫ · শর্ত দিয়ে overload — বেশি নির্দিষ্ট শর্ত জেতে

পর্ব ৯-এ দেখেছেন, একই নামের কয়েকটি ফাংশন থাকলে compiler argument দেখে বাছাই করে (overload resolution). concept এই বাছাইয়ে নতুন একটি মাপকাঠি যোগ করে: যার শর্ত মেলে না, সে বাদ; আর দুজনেরই মিললে, যার শর্ত বেশি নির্দিষ্ট, সে জেতে। প্রথমে একটি প্রোগ্রাম, যাতে দুটি ঘটনাই আছে — শুধু সংখ্যার জন্য একটি average, আর একই নামের দুটি describe:

#include <concepts>
#include <print>
#include <vector>

template <typename T>
concept Number = (std::integral<T> || std::floating_point<T>)
                 && !std::same_as<T, bool>;

template <Number T>
double average(const std::vector<T>& v) {
    double sum = 0;
    for (T x : v) sum += x;
    return v.empty() ? 0.0 : sum / v.size();
}
void describe(std::integral auto)        { std::println("integral"); }
void describe(std::signed_integral auto) { std::println("signed integral (more specific)"); }

int main() {
    std::println("{:.2f} {:.2f}", average(std::vector{70, 85, 90}), average(std::vector{2.5, 3.0}));
    describe(42u);
    describe(-7);
}

এই বাছাইয়ের নিয়মের নাম subsumption, বাংলায় বলা যায় “অন্তর্ভুক্তি”। শর্ত A যদি শর্ত B-র সবকিছু ধারণ করে, আর তার ওপর আরও কিছু চায়, তাহলে A বেশি নির্দিষ্ট — A “B-কে subsume করে”। standard library-তে std::signed_integral-এর সংজ্ঞা হলো std::integral<T> && std::is_signed_v<T> — integral-এর সব, আর তার ওপর signed. ধাপে ধাপে দেখুন:

void describe(std::integral auto);         // ক
void describe(std::signed_integral auto);  // খ

describe(-7);     // -7 হলো int

ক: integral<int>            → true   ✔ টিকে রইল
খ: signed_integral<int>     → true   ✔ টিকে রইল

parameter-এর মিল দুটিতেই হুবহু এক (int)
→ সাধারণ নিয়মে কেউ জেতে না

ক-এর শর্ত:  [ is_integral_v<T> ]

খ-এর শর্ত:  signed_integral<T>
          = integral<T> && is_signed_v<T>
          = [ is_integral_v<T> ] && [ is_signed_v<T> ]

খ সত্য হলে ক-ও সত্য হবেই   (খ-এর ভেতরে ক-এর অংশটি আছে)
ক সত্য হলেও খ সত্য না-ও হতে পারে  (যেমন unsigned)

→ খ বেশি নির্দিষ্ট → খ জেতে
আউটপুট: signed integral (more specific)

ক: integral<unsigned>        → true   ✔
খ: signed_integral<unsigned> → false  ✘ বাদ

একজনই প্রার্থী → ক
আউটপুট: integral

template <typename T> concept Num1 = std::is_integral_v<T>;
template <typename T> concept Num2 = std::is_integral_v<T>
                                     && std::is_signed_v<T>;

void g(Num1 auto);  void g(Num2 auto);
g(-7);   // error: ambiguous!
// Num2-এর is_integral_v আর Num1-এরটি আলাদা জায়গায় লেখা,
// তাই compiler এদের "একই শর্ত" ধরে না।
// সমাধান: Num2 = Num1<T> && std::is_signed_v<T>;

এই কৌশলের একটি পরিচিত ব্যবহার iterator-কে n ঘর এগোনো। random access iterator পেলে এক লাফে n ঘর এগোনো যায়, শুধু forward iterator পেলে একে একে n বার। পুরোনো std::advance-এ এই বাছাই হতো “tag dispatch” নামের এক কৌশলে, যাতে বাছাইয়ের জন্য আলাদা নকল টাইপ বানিয়ে পাঠাতে হতো। concept দিয়ে এখন দুটি overload লিখলেই হয় — একটির শর্ত std::random_access_iterator, অন্যটির std::forward_iterator — আর subsumption নিজেই ঠিকটি বেছে নেয়।

৬ · concept বনাম abstract class — compile-time-এর interface

পর্ব ২৬-এ abstract class দিয়ে interface বানিয়েছিলেন: pure virtual function-এর একটি তালিকা, যা প্রতিটি derived class-কে বাস্তবায়ন করতেই হবে। concept-ও একটি চুক্তি — “এই কাজগুলো থাকতে হবে”। তাহলে দুটির পার্থক্য কী? একই Shape চুক্তি দুই ভাবে পাশাপাশি দেখুন:

struct IShape {
    virtual double area() const = 0;
    virtual ~IShape() = default;
};
struct Circle : IShape {          // বংশ ঘোষণা বাধ্যতামূলক
    double r;
    double area() const override { return 3.14 * r * r; }
};
void report(const IShape& s);    // সাধারণ ফাংশন, একটিই

template <typename T>
concept Shape = requires(const T& s) {
    { s.area() } -> std::convertible_to<double>;
};
struct Circle {                   // কোনো base নেই
    double r;
    double area() const { return 3.14 * r * r; }
};
void report(const Shape auto& s); // template, টাইপ-প্রতি একটি

abstract class:  object → vptr → vtable → area-র ঠিকানা → ডাক
                 (পরোক্ষ ডাক, সাধারণত inline হয় না)

concept:         Circle::area সরাসরি ডাক
                 (compile-এর সময় টাইপ জানা, প্রায়ই inline)

// third_party/geo.h  (ছোঁয়া যাবে না)
struct Polygon { double area() const; };

abstract class:  Polygon IShape থেকে আসেনি →
                 একটি adapter class লিখে মুড়াতে হবে
concept:         Polygon-এ area() আছে → Shape<Polygon> সত্য,
                 সরাসরি report(poly) চলে

std::vector<std::unique_ptr<IShape>> all;   // ✔ Circle, Rect মিশিয়ে
all.push_back(std::make_unique<Circle>(...));

std::vector<Shape> all;     // ✘ concept কোনো টাইপ নয়!
// নানা টাইপ এক জায়গায় রাখতে চলার সময়ের ব্যবস্থা লাগে:
// virtual, std::variant (পর্ব ৩৮) বা type erasure

দুটি প্রতিদ্বন্দ্বী নয়, সঙ্গী। বড় প্রোগ্রামে প্রায়ই দুটিই থাকে: ভেতরের দ্রুত, টাইপ-জানা অংশে concept, আর প্লাগইনের মতো চলার সময়ে বদলানো অংশে virtual. একটি ভালো নিয়ম: আগে জিজ্ঞেস করুন “নানা টাইপকে কি একসাথে, এক তালিকায় রাখতে হবে?” — হ্যাঁ হলে virtual বা variant; না হলে concept.

৭ · static_assert আর if constexpr-এ concept

concept শুধু template-এর মাথায় বসে না। Shape<Circle> নিজেই একটি compile-time bool মান, তাই যেখানে compile-time সত্য-মিথ্যা চলে, সেখানে concept-ও চলে। দুটি জায়গা বিশেষ কাজের।

static_assert — নিজের টাইপের পক্ষে প্রতিশ্রুতি

shapes.cpp-এ দেখেছেন: static_assert(Shape<Circle>);. static_assert compile-এর সময় একটি শর্ত পরীক্ষা করে, মিথ্যা হলে compile থামিয়ে দেয়। টাইপের সংজ্ঞার ঠিক পরে এমন একটি লাইন রাখা একটি ভালো অভ্যাস। কেন? template থেকে দূরে বসে কেউ Circle বদলালে ভাঙনটি ধরা পড়ত অনেক পরে, অন্য কোনো ফাইলে, যেখানে Circle-কে template-এ পাঠানো হয়। static_assert থাকলে ভাঙনটি ধরা পড়ে Circle-এর নিজের ফাইলে। এটি abstract class-এর override শব্দের মতো একটি স্ব-ঘোষণা — structural typing-এ যা নিজে থেকে নেই, তা আপনি হাতে যোগ করছেন।

if constexpr — একই ফাংশনে টাইপ-ভেদে শাখা

পর্ব ৩৯-এ দেখেছেন, if constexpr compile-এর সময় শাখা বাছে, আর বাদ পড়া শাখা instantiate হয় না। শর্ত হিসেবে concept, এমনকি একটি requires expression সরাসরি বসানো যায়:

template <typename T>
void log_value(const T& x) {
    if constexpr (std::integral<T>)
        std::println("int: {}", x);
    else if constexpr (requires { x.name(); })     // ad-hoc শর্ত
        std::println("object: {}", x.name());
    else
        std::println("(unprintable)");
}

দ্বিতীয় শাখার requires { x.name(); } একটি নামহীন requires expression: “x-এর name() ডাকা যায় কি?” Circle দিলে দ্বিতীয় শাখা চলে; int দিলে প্রথমটি, আর দ্বিতীয় শাখা — যেখানে int-এর ওপর .name() লেখা — কখনো instantiate হয় না, তাই error-ও হয় না। একটিমাত্র জায়গায় লাগে এমন ছোট শর্তের জন্য নামহীন রূপ সুবিধাজনক। কিন্তু একই শর্ত দুই জায়গায় লিখতে হলে তাকে নাম দিন — concept বানান।

কখন overload, কখন if constexpr? শাখাগুলো ছোট আর একই কাজের অংশ হলে একটি ফাংশনে if constexpr পড়তে সহজ। শাখাগুলো বড়, বা ভবিষ্যতে নতুন টাইপের জন্য নতুন শাখা অন্য কেউ যোগ করবে — তখন আলাদা overload ভালো, কারণ পুরোনো ফাংশন না ছুঁয়েই নতুন overload লেখা যায়।

৮ · concept ব্যাকরণ দেখে, অর্থ নয় — আর ভালো concept-এর নকশা

এখন সবচেয়ে গুরুত্বপূর্ণ সীমাটি বুঝুন। ধরুন কেউ এমন একটি টাইপ লিখল:

struct Weird {
    int v;
    bool operator==(const Weird&) const { return true; }   // সবাই সমান?
    auto operator<=>(const Weird&) const { return std::strong_ordering::less; }
};   // a < b সত্য, আবার b < a-ও সত্য!

static_assert(std::totally_ordered<Weird>);   // পাস করে!

এখানে a < b আর b < a দুটিই সত্য, আবার a == b-ও সত্য — কোনো যুক্তিসংগত ক্রমের সাথে মেলে না। তবু std::totally_ordered<Weird> সত্য, কারণ concept শুধু দেখে ছয়টি তুলনা লেখা যায় আর ফল bool-এর মতো। এই টাইপের vector-কে std::ranges::sort দিলে compile হবে, কিন্তু ফল অর্থহীন — আর কিছু বাস্তবায়নে sort-এর লুপ array-র সীমার বাইরেও চলে যেতে পারে।

standard এই পার্থক্যকে দুটি শব্দে ভাগ করে। একটি টাইপ একটি concept-কে satisfy করে, যখন ব্যাকরণের শর্তগুলো মেলে — compiler এটুকুই যাচাই করে। আর টাইপটি concept-কে model করে, যখন তার ওপর semantic requirement-ও খাটে — যেমন totally_ordered-এর বেলায়: a < b আর b < a একসাথে সত্য হতে পারে না, a < b আর b < c হলে a < c. এই অংশ লেখা থাকে শুধু standard-এর পাতায়। standard library-র ফাংশনে এমন টাইপ দিলে, যা satisfy করে কিন্তু model করে না, প্রোগ্রামটির আচরণের কোনো নিশ্চয়তা থাকে না, আর compiler-এর কিছু বলার দায়ও নেই।

এর একটি পরিচিত বাস্তব উদাহরণ double. সাধারণ সংখ্যায় double-এর তুলনা নিখুঁত। কিন্তু NaN (“not a number”, যেমন 0.0 / 0.0) এলে NaN < x, x < NaN, NaN == x — সবই মিথ্যা, এমনকি NaN == NaN-ও। standard-এর ব্যাখ্যা হলো, শর্তগুলো প্রযোজ্য শুধু সেই মানগুলোর ওপর, যা নিয়ে আসলে কাজ হচ্ছে। NaN-ভরা ডেটা sort করার আগে NaN বাদ দেওয়া তাই আপনার দায়িত্ব — কোনো concept আপনাকে মনে করিয়ে দেবে না।

ভালো concept-এর তিনটি নিয়ম

• আগে standard concept. সংখ্যা, তুলনা, কপি, ডাকা যায় এমন কিছু, range — প্রায় সবই <concepts>, <iterator> আর <ranges>-এ আছে, নিখুঁত সংজ্ঞা আর subsumption-এর সঠিক গঠনসহ। নিজের Comparable লিখলে সেটি std::totally_ordered-এর সাথে subsumption-এ মিলবে না (৫ নম্বর অংশের ফাঁদ), আর পাঠককে নতুন একটি নাম শিখতে হবে।
• নাম দিন ক্ষমতার নামে। Shape, Printable, PaymentGateway — টাইপটি কী করতে পারে। HasAreaFunction বা HasChargeMethod-এর মতো নাম বাস্তবায়নের খুঁটিনাটি বলে, অর্থ বলে না; আর দুই-তিনটি কাজের শর্ত মিলিয়ে একটি অর্থপূর্ণ ধারণা তৈরিই concept-এর উদ্দেশ্য।
• বেশি শর্ত দেবেন না। template-এর শরীর আসলে যা ব্যবহার করে, শুধু তা-ই চান। শুধু পড়ে এমন ফাংশনে std::copyable চাইলে std::unique_ptr-এর মতো move-only টাইপ অকারণে বাদ পড়ে। -> std::same_as<double> চাইলে যে area() float ফেরত দেয়, সে বাদ পড়ে — convertible_to যথেষ্ট ছিল। অতিরিক্ত শর্ত over-constraining: নিরাপত্তা বাড়ায় না, শুধু কাজের টাইপ আটকায়।

উল্টো ভুলও আছে। concept-এ শর্ত কম, কিন্তু শরীর বেশি ব্যবহার করে — ধরুন Shape শুধু area() চায়, অথচ report-এর শরীরে s.name()-ও আছে। C++ concept template-এর শরীর যাচাই করে না; সে শুধু ডাকার জায়গায় শর্ত দেখে। ফলে name() ছাড়া একটি টাইপ শর্ত পাস করবে, তারপর শরীরের ভেতর থেকে পুরোনো ধাঁচের লম্বা error আসবে। concept আর শরীর মিলিয়ে রাখা তাই আপনার কাজ।

৯ · AI-এর যুগে — concept-কোড যাচাই

AI টুল বিপুল পরিমাণ পুরোনো C++ কোড দেখে শিখেছে, যার বেশিরভাগ C++20-এর আগের। তাই template-এ শর্ত চাইলে এরা প্রায়ই লেখে std::enable_if — SFINAE নামের পুরোনো কৌশল, যা দেখতে এমন:

// পুরোনো পথ (C++11)
template <typename T,
          typename = std::enable_if_t<std::is_integral_v<T>>>
T half(T x) { return x / 2; }

// একই কথা C++20-এ
template <std::integral T>
T half(T x) { return x / 2; }

দুটি একই কাজ করে, কিন্তু প্রথমটি পড়তে কঠিন, error বার্তা দুর্বোধ্য, আর এই রূপে দুটি overload লিখলে আরেকটি ফাঁদ আছে — default template argument আলাদা হলেও signature এক থাকে, তাই compiler “একই template দুবার ঘোষণা” বলে আপত্তি করে। C++20-এর প্রজেক্টে নতুন কোডে enable_if দেখলে concept-এ বদলাতে বলুন। AI-এর আরও কয়েকটি প্রবণতা:

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

• কোথাও enable_if, void_t বা অন্য SFINAE-কৌশল নেই; থাকলে concept-এ বদলেছি
• নিজের লেখা প্রতিটি concept-এর জন্য দেখেছি, std-এ একই জিনিস আছে কি না
• শর্তগুলো শরীরের ব্যবহারের সাথে মেলে — কম নয়, বেশিও নয়
• nested requirement-এর শুরুতে requires শব্দটি আছে
• বড় concept ছোট concept-এর নাম দিয়ে গড়া, শর্ত কপি করে নয়
• একটি ভুল টাইপ দিয়ে ডেকে দেখেছি: error ছোট আর ডাকার লাইনে
• concept যে অর্থের নিয়ম যাচাই করে না, সেগুলো টেস্টে আছে