lifetime — কে কতক্ষণ বাঁচে, dangling কেন বিপদ

১ · প্রতিটি object-এর জন্ম আছে, মৃত্যুও আছে

পর্ব ১০-এ আপনি একটি নিয়ম শিখেছিলেন: “reference কখনো তার object-এর চেয়ে বেশি দিন বাঁচবে না।” আর পর্ব ১৫ থেকে ১৭-এ দেখেছেন pointer, heap আর smart pointer. এই পর্বে সেই সব টুকরো এক জায়গায় জোড়া লাগবে, একটি মাত্র প্রশ্নকে ঘিরে: এই object-টি কখন জন্মায়, আর কখন মরে? এই সময়কালের নাম lifetime — বাংলায় আয়ু।

C++-এর প্রতিটি object — একটি int, একটি std::string, একটি Student — মেমরির কোনো এক জায়গায় থাকে। তার আয়ু শুরু হয় যখন জায়গাটি পাওয়া যায় আর object-টি তৈরি (initialize) হয়। আয়ু শেষ হয় যখন object-টি ধ্বংস হয়: class টাইপ হলে তার destructor চলে, তারপর জায়গাটি অন্য কাজে ফেরত যায়। এর পরে সেই জায়গার দিকে যা কিছু “তাকিয়ে” আছে — reference, pointer, iterator, string_view — সব হয়ে যায় অর্থহীন। এগুলো দিয়ে পড়া বা লেখাকে standard বলে undefined behavior: ফল যা খুশি হতে পারে।

Scope আর lifetime — দুটি আলাদা প্রশ্ন

নতুনরা প্রায়ই দুটি ধারণা গুলিয়ে ফেলেন। Scope হলো কোডের কোন অংশে একটি নাম চেনা যায় — এটি compile-এর সময়ের, লেখার প্রশ্ন। Lifetime হলো প্রোগ্রাম চলার সময় object-টি কখন থেকে কখন পর্যন্ত মেমরিতে আছে — এটি সময়ের প্রশ্ন। সাধারণ local ভ্যারিয়েবলে দুটি প্রায় মিলে যায়: block শেষে নামটিও হারায়, object-ও মরে। কিন্তু সব ক্ষেত্রে মেলে না। একটি pointer-এর নাম হয়তো এখনো scope-এ আছে, অথচ যে object-এর দিকে সে তাকিয়ে আছে, সেটি অনেক আগেই মরে গেছে। এই ফাঁকেই বাগ জন্মায়। নিচের ছবিতে একটি object-এর পুরো জীবন দেখুন:

1const Student* p = nullptr;2{3    Student s{"Rahim", 70};4    p = &s;5}                       // s-এর আয়ু শেষ6std::println("{}", p->name);   // UB

২ · চার রকম আয়ু — storage duration

কোন object কতক্ষণ বাঁচবে, তা মূলত ঠিক হয় সে কোথায় আর কীভাবে তৈরি হলো তার ওপর। C++ standard একে বলে storage duration, আর এর চারটি রূপ আছে:

Static local — যে ভ্যারিয়েবল ফাংশন শেষেও মরে না

ফাংশনের ভেতরে static লিখলে একটি মজার মিশ্রণ পাওয়া যায়। নামটির scope শুধু ফাংশনের ভেতরে, কিন্তু আয়ু পুরো প্রোগ্রামের। একে বলে static local. প্রথমবার ফাংশন ডাকার সময় এটি তৈরি হয়, পরের ডাকগুলোতে আগের মান মনে রাখে। ধরুন একটি টোকেন মেশিন, যা ব্যাংকের কাউন্টারে প্রতিবার পরের নম্বর দেয়:

int nextToken() {
    static int last = 0;     // একবারই তৈরি, প্রোগ্রাম শেষ পর্যন্ত বাঁচে
    return ++last;           // 1, 2, 3, ...
}

