new আর delete — heap মেমরি, আর কেন এড়িয়ে চলবেন

১ · সমস্যা: কতজন গ্রাহক, আগে জানা নেই

পর্ব ১৫-এ আপনি pointer দেখেছেন — এমন ভ্যারিয়েবল, যার ভেতরে আরেকটি object-এর ঠিকানা থাকে। সেখানে প্রতিটি pointer এমন কোনো ভ্যারিয়েবলের দিকে দেখাচ্ছিল, যা আগে থেকেই আছে। এবার প্রশ্নটা উল্টো: যদি object-টিই আগে থেকে না থাকে?

ধরুন আপনি একটি ছোট কুরিয়ার কোম্পানির সফটওয়্যার লিখছেন। প্রতিদিন সকালে প্রোগ্রাম একটি ফাইল থেকে গ্রাহকের তালিকা পড়ে। কোনো দিন ৩০ জন, ঈদের আগে হয়তো ৩০ হাজার। কোড লেখার সময় আপনি জানেন না কতজন — জানা যাবে কেবল প্রোগ্রাম চলার সময়, ফাইল খোলার পর। আবার মাসের শেষে একটি “Report” object বানাতে হবে, যা একটি ফাংশনে তৈরি হয়ে অন্য অনেক ফাংশনে ঘুরবে — অর্থাৎ যে ফাংশন তাকে বানিয়েছে, তার চেয়ে বেশি দিন বাঁচতে হবে।

এই দুটি চাহিদা — চলার সময় ঠিক হওয়া আকার আর ফাংশনের চেয়ে লম্বা আয়ু — সাধারণ local ভ্যারিয়েবল দিয়ে মেটে না। এর জন্য লাগে dynamic memory. কেন লাগে, তা বুঝতে আগে দেখুন একটি C++ প্রোগ্রাম মেমরির কোন দুটি এলাকা সবচেয়ে বেশি ব্যবহার করে।

C++-এ heap থেকে জায়গা চাওয়া হয় new দিয়ে, ফেরত দেওয়া হয় delete দিয়ে। সবচেয়ে ছোট উদাহরণ — একটি int:

void f() {
    int* p = new int(5);   // heap-এ একটি int, মান 5; ঠিকানা থাকে p-তে
    *p = 7;                // pointer দিয়ে heap-এর int-এ লেখা
    delete p;              // heap-এর জায়গা ফেরত
}                          // p নিজে (stack-এ) এখানে মুছে যায়

এখানে দুটি আলাদা জিনিস আছে, আর এদের গুলিয়ে ফেলাই বেশিরভাগ ভুলের উৎস: pointer p নিজে থাকে stack-এ, আর যে int-এর দিকে সে দেখায়, সেটি থাকে heap-এ। ধাপে ধাপে দেখুন, প্রতিটি ধাপে আগে নিজে অনুমান করুন:

STACK                         HEAP
[ f-এর frame ]                (ফাঁকা জায়গা, allocator-এর হাতে)
  p @1000 = ?

STACK                         HEAP
[ f-এর frame ]
  p @1000 = ?                 @7000: [ ৪ বাইট, এখনো মান নেই ]
                              <- allocator একটি ফাঁকা block খুঁজে দিল

STACK                         HEAP
[ f-এর frame ]
  p @1000 = 7000  -------->   @7000: 5

STACK                         HEAP
[ f-এর frame ]
  p @1000 = 7000  -------->   @7000: 7

STACK                         HEAP
[ f-এর frame ]
  p @1000 = 7000  ----?--->   @7000: [ ফেরত দেওয়া — আর আপনার নয় ]
  <- p এখন dangling: ঠিকানা আছে, object নেই

STACK                         HEAP
[ f-এর frame মুছে গেছে, p-ও ]   (সব পরিষ্কার)

delete না লিখলে:
[ frame মুছে গেছে ]           @7000: 7  <- ঠিকানা কারও কাছে নেই: leak

