ranges ও views — C++20-এর পাইপলাইন

১ · সমস্যাটা আগে — কী চাই তা বলা, কীভাবে করব তা নয়

গত কয়েকটি পর্বে আপনি মডিউল ৫-এর চারটি বড় যন্ত্র হাতে পেয়েছেন: container (পর্ব ৩০-৩১) ডেটা রাখে, iterator (পর্ব ৩২) সেই ডেটার ওপর দিয়ে হাঁটে, STL algorithm (পর্ব ৩৩) তৈরি সমাধান দেয়, আর lambda (পর্ব ৩৪) algorithm-কে নিয়ম বলে দেয়। এই পর্বে চারটিকে একসাথে জোড়া লাগাব। শুরু করুন একটি সাধারণ কাজ দিয়ে।

একটি কোচিং সেন্টারের ছাত্রছাত্রীদের তালিকা আছে। আপনার দরকার: “যারা পাস করেছে, তাদের নাম, প্রথম ৩ জন।” মুখে বলতে এক লাইন। কিন্তু C++20-এর আগে STL দিয়ে লিখলে কোডটা দাঁড়াত এমন:

// পুরোনো পথ: প্রতিটি ধাপে একটি নতুন vector, প্রতিবার begin/end-এর জোড়া
std::vector<Student> passed;
std::copy_if(all.begin(), all.end(), std::back_inserter(passed),
             [](const Student& s) { return s.marks >= 40; });

std::vector<std::string> names;
std::transform(passed.begin(), passed.end(), std::back_inserter(names),
               [](const Student& s) { return s.name; });

if (names.size() > 3) names.resize(3);   // প্রথম ৩ জন

কোডটা ঠিকঠাক চলে, কিন্তু তিনটি সমস্যা চোখে পড়ে। এক, প্রতিটি algorithm-কে শুরু আর শেষ — দুটি iterator আলাদা করে দিতে হয়। এই iterator-এর জোড়া ভুল করে দুটি ভিন্ন container থেকে দিলেও (a.begin(), b.end()) compiler কিছু বলে না, আর ফল হয় undefined behavior. দুই, মাঝখানে দুটি অস্থায়ী vector তৈরি হলো — passed আর names — অথচ শেষে লাগবে মাত্র ৩টি নাম। এক লাখ ছাত্রছাত্রী হলে সবার কপি তৈরি হতো, তারপর বেশিরভাগ ফেলে দেওয়া হতো। তিন, কোড পড়ে “পাস করা, নাম, প্রথম ৩” — এই মূল চিন্তাটা খুঁজে বের করতে হয় যন্ত্রপাতির ভিড়ের মধ্য থেকে।

C++20-এর ranges লাইব্রেরি দিয়ে একই কাজ লেখা যায় এভাবে — প্রায় মুখের ভাষার ক্রমে:

auto top3 = all
    | std::views::filter([](const Student& s) { return s.marks >= 40; })
    | std::views::transform(&Student::name)
    | std::views::take(3);              // এখনো কোনো হিসাব হয়নি, কোনো কপিও না

পুরোনো পথ আর নতুন পথের পার্থক্য ধাপে ধাপে দেখুন:

std::sort(v.begin(), v.end());       // ঠিক
std::sort(v.begin(), w.end());       // compile হয়! কিন্তু ভিন্ন container
                                     // => undefined behavior
std::sort(v.end(), v.begin());       // উল্টো ক্রম — এটিও compile হয়

all      (১,০০,০০০ জন)
  └─ copy_if    ──► passed  (ধরুন ৮০,০০০ জনের কপি)
       └─ transform ──► names (৮০,০০০টি নামের কপি)
            └─ resize(3)  ──► শেষে লাগল মাত্র ৩টি
মাঝের দুই vector-এ বাড়তি মেমরি আর বাড়তি সময়

std::ranges::sort(v);                // পুরো container একসাথে
std::ranges::sort(v, std::ranges::greater{});   // বড় থেকে ছোট

ভুল জোড়া দেওয়ার সুযোগই নেই — begin আর end
একই জিনিস থেকে লাইব্রেরি নিজে নেয়।