এর একটি লাভ lifetime-এর দিক থেকেও আছে: static local-এর reference ফেরত দেওয়া নিরাপদ, কারণ ফাংশন শেষ হলেও object-টি মরে না। C++11 থেকে standard নিশ্চয়তা দেয় যে একাধিক thread একসাথে প্রথমবার ফাংশনটি ডাকলেও static local ঠিক একবারই তৈরি হবে। তবে মনে রাখবেন, এটি আসলে একটি লুকোনো global — বেশি ব্যবহারে প্রোগ্রাম বোঝা আর পরীক্ষা করা কঠিন হয়।

Dynamic মানে “কেউ একজনের দায়িত্বে”

পর্ব ১৬-এ দেখেছেন, new দিয়ে বানানো object-এর আয়ু কোনো block-এর সাথে বাঁধা নয়। এটা শক্তি, আবার বিপদও। পর্ব ১৭-এর মূল কথা ছিল RAII: heap-এর object-কে একটি automatic object-এর হাতে তুলে দিন — যেমন std::unique_ptr — যাতে মালিক মরলে object-ও মরে। এভাবে dynamic আয়ুকেও একটি block-এর আয়ুর সাথে বেঁধে ফেলা যায়। একে বলে ownership বা মালিকানা। এই পর্বের প্রতিটি নিরাপদ সমাধানের পেছনে একই প্রশ্ন: ডেটাটির মালিক কে, আর সে কতক্ষণ বাঁচে?

৩ · নিজের চোখে আয়ু দেখা — constructor আর destructor-এর বার্তা

আয়ু চোখে দেখা যায় না — যদি না object নিজে জন্ম আর মৃত্যুর সময় একটি বার্তা ছাপে। Constructor (জন্মের মুহূর্তে চলা ফাংশন) আর destructor (মৃত্যুর মুহূর্তে চলা ফাংশন) পর্ব ২১-এ বিস্তারিত শিখবেন। এখন শুধু এটুকু জানুন: Tracer(...) জন্মের সময় চলে, ~Tracer() মৃত্যুর সময়। নিচের প্রোগ্রামে চার রকম আয়ু আর একটি temporary একসাথে আছে। চালানোর আগে অনুমান করুন — কোন লাইনের পরে কোনটি মরবে?

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

struct Tracer {
    std::string name;
    Tracer(std::string n) : name(n) { std::println("  born : {}", name); }
    ~Tracer() { std::println("  dies : {}", name); }
};
Tracer make(std::string n) { return Tracer(n); }
Tracer office("global");                         // static: puro program

int main() {
    std::println("main starts");
    { Tracer a("block"); }                       // automatic: block-er sheshe
    auto owner = std::make_unique<Tracer>("heap"); // dynamic: owner-er hate
    std::println("  using {}", make("temp").name); // temporary: ';'-e mrittu
    const Tracer& kept = make("extended");       // const&: ayu bare
    owner.reset();                               // malik chhere dilo
    std::println("main ends, kept = {}", kept.name);
}

৪ · Temporary — সেমিকোলনেই যার মৃত্যু

উপরের temp একটি নাম-ছাড়া অস্থায়ী object — temporary. a + b-এর ফল, by value ফেরত দেওয়া কোনো string, std::string("Dhaka") — সবই temporary. এদের আয়ুর নিয়ম সরল: যে full-expression-এ তৈরি, তার শেষেই মৃত্যু। Full-expression মানে মোটামুটি পুরো statement, সেমিকোলন পর্যন্ত। তাই একই লাইনের ভেতরে temporary নিরাপদে ব্যবহার করা যায় — std::println("{}", make("temp").name) ঠিক আছে। সমস্যা শুরু হয় যখন লাইন পেরিয়ে temporary-র দিকে কেউ তাকিয়ে থাকে।

Lifetime extension — মনে করিয়ে দেওয়া, আর তার সীমা

পর্ব ১০-এ আপনি lifetime extension-এর নিয়ম দেখেছেন: temporary সরাসরি একটি local const T& (বা T&&)-এ bind হলে, সে reference-এর সমান দিন বাঁচে। আর দেখেছেন std::max(3, 7)-এর ফাঁদ — মাঝখানে ফাংশন থাকলে নিয়মটি খাটে না। এখানে শুধু সীমাগুলো একটি তালিকায় রাখি:

