optional, variant আর any — “হয়তো”, “এগুলোর একটি” আর “যেকোনো কিছু” টাইপে লেখা

১ · সমস্যাটা আগে — -1, খালি string আর nullptr: যে উত্তর টাইপে লেখা নেই

ধরুন একটি স্কুলের ফলাফল-সফটওয়্যারে একটি ফাংশন আছে: রোল নম্বর দিলে ছাত্রের প্রাপ্ত নম্বর ফেরত দেয়। প্রশ্ন হলো, ওই রোলের কোনো ছাত্র না থাকলে কী ফেরত দেবে? বহু বছর ধরে প্রোগ্রামাররা এর একটি সহজ উত্তর দিয়ে এসেছেন: একটি বিশেষ মান, যা “আসল” উত্তর হতে পারে না।

int marksOf(int roll);              // না পেলে -1 ফেরত দেয় (কোথাও লেখা নেই!)
std::string phoneOf(int roll);      // না পেলে "" (খালি string)
Student* findStudent(int roll);     // না পেলে nullptr

int m = marksOf(42);
int total = m + bonus;              // m যদি -1 হয়? কেউ আটকাবে না

এমন বিশেষ মানকে বলে sentinel value বা magic number. এর তিনটি গভীর সমস্যা আছে। এক, চুক্তিটি থাকে শুধু মানুষের মাথায় বা কোনো মন্তব্যে — int টাইপ দেখে কেউ বুঝতে পারে না যে -1 মানে “নেই”। দুই, যাচাই করা ঐচ্ছিক। ডাকার মানুষ if (m == -1) লিখতে ভুলে গেলে প্রোগ্রাম -1-কেই নম্বর ধরে হিসাব চালিয়ে যায়, আর ছাত্রের মোট নম্বর এক কম দেখায়। compiler-এর চোখে সব বৈধ। তিন, একদিন হয়তো -1 নিজেই বৈধ মান হয়ে যায় — যেমন নেতিবাচক মার্কিংয়ের পরীক্ষায় কারও প্রাপ্ত নম্বর সত্যিই -1. তখন “নেই” আর “-1 পেয়েছে” আলাদা করার কোনো উপায় থাকে না।

pointer-এর nullptr একই রোগের আরেক রূপ। Student* টাইপ বলে না, nullptr আসতে পারে কি না। যাচাই না করে -> লিখলে null dereference — undefined behavior, প্রায়ই crash. ALGOL W ভাষায় ১৯৬৫ সালে null reference যোগ করা Tony Hoare নিজে ২০০৯ সালের একটি বক্তৃতায় একে বলেছিলেন তাঁর “বিলিয়ন ডলারের ভুল” (ভাবনার প্রশ্ন ১-এ বিস্তারিত)।

এই পর্বের তিনটি টাইপ একই দর্শন থেকে এসেছে: যে কথা সত্যি, তা টাইপে লিখুন। ফলাফল “হয়তো আছে, হয়তো নেই” হলে std::optional. ফলাফল “কয়েকটি নির্দিষ্ট ধরনের যেকোনো একটি” হলে std::variant. আর সত্যিই “যেকোনো টাইপ” হলে std::any. তিনটিই C++17-এ standard library-তে এসেছে, আর তিনটিরই উদ্দেশ্য এক — ডাকার মানুষকে প্রতিটি সম্ভাবনা সামলাতে বাধ্য করা, যাতে ভুলে যাওয়া আর নীরবে না ঘটে।

২ · std::optional — “হয়তো একটি মান”

std::optional<T> হলো একটি ছোট বাক্স, যার দুটি অবস্থা: ভেতরে একটি T আছে, অথবা বাক্স খালি। খালি অবস্থার নাম std::nullopt. বাক্সটি একটি সাধারণ মান — heap থেকে মেমরি নেয় না, ভেতরের T আর একটি ছোট “আছে কি নেই” চিহ্ন পাশাপাশি রাখে। GCC-তে std::optional<int>-এর মাপ সাধারণত ৮ বাইট: int-এর ৪, চিহ্নের ১, বাকিটা alignment-এর ফাঁকা জায়গা।

#include <optional>