all | filter(পাস) | transform(নাম) | take(3)

for লুপ প্রথম নাম চাইলে: পাস করা প্রথম জনকে খুঁজে নাম দেয়
তৃতীয় নামের পরে: থামো — বাকি ৯৯,৯০০+ জনকে ছোঁয়াই হয় না
মাঝখানে কোনো vector নেই, কোনো নাম কপি হয়নি

২ · range কী — begin আর end থাকলেই হলো

C++20-এর ভাষায় একটি range হলো এমন যেকোনো জিনিস, যার ওপর begin() ডাকলে একটি iterator আর end() ডাকলে শেষের চিহ্ন পাওয়া যায়। ব্যস, এটুকুই। পর্ব ৮-এর range-for লুপ যেসব জিনিসের ওপর চলে, প্রায় সবই range: std::vector, std::array, std::string, std::map, সাধারণ C-array, এমনকি std::string_view আর std::span.

একটি সূক্ষ্ম পরিবর্তন আছে: C++20-এ শেষের চিহ্নটি iterator-এর টাইপেরই হতে হবে, এমন বাধ্যবাধকতা নেই। একে বলে sentinel — যার কাজ শুধু বলা “এখানে শেষ”। যেমন একটি C-string-এর শেষ চেনা যায় '\0' দেখে; আগে থেকে শেষের ঠিকানা জানার দরকার নেই। আর std::views::iota(1)-এর মতো অসীম range-এর শেষই নেই — তার sentinel কখনো মেলে না। এই নমনীয়তাই পরে view-এর পাইপলাইন সম্ভব করেছে।

std::ranges-এর algorithm

পর্ব ৩৩-এর প্রায় প্রতিটি algorithm-এর একটি নতুন সংস্করণ আছে std::ranges namespace-এ। এরা পুরো range নেয়, আবার চাইলে পুরোনো মতো iterator-জোড়াও নেয়:

std::vector<int> v{5, 2, 8, 1};
std::ranges::sort(v);                          // [1, 2, 5, 8]
auto it = std::ranges::find(v, 8);             // iterator ফেরত দেয়
bool any = std::ranges::any_of(v, [](int x) { return x > 7; });
auto [lo, hi] = std::ranges::minmax(v);        // lo = 1, hi = 8
int n = std::ranges::count_if(v, [](int x) { return x % 2 == 0; });

std::ranges::sort-এর সাথে পুরোনো std::sort-এর পার্থক্য শুধু লেখায় নয়। নতুনগুলো concepts দিয়ে শর্ত বেঁধে দেয় — যেমন sort-এর জন্য random-access iterator লাগে, তাই std::list দিলে error-এর শুরুতেই বলা থাকে কোন শর্ত মেলেনি — template-এর গভীর থেকে আসা দুর্বোধ্য বার্তার তুলনায় অনেক পরিষ্কার। এরা আরও তথ্যপূর্ণ ফল ফেরত দেয়, আর দুটি নতুন সুবিধা আনে: projection (পরের অংশ) আর dangling-সুরক্ষা (৭ নম্বর অংশ)।

৩ · projection — “এই member দেখে সাজাও”

ধরুন struct Student { std::string name; int marks; };-এর একটি vector আছে, আর নম্বর অনুযায়ী সাজাতে চান। পুরোনো পথে তুলনার একটি lambda লিখতে হতো:

// পুরোনো পথ: পুরো তুলনা হাতে লেখা
std::sort(s.begin(), s.end(),
          [](const Student& a, const Student& b) { return a.marks < b.marks; });

// ranges পথ: তুলনা ডিফল্ট (<), শুধু বলে দিন কী তুলনা করতে হবে
std::ranges::sort(s, {}, &Student::marks);

দ্বিতীয় লাইনের তৃতীয় argument-টিকে বলে projection. algorithm প্রতিটি উপাদান তুলনা বা পরীক্ষা করার আগে সেটিকে এই projection-এর মধ্য দিয়ে পাঠায়। &Student::marks হলো একটি pointer to member — এর মানে “যেকোনো Student থেকে তার marks বের করো”। মাঝের {} মানে তুলনার নিয়ম ডিফল্ট রাখো — std::ranges::less, অর্থাৎ ছোট থেকে বড়। উল্টো চাইলে std::ranges::greater{}.