শেষ লাইনটি নতুন আর সবচেয়ে প্রতারক। পর্ব ১৪-এ দেখেছেন, std::string_view একটি হালকা “জানালা”: অন্য কারও লেখার শুরুর ঠিকানা আর দৈর্ঘ্য রাখে, নিজে কোনো লেখার মালিক নয়। এমন টাইপকে বলে view. Reference-এর জন্য language-এ বিশেষ আয়ু-বাড়ানোর নিয়ম আছে, view-এর জন্য নেই। একটি দোকানের রসিদ দিয়ে ধাপে ধাপে দেখুন:

1std::string receipt(int tk) { return "Total amount: " + std::to_string(tk) + " Taka"; }2std::string_view v = receipt(450);3std::println("{}", v);         // UB4std::string r = receipt(450);5std::string_view ok = r;6std::println("{}", ok);        // ঠিক আছে

৫ · Dangling-এর তালিকা — পাঁচটি চেনা রূপ

বাস্তব কোডে dangling প্রায় সবসময় এই পাঁচটি রূপের কোনো একটিতে আসে। প্রতিটির একটি ছোট উদাহরণ দেখুন। এগুলো চালানোর জন্য নয় — ভুল কোড চালিয়ে “দেখি কী হয়” পদ্ধতি এখানে কাজ করে না, কারণ undefined behavior আজ ঠিক ফল দেখিয়ে কাল ভেঙে যেতে পারে।

রূপ ১ — local-এর বা temporary-র reference ফেরত

পর্ব ১০-এ local ভ্যারিয়েবলের reference ফেরত দেওয়ার ভুলটি দেখেছেন। এর একটি সূক্ষ্ম আত্মীয় আছে, যেখানে ফাংশনটি নিজে একদম ঠিক, ভুল হয় ডাকার জায়গায়। ধরুন একটি ফাংশন নামের তালিকা থেকে সবচেয়ে লম্বা নামটি reference হিসেবে ফেরত দেয়:

const std::string& longestName(const std::vector<std::string>& names);  // তালিকার ভেতরের নাম ফেরত

const std::string& a = longestName(students);       // ঠিক: students বেঁচে আছে
const std::string& b = longestName(loadNames());    // ভুল: temporary তালিকা ';'-এ মরে
std::println("{}", b);                              // dangling — heap-use-after-free

loadNames() একটি temporary vector ফেরত দেয়। longestName সেই temporary-র ভেতরের একটি string-এর reference ফেরত দেয়। লাইন শেষে temporary vector মরে, সাথে তার সব নামও — আর b হয়ে যায় একটি dangling reference. ফাংশনটি একই, ব্যবহারে পার্থক্য। GCC 13 থেকে -Wall-এর অংশ -Wdangling-reference ঠিক এই ধাঁচটি ধরতে চেষ্টা করে।

রূপ ২ — view, যার মালিক বদলে গেছে বা মরে গেছে

অংশ ৪-এ temporary-র ওপর string_view দেখেছেন। এবার আরও চতুর রূপ: মালিক বেঁচে আছে, কিন্তু বদলে গেছে। একটি মুদি দোকানের সফটওয়্যার রসিদ বানায়, আর মোট টাকার অংশটি একটি view দিয়ে আলাদা করে রাখে। পরে গ্রাহক আরেকটি জিনিস কিনলেন, রসিদ নতুন করে বানানো হলো:

std::string receipt = buildReceipt(items);            // "...Total: 450 Tk"
std::string_view total = findTotal(receipt);          // receipt-এর ভেতরের একটি অংশ
items.push_back({"Egg", 120});
receipt = buildReceipt(items);                        // নতুন লেখা, হয়তো নতুন মেমরি
std::println("SMS: {}", total);                       // dangling — পুরোনো মেমরি