std::optional<int> a = 42;          // ভেতরে 42
std::optional<int> b;               // খালি
std::optional<int> c = std::nullopt; // খালি — স্পষ্ট করে লেখা

if (a)              { /* মান আছে */ }   // bool-এ রূপান্তর
if (b.has_value())  { /* ... */ }       // একই কাজ, নাম দিয়ে
a.reset();                              // a এখন খালি
a = 7;                                  // আবার মান আছে
a.emplace(9);                           // ভেতরে সরাসরি তৈরি

if (a) কাজ করে কারণ optional-এ একটি explicit operator bool আছে — শর্তের ভেতরে লিখলে নিজে থেকে “মান আছে কি?” প্রশ্নে বদলে যায়। আর has_value() একই প্রশ্ন, শুধু নাম দিয়ে লেখা। কোনটি লিখবেন তা রুচির ব্যাপার; দুটিই সমান দ্রুত।

মান পড়ার তিন উপায় — নিরাপত্তা আলাদা

বাক্স থেকে মান বের করার তিনটি পথ আছে, আর এদের পার্থক্য বোঝা এই পর্বের সবচেয়ে কাজের অংশগুলোর একটি। একটি ভরা optional (a, ভেতরে 42) আর একটি খালি optional (b) পাশাপাশি রেখে ধাপে ধাপে দেখুন। প্রতিটি ধাপে আগে নিজে অনুমান করুন, খালি b-এর বেলায় কী ঘটবে:

1std::optional<int> a = 42, b;   // b খালি2*a;            *b;            // যাচাই নেই3a.value();     b.value();     // যাচাই করে4a.value_or(0); b.value_or(0); // বিকল্প মান

আসল উদাহরণ — রোল দিয়ে ছাত্র খোঁজা

এবার শুরুর সমস্যাটি optional দিয়ে লিখুন। খোঁজার ফাংশন এখন সরাসরি বলছে, “আমি হয়তো একজন Student দেব”। ডাকার মানুষ যাচাই না করে নাম পড়তে পারবেন না — অন্তত ভুলটা লুকানো থাকবে না:

#include <optional>
#include <print>
#include <string>
#include <vector>
struct Student { int roll; std::string name; int marks; };
std::optional<Student> find(const std::vector<Student>& cls, int roll) {
    for (const auto& s : cls)
        if (s.roll == roll) return s;
    return std::nullopt;                       // "not found" is part of the type
}
int main() {
    std::vector<Student> cls{{1, "Rahim", 78}, {2, "Karim", 64}};
    for (int roll : {2, 7}) {
        if (auto s = find(cls, roll)) std::println("roll {}: {} ({})", roll, s->name, s->marks);
        else std::println("roll {}: not found", roll);
    }
    auto grade = [](const Student& s) { return s.marks >= 70 ? 'A' : 'B'; };
    std::println("grade of 1: {}", find(cls, 1).transform(grade).value_or('-'));
    std::println("grade of 9: {}", find(cls, 9).transform(grade).value_or('-'));
    try { std::println("{}", find(cls, 9).value().name); }
    catch (const std::bad_optional_access&) { std::println("value() threw bad_optional_access"); }
}

৩ · optional নিয়ে কাজ — ডিফল্ট মান, C++23-এর শিকল, আর কখন optional নয়

একটি কনফিগারেশন — হয়তো লেখা আছে, হয়তো নেই

একটি সার্ভারের কনফিগারেশন ফাইলে port লেখা থাকতেও পারে, না-ও পারে। না থাকলে 8080 ধরতে হবে। optional-এর সবচেয়ে সাধারণ ব্যবহার ঠিক এটি:

std::optional<std::string> lookup(const Config& cfg, std::string_view key);
std::optional<int> toInt(std::string_view s);        // "80a" হলে খালি

int port = lookup(cfg, "port")       // optional<string>
              .and_then(toInt)       // string → optional<int>; খালি হলে থেমে যায়
              .value_or(8080);       // কোথাও খালি হলে 8080

এখানে দুটি ধাপের যেকোনোটি ব্যর্থ হতে পারে: key না থাকা, অথবা লেখাটি সংখ্যা না হওয়া। পুরোনো ধাঁচে লিখলে দুটি নেস্ট করা if লাগত। C++23 optional-এ তিনটি monadic operation যোগ করেছে, যা এই শিকল সম্ভব করে:

