move semantics — কপি না করে সরানো

১ · একটিই প্রশ্ন — “এর ভেতর থেকে কি নিয়ে নেওয়া যায়?”

পর্ব ২২-এ আপনি move constructor লিখেছেন: source-এর pointer নিজের কাছে নিয়ে নেওয়া, আর source-কে খালি করে দেওয়া। সেখানে একটি প্রশ্ন আমরা পাশে সরিয়ে রেখেছিলাম — compiler কীভাবে জানে কখন copy constructor চালাতে হবে, আর কখন move constructor? দুটোই একই কাজের জন্য: একটি object থেকে আরেকটি বানানো। পার্থক্য শুধু এটুকু যে move source-কে খালি করে দেয়। তাই compiler-কে নিশ্চিত হতে হয়, source খালি হয়ে গেলে কারও কোনো ক্ষতি হবে না।

C++-এ দ্বিতীয় রোলটি হলো temporary object — যেমন একটি ফাংশনের ফেরত দেওয়া মান, বা a + b-এর ফল। এর কোনো নাম নেই, তাই এই লাইনের পর কেউ একে আর ব্যবহার করতেই পারবে না। প্রথম রোলটি হলো নাম আছে এমন একটি ভ্যারিয়েবল। আর সুপারভাইজারের লিখিত অনুমতি? সেটাই std::move.

এই পর্যবেক্ষণটি থেকেই পুরো move semantics দাঁড়িয়ে আছে। প্রতিটি expression-এর একটি value category থাকে। এটি একটি লেবেল, যা compiler-কে বলে দেয় এই জিনিসটি কতদিন বাঁচবে, আর তার ভেতর থেকে জিনিস নিয়ে নেওয়া নিরাপদ কি না। শুরুতে দুটি মোটা দাগের ভাগ মনে রাখুন:

নাম দুটি এসেছে C-এর পুরোনো যুগ থেকে: assignment-এর বাঁ দিকে (left) যা বসতে পারে তা lvalue, আর শুধু ডান দিকে (right) যা বসে তা rvalue. আজকের C++-এ এই ব্যাখ্যা আর পুরোপুরি খাটে না — একটি const int ভ্যারিয়েবল lvalue, অথচ সেটি assignment-এর বাঁ দিকে বসতে পারে না। তাই নামের উৎপত্তি ভুলে যান, একটি সহজ পরীক্ষা মনে রাখুন: & দিয়ে ঠিকানা নেওয়া গেলে সাধারণত lvalue; না গেলে rvalue.

২ · value category-র পরিবার — lvalue, prvalue, xvalue

C++11 move আনার সময় শুধু দুটি ভাগ যথেষ্ট রইল না। কারণ একটি তৃতীয় ধরনের জিনিস দরকার হলো: এমন object, যার নাম আছে, কিন্তু যাকে আপনি “মরে যাওয়ার মতো” ধরে নিতে বলছেন। তাই standard এখন তিনটি মৌলিক category রাখে, আর সেগুলোকে দুটি দলে সাজায়:

                expression
               /          \
         glvalue            rvalue
        (পরিচয় আছে)       (নিয়ে নেওয়া যায়)
        /        \        /        \
   lvalue          xvalue          prvalue
  name, v[0],    std::move(x),    42, a + b,
  *p, "Dhaka"    f() → T&&      f() → T

আর দুটি দলের নাম: glvalue (“generalized lvalue”) মানে lvalue বা xvalue — যাদের একটি নির্দিষ্ট পরিচয় আছে। rvalue মানে prvalue বা xvalue — যাদের থেকে move করা যায়। বেশিরভাগ দৈনন্দিন কাজে “lvalue বনাম rvalue” ভাবলেই চলে; xvalue নামটি দরকার হয় শুধু বোঝাতে যে std::move(x)-এর ফল ঠিক কী।

তত্ত্ব পড়ে মুখস্থ করার চেয়ে কয়েকটি expression ধরে ধরে দেখা সহজ। নিচের প্রতিটি ধাপে একটি expression, তার category আর “নেওয়া যায় কি?” প্রশ্নের উত্তর। শেষ দুটি ধাপে দুটি ছোট ফাঁদ আছে:

1std::string city = "Dhaka";2std::string  get_city();   // by value3std::string& get_ref();    // reference45city6city + "!"7std::move(city)8get_city()9get_ref()10"Dhaka"

৩ · rvalue reference আর overload — কে কোন ফাংশনে যায়

পর্ব ১০-এ দেখেছেন, T& হলো একটি reference — অন্য নামে একই object. C++11 আরেক ধরনের reference আনে: rvalue reference, যা লেখা হয় T&&. দুটির পার্থক্য হলো কীসের সাথে তারা যুক্ত (bind) হতে পারে:

খেয়াল করুন, const T& সবার সাথেই যুক্ত হয় — temporary-র সাথেও। C++98 থেকেই এটা চলে আসছে, আর এ কারণেই move আসার আগে temporary থেকে object বানাতে copy constructor (const T& নেয়) চলত। C++11-এর বুদ্ধিটা হলো একই নামের দ্বিতীয় একটি overload যোগ করা, যা শুধু rvalue নেয়। তখন overload resolution-এর একটি নিয়ম কাজ করে: rvalue আর্গুমেন্টের জন্য T&& হলো const T&-এর চেয়ে ভালো মিল। ফলে:

• lvalue দিলে শুধু const T& খাটে → কপির পথ।
• rvalue (prvalue বা xvalue) দিলে দুটোই খাটে, কিন্তু T&& জেতে → নিয়ে নেওয়ার পথ।
• const object-এ std::move দিলে টাইপ হয় const T&&; সেটি T&&-তে যুক্ত হতে পারে না (const হারাতে পারে না) → আবার const T& → নিঃশব্দে কপি।

move constructor আর copy constructor ঠিক এই জোড়া: T(const T&) আর T(T&&). শুধু constructor নয়, যেকোনো ফাংশনে আপনি এই জোড়া লিখতে পারেন। standard library নিজেও তাই করে — std::vector::push_back-এর দুটি overload আছে, একটি const T& নেয় (কপি করে), অন্যটি T&& নেয় (move করে)। নিচের প্রোগ্রামে একই ফাংশনের দুটি সংস্করণ নিজের নাম প্রিন্ট করে:

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

void take(const std::string& s) { std::println("const&  -> must copy  (size {})", s.size()); }
void take(std::string&& s)      { std::println("&&      -> may steal  (size {})", s.size()); }

std::string make_title() { return "Monthly sales report"; }

int main() {
    std::string name = "Rahim";
    take(name);                               // lvalue
    take(make_title());                       // prvalue
    take(std::move(name));                    // xvalue
    take(static_cast<std::string&&>(name));   // std::move er bhetore thik eta-i
    const std::string city = "Dhaka";
    take(std::move(city));                    // const xvalue
    std::println("name still holds \"{}\"", name);
}

৪ · std::move আসলে একটি cast — আর moved-from object

নামটা বিভ্রান্ত করে, তাই এর ভেতরটা একবার নিজের চোখে দেখে নিন। <utility>-এ std::move-এর সংজ্ঞা মোটামুটি এরকম (C++14 থেকে):

template <class T>
constexpr std::remove_reference_t<T>&& move(T&& t) noexcept {
    return static_cast<std::remove_reference_t<T>&&>(t);
}

পুরো ফাংশনে একটিই লাইন, আর সেটি একটি static_cast. কোনো মেমরি নড়ে না, কোনো pointer বদলায় না, কোনো constructor চলে না। remove_reference_t অংশটি শুধু নিশ্চিত করে যে আর্গুমেন্ট নিজে reference হলেও ফলাফল ঠিক T&& হবে (কেন দরকার, অংশ ৭-এ বুঝবেন)। optimization চালু থাকলে compiler এই ফাংশনের কোনো চিহ্নই রাখে না। std::move-এর একমাত্র কাজ: একটি lvalue-কে xvalue হিসেবে দেখানো, যাতে overload resolution T&&-এর সংস্করণ বাছে। তারপর আসল কাজ — নিয়ে নেওয়া — করে সেই সংস্করণ। ধাপে ধাপে দেখুন একটি লম্বা string-এর ক্ষেত্রে কী হয়:

stack                            heap
s { ptr  = @A000,
    size = 40, cap = 40 } ────►  [ 40 অক্ষর @A000 ]

s { ptr = @A000, size = 40, cap = 40 } ──► [ 40 অক্ষর ]

expression-এর টাইপ:  std::string&&
category:            xvalue
চলা machine instruction: ০টি

প্রার্থী ১:  string(const string&)   ← xvalue-ও নিতে পারে
প্রার্থী ২:  string(string&&)        ← xvalue-এর জন্য ভালো মিল

জয়ী: move constructor

stack                            heap
t { ptr  = @A000,
    size = 40, cap = 40 } ────►  [ 40 অক্ষর @A000 ]  ← একটুও নড়েনি
s { ptr  = নিজের ভেতরের ছোট buffer,
    size = 0 }        (সাধারণ বাস্তবায়নে)

s.size();          // চলে — কোনো পূর্বশর্ত নেই
s = "নতুন নাম";    // চলে — নতুন মান দেওয়া নিরাপদ
s.clear();         // চলে
}                  // s ধ্বংস — নিরাপদ, কিছু মোছার নেই

std::print("{}", s);  // চলে, কিন্তু কী ছাপবে তা ধরে নেবেন না
s[0];                 // বিপদ: s খালি হলে undefined behavior

পর্ব ২২-এ moved-from state-এর নিয়ম দেখেছেন; এখানে একটি ব্যবহারিক নিয়মে মনে রাখুন: std::move লেখা মানে প্রতিজ্ঞা — “এই লাইনের পর আমি এই নামটি আর পড়ব না, যতক্ষণ না নতুন মান দিচ্ছি।” এই প্রতিজ্ঞা ভাঙাকে বলে use-after-move, আর এটি AI-এর লেখা কোডের একটি সাধারণ বাগ। clang-tidy-এর bugprone-use-after-move নামের check এমন জায়গা খুঁজে দেয়।

৫ · move নিজে থেকে কখন হয় — ফেরত দেওয়া, RVO আর copy elision

সবচেয়ে সুখবর: ভালো C++ কোডে আপনাকে খুব কম জায়গায় std::move লিখতে হয়। বেশিরভাগ move compiler নিজেই করে, কারণ সে নিজেই চেনে কোন জিনিস মরতে চলেছে। দুটি জায়গা সবচেয়ে গুরুত্বপূর্ণ।

১. temporary পাঠানো। v.push_back(std::string("Rajshahi")) বা v.push_back(make_title()) — আর্গুমেন্ট prvalue, তাই T&&-এর overload নিজে থেকেই বাছা হয়। এখানে std::move লেখা অর্থহীন।

২. local ভ্যারিয়েবল ফেরত দেওয়া। ধরুন একটি দোকানের মাসিক রিপোর্ট বানানো হচ্ছে — হাজার লাইনের একটি লম্বা string:

std::string build_report(const std::vector<Sale>& sales) {
    std::string out;
    out.reserve(sales.size() * 32);
    for (const Sale& s : sales)
        out += std::format("{:<12}{:>10}\n", s.shop, s.amount);
    return out;                 // কপি নয়: NRVO, না হলে নিজে থেকেই move
}

std::string report = build_report(dhaka_sales);

C++98-এর যুগে অনেকে ভয় পেতেন, “বড় string by value ফেরত দিলে তো পুরোটা কপি হবে!” — তাই out-parameter (void build_report(..., std::string& out)) লিখতেন। আজ সেই ভয় অমূলক, তিনটি স্তরের কারণে:

• RVO (Return Value Optimization): return std::string(...)-এর মতো prvalue ফেরত দিলে object টি সরাসরি caller-এর ভ্যারিয়েবলের জায়গাতেই তৈরি হয়। C++17 থেকে এটি আর optimization নয়, ভাষার নিয়ম — একে বলে guaranteed copy elision. তখন copy বা move constructor থাকারও দরকার নেই।
• NRVO (Named RVO): নাম আছে এমন local (out) ফেরত দিলে compiler চাইলে out-কেই শুরু থেকে caller-এর জায়গায় বানাতে পারে। এটা অনুমোদিত, কিন্তু নিশ্চিত নয়। উপরের মতো সরল ক্ষেত্রে GCC, Clang, MSVC সাধারণত এটা করে।
• নিজে থেকে move (implicit move): NRVO না হলেও, যেমন দুটি আলাদা local-এর একটি শর্তসাপেক্ষে ফেরত দিলে, C++11 থেকে নিয়ম হলো return out;-এ out-কে প্রথমে rvalue হিসেবে ধরা হয়। ফলে কপি নয়, move চলে। C++20 আর C++23 এই নিয়মটি আরও সরল ও বিস্তৃত করেছে।

main-এর stack frame
┌──────────────────────────────┐
│ report : [ খালি জায়গা, এখনো তৈরি হয়নি ] │ ← ঠিকানা @F100
└──────────────────────────────┘
compiler গোপনে build_report-কে দেয়: "ফল বানাও @F100-এ"

main frame:          report @F100  ◄──┐
                                      │ একই মেমরি
build_report frame:  out  ────────────┘
                     (out-এর আলাদা কোনো জায়গা নেই)

@F100 { ptr = @B000, size = 32000 } ──► [ রিপোর্টের ৩২ হাজার অক্ষর ]

caller-এর report ইতিমধ্যেই ভরে উঠছে,
যদিও ফাংশন এখনো শেষ হয়নি

build_report frame ভাঙল — out ধ্বংস হলো না, কারণ
out আসলে report-ই

main frame:  report @F100 ──► [ ৩২ হাজার অক্ষর ]   ✓

return std::string(n, '-');  // prvalue: C++17 থেকে নিশ্চিত ০ copy, ০ move
return out;                  // NRVO হতে পারে; না হলে ১টি move, কপি কখনো নয়
return std::move(out);       // NRVO বন্ধ! সবসময় ১টি move — বেশি কাজ

একটি বাড়তি সুবিধা: C++17-এর নিশ্চিত elision-এর ফলে যে টাইপ কপি বা move কিছুই করা যায় না (যেমন std::mutex ধরে রাখা একটি class), তাকেও একটি factory ফাংশন থেকে prvalue হিসেবে ফেরত দেওয়া যায় — কোনো constructor ডাকারই প্রয়োজন পড়ে না। ভাবনার প্রশ্ন ৩-এ এর পেছনের নকশাটা দেখবেন।

৬ · sink parameter — by value নিন, তারপর move করুন

কিছু ফাংশনের কাজই হলো আর্গুমেন্টটি নিজের কাছে রেখে দেওয়া: একটি setter, যে নাম জমা রাখে; একটি constructor, যে playlist জমা রাখে; একটি add, যে vector-এ ঢোকায়। এমন প্যারামিটারকে বলে sink parameter — পানি যেমন sink-এ গিয়ে আর ফেরে না। এখানে দুটি অবস্থা সামলাতে হয়: caller হয়তো তার জিনিসটি পরেও রাখতে চায় (তাহলে কপি দরকার), নয়তো আর চায় না (তাহলে move যথেষ্ট)।

পুরোনো সমাধান ছিল দুটি overload: set_name(const std::string&) আর set_name(std::string&&). দুটি প্যারামিটার হলে চারটি overload, তিনটিতে আটটি — দ্রুত অসম্ভব হয়ে যায়। আধুনিক সহজ সমাধান: by value নিন, তারপর ভেতরে move করুন।

class Customer {
    std::string name_;
public:
    void set_name(std::string n) { name_ = std::move(n); }   // একটি ফাংশন, দুই কাজ
};

c.set_name(input);              // lvalue: n-এ ১টি কপি, তারপর ১টি move
c.set_name(read_line());        // prvalue: n সরাসরি তৈরি, তারপর ১টি move
c.set_name(std::move(input));   // xvalue: n-এ ১টি move, তারপর ১টি move