receipt নতুন লেখা পেলে তার ভেতরের অক্ষরের মেমরি বদলে যেতে পারে — পুরোনোটি ফেরত যায়। total জানে শুধু পুরোনো ঠিকানা। ফলে গ্রাহকের কাছে SMS-এ আবর্জনা যেতে পারে, অথবা পুরোনো মোট টাকা — যা আরও খারাপ, কারণ কেউ টেরই পাবে না। একই কথা std::span (C++20) আর c_str()-এর ফেরত দেওয়া pointer-এর জন্যও খাটে: মালিককে বদলালে বা মারলে তার সব view অবৈধ।

রূপ ৩ — vector বড় হলে পুরোনো reference

এটি এত প্রচলিত যে এর জন্য পুরো অংশ ৬ রাখা হয়েছে। সংক্ষেপে: push_back-এ জায়গা ফুরালে vector নতুন মেমরিতে সরে যায়, আর আগের সব reference, pointer, iterator অবৈধ হয়ে যায়।

রূপ ৪ — lambda, যে local-কে reference দিয়ে ধরেছে

Lambda হলো কোডের মাঝে লেখা নাম-ছাড়া ছোট ফাংশন, পর্ব ৩৪-এ বিস্তারিত। Lambda বাইরের ভ্যারিয়েবল “ধরে” (capture) রাখতে পারে — কপি করে [x], অথবা reference দিয়ে [&x]. Reference দিয়ে ধরা lambda যদি সেই ভ্যারিয়েবলের চেয়ে বেশি দিন বাঁচে, তাহলে কী হয়, ধাপে ধাপে দেখুন। (std::function এখানে শুধু lambda রাখার একটি বাক্স।)

1std::function<int()> makeCounter() {2    int count = 0;3    return [&count] { return ++count; };4}5auto next = makeCounter();6next();                      // UB7// ঠিক: [count]() mutable { return ++count; }

রূপ ৫ — unique_ptr-এর মালিকানা গেছে, raw pointer রয়ে গেছে

পর্ব ১৭-এ দেখেছেন, p.get() একটি সাধারণ (raw) pointer দেয়, মালিকানা দেয় না। মালিক যদি object ছেড়ে দেয়, raw pointer সেটা জানতে পারে না:

auto order = std::make_unique<Order>(1042);
Order* view = order.get();     // শুধু দেখার জন্য — মালিক নয়
order.reset();                 // মালিক object-টিকে delete করল
std::println("{}", view->id);  // dangling — heap-use-after-free

এই ভুল কোডে খুব কমই এমন পাশাপাশি থাকে। সাধারণত get() হয় এক ফাইলে, reset() বা মালিকের মৃত্যু হয় আরেক ফাইলে, অনেক পরে। তাই নিয়ম: raw pointer বা reference শুধু অল্প সময়ের জন্য নিন — একটি ফাংশন ডাকের ভেতরে — আর কখনো এমন জায়গায় জমিয়ে রাখবেন না, যা মালিকের চেয়ে বেশি দিন বাঁচতে পারে। এটি use-after-free-এর সবচেয়ে পরিচিত পথ, আর নিরাপত্তা-গবেষকদের কাছে খুব দামি একটি ভুল (ভাবনার প্রশ্ন ০১)।

৬ · Vector বড় হলে — reference আর iterator-এর হঠাৎ মৃত্যু

পর্ব ১৩-এ দেখেছেন, std::vector উপাদানগুলো মেমরিতে পাশাপাশি রাখে, আর আগে থেকেই কিছু বাড়তি জায়গা নিয়ে রাখে। কয়টি উপাদান রাখা যায়, তা হলো capacity; কয়টি আছে, তা size. যতক্ষণ size < capacity, push_back শুধু পরের খালি ঘরে লেখে। কিন্তু জায়গা ফুরালে vector-কে নতুন, বড় একটি মেমরি নিতে হয়, পুরোনো উপাদানগুলো সেখানে সরাতে হয়, আর পুরোনো মেমরি ফেরত দিতে হয়। একে বলে reallocation. ঠিক এই মুহূর্তে কী ভাঙে, দেখুন:

@1000  [ 70 ][ 58 ]     <- ঘর ভর্তি, আর জায়গা নেই

@1000  [ 70 ][ 58 ]
         ^
       first   <- @1000-এর নাম

@1000  [ 70 ][ 58 ]                 <- পুরোনো
@2000  [ 70 ][ 58 ][ 91 ][    ]     <- নতুন, capacity 4

@1000  [ ?? ][ ?? ]   (ফেরত দেওয়া)
         ^
       first   <- dangling!
@2000  [ 70 ][ 58 ][ 91 ][    ]  <- marks এখানে

@1000  [ 75? ][ ?? ]   (অন্য কারও জায়গা হতে পারে)
@2000  [ 70 ][ 58 ][ 91 ][    ]  <- আসল নম্বর বদলায়নি!
ASan: heap-use-after-free

@2000  [ 75 ][ 58 ][ 91 ][    ]
         ^
     marks[0]  <- প্রতিবার নতুন করে খোঁজা

এই ভুলের সবচেয়ে চেনা রূপটি লুকিয়ে থাকে লুপে: for (auto& s : students) if (...) students.push_back(...); — range-for-এর ভেতরে আসলে iterator চলছে, আর push_back সেটিকে অবৈধ করে দিতে পারে। আগে থেকে কয়টি উপাদান লাগবে জানা থাকলে marks.reserve(n) দিয়ে জায়গা নিয়ে রাখলে তখন আর reallocation হয় না — কিন্তু সেটা পারফরম্যান্সের কৌশল, নিরাপত্তার নিশ্চয়তা হিসেবে এর ওপর ভরসা করবেন না। কোন container-এর কোন কাজে কী অবৈধ হয়, তার পুরো তালিকা পর্ব ৩০ আর ৩২-এ দেখবেন।

৭ · কীভাবে এড়াবেন — চারটি নকশা-নিয়ম

সুখবর হলো, প্রায় সব dangling এড়ানো যায় চারটি সরল অভ্যাসে। এগুলো আলাদা আলাদা কৌশল নয় — একটিই নীতির চার রূপ: পর্যবেক্ষক কম রাখুন, মালিক বেশি রাখুন।

By value ফেরত — কপির ভয় কেন অমূলক

অনেকে reference ফেরত দেন এই ভয়ে যে বড় string বা vector ফেরত দিলে পুরোটা কপি হবে। আধুনিক C++-এ এই ভয় প্রায় অমূলক। প্রথমত, copy elision: compiler ফেরত দেওয়া object-কে সরাসরি ডাকার জায়গার ভ্যারিয়েবলেই তৈরি করে — একে বলে RVO. C++17 থেকে return Tracer(n);-এর মতো নাম-ছাড়া object ফেরত দিলে এটি বাধ্যতামূলক — অংশ ৩-এর প্রোগ্রামে বাড়তি কোনো born লাইন না দেখার কারণ এটাই। দ্বিতীয়ত, নাম-ওয়ালা local (return best;) ফেরত দিলেও compiler প্রায় সবসময় কপি বাদ দেয়, আর না পারলেও কপির বদলে move করে — অর্থাৎ শুধু ভেতরের মেমরির মালিকানা হাতবদল, যা প্রায় বিনা খরচে হয় (পর্ব ৩৬)। নিচের প্রোগ্রামে অংশ ৫-এর “সবচেয়ে লম্বা নাম” আর অংশ ৬-এর vector — দুটির নিরাপদ রূপ:

#include <print>
#include <string>
#include <vector>

std::string longestName(const std::vector<std::string>& names) {  // by value ferot
    std::string best;
    for (const auto& s : names) if (s.size() > best.size()) best = s;
    return best;
}
int main() {
    std::string top = longestName({"Rahim", "Nusrat Jahan", "Karim"}); // temporary list mrituk
    std::println("longest: {}", top);
    std::vector<int> marks{70, 58};
    std::size_t idx = 0, moves = 0;                 // reference noy, index
    for (int i = 0; i < 100; ++i) {
        auto old = marks.capacity();
        marks.push_back(i);
        if (marks.capacity() != old) ++moves;       // notun memory-te shorlo
    }
    marks[idx] += 5;
    std::println("first = {}, size = {}, moved {} times", marks[idx], marks.size(), moves);
}