মনে রাখার সহজ উপায়: যে ধাপ নিজেও “নেই” বলতে পারে, সেটি and_then-এ; যে ধাপ শুধু রূপ বদলায়, সেটি transform-এ; আর “না পেলে অন্য জায়গায় খোঁজো” হলে or_else — যেমন lookup(cfg, "port").or_else([&] { return lookup(env, "PORT"); }). শিকলের যেকোনো জায়গায় খালি হলে বাকি ধাপগুলো আর চলে না, খালিটাই শেষ পর্যন্ত গড়িয়ে যায়। একই নামের ফাংশনগুলো পর্ব ৩৭-এর std::expected-এও আছে।

optional, pointer আর sentinel — কোনটি কখন

pointer একেবারে বাদ নয়। কোনো বড় object আগে থেকেই কোথাও আছে আর আপনি শুধু সেটিকে দেখাতে চান — কপি না করে — তখন const Student* ফেরত দেওয়া যুক্তিসংগত (মালিকানা নেই এমন observer pointer, পর্ব ১৫ আর ১৭)। কারণ optional ভেতরে মানটির নিজের কপি রাখে।

optional<T&> কেন নেই — আর C++26-এ কী বদলাল

C++17 থেকে C++23 পর্যন্ত std::optional<int&> লেখা যায় না — compile error. বহু বছর ধরে এর কারণ ছিল একটি অমীমাংসিত প্রশ্ন: opt = x; লিখলে কি পুরোনো reference নতুন object-কে দেখাতে শুরু করবে (rebind), নাকি যে object-কে দেখাচ্ছে তার মান বদলাবে (assign through)? দুটি উত্তরই কারও কাছে “স্বাভাবিক”, আর ভুল বোঝাবুঝি মানেই বাগ। তাই এতদিন বিকল্প ছিল সাধারণ pointer, বা std::optional<std::reference_wrapper<T>>. C++26-এর জন্য একটি প্রস্তাব (P2988) গৃহীত হয়ে optional<T&> যোগ হয়েছে, rebind আচরণসহ। তবে compiler আর library-তে এর সমর্থন এখনো আসছে — এই কোর্সের C++23 পরিবেশে আপনি এখনো error পাবেন। নতুন কোডে আপাতত pointer ব্যবহার করুন।

৪ · std::variant — “এগুলোর ঠিক একটি”

optional দুটি সম্ভাবনা বোঝায়: একটি T, অথবা কিছু না। কিন্তু অনেক সময় উত্তর হয় কয়েক ধরনের — আর প্রতিটি ধরনের সাথে আলাদা তথ্য থাকে। একটি bKash বা Nagad পেমেন্টের ফল ভাবুন:

• সফল — সাথে লেনদেনের আইডি আর টাকার পরিমাণ
• প্রত্যাখ্যাত — সাথে কারণ (“ব্যালেন্স কম”, “ভুল PIN”)
• নেটওয়ার্ক সমস্যা — সাথে কত সেকেন্ড পরে আবার চেষ্টা করতে হবে

পুরোনো পথ ছিল একটি বড় struct, যাতে সব ফিল্ড আছে আর একটি kind লেবেল বলে দেয় কোনগুলো অর্থপূর্ণ। সমস্যা: সফল লেনদেনে reason ফিল্ডে কী আছে? কেউ ভুল করে সেটি পড়লে কেউ আটকাবে না। std::variant<Success, Declined, NetworkError> ঠিক এই অবস্থাটি টাইপে লেখে: এই তিনটির ঠিক একটি, একসাথে দুটি কখনো নয়, আর কোনটি তা সবসময় জানা। এমন টাইপকে তত্ত্বের ভাষায় বলে sum type, আর বাস্তবায়নের ভাষায় tagged union.

#include <variant>

std::variant<int, double, std::string> v;   // শুরুতে: int, মান 0
v = 3.5;                                     // এখন double
v = std::string("Dhaka");                    // এখন string

v.index();                                   // 2 — তালিকার কত নম্বর টাইপ
std::holds_alternative<std::string>(v);      // true
std::get<std::string>(v);                    // "Dhaka"
std::get<int>(v);                            // throw std::bad_variant_access
std::get_if<int>(&v);                        // nullptr — exception নয়