পুরোনো lambda-তে একই কথা দুইবার লিখতে হতো (a.marks আর b.marks), আর একটিতে ভুল করে a.marks < a.marks লিখে ফেলাও খুব সহজ ছিল। projection-এ “কী তুলনা করব” আর “কীভাবে তুলনা করব” আলাদা হয়ে যায়। projection শুধু sort-এ নয় — find, max_element, count_if-সহ প্রায় সব ranges algorithm-এ কাজ করে:

auto it  = std::ranges::find(s, "Mitu", &Student::name);      // নাম দিয়ে খোঁজা
auto top = std::ranges::max_element(s, {}, &Student::marks);  // সর্বোচ্চ নম্বর
// projection একটি lambda-ও হতে পারে:
std::ranges::sort(s, {}, [](const Student& x) { return x.name.size(); });

একই vector তিনভাবে সাজালে projection কী দেখে আর ফল কী দাঁড়ায়, ধাপে ধাপে দেখুন:

1std::vector<Student> s{{"Rafi",72},{"Mitu",91},{"Tanha",64},{"Joy",85}};2std::ranges::sort(s, {}, &Student::marks);3std::ranges::sort(s, std::ranges::greater{}, &Student::marks);4std::ranges::sort(s, {}, &Student::name);

৪ · view আর pipe — অলস পাইপলাইন

ranges algorithm-গুলো (sort, find…) সঙ্গে সঙ্গে কাজ করে, ফল দেয়। কিন্তু ranges লাইব্রেরির আসল নতুনত্ব আরেক জাতের জিনিস: view. view হলো একটি range, যা অন্য একটি range-এর ওপর বসে তার উপাদানগুলো বদলে দেখায় — ছেঁকে, রূপান্তর করে, কেটে — কিন্তু নিজে কোনো উপাদান জমিয়ে রাখে না। view তৈরি করার যন্ত্রগুলোকে বলে range adaptor, আর এরা থাকে std::views namespace-এ:

একাধিক view জোড়া দেওয়ার জন্য আছে pipe অপারেটর | — pipe syntax. r | views::filter(f) আর views::filter(r, f) একই জিনিস; কিন্তু pipe-এ ধাপগুলো বাঁ থেকে ডানে, যে ক্রমে ডেটা বয়ে যায় সেই ক্রমেই পড়া যায়। Linux বা macOS-এর terminal-এ যাঁরা cat file | grep error | head -5 লিখেছেন, তাঁদের কাছে এটা চেনা লাগবে — নাম আর ধারণা সেখান থেকেই এসেছে।

অলস মানে সত্যিই অলস

view-এর সবচেয়ে গুরুত্বপূর্ণ বৈশিষ্ট্য হলো lazy evaluation — অলস হিসাব। পাইপলাইন লেখার মুহূর্তে কিছুই হিসাব হয় না; তৈরি হয় শুধু একটি “রেসিপি”। কেউ একটি উপাদান চাইলে (লুপের পরের পাক, বা *it), তখন ঠিক সেই একটি উপাদান পেতে যতটুকু কাজ লাগে, ততটুকুই হয়। নিচের প্রোগ্রামে filter আর transform-এর ভেতরে একটি করে println বসানো আছে, যাতে কে কখন কাজ করে তা চোখে দেখা যায়। আর উৎস হলো std::views::iota(1) — ১, ২, ৩, … করে অসীম পর্যন্ত চলা সংখ্যার ধারা:

#include <print>
#include <ranges>

int main() {
    auto is_even = [](int n) {
        std::println("  filter sees {}", n);
        return n % 2 == 0;
    };
    auto square = [](int n) {
        std::println("  transform gets {}", n);
        return n * n;
    };
    auto pipe = std::views::iota(1) | std::views::filter(is_even)
              | std::views::transform(square) | std::views::take(2);
    std::println("pipeline built, nothing ran yet");
    for (int x : pipe) std::println("loop got {}", x);
}

