map, set আর unordered_map — চাবি দিয়ে খোঁজা

১ · মূল ধারণা — অবস্থান নয়, চাবি দিয়ে খোঁজা

পর্ব ৩০-এ আপনি sequence container দেখেছেন — vector, deque, list. এদের সবার একটি মিল: উপাদানগুলো একটি সারিতে থাকে, আর প্রতিটির একটি অবস্থান আছে — প্রথম, দ্বিতীয়, তৃতীয়। কিন্তু বাস্তবের বহু প্রশ্ন অবস্থান দিয়ে করা হয় না। “রোল ১০৪২-এর ফল কী?” “Karim-এর ফোন নম্বর কত?” “এই পণ্যের দাম কত?” — এখানে আপনার হাতে আছে একটি চাবি (রোল, নাম, পণ্যের কোড), আর আপনি চান তার সাথে যুক্ত তথ্য।

vector দিয়েও এ কাজ করা যায়: std::vector<Student> রেখে প্রতিবার শুরু থেকে লুপ চালিয়ে রোল মেলানো। ১০০ জন ছাত্রছাত্রীতে এটি টের পাওয়া যায় না। কিন্তু একটি বোর্ড পরীক্ষার ফলাফলে কয়েক লাখ রোল থাকে, আর সার্ভারে প্রতি সেকেন্ডে শত শত অনুরোধ আসে। প্রতিটি অনুরোধে লাখ উপাদানে লুপ (O(n)) মানে সার্ভার বসে যাওয়া। associative container এই খোঁজাকে করে O(log n) — দশ লাখ উপাদানে মোটামুটি বিশটি তুলনা — বা গড়ে O(1), অর্থাৎ আকার যত বড়ই হোক, প্রায় একই সময়।

প্রতিটি উপাদান তাই একটি key-value pair: চাবি (রোল ১০৪২) আর মান (GPA 4.75). C++ standard library-তে এমন আটটি container আছে, দুটি পরিবারে ভাগ করা:

২ · std::map — ভেতরে একটি সাজানো tree

std::map চাবিগুলো সবসময় সাজানো রাখে। C++ standard শুধু বলে: খোঁজা, ঢোকানো আর মোছা হবে logarithmic সময়ে, আর ক্রমে হাঁটা যাবে। কোন data structure দিয়ে, তা বলে না। কিন্তু GCC-র libstdc++, Clang-এর libc++ আর Microsoft-এর STL — তিনটিই একই জিনিস ব্যবহার করে: red-black tree, এক ধরনের balanced tree.

ভিত্তিটা একটি binary search tree (BST): প্রতিটি node-এর বাম দিকে সব ছোট চাবি, ডান দিকে সব বড়। খুঁজতে মূল (root) থেকে শুরু করে প্রতিটি node-এ একটি প্রশ্ন — “ছোট না বড়?” — আর প্রতি উত্তরে প্রায় অর্ধেক tree বাদ। কিন্তু সাধারণ BST-এর একটি দুর্বলতা আছে: চাবিগুলো যদি আগে থেকেই সাজানো ক্রমে আসে (রোল ১, ২, ৩, ৪…), প্রতিটি নতুন node আগেরটির ডানে বসে, আর tree হয়ে যায় একটি লম্বা শিকল — খোঁজা আবার O(n). red-black tree প্রতিবার ঢোকানোর পর ছোট একটি পুনর্বিন্যাস (rotation) করে উচ্চতা নিয়ন্ত্রণে রাখে। ঘটনাটি ধাপে ধাপে দেখুন — প্রতিটি ধাপে আগে নিজে অনুমান করুন, নতুন চাবি কোথায় বসবে:

      10(B)

B = কালো node, R = লাল node
নিয়ম: মূল সবসময় কালো

      10(B)
         \
         20(R)     ← নতুন node সবসময় লাল হয়ে ঢোকে

      10(B)
         \
         20(R)
            \
            30(R)  ← লাল বাবার লাল সন্তান: নিয়ম ভাঙল!