কপি তখনই হয়, যখন caller সত্যিই কপি চায় — lvalue দিয়ে। আর প্রতিটি ক্ষেত্রে মাত্র একটি বাড়তি move, যা string বা vector-এর বেলায় কয়েকটি pointer বদলানো মাত্র। এই কৌশলটি নিচে দেখুন — একটি music player অ্যাপ, যেখানে ব্যবহারকারীর playlist player-এর কাছে যায়। Song-এর copy আর move constructor নিজেদের হিসাব রাখে:

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

struct Song {
    std::string title;  static inline int copies = 0, moves = 0;
    explicit Song(const char* t) : title(t) {}
    Song(const Song& o) : title(o.title) { ++copies; }
    Song(Song&& o) noexcept : title(std::move(o.title)) { ++moves; }
};
struct Player {  std::vector<Song> queue;
    void load(std::vector<Song> list) { queue = std::move(list); }   // sink parameter
};
void show(const char* step) { std::println("{:<24} copies={} moves={}", step, Song::copies, Song::moves); Song::copies = Song::moves = 0; }
int main() {
    std::vector<Song> mine{Song("Ekla Cholo Re"), Song("Bhalo Theko"), Song("Amar Sonar Bangla")};
    const std::vector<Song> backup = mine;   Song::copies = 0;   Player p;
    p.load(mine);               show("load(mine)");
    p.load(std::move(mine));    show("load(std::move(mine))");
    p.load(std::move(backup));  show("load(std::move(backup))");
}

৭ · forwarding reference আর std::forward — perfect forwarding

এবার একটি নতুন সমস্যা। একটি রেস্তোরাঁর অ্যাপে make_order(...) নামের একটি factory ফাংশন চাই, যা অর্ডারের আইডি দেয়, লগ লেখে, তারপর যে আর্গুমেন্টগুলো পেয়েছে সেগুলো দিয়ে একটি Order বানায়। প্রশ্ন: factory-র প্যারামিটার কী টাইপের হবে, যাতে caller lvalue দিলে Order-এর কাছে lvalue যায় (কপি), আর temporary দিলে temporary যায় (move)? const T& নিলে সবকিছু lvalue হয়ে যায় — move হারায়। T&& নিলে lvalue নেওয়াই যায় না। প্রতিটি আর্গুমেন্টের জন্য দুটি overload লেখা অসম্ভব। এটাই “forwarding problem”, যা move semantics-এর সাথে একই সময়ে সমাধান করা হয়েছিল।

template-এর T&& আলাদা জিনিস

সমাধানটি লুকিয়ে আছে template argument deduction-এর একটি বিশেষ নিয়মে। যখন একটি function template-এর প্যারামিটার ঠিক T&&, আর T সেই ডাকের সময়েই deduce হচ্ছে, তখন এটি rvalue reference নয় — এটি forwarding reference. এটি lvalue আর rvalue দুটোই নিতে পারে, আর কোনটি পেল সেই তথ্য T-এর ভেতরে লিখে রাখে:

• lvalue std::string দিলে T deduce হয় std::string& (একটি reference!)।
• rvalue std::string দিলে T deduce হয় শুধু std::string.

কিন্তু T = std::string& হলে প্যারামিটার T&& হয়ে দাঁড়ায় std::string& && — reference-এর reference, যা সাধারণ কোডে লেখাই যায় না। এখানে কাজ করে reference collapsing-এর নিয়ম, পুরোটা একটি টেবিলে:

তাহলে ফাংশনের ভেতরে x lvalue হিসেবে এসেছিল নাকি rvalue হিসেবে, সেটা T দেখেই বোঝা যায়। কিন্তু মনে আছে অংশ ২-এর সতর্কতা? x একটি নাম, তাই ভেতরে x লিখলে সবসময় lvalue. মূল পরিচয় ফিরিয়ে আনতে লাগে std::forward: std::forward<T>(x) T দেখে সিদ্ধান্ত নেয় — T reference হলে lvalue ফেরত দেয়, না হলে rvalue (ভেতরে এটিও একটি static_cast<T&&>, যা collapsing নিয়মে ঠিক ফল দেয়)। এক কথায়: std::move সবসময় rvalue বানায়; std::forward শর্তসাপেক্ষে — শুধু তখনই, যখন মূল আর্গুমেন্টটি rvalue ছিল।