২ · new আর delete — জায়গা আর জীবন একসাথে

C++-এ new expression-এর কয়েকটি রূপ আছে। সবগুলোর ফল একটি pointer:

শেষ কলামটিই এই পর্বের প্রথম কঠিন নিয়ম: একটি object-এর new-এর সাথে delete, array-র new[]-এর সাথে delete[]। কোনো pointer দেখে compiler বুঝতে পারে না সেটি একটি object-এর, না একটি array-র প্রথম উপাদানের — দুটোর টাইপই Customer*. তাই কোনটি লিখবেন, সে দায়িত্ব আপনার। অংশ ৪-এ দেখবেন জোড়া না মিললে কী হয়।

new আসলে দুটি কাজ করে

new Report("Oct") এক লাইনের লেখা, কিন্তু ভেতরে দুটি আলাদা ধাপ:

1. জায়গা জোগাড়: একটি Report-এর মাপের কাঁচা মেমরি চাওয়া হয় (ভেতরে operator new নামের একটি ফাংশন এ কাজ করে, যা সাধারণত শেষ পর্যন্ত malloc-এর মতো allocator-কেই ডাকে)।
2. জীবন দেওয়া: সেই জায়গায় Report-এর constructor চলে — member-গুলো তৈরি হয়, std::string-এর ভেতরের লেখা বসে। এর পরেই জিনিসটি সত্যিকারের একটি object.

আর delete expression ঠিক উল্টো ক্রমে কাজ করে: আগে destructor চালিয়ে object-কে তার নিজের রিসোর্স (যেমন std::string-এর ভেতরের heap মেমরি) ফেরত দেওয়ার সুযোগ দেয়, তারপর জায়গাটি allocator-কে ফেরত দেয়। Constructor আর destructor আপনি পর্ব ২১-এ বিস্তারিত শিখবেন; এখনকার জন্য এটুকু জানলেই চলবে — constructor হলো object জন্মের মুহূর্তে নিজে থেকে চলা ফাংশন, আর destructor (~Report()) মৃত্যুর মুহূর্তে নিজে থেকে চলা ফাংশন।

নিচের প্রোগ্রামে constructor আর destructor নিজের নাম প্রিন্ট করে, যাতে দেখা যায় কোন লাইনে কোন object জন্মায় আর মরে। এখানে সব delete সঠিকভাবে লেখা — এটি “হাতে লিখলে ঠিক কীভাবে লিখতে হয়”-এর নমুনা:

#include <print>
#include <string>

struct Report {
    std::string title;
    explicit Report(const char* t) : title(t) { std::println("ctor: {}", title); }
    ~Report() { std::println("dtor: {}", title); }
};

int main() {
    Report* r = new Report("Sales-Oct");     // jayga + constructor
    std::println("using {}", r->title);
    delete r;                                // destructor + jayga ferot
    r = nullptr;                             // dangling na rakhar obhyash

    Report* many = new Report[2]{Report("A"), Report("B")};
    std::println("array ready");
    delete[] many;                           // new[] er jora: delete[]
}

৩ · new বনাম malloc — শুধু জায়গা, না জায়গা আর জীবন?

C থেকে আসা অনেকে ভাবেন, new হলো malloc-এর একটু সুন্দর নাম। আসলে পার্থক্য মৌলিক। malloc একটি সাধারণ ফাংশন, যা শুধু বাইট গোনে — “৪০ বাইট দাও।” সে জানেই না সেই ৪০ বাইটে কী থাকবে, তাই কোনো constructor চালায় না। new একটি ভাষার অংশ, যে টাইপ জানে — “একটি Report বানাও।”