সাধারণ BST হলে এভাবেই থাকত — একটি শিকল,
খুঁজতে n ধাপ।

          20(B)
         /    \
      10(R)   30(R)

বামে ছোট, ডানে বড় — ক্রম অটুট।
উচ্চতা ৩ থেকে কমে ২।

          20(B)
         /    \
      10(B)   30(B)
              /
           25(R)

শুধু রং বদল (rotation লাগেনি)।
ক্রমে হাঁটলে (বাম → node → ডান):  10  20  25  30

এই ছবি থেকে map-এর তিনটি স্বভাব বেরিয়ে আসে, যা মনে রাখার মতো। এক, লুপ চালালে উপাদান আসে চাবির ক্রমে — আলাদা করে sort করতে হয় না। দুই, প্রতিটি উপাদান আলাদা node-এ, তাই map একটি node-based container: ঠিকানা স্থির থাকে, কিন্তু node-গুলো মেমরিতে ছড়িয়ে থাকে, আর vector-এর মতো cache-বান্ধব নয়। তিন, চাবির টাইপের জন্য শুধু “ছোট কি না” তুলনা লাগে — ডিফল্টভাবে operator<.

৩ · map-এর সাথে কাজ — ঢোকানো, খোঁজা, হাঁটা, মোছা

একটি শব্দ-গণনার প্রোগ্রাম দিয়ে শুরু করুন — অনুসন্ধান ইঞ্জিন থেকে শুরু করে ভাষা-মডেলের ডেটা প্রস্তুতিতে এই কাজটি আসল কাজের প্রথম ধাপ। বাক্যটি বাংলা, তবে রোমান হরফে লেখা, যাতে যেকোনো অনলাইন compiler-এ আউটপুট ঠিক দেখায়:

#include <map>
#include <print>
#include <sstream>
#include <string>

int main() {
    std::istringstream in("ami cha khai ami bhat khai ami");
    std::map<std::string, int> freq;               // word -> count, sorted by word
    for (std::string w; in >> w; ) ++freq[w];      // missing word starts at 0
    for (const auto& [word, n] : freq) std::println("{:<5} {}", word, n);

    std::println("size before: {}", freq.size());
    if (freq["dim"] == 0) std::println("no dim");  // trap: this INSERTS "dim"
    std::println("size after:  {}", freq.size());
    if (auto it = freq.find("cha"); it != freq.end())
        std::println("cha -> {}", it->second);      // one lookup, no insert
    std::println("has rice? {}", freq.contains("rice"));
}

লুপের auto& [word, n] হলো পর্ব ১২-এর structured binding. map-এর প্রতিটি উপাদান আসলে একটি std::pair<const std::string, int> — first চাবি, second মান। structured binding দুটিকে সুন্দর নাম দেয়। খেয়াল করুন চাবির টাইপে const: map-এর ভেতরে থাকা অবস্থায় চাবি বদলানো যায় না (কেন, তা ভাবনার প্রশ্ন ৫-এ)। আর auto& না লিখে auto লিখলে প্রতিটি pair কপি হতো — বড় string-এ অকারণ খরচ।

ঢোকানোর চারটি উপায় — কোনটি কখন

map-এ উপাদান ঢোকানোর একাধিক ফাংশন আছে, আর এদের পার্থক্য হলো একটি প্রশ্নে: চাবিটি আগে থেকেই থাকলে কী হবে?

std::map<int, std::string> result;               // roll -> grade

result.insert({1042, "A+"});            // নতুন: ঢুকল
result.insert({1042, "B"});             // আছে: কিছুই বদলায় না! মান এখনো "A+"
auto [it, added] = result.insert({1043, "A"});   // added == true

