copy, move আর Rule of 0/3/5 — object কপি করার নিয়ম

১ · কপি করা মানে কী? — দলিলের ফটোকপি আর চাবি হাতবদল

একটি int কপি করা সহজ। int b = a; লিখলে b-তে a-এর মান বসে, তারপর দুটি সম্পূর্ণ আলাদা। একটি বদলালে অন্যটির কিছু হয় না। C++-এর বেশিরভাগ টাইপ এভাবেই আচরণ করে — একে বলে value semantics. পর্ব ২০ আর ২১-এ আপনি যখন নিজের class বানিয়েছেন, তখনও Student b = a; লিখলে একটি স্বাধীন কপি পেয়েছেন, কারণ ভেতরে ছিল নাম আর নম্বরের মতো সাধারণ ডেটা।

কিন্তু এমন object-এর কথা ভাবুন, যে নিজে একটি resource-এর মালিক — ধরুন একটি ছবির class, যে heap-এ দশ লাখ pixel রেখেছে আর তার ঠিকানা রেখেছে একটি raw pointer-এ। এই object “কপি” করার মানে কী? দুটি সম্ভাব্য উত্তর আছে, আর দুটির ফল একদম আলাদা।

এই তিনটি সাড়াই C++-এ আছে, আর প্রতিটির একটি নাম আছে:

এই পর্বের পুরো গল্প এই তিনটি সাড়াকে ঘিরে: কীভাবে compiler-কে বলবেন কোনটি চান, কখন সে নিজে থেকে কোনটি বেছে নেয়, আর কীভাবে এমন class লিখবেন যেখানে ভুলটা হওয়ার সুযোগই নেই।

২ · ছয়টি বিশেষ সদস্য — compiler যা নিজে লিখে দেয়

পর্ব ২১-এ আপনি constructor আর destructor দেখেছেন। এরা একটি বড় পরিবারের সদস্য, যার নাম special member function. এগুলো বিশেষ, কারণ আপনি না লিখলেও compiler দরকারমতো নিজে এদের ঘোষণা আর সংজ্ঞা লিখে দিতে পারে। একটি Image class-এর জন্য ছয়টির চেহারা:

একটি পার্থক্য আগেই পরিষ্কার করে নিন, কারণ পরীক্ষায় এটা বারবার আসে। constructor চলে নতুন object জন্মানোর সময়; assignment চলে এমন object-এ, যে আগে থেকেই বেঁচে আছে। Image b = a; লেখায় = চিহ্ন থাকলেও এটি assignment নয় — b এইমাত্র জন্মাচ্ছে, তাই copy constructor চলে। b = a; আলাদা লাইনে লিখলে b-এর আগে থেকেই নিজের pixel আছে, তাই copy assignment-কে সেগুলোর ব্যবস্থাও করতে হয়। এই বাড়তি দায়িত্বই assignment-কে কঠিন করে।

move-এর দুটি সদস্যের প্যারামিটারে && চিহ্ন — একে বলে rvalue reference. এর পুরো ব্যাখ্যা পর্ব ৩৬-এ। এখানে শুধু এটুকু জানলেই চলবে: && এমন object-এর সাথে যুক্ত হয়, যার ভেতরের জিনিস নিয়ে নেওয়া নিরাপদ — হয় সেটি একটি temporary object (যেমন ফাংশনের ফেরত দেওয়া মান, যার আর কোনো নাম নেই), নয়তো আপনি std::move লিখে স্পষ্ট অনুমতি দিয়েছেন।

compiler-এর বানানো সংস্করণ কী করে?

আপনি না লিখলে compiler-এর বানানো copy constructor করে memberwise copy: প্রতিটি data member-কে, ঘোষণার ক্রমে, তার নিজের কপির নিয়মে কপি করে। std::string member হলে string-এর নিজের copy constructor চলে (যা deep copy করে)। int হলে মান কপি হয়। আর raw pointer হলে? pointer-এর “মান” তো একটি ঠিকানা — তাই শুধু ঠিকানাটাই কপি হয়। compiler জানে না, আর জানার উপায়ও নেই, যে এই pointer একটি heap ব্লকের মালিক, নাকি শুধু অন্য কোথাও আঙুল দিয়ে দেখাচ্ছে। একইভাবে compiler-এর বানানো move constructor প্রতিটি member-কে move করে, আর destructor প্রতিটি member-এর destructor ডাকে — raw pointer-এর জন্য কিছুই না।