Constructor না চলার পরিণতি গুরুতর। ধরুন Report-এর ভেতরে একটি std::string আছে। malloc দিয়ে জায়গা নিয়ে সরাসরি r->title = "Oct"; লিখলে, std::string-টি কখনো তৈরিই হয়নি — তার ভেতরের pointer আর আকারের ঘরে আবর্জনা। সেই আবর্জনায় লিখতে গেলে undefined behavior. আবার free destructor চালায় না, তাই string-এর নিজের heap মেমরি কখনো ফেরত যায় না। এজন্য C++ Core Guidelines-এর নিয়ম R.10 সোজা বলে: malloc আর free এড়িয়ে চলুন। এগুলো দরকার হয় কেবল C লাইব্রেরির সাথে কাজ করতে, যখন সেই লাইব্রেরি নিজে free করবে।

৪ · চারটি ক্লাসিক বাগ — যেগুলো compile হয়, তবু ভুল

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

১. Leak — যে ঠিকানা হারিয়ে গেছে

void handleOrder(int id) {
    Receipt* r = new Receipt(id);
    r->print();
}   // delete নেই। r মুছে গেল, Receipt রয়ে গেল heap-এ — চিরকালের জন্য

Leak-এর বিশেষত্ব হলো, এটি তাৎক্ষণিক কোনো ভুল দেখায় না। ছোট প্রোগ্রাম কয়েক সেকেন্ড চলে শেষ হয়, আর শেষ হলে অপারেটিং সিস্টেম পুরো প্রোগ্রামের মেমরি এমনিতেই ফেরত নেয় — তাই কেউ টের পায় না। কিন্তু যে প্রোগ্রাম মাসের পর মাস চলে — bKash-এর মতো লেনদেনের সার্ভার, একটি মোবাইল অ্যাপ, একটি গেম — সেখানে প্রতিটি leak জমতে জমতে মেমরি ফুরিয়ে দেয়। আর leak শুধু মেমরি নয়: Receipt-এর destructor যদি একটি ফাইল বন্ধ করার কথা থাকে, সেই ফাইলও খোলা থেকে যায়।

২ ও ৩. Double delete আর use-after-free — একই গল্পের দুই প্রান্ত

এই দুটি বাগ প্রায় সবসময় একই কারণে জন্মায়: একই heap block-এর ঠিকানা একাধিক জায়গায় আছে, কিন্তু কে মালিক, তা স্পষ্ট নয়। একটি গ্রাহক-তালিকার প্রোগ্রামে current আর lastViewed দুটি pointer একই গ্রাহকের দিকে দেখাচ্ছে। সময়রেখা ধরে দেখুন:

1Customer* current = new Customer("Rahim");2Customer* lastViewed = current;3delete current;  current = nullptr;4Customer* other = new Customer("Karim");5std::println("{}", lastViewed->name);6delete lastViewed;

৪. ভুল জোড়া — কেন delete[] আলাদা

Customer* list = new Customer[100];
// ...
delete list;     // ভুল! হওয়া উচিত delete[] list;

কেন দুই রকম delete? কারণ new Customer[100]-এর পর delete-এর কাজ ১০০টি destructor চালানো — আর তার জন্য জানতে হবে “কয়টি?” কিন্তু pointer-এ শুধু প্রথম উপাদানের ঠিকানা আছে। তাই অনেক implementation new[]-এর সময় array-র ঠিক আগে কয়েক বাইটে সংখ্যাটি (১০০) লুকিয়ে লিখে রাখে, আর delete[] সেখান থেকে পড়ে। সাধারণ delete ধরে নেয় একটিই object, ওই লুকানো সংখ্যার কথা জানে না — ফলে সাধারণত মাত্র একটি destructor চলে, বাকি ৯৯টির রিসোর্স leak হয়, আর ভুল ঠিকানা allocator-কে ফেরত দেওয়ায় heap নষ্টও হতে পারে। ঠিক কী ঘটবে, তা নির্ভর করে compiler-এর ওপর; standard শুধু বলে — undefined behavior. GCC আর Clang অনেক সময় এমন স্পষ্ট ভুলে -Wmismatched-new-delete সতর্কবার্তা দেয়, কিন্তু pointer যখন অন্য ফাংশন ঘুরে আসে, তখন কেউ ধরতে পারে না।