variant-এর ভেতরে আসলে কী আছে, ধাপে ধাপে দেখুন। ছবিগুলো সাধারণ বাস্তবায়নের সরল রূপ — standard শুধু আচরণ বলে, ঠিক কোন বাইটে কী থাকবে তা বলে না:

v:  [ জায়গা (সবচেয়ে বড় টাইপের মাপ) ][ tag ]
    [ int: 0                          ][  0  ]

জায়গার মাপ = string-এর মাপ (সবচেয়ে বড়)
GCC 64-বিটে sizeof(v) সাধারণত 40 বাইট

১. পুরোনো int-কে ধ্বংস করা হলো
২. একই জায়গায় নতুন double তৈরি হলো
৩. tag বদলে 1

v:  [ double: 3.5                     ][  1  ]

১. double ধ্বংস (কিছু করার নেই, সাধারণ সংখ্যা)
২. জায়গায় std::string তৈরি — constructor চলল
৩. tag বদলে 2

v:  [ string: "Dhaka"                 ][  2  ]
পরে v-এর টাইপ আবার বদলালে string-এর destructor চলবে

v.index()                        → 2
holds_alternative<string>(v)     → true
get<string>(v)                   → "Dhaka"
get<int>(v)                      → tag 0 নয়!
                                   throw bad_variant_access
get_if<int>(&v)                  → nullptr

কয়েকটি নিয়ম জেনে রাখুন। এক, variant-এ reference, array বা void রাখা যায় না। দুই, একই টাইপ দুবার থাকলে (variant<int, int>) টাইপ দিয়ে get<int> লেখা যায় না, কারণ কোনটি বোঝাচ্ছেন তা অস্পষ্ট — তখন index দিয়ে get<0>. তবে এর চেয়ে ভালো হলো আলাদা নামের ছোট struct বানানো, যেমন struct Taka { int v; }; struct Poisa { int v; };. তিন, “খালি” অবস্থা চাইলে তালিকার প্রথমে std::monostate রাখুন — একটি ফাঁকা টাইপ, যার কাজই হলো “এখনো কিছু নেই” বোঝানো। প্রথম টাইপের ডিফল্ট constructor না থাকলে variant-এর ডিফল্ট constructor-ও থাকে না, তখনও monostate কাজে লাগে।

৫ · std::visit আর overloaded lambda — প্রতিটি টাইপের জন্য নিজের কোড

variant-এ কী আছে তা index() দেখে switch লিখে বের করা যায়, কিন্তু সেটি সেই পুরোনো, ভুলপ্রবণ পথ। C++-এর আসল যন্ত্র হলো std::visit: আপনি এমন একটি “ডাকা যায় এমন জিনিস” দেন, যা variant-এর প্রতিটি টাইপ নিতে পারে, আর visit চলার সময় যে টাইপ আছে, সেটি দিয়ে ঠিক সংস্করণটি ডাকে।

সবচেয়ে সহজ রূপ একটি generic lambda — auto প্যারামিটার সব টাইপই নেয়:

std::variant<int, double, std::string> v = 3.5;
std::visit([](const auto& x) { std::println("{}", x); }, v);   // 3.5

কিন্তু প্রায়ই প্রতিটি টাইপের জন্য আলাদা কাজ দরকার। তখন একটি ছোট কৌশল ব্যবহার করা হয়, যাকে বলে overloaded pattern. কয়েকটি lambda-কে একটি object-এ জুড়ে দেওয়া হয়, যাতে সেই object-এর ডাকার অপারেটর overload হয়ে যায় — প্রতিটি টাইপের জন্য একটি:

template<class... Ts>
struct overloaded : Ts... { using Ts::operator()...; };   // সব lambda-র operator() একসাথে

// C++17-এ এই লাইনটিও লাগত; C++20 থেকে compiler নিজেই বুঝে নেয়:
// template<class... Ts> overloaded(Ts...) -> overloaded<Ts...>;