কোন অবস্থায় compiler কোন সদস্যটি নিজে বানায়, তার নিয়ম কিছুটা জটিল। পুরো টেবিলটি অংশ ৭-এ দেখবেন। আপাতত সবচেয়ে সাধারণ ক্ষেত্রটি মনে রাখুন: আপনি কোনো special member না লিখলে compiler ছয়টিই দরকারমতো বানিয়ে দেয়, আর সেগুলো memberwise কাজ করে।

৩ · shallow copy-র ফাঁদ — দুই pointer, এক বাড়ি

এবার একটি ভুল class দেখুন। Image heap-এ pixel রাখে, constructor-এ new[] করে আর destructor-এ delete[] — পর্ব ১৭-এর RAII মেনেই। শুধু copy-র কথা ভাবা হয়নি:

class Image {
    int n;          // pixel কতগুলো
    int* px;        // heap-এর pixel — এই object এর মালিক
public:
    explicit Image(int size) : n(size), px(new int[size]{}) {}
    ~Image() { delete[] px; }
    // copy constructor লিখিনি — compiler নিজে বানাবে: n কপি, px কপি (শুধু ঠিকানা!)
};

void makeBackup() {
    Image photo(1000000);
    Image backup = photo;   // backup.px == photo.px — একই heap ব্লক
}                           // প্রথমে backup-এর destructor, তারপর photo-র — একই ব্লক দুবার delete[]

কোডটি compile হয়, কোনো warning-ও আসে না। কিন্তু makeBackup শেষ হওয়ার মুহূর্তে একই মেমরি দুবার ফেরত দেওয়া হয় — একে বলে double delete, আর এটি undefined behavior. ধাপে ধাপে দেখুন কী ঘটে:

stack                      heap
photo { n = 1000000,
        px = @5000 } ───►  [ 1000000 pixel @5000 ]

stack                      heap
photo { n = 1000000,
        px = @5000 } ──────►  [ 1000000 pixel @5000 ]
                                ▲
backup { n = 1000000,           │
         px = @5000 } ────────┘   দুজন মালিক, ব্লক একটি

backup.px[0] = 255;   // শুধু backup বদলাতে চেয়েছিলেন

photo.px[0]  → 255     // অথচ photo-ও বদলে গেছে!
"backup" আসলে কোনো backup নয় — একই ছবির দ্বিতীয় নাম

stack                      heap
photo { n = 1000000,
        px = @5000 } ──────►  [ ফেরত দেওয়া মেমরি @5000 ]
                                photo এখন dangling pointer ধরে আছে
backup (ধ্বংস হয়েছে, delete[] @5000 চলেছে)

delete[] @5000   ← দ্বিতীয়বার!

double delete = undefined behavior:
  · কখনো সঙ্গে সঙ্গে crash ("double free detected")
  · কখনো চুপচাপ heap-এর হিসাব নষ্ট — অনেক পরে অন্য জায়গায় crash
  · কখনো কিছুই বোঝা যায় না — সবচেয়ে বিপজ্জনক

সমস্যার মূল কারণটা আরেকবার বলি: compiler জানে না px একটি মালিক pointer. তাই সমাধানও দুটি। হয় compiler-কে বলে দিন কপি কীভাবে হবে (নিজের copy constructor — পরের অংশ), নয়তো raw pointer-এর বদলে এমন member রাখুন, যে নিজেই নিজের কপি জানে (যেমন std::vector<int> — অংশ ৭-এর Rule of Zero).

৪ · deep copy — copy constructor আর copy assignment

সমাধানের প্রথম ধাপ: নিজের copy constructor লেখা, যা নতুন বাড়ি বানায়। নতুন object-এর জন্য নতুন heap ব্লক নিন, তারপর source-এর সব pixel সেখানে কপি করুন। এর নাম deep copy:

Image(const Image& other)
    : n(other.n), px(new int[other.n]) {           // ১. নিজের নতুন ব্লক
    std::copy(other.px, other.px + n, px);         // ২. ভেতরের ডেটা কপি
}

প্যারামিটার const Image& — reference, কারণ by value নিলে সেই প্যারামিটার বানাতেই আবার copy constructor লাগত (অসীম চক্র); আর const, কারণ কপি করার সময় source বদলানোর কোনো কারণ নেই। এবার একই ঘটনা আবার দেখুন:

photo  { n = 1000000, px = @5000 } ──►  [ photo-র pixel  @5000 ]
backup { n = 1000000, px = @9000 } ──►  [ খালি নতুন ব্লক @9000 ]

photo  ──►  [ 12 40 77 ... @5000 ]
                │ │  │
                ▼ ▼  ▼   দশ লাখ মান কপি হচ্ছে
backup ──►  [ 12 40 77 ... @9000 ]

photo  ──►  [ 12  40 77 ... @5000 ]   ← বদলায়নি
backup ──►  [ 255 40 77 ... @9000 ]

backup-এর destructor → delete[] @9000   ✓
photo-র destructor   → delete[] @5000   ✓
প্রতিটি ব্লক ঠিক একবার ফেরত গেল — কোনো double delete নেই

copy assignment — আগে থেকে থাকা object-এ কপি

copy constructor-এর কাজ সহজ, কারণ নতুন object-এর কিছু নেই। কিন্তু b = a;-এ b-এর আগে থেকেই নিজের pixel আছে। তাই copy assignment-কে তিনটি কাজ করতে হয়: নিজের পুরোনো ব্লক ফেরত দেওয়া, নতুন ব্লক নেওয়া, ডেটা কপি করা। প্রথম চেষ্টায় অনেকেই, আর অনেক AI টুলও, এভাবে লেখে:

Image& operator=(const Image& other) {      // ভুল সংস্করণ — দুটি বাগ
    delete[] px;                               // নিজের পুরোনো pixel মুছলাম
    n = other.n;
    px = new int[n];                           // বাগ ২: এখানে exception হলে?
    std::copy(other.px, other.px + n, px);     // বাগ ১: a = a হলে other.px তো এইমাত্র মোছা!
    return *this;
}

বাগ ১ — self-assignment. কেউ a = a; লিখবে কেন? সরাসরি কেউ লেখে না, কিন্তু ঘুরপথে প্রায়ই ঘটে: photos[i] = photos[j]; যখন i আর j সমান, বা দুটি reference একই object দেখায়। তখন other আর *this একই object. প্রথম লাইনেই নিজের pixel মুছে ফেলা হলো, তারপর std::copy সেই মোছা মেমরি থেকে পড়ছে — undefined behavior. পুরোনো সমাধান ছিল শুরুতে একটি পাহারা: if (this == &other) return *this; — এখানে this হলো বর্তমান object-এর ঠিকানা।

বাগ ২ — মাঝপথে ব্যর্থতা। new মেমরি না পেলে std::bad_alloc exception ছোড়ে। তখন পুরোনো ব্লক ইতিমধ্যে মোছা, কিন্তু px এখনো সেই মোছা ঠিকানা ধরে আছে। object টি ভাঙা অবস্থায় রয়ে গেল, আর পরে তার destructor আবার সেই ঠিকানা মুছবে। self-check এই বাগ সারায় না।

copy-and-swap — দুটি বাগের একটি সমাধান

অভিজ্ঞ C++ প্রোগ্রামাররা এখানে একটি কৌশল ব্যবহার করেন, যার নাম copy-and-swap. ধারণাটা হলো: যা ভাঙতে পারে (নতুন মেমরি নেওয়া, ডেটা কপি), তা আগে একটি আলাদা অস্থায়ী object-এ করুন। সেটা সফল হলে তবেই নিজের সাথে অদলবদল করুন — আর অদলবদল কখনো ব্যর্থ হয় না, কারণ শুধু দুটি int আর দুটি pointer বদলানো হচ্ছে।

void swap(Image& other) noexcept {             // শুধু pointer আর size অদলবদল
    std::swap(n, other.n);
    std::swap(px, other.px);
}
Image& operator=(const Image& other) {
    Image tmp(other);    // ১. আগে কপি (ব্যর্থ হলে exception — *this একদম অক্ষত)
    swap(tmp);           // ২. নতুন ডেটা আমার, পুরোনো ডেটা tmp-এর
    return *this;
}                        // ৩. tmp-এর destructor আমার পুরোনো pixel মুছে দেয়

খেয়াল করুন কী কী হলো। self-assignment-এ tmp একটি সম্পূর্ণ নতুন কপি, তাই কিছুই হারায় না — পাহারার দরকারই নেই। new ব্যর্থ হলে exception ওঠে প্রথম লাইনেই, যখন *this এখনো ছোঁয়া হয়নি। হয় পুরো assignment সফল, নয়তো কিছুই বদলায় না — এই প্রতিশ্রুতিকে বলে strong exception guarantee. আর পুরোনো pixel মোছার কোড আলাদা করে লিখতেই হয়নি — destructor-এর কাজই সেটা। std::swap এখানে শুধু int আর pointer অদলবদল করে, যা কখনো exception ছোড়ে না।