1void target(const std::string&);  // কপি2void target(std::string&&);       // move3template <class T>4void wrap(T&& x) {5    target(x);                // ভুল6    target(std::forward<T>(x)); // ঠিক7}8wrap(name);                 // lvalue9wrap(std::string("Rina"));  // prvalue

এবার রেস্তোরাঁর factory. variadic template দিয়ে যেকোনো সংখ্যক আর্গুমেন্ট নেওয়া যায়, আর ... দিয়ে প্রতিটিকে আলাদাভাবে forward করা যায়:

struct Order {
    std::string customer;
    std::vector<std::string> items;
    int table;
    Order(std::string c, std::vector<std::string> i, int t)
        : customer(std::move(c)), items(std::move(i)), table(t) {}
};

template <class... Args>
Order make_order(Args&&... args) {
    log_new_order();                                  // বাড়তি কাজ
    return Order(std::forward<Args>(args)...);        // প্রতিটি আর্গুমেন্ট যেমন এসেছিল
}

std::string regular = "Karim bhai";
auto o1 = make_order(regular, std::vector<std::string>{"cha", "singara"}, 4);
// regular → কপি হয়ে যায় (caller-এর নাম অক্ষত), vector-টি → move, 4 → int

standard library-র অনেক পরিচিত ফাংশন ঠিক এই ছাঁচে লেখা: std::make_unique আর্গুমেন্টগুলো object-এর constructor-এ forward করে, আর emplace_back সেগুলো vector-এর ভেতরের জায়গায় সরাসরি constructor-এ পাঠায় — তাই v.emplace_back("Karim", items, 4) লিখলে কোনো অস্থায়ী Order-ই তৈরি হয় না।

কোনটি forwarding reference, কোনটি নয়

নিয়মটি সংকীর্ণ, তাই এখানে ভুল হয় সবচেয়ে বেশি — মানুষেরও, AI-এরও:

সহজ নিয়মে মনে রাখুন: rvalue reference পেলে std::move, forwarding reference পেলে std::forward. উল্টোটা করলে বাগ: forwarding reference-এ std::move লিখলে caller-এর lvalue-ও চুপচাপ খালি হয়ে যায়। আর একটি forwarded আর্গুমেন্টকে একবারের বেশি forward করবেন না — প্রথমবারেই সেটি move হয়ে যেতে পারে।

৮ · move-only টাইপ, container থেকে move, আর যখন move দ্রুত নয়

যাদের শুধু move করা যায়

পর্ব ২২-এ দেখেছেন, কিছু জিনিসের কপি করার কোনো অর্থ নেই। standard library-তে এমন move-only type অনেক: std::unique_ptr (একটি heap object-এর একমাত্র মালিক), std::thread (একটি চলমান thread-এর হাতল, পর্ব ৪৫), std::fstream আর std::ofstream (একটি খোলা ফাইল, পর্ব ৪৪), std::unique_lock, std::future. এদের সাথে কাজের নিয়ম সহজ: কপি চাইলে compile error, হাতবদল করতে চাইলে std::move.

std::vector<std::unique_ptr<Driver>> fleet;
auto d = std::make_unique<Driver>("Sohel", "Dhaka Metro-Ga 11");
fleet.push_back(d);                     // error: unique_ptr কপি করা যায় না
fleet.push_back(std::move(d));          // ঠিক — d এখন নিশ্চিতভাবে nullptr
fleet.push_back(std::make_unique<Driver>("Rina", "Ga 12"));   // prvalue — move নিজে থেকেই

std::ofstream make_log() { return std::ofstream("trip.log"); }  // move-only টাইপও by value ফেরত