লাইনটি ছোট, কিন্তু ঘন। class... Ts একটি parameter pack — যতগুলো খুশি টাইপ (পর্ব ২৯-এর variadic template). overloaded সবগুলো lambda-র টাইপ থেকে একসাথে inherit করে। আর using Ts::operator()...; প্রতিটি base-এর operator()-কে এক জায়গায় এনে overload-এর একটি সেট বানায় (এটি একটি pack-ভিত্তিক using-declaration). ফল: একটি object, যাকে Circle দিলে Circle-এর lambda চলে, Rect দিলে Rect-এর। আশ্চর্যের বিষয়, এই দরকারি টুকরোটি এখনো standard library-তে নেই — প্রত্যেক প্রজেক্ট নিজে লিখে নেয়।

একটি আকৃতি — Circle অথবা Rect

struct Circle { double r; };
struct Rect   { double w, h; };
using Shape = std::variant<Circle, Rect>;

double area(const Shape& s) {
    return std::visit(overloaded{
        [](const Circle& c) { return 3.14159 * c.r * c.r; },
        [](const Rect& r)   { return r.w * r.h; },
    }, s);
}
// area(Rect{3, 4}) == 12,  area(Circle{1}) ≈ 3.14159

area(Rect{3, 4}) ডাকলে ভেতরে কী ঘটে, ধাপে ধাপে দেখুন। লক্ষ করুন, কাজের একটি অংশ ঘটে compile-এর সময়, আর বাকিটা চলার সময়:

Shape = variant<Circle, Rect>
compiler প্রতিটি টাইপের জন্য জিজ্ঞেস করে:
  overloaded{...}(const Circle&) ডাকা যায়?  হ্যাঁ → double
  overloaded{...}(const Rect&)   ডাকা যায়?  হ্যাঁ → double
সব ফেরত-টাইপ এক?  হ্যাঁ
=> টেবিল: [0] Circle-এর lambda  [1] Rect-এর lambda

s:  [ Rect: w=3, h=4 ][ tag = 1 ]
visit শুধু tag পড়ে: 1

টেবিল[1] → Rect-এর lambda
if-else-এর শিকল নেই, টাইপের তুলনা নেই —
tag একটি সংখ্যা, সংখ্যাটিই ঘরের ঠিকানা

[](const Rect& r) { return r.w * r.h; }
   r = s-এর ভেতরের Rect-এর reference
   (কপি হয়নি, যাচাই আগেই হয়ে গেছে)

3 * 4 = 12
visit যা ফেরত দেয়, area() তাই ফেরত দেয়: 12.0

আসল উদাহরণ — পেমেন্টের ফল

এবার শুরুর পেমেন্ট-ফলের উদাহরণটি পুরো প্রোগ্রামে দেখুন। তিনটি ভিন্ন ফল একটি তালিকায়, আর একটি visit প্রতিটির জন্য ঠিক বার্তাটি ছাপায়। শেষে get_if আর holds_alternative-ও দেখানো হলো:

#include <print>
#include <string>
#include <variant>
#include <vector>
struct Success      { std::string txn; int taka; };
struct Declined     { std::string reason; };
struct NetworkError { int retryAfter; };
using PayResult = std::variant<Success, Declined, NetworkError>;
template<class... Ts> struct overloaded : Ts... { using Ts::operator()...; };

int main() {
    std::vector<PayResult> all{Success{"TX7781", 500}, Declined{"low balance"}, NetworkError{30}};
    for (const auto& r : all)
        std::visit(overloaded{
            [&](const Success& s)      { std::println("[{}] paid {} taka, id {}", r.index(), s.taka, s.txn); },
            [&](const Declined& d)     { std::println("[{}] declined: {}", r.index(), d.reason); },
            [&](const NetworkError& n) { std::println("[{}] retry in {} s", r.index(), n.retryAfter); },
        }, r);
    if (auto* s = std::get_if<Success>(&all[0])) std::println("first txn: {}", s->txn);
    std::println("last holds Declined? {}", std::holds_alternative<Declined>(all[2]));
}

JSON-এর মতো একটি মান

variant-এর আরেকটি পরিচিত ব্যবহার এমন মান, যা কয়েকটি মৌলিক টাইপের যেকোনোটি হতে পারে — যেমন একটি JSON ফাইলের একটি ঘর:

using Json = std::variant<std::nullptr_t, bool, int, double, std::string>;