এ পর্যন্ত আমরা তিনটি জিনিস নিজে লিখলাম: destructor, copy constructor আর copy assignment. এটা কাকতালীয় নয়। যে class-কে নিজের destructor লিখতে হয়েছে, সে নিশ্চয়ই কোনো রিসোর্স নিজে সামলাচ্ছে — আর তখন compiler-এর memberwise copy প্রায় নিশ্চিতভাবেই ভুল। এই পর্যবেক্ষণটিকে বলে Rule of Three: তিনটির একটি লিখতে হলে, সম্ভবত তিনটিই লিখতে হবে। নিয়মটি ১৯৯০-এর দশক থেকে C++ সম্প্রদায়ে প্রচলিত।

৫ · move — কপি না করে চাবি হাতবদল

deep copy নিরাপদ, কিন্তু সবসময় দরকার নয়। ধরুন একটি ফাংশন ক্যামেরা থেকে একটি ছবি লোড করে ফেরত দিল, বা আপনি একটি ছবি একটি album-এর vector-এ ঢুকিয়ে দিচ্ছেন আর মূল ভ্যারিয়েবলটি আর ব্যবহার করবেন না। এসব ক্ষেত্রে দশ লাখ pixel কপি করে তারপর মূলটি মুছে ফেলা হলো নতুন বাড়ি বানিয়ে পুরোনোটা ভেঙে ফেলার মতো অপচয়। দরকার ছিল শুধু চাবি হাতবদল।

C++11 এজন্যই move semantics এনেছে। move constructor source-এর pointer নিজের কাছে নিয়ে নেয়, আর source-এর pointer nullptr করে দেয় — যাতে source-এর destructor পরে কিছু না মোছে:

Image(Image&& other) noexcept
    : n(std::exchange(other.n, 0)),              // other.n নাও, other.n = 0
      px(std::exchange(other.px, nullptr)) {}    // other.px নাও, other.px = nullptr

Image& operator=(Image&& other) noexcept {
    if (this != &other) {
        delete[] px;                             // নিজের পুরোনো pixel ফেরত
        n  = std::exchange(other.n, 0);
        px = std::exchange(other.px, nullptr);
    }
    return *this;
}

std::exchange (C++14 থেকে, <utility>-এ) এক লাইনে দুটি কাজ করে: প্রথম আর্গুমেন্টে নতুন মান বসায় আর পুরোনো মানটি ফেরত দেয়। move লেখার জন্য এটি একদম মাপমতো — “আপনার জিনিসটা আমাকে দিন, আর আপনি খালি হয়ে যান।” move assignment-এ self-check রাখা হয়েছে, কারণ a = std::move(a);-এ নিজের pixel মুছে তারপর সেই মোছা ঠিকানা নিজেকে দেওয়া হতো।

1Image a(1000000);2Image c = std::move(a);3  : n(std::exchange(other.n, 0))4  , px(std::exchange(other.px, nullptr)) {}5a = Image(10);   // খালি a-তে নতুন মান6}  // scope শেষ

এবার পাঁচটি সদস্য একসাথে চালিয়ে দেখুন। নিচের Image-এ প্রতিটি special member নিজের নাম প্রিন্ট করে। assignment-টি copy-and-swap-এর একটি সংক্ষিপ্ত রূপ — প্যারামিটার by value নেয়, ফলে একটিমাত্র ফাংশন copy assignment আর move assignment দুটোর কাজ করে (lvalue দিলে প্যারামিটার কপি হয়ে আসে, std::move করা object দিলে move হয়ে, আর temporary দিলে সরাসরি প্যারামিটারেই তৈরি হয়ে):

#include <algorithm>
#include <print>
#include <utility>