View রাখার নিয়ম

তার মানে কি string_view খারাপ? একদম না। void printLine(std::string_view s) — এমন প্যারামিটারে এটি std::string, "লেখা" বা অন্য কোনো লেখার টুকরো, সবই কপি ছাড়া নিতে পারে, আর ফাংশন চলার পুরো সময় ডাকার জায়গার মালিক বেঁচে থাকে। বিপদ তখনই, যখন view মালিককে ছাড়িয়ে বাঁচে: struct-এর member হিসেবে, ফেরতের টাইপ হিসেবে, বা কোনো container-এ জমিয়ে রাখলে। এমন কিছু সত্যিই দরকার হলে (যেমন বড় একটি ফাইলের টুকরোগুলোর দিকে view, যেখানে ফাইলটি পুরো সময় বেঁচে থাকে) কোডে মন্তব্য লিখে স্পষ্ট করুন — “এই view-এর মালিক fileText, যা Parser-এর চেয়ে বেশি দিন বাঁচে।”

৮ · টুল দিয়ে ধরা — warning, AddressSanitizer আর lifetime-এর ভবিষ্যৎ

মানুষের চোখ সব dangling ধরতে পারে না, তাই টুলের সাহায্য নিন। তিনটি স্তর আছে — compile-এর সময়, চলার সময়, আর নকশার নিয়মে।

স্তর ১ — compiler-এর সতর্কবার্তা

সবসময় -Wall -Wextra দিয়ে compile করুন। GCC-র -Wreturn-local-addr (ডিফল্টভাবেই চালু) local-এর ঠিকানা বা reference ফেরত দিলে সতর্ক করে। GCC 13 থেকে -Wdangling-reference (-Wall-এর অংশ) অংশ ৫-এর longestName(loadNames())-এর মতো ধাঁচ ধরার চেষ্টা করে, আর GCC 12 থেকে আছে -Wdangling-pointer. Clang-এর -Wdangling পরিবারের সতর্কবার্তা temporary-র ওপর string_view-এর মতো কিছু ক্ষেত্র ধরে। তবে এগুলোর কোনোটিই সব ধরতে পারে না, আর কিছু ক্ষেত্রে ভুল সতর্কবার্তাও দেয় — কেন, তা ভাবনার প্রশ্ন ০৩-এ।

স্তর ২ — AddressSanitizer: চলার সময় হাতেনাতে ধরা

পর্ব ০৩-এ sanitizer-এর নাম শুনেছেন। Lifetime-এর বাগের জন্য সবচেয়ে কাজের হলো AddressSanitizer (ASan). এটি প্রোগ্রামের প্রতিটি মেমরি-ব্যবহারের পাশে পাহারা বসায়, আর মৃত বা ফেরত দেওয়া মেমরি ছুঁলেই প্রোগ্রাম থামিয়ে বিস্তারিত রিপোর্ট দেয়। নিজের কম্পিউটারে চালাতে:

g++ -std=c++23 -g -fsanitize=address -fno-omit-frame-pointer order.cpp -o order
./order

অংশ ৫-এর unique_ptr-এর ভুল কোডটি এভাবে চালালে রিপোর্টের মূল অংশ দেখতে এমন হয় (ঠিকানা আর লাইন নম্বর আপনার মেশিনে আলাদা হবে):

==4127==ERROR: AddressSanitizer: heap-use-after-free on address 0x502000000010
READ of size 4 at 0x502000000010 thread T0
    #0 in main order.cpp:12
freed by thread T0 here:
    #0 in operator delete(void*, unsigned long)
    #1 in std::unique_ptr<Order>::reset(Order*) ...
    #2 in main order.cpp:11