Json a = 42, b = 3.5, c = std::string("Dhaka"), d = true, e = nullptr;
// সত্যিকারের JSON-এ তালিকা আর object-ও থাকে, যার ভেতরে আবার Json —
// তখন নিজের ভেতরে নিজেকে রাখতে vector বা unique_ptr-এর মতো একটি ধাপ লাগে।

একটি ফাঁদের কথা জেনে রাখুন। std::variant<bool, std::string> v = "hi"; — এখানে "hi" একটি const char*, যা bool-এও রূপান্তর হতে পারে, string-এও। C++17-এর মূল নিয়মে এটি bool বেছে নিত, আর v হয়ে যেত true! C++20-এ একটি সংশোধনী (P0608) এই রূপান্তরের নিয়ম কড়া করেছে, তাই আধুনিক GCC-তে এখন string বাছাই হয় (index 1). পুরোনো compiler-এ কোড চালাতে হলে স্পষ্ট লিখুন: std::string("hi").

৬ · নতুন টাইপ যোগ করলে compile error — exhaustiveness-এর উপহার

এখন সেই কথা, যার জন্য variant-কে অনেকে এত পছন্দ করেন। ছয় মাস পরে কেউ Shape-এ একটি Triangle যোগ করলেন। পুরোনো ধাঁচের switch হলে কী হতো, আপনি জানেন: যে switch-এ Triangle-এর শাখা নেই, সেটি চুপচাপ default-এ যেত, বা কিছুই করত না। visit-এ কী হয়, দেখুন:

using Shape = std::variant<Circle, Rect>;

double area(const Shape& s) {
    return std::visit(overloaded{
        [](const Circle& c) { ... },
        [](const Rect& r)   { ... },
    }, s);
}

struct Triangle { double b, h; };
using Shape = std::variant<Circle, Rect, Triangle>;

// area()-এ কেউ হাত দেয়নি।
// perimeter(), draw(), toJson()-এও না।

In instantiation of 'std::visit(...)
  [with _Visitor = overloaded<...Circle&..., ...Rect&...>;
        _Variants = const variant<Circle, Rect, Triangle>&]':
prog.cc:8:22:   required from here
error: no type named 'type' in
  'struct std::invoke_result<overloaded<...>,
                             const Triangle&>'

    return std::visit(overloaded{
        [](const Circle& c)   { ... },
        [](const Rect& r)     { ... },
        [](const Triangle& t) { return 0.5 * t.b * t.h; },
    }, s);

// সতর্কতা: [](const auto&) { return 0.0; } দিয়ে
// “বাকি সব” ধরলে এই নিরাপত্তা হারিয়ে যায়।

এই গুণটির নাম exhaustiveness — প্রতিটি সম্ভাবনা সামলানো হয়েছে কি না, compiler-এর যাচাই। Rust-এ এটি ভাষারই নিয়ম — কোনো বিকল্প বাদ পড়লে compile error; Haskell বা OCaml-এ compiler অন্তত সতর্কবার্তা দেয় (ভাবনার প্রশ্ন ৪)। C++-এ এটি আসে library-র কৌশল থেকে, তাই error message সুন্দর নয় — কিন্তু নিরাপত্তাটি পুরোপুরি আসল। উল্টো দিক থেকে ভাবুন: compile error এখানে বন্ধু। যে ভুল compile-এর সময় ধরা পড়ে, তা কোনো গ্রাহকের ফোনে পৌঁছায় না।

যখন variant “কিছুই না” হয়ে যায় — valueless_by_exception

variant-এর একটি বিরল কোণ আছে। v-তে একটি int আছে, আর আপনি লিখলেন v = BigThing{...};. variant-কে আগে int ধ্বংস করতে হয়, তারপর জায়গায় BigThing তৈরি করতে হয়। কিন্তু যদি BigThing-এর constructor মাঝপথে exception ছোড়ে? পুরোনো int ইতিমধ্যে নেই, নতুন BigThing-ও তৈরি হয়নি। তখন variant ঢোকে একটি বিশেষ অবস্থায়: valueless by exception. এ অবস্থায় v.valueless_by_exception() দেয় true, v.index() দেয় std::variant_npos, আর visit বা get ছোড়ে bad_variant_access. আবার একটি মান বসালেই variant স্বাভাবিক হয়।