container থেকে বের করে আনা

কখনো একটি vector-এর উপাদানগুলো আরেক জায়গায় পাঠাতে হয়, আর মূল vector আর লাগে না। সাধারণ range-for-এ auto& দিয়ে প্রতিটি উপাদানকে move করা যায়; আর <algorithm>-এ একটি তিন-আর্গুমেন্টের std::move algorithm আছে (একই নাম, কিন্তু <utility>-এর cast থেকে আলাদা ফাংশন), যা একটি range-এর প্রতিটি উপাদান গন্তব্যে move করে:

for (auto& song : today) player.add(std::move(song));     // প্রতিটি move
today.clear();                                             // moved-from উপাদানগুলো ফেলে দিন

std::move(old_q.begin(), old_q.end(), std::back_inserter(new_q));   // algorithm সংস্করণ

Task t = std::move(tasks.back());   // শেষেরটি বের করা — move, তারপর
tasks.pop_back();                   // খালি খোলসটি সরানো

দুটি সতর্কতা। এক, move করার পর মূল container-এ উপাদানগুলো এখনো আছে — moved-from অবস্থায়, সংখ্যা একই। তাই কাজ শেষে clear() করুন, বা আর পড়বেন না। দুই, std::map বা std::set-এর key const, তাই std::move(it->first) চুপচাপ কপি করে। key সত্যিই বের করে আনতে হলে C++17-এর extract ব্যবহার করুন (পর্ব ৩১)।

যখন move কপির চেয়ে দ্রুত নয়

move-এর গতি আসে একটি জিনিস থেকে: object-এর আসল ডেটা অন্য কোথাও (heap-এ) থাকে, আর object নিজে শুধু তার ঠিকানা রাখে। ঠিকানা হাতবদল সস্তা। কিন্তু যেখানে ডেটা object-এর নিজের ভেতরেই থাকে, সেখানে “নিয়ে নেওয়ার” মতো কোনো ঠিকানা নেই — move করতেও সব বাইট কপি করতে হয়:

তাই int বা Point-এ std::move লেখা ক্ষতিকর নয়, কিন্তু অর্থহীন — আর পাঠকের মনে ভুল ধারণা জাগায় যে এখানে কিছু দামি ঘটছে। ছোট string-এর ক্ষেত্রেও move সস্তা, কারণ কয়েকটি বাইট কপি করা খুব দ্রুত। পরিমাপের আগে “move দিয়ে গতি বাড়াই” ভাবনা থেকে সাবধান থাকুন।

৯ · AI-এর যুগে — ছিটানো std::move চিনে ফেলা

AI টুলগুলো “আধুনিক, দ্রুত C++” লিখতে বললে প্রায়ই সব জায়গায় std::move ছিটিয়ে দেয়, যেন যত বেশি move, তত বেশি গতি। দেখে পেশাদার মনে হয়, কিন্তু এই পর্বে আপনি দেখেছেন — ভুল জায়গার move হয় অর্থহীন, হয় ধীর, হয় বাগ। AI-এর কোড পড়ার সময় এই টেবিলটি পাশে রাখুন:

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

• প্রতিটি return std::move(...) খুঁজেছি; ফেরত দেওয়া জিনিসটা সাধারণ local বা by value প্যারামিটার হলে std::move মুছে দিয়েছি
• প্রতিটি std::move(x)-এর পরের লাইনগুলো পড়েছি: নতুন মান দেওয়ার আগে কোথাও x পড়া হচ্ছে না
• যে জিনিসে move করা হচ্ছে তা const নয় (const হলে move আসলে কপি)
• template-এ T&& দেখলে মিলিয়েছি: সেটি সত্যিই forwarding reference কি না, আর সেখানে std::forward<T> আছে, std::move নয়
• নিজে লেখা move constructor আর move assignment-এ noexcept আছে; সম্ভব হলে Rule of Zero
• -Wall -Wextra দিয়ে compile করে -Wpessimizing-move আর -Wredundant-move warning দেখেছি, আর clang-tidy-এর use-after-move check চালিয়েছি