class Image {                                // pixel-er ekmatro malik
    int n = 0;  int* px = nullptr;
public:
    explicit Image(int size) : n(size), px(new int[size]{}) { std::println("ctor      n={}", n); }
    Image(const Image& o) : n(o.n), px(new int[o.n]) {           // deep copy
        std::copy(o.px, o.px + n, px);  std::println("copy ctor n={}", n); }
    Image(Image&& o) noexcept                                    // pointer-ta niye nao
        : n(std::exchange(o.n, 0)), px(std::exchange(o.px, nullptr)) { std::println("move ctor n={}, source n={}", n, o.n); }
    Image& operator=(Image o) noexcept {                         // copy-and-swap
        std::swap(n, o.n);  std::swap(px, o.px);  std::println("assign    n={}", n);  return *this; }
    ~Image() { std::println("dtor      n={}", n);  delete[] px; }
};
int main() {
    Image a(1000);
    Image b = a;                 // copy
    Image c = std::move(a);      // move
    b = Image(5);                // assign
}

move-এর পরে source-এর কী অবস্থা?

নিজের class-এ আপনি ঠিক করেন। আমাদের Image-এ সরানো object নিশ্চিতভাবে খালি (n=0, px=nullptr). কিন্তু standard library-র টাইপের ক্ষেত্রে নিয়মটা সাবধানে পড়ুন: move-এর পর তারা থাকে “valid but unspecified” অবস্থায় — বৈধ, কিন্তু ঠিক কী মান তা বলা নেই। একে বলে moved-from state. এমন object ধ্বংস করা যায়, নতুন মান দেওয়া যায়, আর যে ফাংশনের কোনো পূর্বশর্ত নেই (যেমন size(), clear()) তা ডাকা যায়। কিন্তু “একটি moved-from std::string খালি” — এটা ধরে নেবেন না। ব্যতিক্রম হলো std::unique_ptr: move-এর পর সেটি nullptr হবে, standard তা নিশ্চিত করে (পর্ব ১৭)। সবচেয়ে নিরাপদ অভ্যাস: move করা object-এ নতুন মান না দিয়ে তা আর পড়বেন না।

৬ · noexcept — vector কেন move-এ ভরসা করতে চায়

উপরের move constructor-এ একটি শব্দ খেয়াল করেছেন: noexcept. এটা ঘোষণা করে, এই ফাংশন কোনো exception বাইরে ছুড়বে না। শুনতে সামান্য, কিন্তু এর অভাবে আপনার move অনেক জায়গায় কাজেই লাগে না। কারণটা বুঝতে std::vector-এর ভেতরে তাকান।

পর্ব ১৩-এ দেখেছেন, vector-এর জায়গা ফুরিয়ে গেলে সে একটি বড় নতুন ব্লক নেয়, পুরোনো সব উপাদান সেখানে নিয়ে যায়, তারপর পুরোনো ব্লক মোছে। C++98 থেকেই push_back প্রতিশ্রুতি দেয়: বড় হওয়ার সময় কিছু ব্যর্থ হলে vector আগের মতোই থাকবে — strong guarantee. পুরোনো উপাদানগুলো কপি করে নিলে এটা সহজ: মাঝপথে একটি কপি ব্যর্থ হলে নতুন ব্লক ফেলে দাও, পুরোনো ব্লক অক্ষতই আছে।

এখন উপাদানগুলো move করলে কী হয়? ধরুন ১০টির মধ্যে ৬টি সরানো হয়ে গেছে, আর সপ্তমটির move exception ছুড়ল। প্রথম ৬টির ডেটা এখন নতুন ব্লকে, পুরোনো ব্লকে তারা খালি। ফেরত সরাতে গেলে আবার move লাগবে — যা আবার ব্যর্থ হতে পারে। ভাঙা ডিম আর জোড়া লাগানো যায় না। তাই vector-এর নিয়ম: উপাদানের move constructor noexcept হলে move করব; না হলে, আর কপি করা গেলে, কপি করব। (ভেতরে সে std::move_if_noexcept নামের একটি সাহায্যকারী দিয়ে এই সিদ্ধান্ত নেয়।) নিচে দুটি টাইপ — একটির move-এ noexcept আছে, অন্যটিতে নেই:

#include <print>
#include <string_view>
#include <vector>

std::string_view used = "nothing";                 // shesh kon special member cholechhe
struct Safe {
    Safe() = default;
    Safe(const Safe&) { used = "copy ctor"; }
    Safe(Safe&&) noexcept { used = "move ctor"; }
};
struct Risky {
    Risky() = default;
    Risky(const Risky&) { used = "copy ctor"; }
    Risky(Risky&&) { used = "move ctor"; }          // noexcept nei
};
int main() {
    std::vector<Safe> s(1);  std::vector<Risky> r(1);
    while (s.size() < s.capacity()) s.emplace_back();   // jayga purota bhoro
    while (r.size() < r.capacity()) r.emplace_back();
    used = "nothing";  s.emplace_back();  std::println("vector<Safe>  grew using: {}", used);
    used = "nothing";  r.emplace_back();  std::println("vector<Risky> grew using: {}", used);
}