বাস্তবে এটি প্রায় দেখাই যায় না — কেবল তখনই সম্ভব, যখন কোনো টাইপের তৈরি বা কপি exception ছুড়তে পারে, আর সেই exception আপনি ধরে variant-টি আবার ব্যবহার করছেন। সাধারণ int, double, string-এর মতো টাইপে move করার সময় exception হয় না, আর library অনেক ক্ষেত্রে আগে একটি অস্থায়ী কপি বানিয়ে ঝুঁকি এড়িয়ে চলে। কেন standard এই অবস্থাটি রাখল, সেটি একটি চমৎকার নকশা-বিতর্ক — ভাবনার প্রশ্ন ৩-এ।

৭ · variant বনাম virtual — বন্ধ তালিকা বনাম খোলা তালিকা

পর্ব ২৫-এ একই সমস্যা — নানা ধরনের Payment বা Shape — সমাধান করেছিলেন inheritance আর virtual function দিয়ে। এখন আরেকটি সমাধান হাতে এল। কোনটি কখন? উত্তরটি সুন্দরভাবে দুটি প্রশ্নে ভাগ করা যায়: নতুন টাইপ বেশি যোগ হবে, নাকি নতুন কাজ (operation) বেশি যোগ হবে?

এই টানাপোড়েনের একটি বিখ্যাত নাম আছে: expression problem. Philip Wadler ১৯৯৮ সালে নামটি দেন, যদিও সমস্যাটি তার আগেই পরিচিত ছিল। প্রশ্নটা হলো — এমন নকশা কি সম্ভব, যেখানে নতুন টাইপ আর নতুন কাজ দুটোই পুরোনো কোড না বদলে যোগ করা যায়, আর টাইপ-নিরাপত্তাও থাকে? সাধারণ object-oriented নকশা এক দিকে সহজ, sum type অন্য দিকে। তাই প্রশ্নটা “কোনটি ভালো” নয়, বরং “আপনার সমস্যায় কোন দিকটা বেশি বদলায়”।

variant-এর একটি বাড়তি সুবিধা value semantics: std::vector<Shape> লিখলে সব আকৃতি পাশাপাশি মেমরিতে থাকে, কপি করলে সত্যিকারের কপি হয়, কোনো unique_ptr লাগে না। দামটিও জেনে রাখুন: একটি ছোট টাইপ আর একটি বিশাল টাইপ একই variant-এ থাকলে প্রতিটি variant বিশালটির মাপ নেয়। তেমন হলে বড় টাইপটিকে std::unique_ptr-এ রাখুন, বা নকশা ভাবুন। দুটি পথই dynamic dispatch — চলার সময় টাইপ দেখে কোড বাছাই — শুধু টেবিলটি থাকে ভিন্ন জায়গায়।

৮ · std::any — “যেকোনো কিছু”, আর কেন প্রায়ই ভুল উত্তর

optional বলে “হয়তো একটি T”, variant বলে “এই তালিকার একটি”। std::any বলে “যেকোনো টাইপের একটি মান — কোনটি, তা আমি টাইপে বলব না”। এর ভেতরে মানটি ছাড়াও থাকে টাইপের তথ্য, আর পড়তে হয় std::any_cast দিয়ে, ঠিক কোন টাইপ আশা করছেন তা বলে দিয়ে:

#include <any>

std::any a = 42;                      // ভেতরে int
std::any_cast<int>(a);                // 42
std::any_cast<long>(a);               // throw std::bad_any_cast — int ≠ long!
if (auto* p = std::any_cast<int>(&a)) { /* pointer দিলে: ভুল টাইপে nullptr */ }

a = std::string("Dhaka");             // এখন string — any নিজেও টাইপ বদলাতে পারে
a = "Dhaka";                          // সাবধান: এটি const char*, string নয়
a.has_value();  a.reset();  a.type(); // type() একটি typeid তথ্য দেয়