result.try_emplace(1044, "A-");         // C++17: না থাকলে বানাও, থাকলে ছোঁবেও না
result.insert_or_assign(1042, "A");     // C++17: থাকলে বদলাও, না থাকলে ঢোকাও
result[1045] = "B+";                    // কাজ করে, কিন্তু আগে ডিফল্ট "" বানিয়ে তারপর বদলায়

result.erase(1043);                     // চাবি দিয়ে মোছা; ফেরত দেয় কয়টি মুছল (0 বা 1)

insert পুরোনো মান কখনো বদলায় না — এটি অনেককে অবাক করে। ফেরত আসা জোড়ার bool বলে দেয় ঢোকানো হলো কি না। try_emplace একই কাজ করে, কিন্তু আরও সাশ্রয়ী: চাবি থাকলে আর্গুমেন্ট থেকে কোনো object বানায়ও না, move-ও করে না। insert_or_assign হলো “থাকলে বদলাও” — আর m[k] = v-এর মতো হলেও এটি ডিফল্ট মান বানানোর বাড়তি ধাপ নেয় না, আর জানিয়ে দেয় নতুন ঢুকল কি না। এই দুটি C++17 থেকে আছে।

৪ · operator[]-এর ফাঁদ — পড়তে গিয়ে লিখে ফেলা

অন্য ভাষা থেকে আসা প্রোগ্রামারদের কাছে m[key] দেখতে নিছক “পড়া”। Python-এ d["x"] চাবি না থাকলে error দেয়। C++-এ নিয়মটা আলাদা: m[key] সবসময় একটি reference ফেরত দেয়, যাতে আপনি m[key] = 5 লিখতে পারেন। কিন্তু চাবিটি না থাকলে reference দেওয়ার মতো কিছু নেই — তাই C++ আগে একটি ডিফল্ট মান দিয়ে নতুন উপাদান ঢুকিয়ে দেয়, তারপর তার reference দেয়। int-এর ডিফল্ট 0, string-এর ফাঁকা "". কোনো error নেই, কোনো warning নেই। একটি দোকানের স্টক-হিসাবে ঘটনাটি দেখুন:

1std::map<std::string, int> stock{{"pen", 5}};2if (stock["pencil"] > 0) std::println("in stock");3std::println("items: {}", stock.size());4if (auto it = stock.find("eraser");5    it != stock.end() && it->second > 0) { ... }

এই ফাঁদের দুটি পার্শ্ব-প্রমাণ আছে, যা compiler নিজেই দেয়। প্রথমত, একটি const std::map-এ operator[] ডাকাই যায় না — compile error — কারণ সেটি map বদলাতে পারে। তাই ফাংশনে const std::map<...>& নিলে আপনি বাধ্য হন find বা at ব্যবহার করতে। দ্বিতীয়ত, মানের টাইপের default constructor না থাকলে [] compile হয় না, কারণ ডিফল্ট মান বানানোর উপায় নেই।

৫ · set, multimap আর multiset

অনেক সময় চাবির সাথে কোনো মান লাগে না — শুধু জানতে চান কোনো কিছু “তালিকায় আছে কি না”। একটি ওয়েবসাইটে আজ কতজন আলাদা দর্শক এসেছেন? একই দর্শক দশবার পাতা খুললেও তিনি একজন। এখানে std::set: প্রতিটি মান একবারই থাকে, সাজানো ক্রমে।

std::set<int> visitors;
for (int id : {7, 3, 7, 9, 3, 7}) visitors.insert(id);   // একই id আবার এলে কিছুই হয় না
// visitors = {3, 7, 9}, visitors.size() == 3

auto [pos, isNew] = visitors.insert(5);   // isNew == true
std::set<int> uniq(v.begin(), v.end());   // একটি vector থেকে আলাদা মানগুলো, সাজানো

set-এর উপাদান চাবি নিজেই, তাই iterator দিয়ে সেটি বদলানো যায় না — *it = 10 compile error. বদলাতে চাইলে পুরোনোটি মুছে নতুনটি ঢোকাতে হয়।