৭ · Rule of Three → Five → Zero

C++11 move আনার পর Rule of Three বড় হয়ে হলো Rule of Five: destructor, copy constructor, copy assignment, move constructor, move assignment — এর একটিও নিজে লিখলে বা delete করলে, পাঁচটির কথাই ভাবুন। “ভাবুন” মানে প্রতিটিকে হয় লিখুন, হয় = default, হয় = delete — কিন্তু চুপ করে compiler-এর হাতে ছেড়ে দেবেন না। কেন ছেড়ে দেওয়া বিপজ্জনক, সেটা বোঝা যায় compiler-এর নিয়মগুলো দেখলে।

compiler কখন কোনটি বানায় — Hinnant-এর টেবিল

move semantics-এর প্রধান নকশাকারদের একজন Howard Hinnant নিয়মগুলো একটি টেবিলে সাজিয়েছিলেন, যা এখন বহু জায়গায় উদ্ধৃত হয়। সারিতে: আপনি নিজে কোন সদস্যটি ঘোষণা করেছেন। ঘরে: বাকিগুলোর কী হয়। implicitly declared মানে compiler নিজে বানায়।

টেবিলের তিনটি জিনিস মুখস্থ নয়, বুঝে রাখুন। এক, destructor বা copy-র যেকোনো একটি ঘোষণা করলেই move আর তৈরি হয় না। compiler-এর যুক্তি: “আপনি নিজে রিসোর্স সামলাচ্ছেন, আমি move কীভাবে করব আন্দাজ করব না।” দুই, move-এর কোনো একটি ঘোষণা করলে copy দুটি deleted হয় — অর্থাৎ ব্যবহার করলে compile error. তিন, “deprecated” মানে এখনো বানায়, শুধু পুরোনো কোড না ভাঙার জন্য; ভবিষ্যতে বাদ যেতে পারে, আর GCC-তে -Wextra দিলে এমন ক্ষেত্রে ব্যবহারে warning আসতে পারে।

নীরব ফাঁদ: destructor লিখলেই move হারায়

প্রথম নিয়মটির একটি অপ্রত্যাশিত ফল আছে। ধরুন একটি Album class-এ std::vector<Photo> আছে, যা নিজেই নিখুঁত move জানে। কেউ ডিবাগ করার জন্য এক লাইনের একটি destructor যোগ করলেন: ~Album() { std::println("album closed"); }. কোড compile হয়, সব ঠিক চলে। কিন্তু এখন Album-এর move constructor আর তৈরি হয় না। Album b = std::move(a); লিখলে কোনো error আসে না — কারণ copy constructor আছে, আর const Album& একটি rvalue-কেও নিতে পারে। ফলে move-এর বদলে চুপচাপ পুরো album deep copy হয়, হাজার ছবিসহ। কোনো warning নেই, শুধু প্রোগ্রাম ধীর। সমাধান: destructor লিখলে move দুটিকে স্পষ্ট করে ফিরিয়ে আনুন — Album(Album&&) noexcept = default; আর Album& operator=(Album&&) noexcept = default; — আর তখন copy দুটিও = default লিখুন, কারণ move ঘোষণা করায় সেগুলো deleted হয়ে গেছে। ঠিক এজন্যই Rule of Five বলে, পাঁচটির কথাই ভাবুন।

Rule of Zero — সবচেয়ে ভালো নিয়ম: একটিও লিখবেন না

এতক্ষণ যা লিখলাম, তা পড়ে মনে হতে পারে C++ class লেখা মানেই পাঁচটি জটিল ফাংশন। আসলে উল্টো। ২০১২ সালে R. Martinho Fernandes একটি ব্লগ লেখায় যুক্তি দেন: যে class-এর কাজ রিসোর্সের মালিকানা সামলানো, সে শুধু সেই কাজই করবে; বাকি সব class এমন মালিক-টাইপকে member হিসেবে রাখবে আর কোনো special member লিখবে না। এর নাম Rule of Zero. Standard library ইতিমধ্যে মালিক-টাইপগুলো দিয়ে রেখেছে: std::string, std::vector, std::unique_ptr. আমাদের Image এবং album এভাবে লিখলে:

struct Image {                          // Rule of Zero — একটিও special member নেই
    int width = 0, height = 0;
    std::vector<int> px;                // vector নিজেই deep copy, move, delete জানে
};
struct Photo  { std::string caption; Image image; };
class  Album  {
    std::string title;
    std::vector<Photo> photos;
public:
    void add(Photo p) { photos.push_back(std::move(p)); }
};

Album trip = loadAlbum("coxs-bazar");   // ফেরত আসা মান: move বা copy elision
Album backup = trip;                    // deep copy — সব ছবি, সব caption
Album shared = std::move(trip);         // move — শুধু কয়েকটি pointer হাতবদল

এখানে কোনো destructor নেই, কোনো copy constructor নেই, কোনো new নেই — অথচ সব কাজ ঠিকঠাক। compiler-এর বানানো copy প্রতিটি member কপি করে, আর vector ও string নিজেরা deep copy করে। compiler-এর বানানো move প্রতিটি member move করে, আর সেগুলো noexcept — তাই std::vector<Album> বড় হওয়ার সময়ও move-ই হয়। একটিও বাগ লেখার সুযোগ নেই, কারণ কোনো কোডই লেখা হয়নি। C++ Core Guidelines-ও একই কথা বলে: special member এড়াতে পারলে এড়িয়ে চলুন (নিয়ম C.20), আর একটি লিখলে বা delete করলে সবগুলোর কথা ভাবুন (নিয়ম C.21).

তাহলে কোন class-এর জন্য কোন নিয়ম? প্রতিটি ধাপে নিজেকে প্রশ্নটি করুন:

member-গুলো দেখুন:
  std::string name;            → নিজের রিসোর্স সামলায়, আপনার নয়
  std::vector<Photo> photos;   → নিজের রিসোর্স সামলায়
  std::unique_ptr<Engine> e;   → নিজের রিসোর্স সামলায়
  int* px;   // new[] করেছি    → এটা আপনার দায়িত্ব

struct Student { std::string name; std::vector<int> marks; };

destructor লিখবেন না, copy/move লিখবেন না।
compiler-এর বানানো ছয়টিই সঠিক, দ্রুত, noexcept move সহ।
লক্ষ্য: আপনার class-গুলোর ৯০%-এর বেশি যেন এখানে পড়ে

int* px;                 →  std::vector<int> px;
Engine* e;               →  std::unique_ptr<Engine> e;
FILE* f;  (fopen/fclose) →  std::unique_ptr<FILE, Closer> f;   // custom deleter, পর্ব ১৭

মোড়ানো গেলে → আবার Rule of Zero

~T();                              // ছাড়ে
T(const T&);  T& operator=(const T&);   // deep copy — অথবা = delete
T(T&&) noexcept;  T& operator=(T&&) noexcept;   // চুরি করে, source খালি

class টি শুধু এই রিসোর্সটিই সামলাবে, আর কিছু নয়।
(Rule of Three = শুধু প্রথম তিনটি; move নেই বলে rvalue থেকেও কপি হয় — ঠিক, কিন্তু ধীর)

৮ · = delete আর = default — কপি-অযোগ্য টাইপ বানানো

কিছু জিনিস কপি করার কোনো অর্থই হয় না। একটি ডেটাবেস সংযোগের কথা ভাবুন: সার্ভারের সাথে একটি খোলা নেটওয়ার্ক সংযোগ, যার পেছনে সার্ভারে একটি session চলছে। এই object “কপি” করলে কী হবে — একই সংযোগ দুজনে ব্যবহার করবে, আর দুজনেই একদিন বন্ধ করবে? নাকি গোপনে নতুন সংযোগ খুলবে, যা ধীর আর ব্যয়বহুল? দুটোই বিভ্রান্তিকর। সবচেয়ে সৎ উত্তর: এটা কপি করা যাবে না। কিন্তু মালিকানা হাতবদল (move) পুরোপুরি যুক্তিসঙ্গত — যেমন একটি connection pool থেকে সংযোগ একটি কাজের হাতে দেওয়া।

C++11 থেকে এর জন্য আছে = delete. যে ফাংশন delete করা হয়, তাকে ডাকার চেষ্টা করলেই compile error:

class DatabaseConnection {
    DbHandle* h = nullptr;                       // C লাইব্রেরির handle
public:
    explicit DatabaseConnection(const std::string& url) : h(db_open(url.c_str())) {}
    ~DatabaseConnection() { if (h) db_close(h); }