previously allocated by thread T0 here:
    #0 in operator new(unsigned long)
    #1 in main order.cpp:9

রিপোর্টটি তিনটি প্রশ্নের উত্তর দেয়: কোথায় মৃত মেমরি ছোঁয়া হলো (লাইন ১২), কোথায় সেটি ফেরত গিয়েছিল (reset, লাইন ১১), আর কোথায় জন্মেছিল (লাইন ৯)। Dangling-এর বাগ খুঁজতে ঠিক এই তিনটি তথ্যই লাগে। ASan যে নামগুলো দেয়, তা চিনে রাখুন: heap-use-after-free (heap-এর মৃত object), stack-use-after-scope (block শেষ হওয়া local), stack-use-after-return (ফেরত যাওয়া ফাংশনের local). ASan প্রোগ্রামকে কয়েক গুণ ধীর করে আর মেমরি বেশি নেয়, তাই এটি টেস্ট আর ডিবাগের জন্য, চূড়ান্ত সংস্করণের জন্য নয় (পর্ব ৪৮)। আর মনে রাখুন, ASan শুধু সেই বাগ ধরে, যে পথে প্রোগ্রাম আসলে চলেছে — না-চলা কোডের বাগ সে দেখে না।

স্তর ৩ — নকশার নিয়ম: Core Guidelines আর profiles

Bjarne Stroustrup আর Herb Sutter-এর নেতৃত্বে লেখা C++ Core Guidelines-এ একটি “lifetime profile” আছে — কিছু নিয়ম, যা মানলে কোনো টুল স্থানীয়ভাবে (একেকটি ফাংশন দেখে) প্রমাণ করতে পারে যে pointer আর reference dangling হবে না। Herb Sutter ২০১৮ সালে এর বিস্তারিত নকশা প্রকাশ করেন, আর Microsoft-এর Visual C++ ও Clang-এর পরীক্ষামূলক সংস্করণে এর কিছু অংশ বাস্তবায়িত হয়েছে। এর পেছনের বড় আলোচনা হলো safety profile — কোডের একটি অংশে “এই নিরাপদ নিয়মগুলো চালু” বলে দিলে compiler বিপজ্জনক ধাঁচ আটকাবে। এটি নিয়ে C++ standard কমিটিতে কয়েক বছর ধরে জোর বিতর্ক চলছে, আর এখনো (এই লেখার সময়) এটি standard-এর অংশ হয়নি।

৯ · AI-এর যুগে — lifetime-এর ভুল খুঁজে বের করা

AI টুলের লেখা C++ কোডে lifetime-এর ভুল বিশেষ করে বিপজ্জনক, কারণ এগুলো compile হয়, ছোট টেস্টে ঠিক চলে, আর দেখতে “পরিপাটি আধুনিক” লাগে — string_view আর reference দেখে মনে হয় লেখক পারফরম্যান্স নিয়ে সচেতন। AI টুল কোনো object-এর আয়ু সত্যিই হিসাব করে না; সে প্রচলিত ধাঁচ অনুকরণ করে। যে ভুলগুলো বারবার দেখা যায়:

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

• প্রতিটি & বা * ফেরতের টাইপ দেখে বলতে পারি — object-টি কার, আর ফাংশন শেষে সে বেঁচে থাকে কেন
• কোনো struct বা class-এর member string_view, span, reference বা raw pointer হলে তার মালিক ও আয়ু কোডে লেখা আছে
• কোনো string_view বা const& এমন expression থেকে তৈরি হয়নি, যা temporary বানায় (a + b, by value ফেরত দেওয়া ফাংশন)
• Vector-এ push_back, insert বা erase-এর পরে আগের কোনো iterator, pointer বা reference ব্যবহার হয়নি
• যে lambda সংরক্ষিত হয়, ফেরত যায় বা অন্য thread-এ চলে, তাতে [&] নেই
• -Wall -Wextra পরিষ্কার, আর টেস্টগুলো -fsanitize=address দিয়ে একবার চালিয়েছি