std::multimap আর std::multiset একই চাবি একাধিকবার রাখতে দেয়। একই দামের দুটি পণ্য, একই নম্বর পাওয়া কয়েকজন ছাত্রছাত্রী — এমন ক্ষেত্রে। multimap-এ operator[] নেই (কোন মানটির reference দেবে?); একই চাবির সবগুলো পেতে equal_range(k). আর multiset-এ একটি সূক্ষ্ম ফাঁদ: ms.erase(5) সব 5 মুছে দেয়; শুধু একটি মুছতে চাইলে ms.erase(ms.find(5)) — আর তার আগে নিশ্চিত হোন find end() দেয়নি।

৬ · unordered_map — hash table: চাবি থেকে সরাসরি ঘরে

map প্রতিটি খোঁজায় tree বেয়ে নামে — log n ধাপ। এর চেয়ে দ্রুত হতে পারে কি? একটি সরকারি অফিসের নথি-ঘর ভাবুন, যেখানে ১০০টি তাক। নিয়ম: ফাইল নম্বরের শেষ দুই অঙ্ক দেখে সেই তাকে রাখা হবে। ফাইল ৪৫৬৭৩ যায় তাক ৭৩-এ। খুঁজতেও একই হিসাব — সরাসরি তাক ৭৩, সেখানে হয়তো তিন-চারটি ফাইল, একটু দেখলেই পাওয়া যায়। তাক যত বেশি, প্রতি তাকে ফাইল তত কম। এটাই hash table.

C++11 থেকে std::unordered_map আর std::unordered_set এভাবেই কাজ করে। তিনটি অংশ: একটি hash function (চাবি থেকে একটি বড় পূর্ণসংখ্যা — standard library-তে std::hash), একসারি bucket (তাক), আর একই bucket-এ পড়া চাবিদের তালিকা। নিচের সংখ্যাগুলো বোঝানোর জন্য বানানো; আসল hash অনেক বড় সংখ্যা, আর bucket-এর সংখ্যাও বাস্তবায়নভেদে আলাদা:

std::hash<std::string>{}("rahim")  →  9137   (উদাহরণের সংখ্যা)

একই চাবি থেকে সবসময় একই সংখ্যা আসবে —
এটাই hash function-এর একমাত্র বাধ্যতামূলক নিয়ম।

bucket = 9137 % 8 = 1

[0] —
[1] → rahim:90
[2] —   [3] —   [4] —   [5] —   [6] —   [7] —

hash("karim") = 6017,  6017 % 8 = 1   ← আবার bucket 1!

[1] → rahim:90 → karim:75     (একই bucket-এ একটি তালিকা)
[4] → nila:88                 (hash 4100 % 8 = 4)

ভিন্ন চাবি, একই bucket — একে বলে collision.

hash("karim") = 6017 → bucket 1
  rahim == karim ?  না
  karim == karim ?  হ্যাঁ  → iterator ফেরত

পুরো table নয়, শুধু একটি bucket-এর ছোট তালিকা দেখা হলো।

load factor = size / bucket_count = 9 / 8 = 1.125
max_load_factor() = 1.0  → সীমা পার!

bucket বাড়ানো হলো (যেমন 8 → 17), প্রতিটি চাবির
bucket নতুন করে হিসাব:  9137 % 17 = 8,  6017 % 17 = 16 ...
→ সব iterator অচল;  উপাদানের pointer/reference ঠিক থাকে।

ক্রমের ওপর কখনো ভরসা নয়