৫ · Exception আর early return — হাতে লেখা delete কেন ভঙ্গুর

ধরুন আপনি সাবধানী। প্রতিটি new-এর নিচে একটি delete লিখেছেন, ঠিক জোড়া মিলিয়ে। তবু বিপদ কাটেনি — কারণ ফাংশন সবসময় শেষ লাইন পর্যন্ত পৌঁছায় না। ফাংশন থেকে বেরোনোর পথ অনেক: মাঝখানে একটি return, লুপের ভেতরের break, বা সবচেয়ে লুকানো — একটি exception. কুরিয়ার কোম্পানির গ্রাহক-তালিকা লোড করার এই ফাংশনটি দেখুন (exception-এর পুরো গল্প পর্ব ৩৭-এ; এখন শুধু জানুন, throw হলে ফাংশন সেই লাইনেই থেমে যায় আর নিয়ন্ত্রণ সোজা বাইরে কোথাও চলে যায়):

1bool loadCustomers(const std::string& path) {2    Customer* list = new Customer[500];3    std::ifstream file(path);4    if (!file) return false;         // delete বাদ!5    parseAll(file, list);            // throw করতে পারে6    delete[] list;7    return true;8}

শেষ ধাপের পর্যবেক্ষণটিই সমাধানের চাবি: file-এর destructor চলেছে, list-এর delete চলেনি। Stack-এর object যেভাবেই ফাংশন শেষ হোক — স্বাভাবিকভাবে, return-এ, বা exception-এ — নিজের destructor চালায়। তাহলে heap-এর block-এর দায়িত্ব যদি এমন একটি stack-object-কে দেওয়া যায়, যার destructor-এ delete লেখা? এই ধারণার নাম RAII, আর পরের অংশে এটিই দেখবেন।

মেমরি না পেলে — std::bad_alloc

Heap অসীম নয়। সাধারণ new যখন জায়গা জোগাড় করতে পারে না, তখন nullptr ফেরত দেয় না — <new>-এ সংজ্ঞায়িত std::bad_alloc exception ছোড়ে। তাই C-এর অভ্যাসে if (p == nullptr) পরীক্ষা সাধারণ new-এর পরে অর্থহীন — ব্যর্থ হলে প্রোগ্রাম ওই লাইন পর্যন্ত পৌঁছায়ই না। কেউ exception না চাইলে new (std::nothrow) Customer[n] লিখতে পারেন; তখন ব্যর্থ হলে nullptr আসে, আর পরীক্ষা করা আপনার দায়িত্ব।

try {
    auto* big = new double[n];       // n খুব বড় হলে bad_alloc
    // ...
    delete[] big;
} catch (const std::bad_alloc&) {
    std::println("not enough memory for {} values", n);
}

বাস্তবে একটি সূক্ষ্মতা আছে: Linux সাধারণত মেমরির প্রতিশ্রুতি আগে দেয়, আসল জায়গা দেয় ব্যবহারের সময় (একে বলে overcommit). ফলে সেখানে বিশাল new-ও প্রায়ই সফল হয়, আর মেমরি সত্যিই ফুরালে অপারেটিং সিস্টেম প্রোগ্রামটিকেই বন্ধ করে দিতে পারে। তাই bad_alloc সবচেয়ে নিশ্চিতভাবে দেখা যায় অসম্ভব বড় অনুরোধে, বা মেমরি-সীমা বাঁধা পরিবেশে। Embedded সিস্টেমে, যেখানে exception বন্ধ রাখা হয়, সেখানে nothrow রূপ বা নিজস্ব allocator বেশি প্রচলিত।

৬ · “Naked new” কেন নয় — আর তার বদলে কী

এখন পর্যন্ত যা দেখলেন, তার সারকথা: হাতে new/delete লেখা মানে প্রতিটি block-এর জন্য — প্রতিটি return-পথে, প্রতিটি সম্ভাব্য exception-এ, প্রতিটি কপি করা pointer-এর ক্ষেত্রে — মাথায় হিসাব রাখা “কে, কখন, একবার ফেরত দেবে।” মানুষ এ হিসাব নির্ভুলভাবে রাখতে পারে না, অন্তত বড় কোডবেসে বছরের পর বছর ধরে নয়। তাই Bjarne Stroustrup ও Herb Sutter-এর সম্পাদিত C++ Core Guidelines-এর নিয়ম R.11: “Avoid calling new and delete explicitly” — new আর delete সরাসরি ডাকবেন না। কোনো মালিক-object ছাড়া কাঁচা pointer-এ রাখা new-কে বলে naked new.

এর মানে heap ব্যবহার বন্ধ নয় — মানে heap-এর প্রতিটি block-এর একজন মালিক-object থাকবে, যার destructor ফেরত দেবে। এই মালিকানার (ownership) কাজ করে দেওয়ার জন্য standard library-তে তৈরি টাইপ আছে:

std::unique_ptr হলো একটি smart pointer — pointer-এর মতো -> দিয়ে ব্যবহার করা যায়, কিন্তু সে নিজে একটি stack-object, আর তার destructor-এ লেখা আছে delete. std::make_unique (C++14) heap-এ object বানিয়ে সরাসরি তার হাতে দেয়, তাই আপনার কোডে new শব্দটিও থাকে না। ভাগাভাগি মালিকানার জন্য আছে std::shared_ptr. এগুলো কীভাবে কাজ করে, কেন unique_ptr কপি করা যায় না, আর কখন কোনটি — সেটা পর্ব ১৭-এর পুরো বিষয়। এখানে শুধু ফলাফলটি দেখুন — অংশ ৫-এর একই ব্যর্থতার পথ, এবার মালিক-object দিয়ে:

STACK                              HEAP
[ loadCustomers ]
  list  { data: 7000, size: 500 } ---> @7000: ৫০০ Customer
  <- vector নিজেই heap থেকে নিয়েছে

STACK                              HEAP
[ loadCustomers ] বন্ধ হচ্ছে...
  list.~vector()  চলল  --->     @7000: ৫০০ destructor, তারপর ফেরত
                                   leak: 0

STACK                              HEAP
[ loadCustomers ] unwinding...
  file.~ifstream()  চলল          (ফাইল বন্ধ)
  list.~vector()    চলল  --->   @7000: ফেরত
                                   leak: 0

STACK                              HEAP
[ build ]
  r  (unique_ptr) ---------------> @9000: Report "Monthly"
ফাংশন যেভাবেই শেষ হোক:
  r.~unique_ptr() → delete       @9000: ~Report(), তারপর ফেরত

এবার নিজে চালিয়ে দেখুন। একই Report, এবার std::make_unique দিয়ে, আর একটি ফাংশন যেখানে ইচ্ছা করে মাঝপথে return রাখা হয়েছে। সাথে একটি গ্রাহক-তালিকা, যা নিজের heap নিজেই সামলায়:

#include <memory>
#include <print>
#include <string>
#include <vector>
struct Report {
    std::string title;
    explicit Report(const char* t) : title(t) { std::println("ctor: {}", title); }
    ~Report() { std::println("dtor: {}", title); }
};
void build(bool fileOk) {
    auto r = std::make_unique<Report>("Monthly");   // malik: r
    if (!fileOk) return;                            // early return - tobu dtor cholbe
    std::println("built {}", r->title);
}
int main() {
    std::vector<std::string> customers{"Rahim", "Karim", "Sumi"};
    customers.push_back("Nadia");                   // vector nijei heap samlay
    std::println("{} customers", customers.size());
    build(false);
    build(true);
}

৭ · আরও কিছু জানা দরকার — placement new আর বাগ ধরার যন্ত্র

Placement new — শুধু চিনে রাখুন

new দুটি কাজ করে — জায়গা আর জীবন। কখনো কখনো জায়গা আগে থেকেই আছে, শুধু জীবন দরকার। যেমন std::vector ভেতরে আগে একসাথে অনেকটা কাঁচা জায়গা নিয়ে রাখে (capacity), তারপর push_back-এর সময় ঠিক পরের ঘরে একটি object তৈরি করে। এর জন্য আছে placement new: new (ঠিকানা) T(...) — নতুন মেমরি নেয় না, দেওয়া ঠিকানায় শুধু constructor চালায়। এর destructor হাতে ডাকতে হয়, আর জায়গা ফেরত দিতে হয় আলাদাভাবে। এটি লাইব্রেরি-লেখকদের যন্ত্র; সাধারণ কোডে আপনার দেখা পাওয়ার কথা নয়, আর নিজে লেখার দরকারও পড়বে না।

যে বাগ চোখে দেখা যায় না, তা যন্ত্র দিয়ে ধরুন

অংশ ৪-এর বাগগুলো প্রায়ই নীরব থাকে। তাই পেশাদার C++ দলগুলো চোখের ওপর ভরসা করে না, যন্ত্র ব্যবহার করে:

অংশ ৪-এর use-after-free কোড ASan দিয়ে চালালে লাইন ৫-এই প্রোগ্রাম থেমে যায়, আর বার্তায় লেখা থাকে heap-use-after-free, সাথে তিনটি ঠিকানার ইতিহাস: কোথায় পড়া হলো, কোথায় delete হয়েছিল, আর কোথায় new হয়েছিল। কোনো leak থাকলে প্রোগ্রাম শেষে আসে detected memory leaks আর কোন লাইনের new থেকে কত বাইট হারাল। এগুলোর ব্যবহার, ডিবাগার আর টেস্টের সাথে, পর্ব ৪৮-এ দেখবেন। এখনকার পরামর্শ: শেখার সময় নিজের প্রোগ্রাম মাঝে মাঝে -fsanitize=address দিয়ে চালান — sanitizer হলো সেই শিক্ষক, যে প্রতিটি মেমরি-ভুল লাইন নম্বরসহ ধরিয়ে দেয়।

৮ · AI-এর যুগে — AI-এর লেখা মেমরি-কোড যাচাই

অনলাইনে C++-এর বিপুল পরিমাণ পুরোনো কোড, টিউটোরিয়াল আর পাঠ্যবইয়ের উদাহরণ আছে, যেগুলো C++11-এর আগের রীতিতে লেখা — সর্বত্র new আর delete. AI টুল সেখান থেকেই শিখেছে, তাই “একটি dynamic array বানাও” বললে প্রায়ই সোজা new int[n] লিখে দেয়। কোড compile হয়, ছোট পরীক্ষায় ঠিক চলে — ভুল ধরা পড়ে শুধু ব্যর্থতার পথে বা দীর্ঘ সময় চালালে। সাধারণ ভুলগুলো:

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

• কোডে new আর delete শব্দ খুঁজেছি; প্রতিটি new-এর ফল সাথে সাথে কোনো মালিক-object-এর হাতে যায়, নাহলে vector/make_unique দিয়ে বদলেছি
• প্রতিটি new[]-এর জোড়া delete[] (বা ভালো হয়, পুরোটাই std::vector)
• প্রতিটি return, break আর exception ছুড়তে পারে এমন ডাক ধরে দেখেছি — সেই পথে কি কোনো heap block মালিকহীন হয়?
• যে ফাংশন কাঁচা pointer ফেরত দেয়, তার জন্য বলতে পারি — ডাকার মানুষ কি delete করবেন, না শুধু দেখবেন?
• একই ঠিকানা দুটি pointer-এ কপি হলে স্পষ্ট — শুধু একজন মালিক, অন্যজন দেখে মাত্র
• -fsanitize=address দিয়ে চালিয়েছি, ব্যর্থতার পথগুলোসহ (ভুল ফাইলের নাম দিয়ে) — কোনো leak বা use-after-free রিপোর্ট নেই