লুপের প্রতিটি পাকে কোন স্তর কী করছে, আর কোন উপাদান কখনো কাজেই লাগে না — ধাপে ধাপে দেখুন। প্রতিটি ধাপে আগে নিজে অনুমান করুন, পরের আউটপুট লাইন কী হবে:

1auto pipe = iota(1) | filter(is_even)2          | transform(square) | take(2);3println("pipeline built, nothing ran yet");4for (int x : pipe)5    println("loop got {}", x);

৫ · view-এর বাক্স — কোনটি কী করে

standard library-তে কয়েক ডজন view আছে। প্রতিদিনের কাজে লাগে এর অল্প কয়েকটি। নিচের তালিকায় পাশে দেখানো ফলগুলো v = {1, 2, 3, 4, 5, 6} ধরে। শেষের চারটি C++23 থেকে; এই পর্বের সব উদাহরণ আমরা GCC-র নতুন সংস্করণে (-std=c++23) পরীক্ষা করেছি — পুরোনো compiler-এ C++23-এর view না-ও থাকতে পারে।

তিনটি বাস্তব ব্যবহার

প্রথম ১০টি জোড় সংখ্যার বর্গ। iota একটি অসীম ধারা দেয়; জোড় বানানো আর বর্গ করা দুটি transform; take(10) থামায়। কোনো লুপ-সূচক নেই, কোনো “কতদূর যাব” হিসাব নেই:

auto even_squares = std::views::iota(1)
    | std::views::transform([](int n) { return 2 * n; })     // 2, 4, 6, ...
    | std::views::transform([](int n) { return n * n; })     // 4, 16, 36, ...
    | std::views::take(10);
std::println("{}", even_squares);   // [4, 16, 36, 64, 100, 144, 196, 256, 324, 400]

শেষ লাইনটি খেয়াল করুন: C++23 থেকে std::println (পর্ব ৭) একটি পুরো range সরাসরি ছাপতে পারে — বর্গবন্ধনী আর কমাসহ। vector, map, এমনকি একটি view-ও। ডিবাগ করার সময় এটা খুব কাজের; আগে এজন্য একটি লুপ লিখতে হতো। (string-এর range ছাপলে প্রতিটি লেখা উদ্ধৃতিচিহ্নসহ আসে: ["rice", "dal"].)

কমা দিয়ে আলাদা করা একটি লাইন ভাঙা। CSV ফাইলের একটি লাইন বা একটি ফর্মের ইনপুট প্রায়ই এমন আসে। split প্রতিটি টুকরোকে একটি ছোট sub-range হিসেবে দেয়, যা থেকে সরাসরি string_view বানানো যায় — কোনো অক্ষর কপি না করে:

std::string_view line = "Dhaka,Rajshahi,Khulna";
for (auto part : line | std::views::split(','))
    std::println("city: {}", std::string_view(part));   // Dhaka, Rajshahi, Khulna

// টুকরোগুলো রেখে দিতে চাইলে (C++23):
auto cities = line | std::views::split(',')
                   | std::ranges::to<std::vector<std::string>>();

একটি map-এর শুধু চাবি বা শুধু মান। পর্ব ৩১-এর std::map<std::string, int> marks থেকে সব নাম চাইলে marks | std::views::keys, সব নম্বর চাইলে marks | std::views::values. আগে এর জন্য structured binding-এর লুপ লিখে একটি অংশ ফেলে দিতে হতো।

৬ · বাস্তব পাইপলাইন আর ফল জমানো — ranges::to

এবার মডিউল ৫-এর সব যন্ত্র একসাথে। একটি অনলাইন দোকানের অর্ডারের তালিকা: প্রতিটি অর্ডারের id, টাকা পরিশোধ হয়েছে কি না, আর মোট দাম — পয়সায়, যাতে ভগ্নাংশের ঝামেলা না থাকে। দরকার: পরিশোধিত অর্ডারগুলোর মধ্যে সবচেয়ে বড় ৫টির দাম, টাকায়, আর তাদের যোগফল। ব্যবহার হয়েছে container (vector), algorithm (sort), projection, তিনটি view, lambda, আর শেষে ফল জমানো:

#include <algorithm>
#include <functional>
#include <print>
#include <ranges>
#include <vector>

struct Order { int id; bool paid; int paisa; };

int main() {
    std::vector<Order> orders{{101, true, 45000}, {102, false, 99000},
        {103, true, 120050}, {104, true, 30000}, {105, false, 15000},
        {106, true, 87500}, {107, true, 64000}, {108, true, 9900}};
    std::ranges::sort(orders, std::ranges::greater{}, &Order::paisa);
    auto top = orders
        | std::views::filter([](const Order& o) { return o.paid; })
        | std::views::transform([](const Order& o) { return o.paisa / 100; })
        | std::views::take(5);
    std::println("top paid (taka): {}", top);
    auto saved = top | std::ranges::to<std::vector>();
    std::println("saved {} values, total = {}", saved.size(),
                 std::ranges::fold_left(saved, 0, std::plus{}));
}

খেয়াল করুন, sort-কে পাইপের ভেতরে রাখা যায়নি — আগে আলাদা লাইনে করতে হয়েছে। কারণ সাজাতে হলে সব উপাদান একসাথে দেখতে হয়, আর অলস view তা পারে না। “কোনটি সবচেয়ে বড়” জানতে শেষ উপাদান পর্যন্ত না দেখে উপায় নেই। তাই নিয়ম: যে কাজে পুরো ডেটা একসাথে লাগে (sort, unique, shuffle), সেটি algorithm; যে কাজ একটি একটি করে করা যায় (ছাঁকা, রূপান্তর, কাটা), সেটি view.

view থেকে আসল container — materialize করা

view-এর ফল কখনো কখনো ধরে রাখতে হয় — ফাংশন থেকে ফেরত দিতে, একাধিকবার ব্যবহার করতে, বা মূল container বদলানোর আগে। একে বলে materialize করা। C++23 থেকে সবচেয়ে সহজ পথ std::ranges::to:

auto v1 = view | std::ranges::to<std::vector>();          // element-এর টাইপ নিজে বোঝে
auto v2 = view | std::ranges::to<std::vector<long>>();    // টাইপ নিজে বলে দেওয়া
auto s  = chars | std::ranges::to<std::string>();

// C++20-এ ranges::to নেই — একটি সাধারণ লুপই সবচেয়ে পরিষ্কার:
std::vector<int> v3;
for (int x : view) v3.push_back(x);

C++20-এ ranges এল, কিন্তু ranges::to এল এক সংস্করণ পরে — তাই অনেক C++20 কোডে আর অনলাইনের পুরোনো উত্তরে আপনি হাতে লেখা লুপ দেখবেন। দুটিই ঠিক। শুধু একটি জিনিস মনে রাখুন: std::vector<int> v(view.begin(), view.end()) সব view-এ চলে না, কারণ কিছু view-এর begin আর end-এর টাইপ আলাদা (সেই sentinel). লুপ বা ranges::to সবসময় চলে।

৭ · view আর lifetime — যেখানে পাইপ ফেটে যায়

view ডেটার মালিক নয় — এটাই তার শক্তি, আর এটাই তার বিপদ। পর্ব ১৮-এ আপনি দেখেছেন, dangling reference বা dangling view মানে এমন কিছুর দিকে তাকিয়ে থাকা, যা ইতিমধ্যে ধ্বংস হয়েছে। ranges-এ এই ভুলের দুটি রূপ আছে — একটি লাইব্রেরি নিজে আটকায়, অন্যটি আপনাকে আটকাতে হয়।

লাইব্রেরি যা আটকায় — ranges::dangling

একটি ফাংশন vector ফেরত দেয়, আর আপনি সেই ফলের ওপর সরাসরি find বা max_element ডাকলেন:

std::vector<int> prices();                        // নতুন vector ফেরত দেয়

auto it = std::ranges::max_element(prices());     // compile হয়, কিন্তু...
int m = *it;   // error: no match for 'operator*'
               // (operand type is 'std::ranges::dangling')