unordered_map-এ লুপ চালালে উপাদান আসে bucket-এর ক্রমে — যা নির্ভর করে hash-এর মান, bucket-এর সংখ্যা, ঢোকানোর ইতিহাস আর library-র বাস্তবায়নের ওপর। GCC-তে এক ক্রম, MSVC-তে আরেক; একই প্রোগ্রামে আরও কয়েকটি উপাদান ঢোকালে rehash হয়ে পুরো ক্রমই বদলে যেতে পারে। তাই unordered_map-এর লুপের আউটপুট কখনো পরীক্ষার “প্রত্যাশিত ফল” বানাবেন না, আর কাউকে সাজানো তালিকা দেখাতে চাইলে map ব্যবহার করুন, অথবা উপাদানগুলো একটি vector-এ নিয়ে sort করুন। এ কারণেই এই পর্বের কোনো চালানো কোড unordered_map-এর লুপ ছাপায় না।

খারাপ ক্ষেত্র আর অবিশ্বস্ত চাবি

“গড়ে O(1)” কথাটার “গড়ে” অংশটি গুরুত্বপূর্ণ। যদি অনেক চাবি একই bucket-এ পড়ে, সেই bucket-এর তালিকা লম্বা হয়, আর খোঁজা নেমে আসে O(n)-এ — সব চাবি এক bucket-এ পড়লে hash table একটি linked list ছাড়া কিছু নয়। সাধারণ ডেটায় এটি প্রায় কখনো হয় না। কিন্তু চাবিগুলো যদি বাইরের, অবিশ্বস্ত কারও কাছ থেকে আসে — একটি ওয়েব ফর্মের ফিল্ডের নাম, নেটওয়ার্ক থেকে আসা ID — তাহলে কেউ ইচ্ছা করে বেছে বেছে একই bucket-এর চাবি পাঠিয়ে সার্ভারকে ধীর করে দিতে পারে। এই ঝুঁকির নাম hash flooding. প্রতিরক্ষার সাধারণ উপায়: একটি অনুরোধে চাবির সংখ্যা সীমিত রাখা, প্রোগ্রাম চালুর সময় এলোমেলো বীজ (seed) মেশানো hash ব্যবহার করা, বা সংবেদনশীল জায়গায় map-এর মতো tree-ভিত্তিক container, যার খারাপ ক্ষেত্রও O(log n). C++ standard std::hash-কে এলোমেলো করার বাধ্যবাধকতা দেয় না, আর প্রচলিত বাস্তবায়নে এটি নির্দিষ্ট (deterministic) — যেমন GCC-র libstdc++-এ একটি int-এর hash সাধারণত সংখ্যাটি নিজেই।

৭ · নিজের টাইপকে চাবি বানানো

int বা string চাবি হিসেবে সরাসরি চলে, কারণ এদের তুলনা আর hash দুটোই তৈরি আছে। কিন্তু যদি চাবি হয় একটি struct — ধরুন একটি পরীক্ষার আসন: ভবন আর কক্ষ নম্বর? তখন container-কে বলে দিতে হয়, এই টাইপকে কীভাবে তুলনা বা hash করবে।

map আর set-এর জন্য — “ছোট কি না”

map ডিফল্টভাবে std::less<Key> ব্যবহার করে, যা a < b ডাকে। সবচেয়ে সহজ পথ পর্ব ২৩-এর <=> (three-way comparison) default করে দেওয়া — compiler সদস্যগুলো ঘোষণার ক্রমে তুলনা করে:

struct Seat {
    int building, room;
    auto operator<=>(const Seat&) const = default;   // C++20: <, ==, > সব তৈরি
};
std::map<Seat, std::string> plan;
plan[{2, 305}] = "roll 1042";      // building আগে, তারপর room দিয়ে সাজানো

// নিজের নিয়ম চাইলে তুলনার object দিন, যেমন বড় থেকে ছোট:
std::map<int, std::string, std::greater<>> rank;