লক্ষ করুন any_cast<long>: ভেতরে int থাকলে long চাইলেও exception — যদিও int সহজেই long-এ রূপান্তর হয়। any_cast টাইপ হুবহু মেলায়, কোনো রূপান্তর করে না। ভুল টাইপে ছোড়ে std::bad_any_cast. আর a = "Dhaka" রাখে একটি const char* — পরে any_cast<std::string> চাইলে আবার exception. এই দুটি ভুলই compile-এর সময় ধরা পড়ে না, কারণ any-র টাইপ থেকে compiler কিছুই জানে না।

any হলো type erasure-এর একটি উদাহরণ — আসল টাইপটি বাইরে থেকে মুছে ফেলা। এর দাম তিনটি। এক, টাইপ-যাচাই চলার সময়, তাই ভুল ধরা পড়ে চালানোর পর, compile-এর সময় নয়। দুই, বড় মান সাধারণত heap-এ রাখা হয় (ছোট মান library ভেতরেই রাখতে পারে — small buffer optimization), যা variant কখনো করে না। তিন, কোডটি নিজেই বলে না কোন কোন টাইপ আসতে পারে — পাঠককে পুরো প্রোগ্রাম খুঁজে বের করতে হয়। আর ভেতরে রাখা টাইপকে কপি করা যেতে হয় (copy-constructible), তাই move-only টাইপ সরাসরি রাখা যায় না।

এক অনুচ্ছেদে tuple আর structured binding

এই পর্বের টাইপগুলোকে পর্ব ১২-এর পরিচিত টাইপগুলোর পাশে রাখলে ছবিটি সম্পূর্ণ হয়। struct, std::pair আর std::tuple বলে “এটা এবং ওটা” — একসাথে সবগুলো মান থাকে (তত্ত্বের ভাষায় product type). variant বলে “এটা অথবা ওটা” (sum type), আর optional হলো “T অথবা কিছু না”। structured binding দিয়ে product type সহজে খোলা যায়: auto [ok, marks] = ...;. একসময় “হয়তো একটি মান” বোঝাতে অনেকে std::pair<bool, int> ফেরত দিতেন — কিন্তু তাতে ok-এর মান false হলেও marks-এ কিছু একটা থাকে, আর কেউ ভুল করে সেটি পড়তে পারে। optional সেই ফাঁক বন্ধ করেছে: মান না থাকলে পড়ার মতো কিছুই নেই। সংক্ষেপে: সবগুলো একসাথে হলে struct বা tuple, একটি মাত্র হলে variant, থাকতেও পারে না-ও পারে হলে optional.

৯ · AI-এর যুগে — “নেই” আর “এগুলোর একটি” ঠিকমতো লেখা হয়েছে কি না

AI টুলগুলো শিখেছে বিপুল পরিমাণ পুরোনো C আর C++ কোড থেকে, যেখানে optional বা variant ছিলই না। তাই না চাইলে তারা প্রায়ই সেই পুরোনো রীতিতে ফেরে: খুঁজে না পেলে -1, string না পেলে "", object না পেলে nullptr. আবার optional ব্যবহার করলেও প্রায়ই যাচাই ছাড়া *opt লেখে, কারণ ছোট উদাহরণে সেটি সংক্ষিপ্ত দেখায়। আর “নানা টাইপের ডেটা” শুনলেই কখনো কখনো std::any টেনে আনে, যেখানে variant অনেক ভালো হতো। সাধারণ ভুলগুলো:

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

• “না পাওয়া” বোঝাতে কোথাও -1, "", 0 বা nullptr ফেরত দেওয়া হয়নি — টাইপেই optional বা expected লেখা
• প্রতিটি *opt আর opt->-এর আগে যাচাই আছে, অথবা value_or/value() ব্যবহার হয়েছে
• variant-এর মান পড়া হয়েছে visit দিয়ে; একা std::get থাকলে তার আগে টাইপ যাচাই আছে
• visitor-এ catch-all auto lambda নেই, অথবা থাকলে তার পেছনে স্পষ্ট কারণ আছে
• std::any খুঁজেছি — প্রতিটির জন্য জিজ্ঞেস করেছি, টাইপের তালিকা কি আসলে জানা?
• নিজে variant-এ একটি নতুন টাইপ যোগ করে compile করেছি, আর দেখেছি compiler প্রতিটি অসম্পূর্ণ visit ধরিয়ে দিয়েছে