    DatabaseConnection(const DatabaseConnection&) = delete;              // কপি নিষেধ
    DatabaseConnection& operator=(const DatabaseConnection&) = delete;

    DatabaseConnection(DatabaseConnection&& o) noexcept                  // হাতবদল চলে
        : h(std::exchange(o.h, nullptr)) {}
    DatabaseConnection& operator=(DatabaseConnection&& o) noexcept {
        if (this != &o) { if (h) db_close(h); h = std::exchange(o.h, nullptr); }
        return *this;
    }
};

DatabaseConnection a("db://shop");
DatabaseConnection b = a;              // error: use of deleted function
DatabaseConnection c = std::move(a);   // ঠিক আছে — a এখন খালি

এটাই একটি move-only type, ঠিক পর্ব ১৭-এর std::unique_ptr-এর মতো — আর আসলে unique_ptr নিজেও ঠিক এভাবেই তার copy delete করে রেখেছে। C++11-এর আগে প্রোগ্রামাররা copy constructor-কে private করে আর সংজ্ঞা না দিয়ে একই কাজ করতেন; error আসত, কিন্তু অস্পষ্ট বার্তায়, কখনো link করার সময়। = delete উদ্দেশ্যটা কোডেই লিখে রাখে।

আরও ভালো, Rule of Zero দিয়েও একই ফল পাওয়া যায়: handle-টিকে custom deleter সহ std::unique_ptr<DbHandle, Closer>-এ রাখুন। unique_ptr কপি-অযোগ্য, তাই compiler-এর বানানো copy নিজে থেকেই deleted হবে; move-এ unique_ptr move হবে, noexcept সহ; আর destructor-ও লিখতে হবে না। পাঁচটি ফাংশনের কাজ একটি member করে দিল।

উল্টো দিকে আছে = default: “compiler, আপনার স্বাভাবিক সংস্করণটিই বানিয়ে দিন।” এটি কাজে লাগে যখন কোনো নিয়মে সদস্যটি হারিয়ে যায় অথচ আপনি সেটা চান — যেমন অংশ ৭-এর Album-এ destructor রাখার পর move ফিরিয়ে আনা, বা অন্য constructor লেখার পর default constructor ফিরিয়ে আনা (Image() = default;). আর পর্ব ২৪-২৫-এ দেখবেন, inheritance-এর base class-এ virtual ~Shape() = default; লেখার চল আছে — তখনও এটি একটি ঘোষিত destructor, তাই move হারায়; দরকার হলে বাকিগুলোও = default করতে হয়।

৯ · AI-এর যুগে — boilerplate নয়, মালিকানা যাচাই

“একটি C++ class লেখো” বললে AI টুল প্রায়ই পাঁচটি special member সহ লম্বা কোড দেয়। দেখে পেশাদার মনে হয়, কিন্তু এই কোডের প্রতিটি লাইন একটি সম্ভাব্য বাগ। অনলাইনে Rule of Five শেখানোর অসংখ্য টিউটোরিয়াল আছে, যেখানে উদাহরণের খাতিরে raw pointer ব্যবহার করা হয়েছে — AI সেই ছাঁচই নকল করে, এমনকি যখন একটি std::vector member-ই যথেষ্ট ছিল। সাধারণ ভুলগুলো:

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

• প্রতিটি special member দেখে প্রশ্ন করেছি: এটা কি সত্যিই দরকার, নাকি একটি std::vector/std::string/std::unique_ptr member দিয়েই Rule of Zero হতো?
• নিজে লেখা move constructor আর move assignment-এ noexcept আছে, আর source-কে খালি (nullptr, size 0) রাখা হয়েছে
• copy assignment self-assignment-এ নিরাপদ (copy-and-swap বা this != &other), আর new ব্যর্থ হলে object ভাঙে না
• destructor আছে অথচ move নেই — এমন class খুঁজেছি; থাকলে move = default করেছি বা destructor সরিয়েছি
• যে জিনিস কপি করার মানে হয় না (সংযোগ, lock, ফাইল), তার copy = delete বা unique_ptr দিয়ে বন্ধ
• static_assert আর std::is_nothrow_move_constructible_v দিয়ে compile-এর সময়েই প্রতিশ্রুতিগুলো যাচাই করেছি, আর -fsanitize=address দিয়ে চালিয়ে দেখেছি double delete নেই