prices()-এর ফল একটি temporary object — লাইনটি শেষ হতেই সেটি ধ্বংস। পুরোনো std::max_element হলে একটি iterator ফেরত আসত, যা মৃত মেমরির দিকে তাকিয়ে আছে, আর *it চুপচাপ undefined behavior হতো। ranges সংস্করণ বুঝে ফেলে যে আপনি একটি temporary পাঠিয়েছেন, তাই iterator-এর বদলে ফেরত দেয় std::ranges::dangling নামের একটি ফাঁকা টাইপ। এটি দিয়ে কিছুই করা যায় না — dereference করতে গেলেই compile error. চলার সময়ের একটি নীরব বাগ হয়ে গেল চোখের সামনের error. সমাধান: আগে ফলটি একটি নামযুক্ত ভ্যারিয়েবলে রাখুন — auto p = prices(); — তারপর তার ওপর algorithm ডাকুন।

(যেসব range নিজে ডেটার মালিক নয়, যেমন std::string_view বা std::span, সেগুলো temporary হলেও তাদের iterator নিরাপদ, কারণ ডেটা অন্য কোথাও বেঁচে আছে। এমন range-কে বলে borrowed range, আর এদের বেলায় dangling ফেরত আসে না।)

যা আপনাকে আটকাতে হয় — মৃত container-এর ওপর view

নিচের ফাংশনটি দেখতে নিরীহ। এটি একটি view ফেরত দেয়, যাতে ডাকার জায়গায় অলসভাবে পাস নম্বরগুলো পাওয়া যায়। কিন্তু view যে container-এর দিকে তাকিয়ে আছে, সেটি ফাংশনের local ভ্যারিয়েবল (এই কোড চালাবেন না):

1auto passed_marks() {2    std::vector<int> marks{72, 35, 91, 28};3    return marks | std::views::filter(pass);4}                        // marks এখানে ধ্বংস5auto v = passed_marks();6for (int m : v) std::println("{}", m);

একটি আশার খবর: ২০২১ সালে গৃহীত একটি সংশোধনী (P2415, যা C++20-এর ওপরও প্রয়োগ করা হয়েছে) অনুযায়ী, pipe-এর বাঁ দিকে যদি সরাসরি একটি temporary container থাকে — যেমন make_marks() | views::filter(pass) — তাহলে view সেটিকে move করে নিজের ভেতরে নেয় (owning_view), আর তখন view-ই মালিক। তাই এই রূপটি নিরাপদ। বিপদ থাকে নামযুক্ত ভ্যারিয়েবলে, যার আয়ু view-এর আগে শেষ হয় — ঠিক উপরের মতো। আর মনে রাখবেন, এই নিয়ম পুরোনো compiler-এ না-ও থাকতে পারে।

view চলার সময় container বদলানো

দ্বিতীয় বিপদটিও পর্ব ৩০-৩২-এর পরিচিত iterator invalidation. একটি view একটি vector-এর দিকে তাকিয়ে আছে, আর লুপের ভেতরে আপনি সেই vector-এ push_back করলেন। vector বড় জায়গায় সরে গেলে view-এর iterator পুরোনো, ফেরত দেওয়া মেমরির দিকে তাকিয়ে থাকে — আবার undefined behavior. নিয়ম: view দিয়ে পড়ার সময় উৎস container-এর আকার বদলাবেন না। বদলাতে হলে আগে ranges::to দিয়ে আলাদা কপি নিন, অথবা C++20-এর std::erase_if-এর মতো ফাংশন ব্যবহার করুন।

filter view কেন const দিয়ে চলে না

একটি অবাক-করা নিয়ম, যা AI-এর কোডেও প্রায়ই compile error আনে: void show(const auto& r) ফাংশনে একটি filter view পাঠালে GCC বলে passing 'const ...filter_view...' as 'this' argument discards qualifiers. কারণ filter view প্রথমবার begin() ডাকার সময় প্রথম যোগ্য উপাদান খুঁজে বের করে আর সেই অবস্থান মনে রাখে (cache করে), যাতে পরের বার আবার খুঁজতে না হয়। মনে রাখা মানে নিজেকে বদলানো, তাই begin() const হতে পারে না। সমাধান সহজ: view-কে by value নিন (void show(auto r)) — view কপি সস্তা — অথবা forwarding reference (auto&& r). এর পেছনের নকশার কারণ ভাবনার প্রশ্ন ৩-এ।