নিজে তুলনা লিখলে একটি কঠিন নিয়ম মানতে হয়: strict weak ordering. সহজ ভাষায় — a < a কখনো সত্য নয়, a < b আর b < c হলে a < c, আর যে দুটি চাবির কোনোটিই অন্যটির চেয়ে ছোট নয়, map তাদের “একই চাবি” ধরে। সবচেয়ে সাধারণ ভুল <= দিয়ে তুলনা লেখা — তখন a <= a সত্য, আর map-এর আচরণ undefined: খোঁজা ব্যর্থ হতে পারে, একই চাবি দুবার ঢুকতে পারে। আরেকটি ফাঁদ: তুলনায় শুধু building দেখলে একই ভবনের সব কক্ষ map-এর চোখে “একই চাবি” — দ্বিতীয়টি আর ঢুকবে না।

unordered_map-এর জন্য — hash আর ==

unordered container-এর লাগে দুটি জিনিস: operator== আর একটি hash. hash দেওয়ার প্রচলিত উপায় std::hash-এর একটি template specialization লেখা — নিজের টাইপের জন্য namespace std-এ এটি লেখার অনুমতি standard দেয়:

struct Seat {
    int building, room;
    bool operator==(const Seat&) const = default;
};
template <> struct std::hash<Seat> {
    std::size_t operator()(const Seat& s) const noexcept {
        std::size_t h = std::hash<int>{}(s.building);
        return h * 31 + std::hash<int>{}(s.room);   // সরল মিশ্রণ; শেখার জন্য যথেষ্ট
    }
};
std::unordered_map<Seat, std::string> seatOf;     // এখন চলবে

শুধু h1 ^ h2 (XOR) লেখা একটি পরিচিত দুর্বল অভ্যাস: {1, 2} আর {2, 1}-এর hash একই হয়, আর {5, 5}-এর মতো সমান জোড়া সবই 0 দেয় — collision বাড়ে। গুণ করে মেশানো একটু ভালো; গুরুত্বপূর্ণ কাজে পরীক্ষিত একটি hash-combine ব্যবহার করুন — যেমন Boost-এর hash_combine. আর নিয়মটি ভুলবেন না: যে দুটি চাবি ==, তাদের hash অবশ্যই সমান হতে হবে — hash-এ যে সদস্য নেই, ==-তে থাকতে পারে, কিন্তু উল্টোটা চলবে না।

৮ · Range query — lower_bound আর upper_bound

সাজানো থাকার সবচেয়ে বড় পুরস্কার এখানে। একটি অনলাইন দোকানে ক্রেতা ফিল্টার দিলেন: “দাম ৫০০ থেকে ১০০০ টাকা”। unordered_map-এ এর একমাত্র উপায় সব পণ্যে লুপ চালানো। কিন্তু দাম যদি সাজানো চাবি হয়, তাহলে ৫০০-এর জায়গায় সরাসরি নেমে গিয়ে ১০০০ পার হওয়া পর্যন্ত হাঁটলেই হয়। এই দুই জায়গা খুঁজে দেয় দুটি ফাংশন: lower_bound আর upper_bound. একই দামের দুটি পণ্য থাকতে পারে, তাই এখানে multimap:

#include <iterator>
#include <map>
#include <print>
#include <string>

int main() {
    std::multimap<int, std::string> byPrice{       // price -> product, sorted
        {450, "pen set"}, {1200, "headphone"}, {650, "mouse"},
        {980, "keyboard"}, {500, "notebook"}, {650, "USB hub"},
        {1000, "power bank"}};

    auto from = byPrice.lower_bound(500);     // first price >= 500
    auto to   = byPrice.upper_bound(1000);    // first price >  1000
    for (auto it = from; it != to; ++it)
        std::println("{:>5}  {}", it->first, it->second);
    std::println("items in 500..1000: {}", std::distance(from, to));
}

দুটি ফাংশনের পার্থক্য একটি অক্ষরে: lower_bound দেয় প্রথম উপাদান যা >= চাবি, upper_bound দেয় প্রথম উপাদান যা > চাবি। জোড়াটি তাই একটি অর্ধ-খোলা পরিসর [from, to) বানায় — STL-এর সব পরিসরের মতো (পর্ব ৩২-এ iterator নিয়ে বিস্তারিত)। ধাপে ধাপে দেখুন:

1// সাজানো: 450 500 650 650 980 1000 12002auto from = byPrice.lower_bound(500);3auto to   = byPrice.upper_bound(1000);4for (auto it = from; it != to; ++it) print5// lower_bound(1100) == upper_bound(1150)

৯ · কোনটি বেছে নেবেন — map, unordered_map, নাকি সাজানো vector

Big-O-র হিসাবে unordered_map-ই জয়ী মনে হয়: O(1) বনাম O(log n). কিন্তু বাস্তবের গতি নির্ধারণে বড় ভূমিকা রাখে মেমরি। map আর unordered_map দুটিই প্রতিটি উপাদানের জন্য আলাদা heap node নেয়। খোঁজা মানে pointer ধরে ধরে মেমরির দূর দূর জায়গায় লাফ — আর প্রতিটি লাফ cache-এ না পেলে CPU-কে অপেক্ষা করতে হয়। অন্যদিকে একটি সাজানো vector-এর সব উপাদান পাশাপাশি (cache locality), আর std::ranges::lower_bound দিয়ে তাতে binary search-ও O(log n). কয়েক হাজার উপাদান পর্যন্ত, যা একবার বানিয়ে বারবার পড়া হয়, সাজানো vector প্রায়ই দুটি map-কেই হারায়।

std::flat_map (আর flat_set) C++23-এ <flat_map> header-এ এসেছে। এটি map-এর মতো interface দেয়, কিন্তু ভেতরে চাবি আর মান দুটি আলাদা সাজানো vector-এ রাখে। ধারণাটি নতুন নয় — Boost.Container বহু বছর ধরে flat_map দিয়ে আসছে। তবে C++23 নতুন বলে সব compiler-এর library-তে এটি সমানভাবে তৈরি না-ও থাকতে পারে; ব্যবহারের আগে নিজের compiler-এ দেখে নিন। আর শেষ কথা: অনুমানে নয়, মেপে বেছে নিন (পর্ব ৪৯)। ১০০টি উপাদানে container-এর পার্থক্য প্রায় কখনো গুরুত্বপূর্ণ নয়; পরিষ্কার কোডই সেখানে বড় জয়।

১০ · AI-এর যুগে — map-এর কোডে যে ভুলগুলো খুঁজবেন

AI টুল map আর unordered_map-এর কোড খুব সাবলীলভাবে লেখে, আর প্রায় সবসময় তা compile হয়। কিন্তু এই container-গুলোর ভুল বেশিরভাগই নীরব: ভুল container বাছাই, অকারণ দ্বিগুণ খোঁজা, আর [] দিয়ে “খুঁজতে গিয়ে” ঢুকিয়ে ফেলা। অনলাইনের প্রচুর পুরোনো কোডে if (m.count(k)) x = m[k]; ধরনের লাইন আছে, তাই AI-ও সেই রীতি শিখেছে। সাধারণ ভুলগুলো:

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

• প্রতিটি m[k] খুঁজে দেখেছি — সেখানে ঢোকানোই কি উদ্দেশ্য? না হলে find/contains/at
• কোথাও একই চাবি পরপর দুবার খোঁজা হচ্ছে না (find-এর পরে আবার [])
• unordered container-এর লুপের ক্রমের ওপর কোনো আউটপুট বা টেস্ট নির্ভর করে না
• container বাছাইয়ের কারণ আছে: ক্রম বা range লাগলে map, শুধু খোঁজা হলে unordered_map, পড়া-বেশি হলে সাজানো vector
• map/set-এ member lower_bound/find ব্যবহার হয়েছে, std:: algorithm নয়
• নিজের চাবির টাইপে তুলনা strict weak ordering মানে, আর hash সমান চাবিতে সমান মান দেয়