RAII ও smart pointer — মালিকানার নিয়ম

১ · সমস্যাটা আগে — যা ধার নেবেন, তা ফেরত দিতে হবে

আগের পর্বে আপনি new দিয়ে heap থেকে মেমরি নিয়েছেন আর delete দিয়ে ফেরত দিয়েছেন। সেখানেই দেখেছেন, ফেরত দিতে ভুলে গেলে কী হয়। কিন্তু মেমরি একমাত্র জিনিস নয়, যা প্রোগ্রাম ধার নেয়। খোলা ফাইল, ডেটাবেসের সংযোগ, নেটওয়ার্ক socket, একাধিক thread-এর মধ্যে ভাগ করা তালা (lock) — এ সবই সীমিত, আর সবই কাজ শেষে ফেরত দিতে হয়। এমন যেকোনো জিনিসকে বলে resource (রিসোর্স)।

আগে পুরোনো ব্যবস্থার সমস্যাটা কোডে দেখুন। একটি অনলাইন দোকানের অর্ডার প্রক্রিয়া করার ফাংশন — হাতে new আর delete দিয়ে লেখা:

void processOrder(int id) {
    Order* o = new Order(id);       // heap থেকে নেওয়া
    if (!o->valid()) return;        // ফাঁক ১: আগেভাগে ফেরা — delete হলো না
    o->charge();                    // ফাঁক ২: এখানে exception হলে? delete হলো না
    o->ship();
    delete o;                       // শুধু সব ঠিকঠাক চললেই এখানে পৌঁছায়
}

কোডটি দেখতে নিরীহ, কিন্তু এতে দুটি গর্ত। অর্ডার অবৈধ হলে ফাংশন আগেভাগে ফেরে, আর delete লাইনে কখনো পৌঁছায় না। আর charge() যদি কোনো exception ছোড়ে (ধরুন bKash-এর সার্ভারে সংযোগ পাওয়া গেল না) — exception ছোড়ার পর ফাংশনের বাকি অংশ আর চলে না, আবারও delete বাদ। প্রতিবার এমন হলে কিছু মেমরি চিরতরে আটকে যায় — একে বলে memory leak. দিনে লাখ অর্ডার হলে সার্ভারের মেমরি ধীরে ধীরে ভরে যায়, আর কয়েকদিন পর কেউ বুঝতে পারে না কেন সার্ভার রিস্টার্ট করতে হচ্ছে।

হাতে ঠিক করার চেষ্টা করলে প্রতিটি return-এর আগে delete বসাতে হয়, প্রতিটি সম্ভাব্য exception-এর চারপাশে try/catch দিতে হয়। ফাইল আর lock যোগ হলে প্রতিটি বের হওয়ার পথে তিনটি জিনিস মনে রাখতে হয়। ছয় মাস পর কেউ একটি নতুন return যোগ করলেন, আর ভুলে গেলেন — বাগ ফিরে এল। সমস্যাটা প্রোগ্রামারের অমনোযোগ নয়, পদ্ধতির। “মনে রেখে ফেরত দেওয়া” এমন একটি দায়িত্ব, যা মানুষ বড় কোডে নির্ভরযোগ্যভাবে পালন করতে পারে না।

২ · RAII — রিসোর্স বাঁধা থাকে object-এর জীবনের সাথে

C++-এ প্রতিটি class-এর দুটি বিশেষ ফাংশন থাকতে পারে। constructor চলে object তৈরির মুহূর্তে। destructor — নাম ~ চিহ্ন দিয়ে শুরু, যেমন ~Book() — চলে object-এর জীবন শেষ হওয়ার মুহূর্তে। পর্ব ২১-এ এ দুটি বিস্তারিত দেখবেন; আজ শুধু একটি কথা জরুরি: একটি local object-এর scope যেভাবেই শেষ হোক, compiler তার destructor ডাকবেই। স্বাভাবিকভাবে }-এ পৌঁছালে, মাঝপথে return করলে, লুপ থেকে break করলে, এমনকি exception উড়ে গেলেও।

এই নিশ্চয়তাকে কাজে লাগানোর কৌশলের নাম RAII — Resource Acquisition Is Initialization. নামটা খটমটে, কিন্তু ধারণা দুই লাইনের:

এবার লাইব্রেরির বইটিকেই একটি ছোট RAII class বানিয়ে দেখুন। constructor-এ “বই নিলাম” আর destructor-এ “বই ফেরত দিলাম” প্রিন্ট হবে, যাতে আপনি নিজের চোখে দেখেন destructor কখন চলে। study ফাংশনটি দুবার ডাকা হয় — একবার সব ঠিকঠাক, একবার মাঝপথে exception (লোডশেডিং!) সহ:

#include <print>
#include <stdexcept>
#include <string>

class Book {                        // RAII: constructor-e nei, destructor-e ferot
    std::string title;
public:
    explicit Book(const std::string& t) : title(t) { std::println("borrow : {}", title); }
    ~Book() { std::println("return : {}", title); }
};

void study(bool fail) {
    Book a("C++ Primer");
    Book b("Algorithms");
    if (fail) throw std::runtime_error("load-shedding");
    std::println("studying done");
}
int main() {
    study(false);
    try { study(true); }
    catch (const std::exception& e) { std::println("caught: {}", e.what()); }
}

দ্বিতীয় ডাকে ভেতরে ঠিক কী ঘটে, ধাপে ধাপে দেখুন। প্রতিটি ধাপে আগে নিজে অনুমান করুন, তারপর “পরে” চাপুন:

1void study() {2    Book a("C++ Primer");3    Book b("Algorithms");4    throw std::runtime_error("load-shedding");5    std::println("studying done");   // কখনো চলে না6}7try { study(); }8catch (const std::exception& e) { std::println("caught: {}", e.what()); }

৩ · RAII সবখানে — ফাইল, lock আর মেমরি

সুখবর হলো, বেশিরভাগ সময় RAII class আপনাকে নিজে লিখতে হয় না। C++-এর standard library-র প্রায় প্রতিটি রিসোর্স-ধরা টাইপ ইতিমধ্যে RAII. আপনি এগুলো ব্যবহার করে আসছেন, হয়তো খেয়াল না করেই।

ফাইল — std::ofstream

void saveReport(const std::string& text) {
    std::ofstream out("report.txt");    // constructor: ফাইল খোলে
    if (text.empty()) return;           // আগেভাগে ফেরা — তবু ফাইল বন্ধ হবে
    out << text;
}                                       // destructor: ফাইল বন্ধ করে

এখানে কোথাও close() নেই, দরকারও নেই। out-এর scope যেভাবেই শেষ হোক, তার destructor ফাইলের বাকি লেখা ডিস্কে পাঠিয়ে ফাইলটি বন্ধ করে। (ফাইল নিয়ে বিস্তারিত পর্ব ৪৪-এ।)

Lock — std::lock_guard (এক ঝলক)

একাধিক thread একসাথে একটি দোকানের মোট বিক্রির হিসাব বাড়ালে গোলমাল হয়, তাই একটি তালা লাগে — mutex. তালা লাগিয়ে খুলতে ভুলে গেলে বাকি সব thread চিরকাল দাঁড়িয়ে থাকে, যেন ঢাকার মোড়ে সিগন্যাল লাল হয়ে আটকে গেছে। RAII সমাধান std::lock_guard:

std::mutex m;
long long totalSales = 0;

void addSale(int taka) {
    std::lock_guard<std::mutex> lock(m);   // constructor: তালা লাগায়
    totalSales += taka;                     // এখানে exception হলেও...
}                                           // destructor: তালা খোলে

thread আর mutex-এর পুরো ব্যাখ্যা পর্ব ৪৫-এ। এখন শুধু নকশাটা দেখুন — একই ছাঁচ: তৈরিতে নেওয়া, ধ্বংসে ফেরত।

মেমরি — std::vector আর std::string

পর্ব ১৩-এর std::vector আর পর্ব ১৪-এর std::string দুটিই ভেতরে heap থেকে মেমরি নেয়। আপনি কখনো তাদের জন্য delete লেখেননি, কারণ তাদের destructor সেটা করে। vector হলো সবচেয়ে বেশি ব্যবহৃত RAII object. তাই heap-এ একসাথে অনেক জিনিস দরকার হলে প্রথম উত্তর সবসময় std::vector — আলাদা কিছু ভাবার আগে।

৪ · std::unique_ptr — একজনই মালিক

কখনো কখনো সত্যিই একটি একক object heap-এ রাখতে হয় — যেমন object-টি অনেক বড়, বা তার আসল টাইপ চলার সময় ঠিক হয় (পর্ব ২৫-এর polymorphism), বা সেটি থাকতেও পারে, না-ও থাকতে পারে। তখন new-এর বদলে আধুনিক C++-এর উত্তর একটি smart pointer — pointer-এর মতো ব্যবহার করা যায় এমন একটি RAII object, যে নিজের destructor-এ heap-এর object মুছে দেয়। সবচেয়ে সরল আর সবচেয়ে বেশি ব্যবহৃতটি হলো std::unique_ptr (<memory> header-এ)।

এর পেছনের ধারণাটির নাম ownership বা মালিকানা: কে এই রিসোর্স ফেরত দেওয়ার দায়িত্বে? unique_ptr-এর উত্তর — ঠিক একজন। একটি জমির দলিল যেমন একজনের নামে থাকে; বিক্রি করলে দলিল হাতবদল হয়, কিন্তু দুজনের হাতে একই দলিলের দুটি আসল কপি থাকতে পারে না।

#include <memory>

auto order = std::make_unique<Order>(1042);   // heap-এ Order, মালিক order
order->charge();                             // pointer-এর মতোই ব্যবহার
Order& o = *order;                           // * দিয়ে আসল object
// scope শেষে order-এর destructor → Order মুছে যায়। delete লাগে না।

std::make_unique (C++14 থেকে) heap-এ object বানিয়ে সরাসরি একটি unique_ptr ফেরত দেয়, তাই কোডে new শব্দটিই আসে না। আকারে আর গতিতে ডিফল্ট unique_ptr একটি সাধারণ raw pointer-এর মতোই — বাস্তব compiler-এ এর আকার একটি pointer-এর সমান, আর ব্যবহারে বাড়তি খরচ প্রায় শূন্য। নিরাপত্তা পাচ্ছেন, দাম দিচ্ছেন না।

কপি নিষেধ, move চলে

“একজনই মালিক” নিয়মটা compiler জোর করে চালায়। unique_ptr কপি করার চেষ্টা করলে compile error — কারণ কপি হলে দুজন মালিক হতো, আর দুজনেই একদিন delete করত (double delete, undefined behavior). কিন্তু মালিকানা হাতবদল করা যায়, std::move দিয়ে। std::move নিজে কিছু সরায় না; সে শুধু বলে “এই object-এর ভেতরের জিনিস নিয়ে যাওয়া যাবে” — বাকি গল্প পর্ব ৩৬-এ। এমন টাইপ, যা কপি হয় না কিন্তু move হয়, তাকে বলে move-only type. একটি অর্ডারের পার্সেল গুদাম থেকে কুরিয়ারের হাতে যাওয়ার পথ ধাপে ধাপে দেখুন:

1void ship(std::unique_ptr<Order> o) { /* ... */ }  // o মালিক হবে2auto order = std::make_unique<Order>(1042);3auto copy = order;                 // error4auto courier = std::move(order);5if (!order) std::println("order is empty");6ship(std::move(courier));7// ship() শেষ — o-এর scope শেষ

বাস্তব উদাহরণ — Order আর তার Item

একটি অর্ডারে কয়েকটি পণ্য (Item) আছে, আর অর্ডার মুছলে পণ্যের তালিকাও মুছে যাওয়া উচিত — এটি পরিষ্কার “একজন মালিক” সম্পর্ক। সবচেয়ে সরল রূপ std::vector<Item> — এখানে vector নিজেই মালিক, smart pointer লাগেই না। কিন্তু Item যদি নানা ধরনের হয় (ডিজিটাল পণ্য, ভারী পণ্য, ফ্রিজে রাখার পণ্য — পর্ব ২৫-এ দেখবেন কেন তখন pointer লাগে), তখন:

struct Order {
    int id;
    std::vector<std::unique_ptr<Item>> items;   // প্রতিটি Item-এর একমাত্র মালিক Order
};
order.items.push_back(std::make_unique<DigitalItem>("e-book"));
// Order ধ্বংস → vector ধ্বংস → প্রতিটি unique_ptr ধ্বংস → প্রতিটি Item মুছে যায়

খেয়াল করুন, Order-এ কোনো destructor লিখতে হয়নি। vector জানে তার উপাদানদের ধ্বংস করতে, আর প্রতিটি unique_ptr জানে তার Item মুছতে। RAII object-এর ভেতরে RAII object — দায়িত্ব নিজে থেকে শিকলের মতো নেমে যায়।

৫ · unique_ptr ফাংশনে পাঠানো — মালিকানা দেবেন, না শুধু ব্যবহার করতে দেবেন?

নতুনদের সবচেয়ে বড় বিভ্রান্তি এখানেই: “আমার কাছে unique_ptr আছে, তাই ফাংশনও unique_ptr নেবে।” না। প্রশ্ন একটাই — ফাংশনটি কি মালিকানা নিয়ে কিছু করবে, নাকি শুধু object-টি ব্যবহার করবে? বেশিরভাগ ফাংশন শুধু ব্যবহার করে, আর তাদের smart pointer-এর কথা জানারই দরকার নেই।

প্রথম তিনটি সারি সবচেয়ে বেশি দরকার পড়ে। print(const Order&) ফাংশনটি এখন যেকোনো Order নিতে পারে — stack-এর হোক, vector-এর ভেতরের হোক, unique_ptr-এর হোক, shared_ptr-এর হোক। এটি পর্ব ১০-এর reference-এর পুরোনো শিক্ষা: শুধু ব্যবহারের জন্য T& বা const T&. আর get() ফেরত দেয় ভেতরের raw pointer — শুধু দেখার জন্য, মালিকানা ছাড়া। আধুনিক C++-এ raw pointer মানে “আমি মালিক নই” — তাই get()-এর pointer কখনো delete করবেন না।

৬ · std::shared_ptr — ভাগাভাগির মালিকানা

কিছু ক্ষেত্রে একজন মালিক যথেষ্ট নয়। ধরুন একটি অনলাইন অফিস অ্যাপে একটি ডকুমেন্ট দুজন সম্পাদক একসাথে খুলেছেন — রিনা আর সাকিব। দুজনের জানালাই ডকুমেন্টটি ধরে আছে। রিনা জানালা বন্ধ করলে ডকুমেন্ট মোছা যাবে না, কারণ সাকিব এখনো কাজ করছেন। কে আগে বন্ধ করবেন, আগে থেকে জানা নেই। শেষজন বন্ধ করলেই ডকুমেন্টটি মেমরি থেকে সরানো উচিত।

এর জন্য std::shared_ptr. এটি reference counting ব্যবহার করে: পেছনে একটি সংখ্যা রাখে — এই মুহূর্তে কতজন shared_ptr এই object-এর মালিক। shared_ptr কপি করলে সংখ্যা বাড়ে, একটি ধ্বংস হলে কমে, আর শূন্যে নামলে object মুছে যায়। সংখ্যাটি দেখা যায় use_count() দিয়ে। পুরো জীবনচক্রটি দেখুন:

1auto doc = std::make_shared<Doc>("report");2{   auto sakib = doc;              // কপি3    std::println("{}", doc.use_count());4}                                  // sakib ধ্বংস5doc.reset();                       // শেষ মালিক চলে গেল

shared_ptr-এর দাম

এই সুবিধা বিনামূল্যে আসে না, আর সেটা জানা জরুরি:

• আকার দ্বিগুণ। একটি shared_ptr বাস্তব compiler-গুলোতে সাধারণত দুটি pointer-এর সমান — একটি object-এর দিকে, একটি control block-এর দিকে।
• বাড়তি বরাদ্দ। control block-এর জন্য heap-এ জায়গা লাগে। make_shared object আর control block একবারে বরাদ্দ করে এটা কমায়; std::shared_ptr<Doc>(new Doc(...)) লিখলে দুবার বরাদ্দ হয়।
• প্রতিটি কপিতে atomic গোনা। যেকোনো thread থেকে নিরাপদে কপি করা যায় বলে সংখ্যাটি বাড়ানো-কমানো হয় atomic নির্দেশ দিয়ে — সাধারণ যোগের চেয়ে বেশ ধীর, বিশেষ করে অনেক CPU core একই সংখ্যায় হাত দিলে। তাই shared_ptr অকারণে by value পাঠালে প্রতিটি ডাকেই এই খরচ।
• কে কখন মোছে, তা অস্পষ্ট। unique_ptr-এ এক নজরে দেখা যায় object কোথায় মরবে। shared_ptr-এ object বাঁচে “যতক্ষণ কেউ ধরে আছে” — আর বড় প্রোগ্রামে সেই “কেউ” খুঁজে পাওয়া কঠিন।

এবার দুই ধরনের মালিকানা একসাথে চালিয়ে দেখুন। destructor-এ close প্রিন্ট হয়, তাই আপনি দেখবেন কোন object ঠিক কখন মুছছে:

#include <memory>
#include <print>
#include <string>
#include <utility>

struct Doc {
    std::string name;
    explicit Doc(const std::string& n) : name(n) { std::println("open  {}", name); }
    ~Doc() { std::println("close {}", name); }
};

int main() {
    auto a = std::make_unique<Doc>("invoice");
    auto b = std::move(a);                         // malikana a theke b-te
    std::println("a empty? {}", a == nullptr);
    auto s1 = std::make_shared<Doc>("report");
    { auto s2 = s1; std::println("count = {}", s1.use_count()); }
    std::println("count = {}", s1.use_count());
    std::weak_ptr<Doc> w = s1;                    // dekhe, malik hoy na
    s1.reset();                                    // count 0 -> close report
    std::println("expired? {}", w.expired());
}

৭ · std::weak_ptr — দেখে, কিন্তু মালিক হয় না

shared_ptr-এর একটি অন্ধ জায়গা আছে। ধরুন একটি ই-কমার্স সাইটের মেনুতে ক্যাটাগরি গাছের মতো সাজানো: “ইলেকট্রনিক্স” (parent)-এর নিচে “মোবাইল” (child). parent তার child-কে ধরে রাখে, আর child-কেও জানতে হয় তার parent কে (“পেছনে যান” বোতামের জন্য)। দুই দিকেই shared_ptr দিলে কী হয়?

local p  ──>  [ Parent  count = 1 ]
local c  ──>  [ Child   count = 1 ]

local p  ──>  [ Parent  count = 1 ]
                    │ child (shared_ptr)
                    ▼
local c  ──>  [ Child   count = 2 ]

local p  ──>  [ Parent  count = 2 ]  ◄──┐
                    │ child           │ parent (shared_ptr)
                    ▼                 │
local c  ──>  [ Child   count = 2 ]  ──┘

local p  (নেই)      [ Parent  count = 1 ]  ◄──┐
                    │ child           │ parent
                    ▼                 │
local c  (নেই)      [ Child   count = 1 ]  ──┘
বাইরের কেউ এদের ছুঁতে পারে না, destructor কখনো চলবে না → memory leak

local p  (নেই)      [ Parent  count = 0 ]  → মুছে গেল
                    │ child           ┊ parent (weak — গোনে না)
                    ▼                 ┊
local c  (নেই)      [ Child   count = 0 ]  → তারপর এটিও মুছে গেল

weak_ptr দিয়ে সরাসরি object ব্যবহার করা যায় না, কারণ সে জানে না object এখনো বেঁচে আছে কি না। ব্যবহারের আগে lock() ডাকতে হয়: object থাকলে সে একটি নতুন shared_ptr ফেরত দেয় (ব্যবহারের সময়টুকু object বাঁচিয়ে রাখতে), না থাকলে খালি shared_ptr.

struct Child {
    std::weak_ptr<Parent> parent;               // দেখে, মালিক নয়
    void goBack() {
        if (auto p = parent.lock()) p->show();  // বেঁচে থাকলে ব্যবহার
        else std::println("parent আর নেই");
    }
};

বাস্তব উদাহরণ — যে cache শুধু নজর রাখে

একটি ছবি-দেখার অ্যাপ বড় ছবিগুলো মেমরিতে রাখে। একই ছবি দুটি জানালায় খোলা থাকলে দুবার লোড করার মানে নেই — তাই একটি cache থাকে, যা নাম দিয়ে ছবি খুঁজে দেয়। কিন্তু cache যদি shared_ptr দিয়ে ছবিগুলো ধরে রাখে, তাহলে কেউ না দেখলেও কোনো ছবি কখনো মুছবে না — cache নিজেই মেমরি খেয়ে ফেলবে। সমাধান: cache রাখবে weak_ptr.

std::unordered_map<std::string, std::weak_ptr<Image>> cache;   // পর্ব ৩১-এ map

std::shared_ptr<Image> getImage(const std::string& name) {
    if (auto img = cache[name].lock()) return img;        // কেউ এখনো দেখছে — একই ছবি
    auto img = std::make_shared<Image>(name);             // নেই — নতুন করে লোড
    cache[name] = img;                                    // cache শুধু নজর রাখে
    return img;
}

যতক্ষণ কোনো জানালা ছবিটি ধরে আছে, cache একই ছবি ফেরত দেয়। সব জানালা বন্ধ হলে ছবি মুছে যায়, আর cache-এর weak_ptr নিজে থেকেই “expired” হয়ে যায় — পরের বার নতুন করে লোড হবে। মালিক জানালাগুলো; cache শুধু খাতায় নাম লিখে রাখে।

৮ · Custom deleter আর মালিকানার নিয়ম-সারাংশ

অনেক পুরোনো বা C লাইব্রেরি — ফাইলের FILE*, ডেটাবেস, গ্রাফিক্স — নিজের “খোলা” আর “বন্ধ” ফাংশন দেয়। এদের ফেরত delete দিয়ে হয় না। unique_ptr-কে বলে দেওয়া যায় কীভাবে ফেরত দিতে হবে — একে বলে custom deleter:

struct FileCloser {
    void operator()(std::FILE* f) const { std::fclose(f); }   // delete-এর বদলে fclose
};
using FilePtr = std::unique_ptr<std::FILE, FileCloser>;

FilePtr log{std::fopen("sales.log", "a")};
if (log) std::fputs("new sale\n", log.get());
// scope শেষে নিজে থেকেই fclose — আর fopen ব্যর্থ হলে (nullptr) কিছুই ডাকা হয় না

খালি (nullptr) unique_ptr-এর জন্য deleter ডাকা হয় না, তাই fclose(nullptr)-এর বিপদও নেই। এভাবে যেকোনো C API-কে দুই লাইনে RAII বানানো যায়। shared_ptr-ও deleter নেয় (std::shared_ptr<std::FILE> f(std::fopen(...), FileCloser{});), পার্থক্য হলো সেখানে deleter টাইপের অংশ নয়, control block-এ জমা থাকে।

মালিকানার নিয়ম — এক পাতায়

এর ফল একটি সুন্দর নকশা-নীতি, যাকে বলে Rule of Zero: আপনার নিজের class-এ destructor, copy বা move নিজে লিখবেন না; রিসোর্স রাখুন vector, string, unique_ptr-এর মতো RAII সদস্যে — তারা নিজেরাই সব ঠিকঠাক করবে। উপরের Order struct ঠিক তাই করেছে। কেন এটি “শূন্যের নিয়ম”, আর কখন ৩ বা ৫টি ফাংশন নিজে লিখতে হয়, তা পর্ব ২২-এ।

৯ · AI-এর যুগে — smart pointer-এর ভুল ধরা

AI টুল smart pointer ব্যবহার করে ঠিকই, কিন্তু প্রায়ই ভুল জায়গায় বা ভুল ভাবে। কারণ অনলাইনে প্রচুর কোড আছে যেখানে “নিরাপদ থাকতে সবখানে shared_ptr” লেখা হয়েছে, বা C++11-এর আগের রীতিতে লেখা। এই কোড compile হয়, চলেও — সমস্যা দেখা দেয় ধীরগতি, leak বা অস্পষ্ট নকশা হিসেবে। সাধারণ ভুলগুলো:

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

• কোডে new বা delete খুঁজেছি — পেলে কারণ জিজ্ঞেস করেছি (প্রায় সবসময় make_unique/make_shared বা vector দিয়ে বদলানো যায়)
• প্রতিটি shared_ptr-এর জন্য বলতে পারি: কোন কোন অংশ একে বাঁচিয়ে রাখে, আর কেন একজন মালিক যথেষ্ট নয়
• দুই দিকে যাওয়া প্রতিটি সম্পর্কে (parent ↔ child, observer) অন্তত একদিক weak_ptr বা raw pointer
• যে ফাংশন শুধু ব্যবহার করে, তার প্যারামিটার T&/const T&/T* — smart pointer by value নয়
• destructor-এ প্রিন্ট বসিয়ে চালিয়ে দেখেছি: প্রতিটি object-এর destructor ঠিক একবার চলে, আর প্রোগ্রাম শেষের আগে কেউ বাদ পড়েনি
• সন্দেহ হলে -fsanitize=address দিয়ে চালিয়েছি — Linux-এ এটি leak-ও রিপোর্ট করে