৮ · গতি, পাঠযোগ্যতা, আর কখন সাধারণ লুপই ভালো

গতি। view-এর পাইপলাইন optimization চালু করে (-O2) compile করলে সাধারণত হাতে লেখা লুপের কাছাকাছি গতিতে চলে, কারণ প্রতিটি view একটি template, আর lambda-গুলো inline হয়ে যায় — শেষে মেশিন কোডে প্রায় একটি সাধারণ লুপই থাকে। মধ্যবর্তী vector না থাকায় পুরোনো copy_if-transform পথের চেয়ে প্রায়ই দ্রুতও। তবে কিছু সতর্কতা আছে। optimization ছাড়া (debug build) ranges-এর কোড লক্ষণীয়ভাবে ধীর হতে পারে, কারণ স্তরগুলো আলাদা ফাংশন-ডাক হিসেবে থেকে যায়। কিছু জোড়া — যেমন filter-এর পরে reverse, বা উপরের take-এর এক ধাপ বাড়তি টানা — বাড়তি কাজ করে। আর template-ভারী কোড compile হতে বেশি সময় নেয়, error message-ও দীর্ঘ হয়। “ranges ধীর” বা “ranges দ্রুত” — কোনোটাই অন্ধভাবে বিশ্বাস করবেন না; দরকার হলে পর্ব ৪৯-এর মতো মেপে দেখুন।

পাঠযোগ্যতা। ranges-এর আসল লাভ পরিষ্কার কোড। কিন্তু pipe-এর নেশা লাগলে উল্টো ফল হয়। আট ধাপের একটি পাইপলাইন, যার প্রতিটি ধাপে তিন লাইনের lambda, আর মাঝখানে zip-chunk-join — পড়তে গিয়ে পাঠককে মাথায় পুরো ডেটার আকার কল্পনা করতে হয়। তুলনা করুন:

লম্বা পাইপলাইন ভাঙার একটি সহজ কৌশল: মাঝের অংশগুলোকে নাম দিন। view কপি সস্তা আর অলস, তাই auto paid = orders | views::filter(is_paid); লিখে তারপর auto top = paid | views::transform(to_taka) | views::take(5); — একই কাজ, একই গতি, কিন্তু প্রতিটি নাম একটি মন্তব্যের কাজ করে। lambda-কেও নাম দিন (is_paid, to_taka), পর্ব ৩৪-এর মতো।

৯ · AI-এর যুগে — AI-এর লেখা পাইপলাইন যাচাই

AI টুল ranges-এর কোড লিখতে ভালোবাসে, কারণ pipe-এর কোড দেখতে আধুনিক আর সংক্ষিপ্ত। কিন্তু ranges এসেছে মাত্র C++20-এ, আর C++23-এর অংশগুলো আরও নতুন — তাই প্রশিক্ষণের ডেটায় পুরোনো, ভুল বা range-v3-এর মিশ্রিত উদাহরণ প্রচুর। তার ওপর view-এর সবচেয়ে বড় ভুলগুলো (lifetime) compile হয় এবং ছোট পরীক্ষায় ঠিক ফলও দেয়। সাধারণ ভুলগুলো:

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

• প্রতিটি view-এর উৎস খুঁজেছি — উৎসটি view-এর পুরো ব্যবহারকাল জুড়ে বেঁচে আছে
• কোনো ফাংশন local container-এর ওপর বসা view ফেরত দিচ্ছে না
• view দিয়ে ঘোরার সময় উৎস container-এ push_back, insert বা erase নেই
• সব নাম std::ranges বা std::views-এর; C++23-এর জিনিস থাকলে প্রজেক্ট সত্যিই C++23
• পাইপলাইন মুখে পড়ে দেখেছি — ধাপের ক্রম (যেমন take আগে না filter আগে) আমার চাওয়ার সাথে মেলে
• -fsanitize=address দিয়ে চালিয়ে কোনো use-after-free পাইনি