constexpr — compile-এর সময়েই হিসাব

১ · সমস্যাটা আগে — যে উত্তর কখনো বদলায় না

একটি প্রোগ্রাম চলার সময় অনেক হিসাব করে। কিছু হিসাবের উত্তর নির্ভর করে ব্যবহারকারীর ওপর — কে কত টাকা পাঠালেন, কোন ফাইল খুললেন। কিন্তু কিছু হিসাবের উত্তর পৃথিবীর কোনো ব্যবহারকারী বদলাতে পারেন না। এক দিনে সবসময় ২৪ × ৬০ × ৬০ = ৮৬,৪০০ সেকেন্ড। ১ টাকা সবসময় ১০০ পয়সা। ৫০-এর নিচে মৌলিক সংখ্যা সবসময় ওই ১৫টিই। ফাইল যাচাইয়ে ব্যবহৃত CRC-এর ২৫৬ ঘরের টেবিলও প্রতিবার একই।

এমন উত্তর প্রতিবার প্রোগ্রাম চালানোর সময় নতুন করে হিসাব করা অপচয়। একটি কুইজ অ্যাপের কথা ভাবুন, যা লাখো ফোনে চলে আর প্রতিবার খোলার সময় একটি মৌলিক সংখ্যার টেবিল বানায়। প্রতিটি ফোন একই কাজ করছে, একই ফল পাচ্ছে — বারবার, প্রতিদিন। এর চেয়ে ভালো হতো যদি টেবিলটি একবার বানিয়ে প্রোগ্রামের ভেতরেই রেখে দেওয়া যেত।

C++ এখানে দুটি লাভ দেয়, আর দ্বিতীয়টি প্রথমটির চেয়েও গুরুত্বপূর্ণ।

এই পর্বের সব যন্ত্র — constexpr, consteval, constinit, static_assert, if constexpr — একটিই প্রশ্নের নানা উত্তর: “এই কাজটি কি compile-এর সময়েই করা যায়, আর গেলে compiler কী নিশ্চয়তা দেবে?” যে মান compile-এর সময় হিসাব করা যায়, standard তাকে বলে constant expression, আর compiler যখন সেটি হিসাব করে, সেই প্রক্রিয়াকে বলে constant evaluation.

২ · const বনাম constexpr — “বদলাবে না” আর “আগেই জানা”

পর্ব ৫-এ আপনি const দেখেছেন। দুটি শব্দ দেখতে কাছাকাছি, আর AI টুলও প্রায়ই গুলিয়ে ফেলে। কিন্তু এরা দুটি ভিন্ন প্রশ্নের উত্তর দেয়।

int read_price();                       // চলার সময় ফাইল থেকে পড়ে

const int price = read_price();         // ঠিক আছে: মান চলার সময় আসে, তারপর আর বদলাবে না
constexpr int day = 24 * 60 * 60;       // ঠিক আছে: compiler নিজেই 86400 বের করে
constexpr int bad = read_price();       // error: compile-এর সময় এর মান জানা অসম্ভব

int counts[day / 3600];                 // ঠিক: array-র মাপ compile-এর সময় জানা চাই
// price = 50;                          // error: const বদলানো যায় না

const একটি প্রতিশ্রুতি: এই মান আর বদলাবে না। মানটি কোথা থেকে এল — ধ্রুবক থেকে, নাকি চলার সময় ফাইল পড়ে — তাতে const-এর কিছু যায় আসে না। constexpr আরও কড়া দাবি: এই মান compiler-কে এখনই বের করতে হবে। না পারলে compile error. আর যে মান compile-এর সময়েই জানা, সেটি স্বাভাবিকভাবেই বদলানো যায় না — তাই প্রতিটি constexpr ভ্যারিয়েবল নিজে থেকেই const.

একটি সূক্ষ্ম পুরোনো নিয়ম জেনে রাখুন। const int k = 10; — integer টাইপের const, যার প্রথম মান একটি ধ্রুবক — C++-এ বহু আগে থেকেই constant expression হিসেবে চলে। এটি C-এর সাথে পুরোনো সামঞ্জস্যের জন্য রাখা। কিন্তু const double বা অন্য টাইপে এই ছাড় নেই, আর পাঠকও দেখে বুঝতে পারেন না মানটি কোথা থেকে এল। তাই নিয়মটা সরল রাখুন: মান compile-এর সময় জানা থাকতেই হবে — constexpr. শুধু “বদলাবে না” বলতে চান — const.

পুরোনো পথ: #define

C আর পুরোনো C++ কোডে ধ্রুবক লেখা হতো preprocessor-এর macro দিয়ে: #define POISHA_PER_TAKA 100. এটি compile-এর আগেই লেখা-বদল করে — নামটি যেখানে আছে, সেখানে অক্ষরে অক্ষরে 100 বসিয়ে দেয়। কোনো টাইপ নেই, namespace মানে না, debugger-এ নাম দেখা যায় না। আর বন্ধনী ভুললে বিপদ: #define DAY 24*60*60 লিখে x / DAY করলে আসলে হয় x / 24 * 60 * 60. constexpr int day = 24 * 60 * 60; একটি সত্যিকারের ভ্যারিয়েবল — টাইপ আছে, scope আছে, ভুল হলে compiler পরিষ্কার error দেয়। কোডে খোলা magic number না লিখে নাম দেওয়া constexpr ধ্রুবক লিখুন।

৩ · constexpr ফাংশন — একই ফাংশন, দুই সময়ে

ধ্রুবক লেখা সহজ অংশ। আসল শক্তি আসে যখন একটি পুরো ফাংশনকে constexpr বলেন। এর মানে: “এই ফাংশনটি compile-এর সময়েও চালানো যাবে।” লক্ষ করুন — যাবে, যেতে হবে না। একই ফাংশন কোথায় চলবে, তা ঠিক হয় ডাকার জায়গা দেখে:

• ফলটি যদি এমন জায়গায় লাগে যেখানে compile-এর সময়ের মান বাধ্যতামূলক — constexpr ভ্যারিয়েবল, static_assert, array-র মাপ, template argument — তাহলে compiler ফাংশনটি নিজেই চালায়। সব argument-ও তখন ধ্রুবক হতে হবে।
• argument যদি চলার সময়ের মান হয় — যেমন ব্যবহারকারীর ইনপুট — তাহলে ফাংশনটি একটি সাধারণ ফাংশনের মতো চলার সময় চলে। কোনো error নেই।

নিচের প্রোগ্রামে একটি টাকা-থেকে-পয়সা রূপান্তর, এক দিনের সেকেন্ড, আর ১ থেকে n পর্যন্ত যোগফলের একটি ফাংশন আছে। দুটি static_assert compiler-কে দিয়ে উত্তর যাচাই করিয়ে নেয় — ভুল হলে প্রোগ্রাম তৈরিই হতো না:

#include <print>

constexpr long long poisha(long long taka) { return taka * 100; }
constexpr int seconds_per_day = 24 * 60 * 60;

constexpr int sum_to(int n) {           // C++14 থেকে লুপ চলে
    int s = 0;
    for (int i = 1; i <= n; ++i) s += i;
    return s;
}

static_assert(seconds_per_day == 86400);
static_assert(sum_to(10) == 55);        // compiler নিজে হিসাব করে মিলিয়ে দেখে

int main() {
    constexpr long long fee = poisha(25);   // compile-এর সময়: 2500
    int n = 4;                              // সাধারণ ভ্যারিয়েবল
    for (int k = 0; k < 3; ++k) n += k;     // n = 7, ধ্রুবক নয়
    std::println("fee = {} poisha", fee);
    std::println("seconds per day = {}", seconds_per_day);
    std::println("sum_to({}) = {}", n, sum_to(n));  // চলার সময়ের ডাক
}

এবার একই poisha ফাংশন চারটি ভিন্ন জায়গায় ডাকলে compiler কী করে, ধাপে ধাপে দেখুন। প্রতিটি ধাপে আগে নিজে অনুমান করুন — compile-এর সময়, চলার সময়, নাকি error?

constexpr long long fee = poisha(25);

compiler:  25 * 100 = 2500   (নিজেই হিসাব করল)
মেশিন কোডে: fee = 2500       (কোনো ডাক নেই, কোনো গুণ নেই)

static_assert(poisha(2) == 200);    // সত্য: বিল্ড চলবে
static_assert(poisha(2) == 20);     // মিথ্যা:

error: static assertion failed
note: the comparison reduces to '(200 == 20)'

long long t;
std::cin >> t;                      // মান জানা যাবে শুধু চলার সময়
long long p = poisha(t);            // ঠিক আছে: সাধারণ ফাংশন-ডাক

ব্যবহারকারী 40 দিলে  =>  p = 4000  (চলার সময় হিসাব)

long long t;
std::cin >> t;
constexpr long long q = poisha(t);  // compiler-কে এখনই উত্তর দিতে বলা হলো

error: the value of 't' is not usable in a constant expression

constexpr ফাংশন সম্পর্কে আরও দুটি কথা। এক, constexpr ফাংশন নিজে থেকেই inline — তাই এর পুরো সংজ্ঞা সাধারণত header-এ থাকে, কারণ compiler-কে ডাকার জায়গাতেই ফাংশনের ভেতরটা দেখতে হয়। দুই, constexpr ফাংশনে যে টাইপ ব্যবহার করা যায়, তাদের বলে literal type — int, double, pointer, আর এমন class যার অন্তত একটি constexpr constructor আছে। নিজের struct Money-কেও constexpr constructor দিয়ে compile-এর সময়ে ব্যবহারযোগ্য করা যায়।

৪ · static_assert — compile-এর সময়ের পাহারাদার

static_assert(শর্ত, "বার্তা"); compiler-কে বলে: “এই শর্তটি compile-এর সময় পরীক্ষা করো; মিথ্যা হলে বার্তাটি দেখিয়ে বিল্ড থামাও।” চলার সময় এর কোনো খরচ নেই — প্রোগ্রামে এর চিহ্নই থাকে না। C++11-এ বার্তা দেওয়া বাধ্যতামূলক ছিল; C++17 থেকে বার্তা ছাড়াও লেখা যায়।

সবচেয়ে বাস্তব ব্যবহারটি নেটওয়ার্ক বা ফাইলের ফরম্যাটে। ধরুন একটি মোবাইল অ্যাপ সার্ভারে একটি ছোট header পাঠায়, যার মাপ প্রোটোকলে ঠিক ৮ বাইট লেখা আছে। কেউ পরে একটি ফিল্ড যোগ করলেন, বা টাইপ বদলালেন, বা compiler padding যোগ করল — তখন অন্য প্রান্ত ভুল বাইট পড়বে, আর বাগটি ধরা পড়বে অনেক পরে, অদ্ভুত আচরণ হিসেবে। static_assert সেই অনুমানটিকে কোডে লিখে রাখে:

#include <cstdint>
#include <type_traits>

struct PacketHeader {
    std::uint16_t type;
    std::uint16_t length;
    std::uint32_t seq;
};

static_assert(sizeof(PacketHeader) == 8, "wire format: header must be 8 bytes");
static_assert(std::is_trivially_copyable_v<PacketHeader>,
              "header is copied byte-by-byte");

// কেউ 'std::uint8_t flags;' যোগ করলে:
// error: static assertion failed: wire format: header must be 8 bytes

এখানে দুই রকম প্রশ্ন করা হয়েছে। sizeof একটি পরিচিত compile-time প্রশ্ন — “এই টাইপ কত বাইট?” আর std::is_trivially_copyable_v হলো একটি type trait — টাইপ সম্পর্কে হ্যাঁ/না প্রশ্ন, যার উত্তর compile-এর সময়ে একটি bool ধ্রুবক। <type_traits> হেডারে এমন অনেক প্রশ্ন তৈরি আছে: std::is_integral_v<T> (T কি পূর্ণসংখ্যার টাইপ?), std::is_floating_point_v<T>, std::is_same_v<A, B> (দুটি টাইপ কি হুবহু এক?), std::is_signed_v<T>. এগুলো static_assert আর if constexpr-এর স্বাভাবিক সঙ্গী।

আরও কয়েকটি জায়গা, যেখানে static_assert অভিজ্ঞ কোডে প্রায়ই দেখা যায়:

• প্ল্যাটফর্মের অনুমান: static_assert(sizeof(void*) == 8); — কোডটি যদি শুধু ৬৪-বিট সিস্টেমের জন্য লেখা হয়, ৩২-বিটে বিল্ডই হবে না।
• টেবিল আর enum মেলানো: একটি enum-এ যতগুলো রং, নামের তালিকায় ততগুলো নাম — নতুন রং যোগ করে নাম লিখতে ভুলে গেলে বিল্ড থামবে।
• template-এর শর্ত: static_assert(std::is_integral_v<T>, "integers only"); — ভুল টাইপ দিলে দীর্ঘ, দুর্বোধ্য error-এর বদলে একটি পরিষ্কার বাক্য। (পরের পর্বের concepts এ কাজ আরও সুন্দরভাবে করে।)
• constexpr ফাংশনের টেস্ট: static_assert(sum_to(10) == 55); — ছোট unit test, যা প্রতিবার compile-এর সময় চলে।

একটি compile-time-যাচাই করা শতাংশ

একটি ছাড়ের হার কখনো ১০০%-এর বেশি বা ০%-এর কম হতে পারে না। চলার সময় পরীক্ষা করা যায়, কিন্তু হারটি যদি কোডেই লেখা থাকে, তবে ভুলটা চলার সময় পর্যন্ত অপেক্ষা করবে কেন? constexpr constructor-এ একটি পরীক্ষা বসান:

struct Percent {
    int value;
    constexpr explicit Percent(int v) : value(v) {
        if (v < 0 || v > 100) throw "percent must be 0..100";   // compile-এর সময় চললে: error
    }
};

constexpr Percent eid_discount{15};    // ঠিক আছে
constexpr Percent typo{150};           // compile error: throw চলেছে constant evaluation-এ

কৌশলটি হলো: constant evaluation চলার সময় যদি কোনো throw-এ পৌঁছায়, তবে ফলটি আর constant expression নয় — তাই constexpr ভ্যারিয়েবলে সেটি compile error. আর চলার সময় একই constructor ডাকা হলে সত্যিকারের exception ছোড়া হয় (পর্ব ৩৭)। একটি নিয়ম, দুই জায়গায় পাহারা। (বাস্তব কোডে "..."-এর বদলে std::invalid_argument ছুড়ুন; এখানে সংক্ষেপের জন্য লেখা।)

৫ · consteval আর constinit — C++20-এর দুই কড়া নিয়ম

constexpr নমনীয় — compile-এর সময়েও চলে, চলার সময়েও। কখনো কখনো এই নমনীয়তাই সমস্যা। C++20 দুটি নতুন শব্দ এনেছে, যারা দুই ভিন্ন দিক থেকে নিয়ম কড়া করে।

consteval — “শুধু compile-এর সময়”

consteval দিয়ে ঘোষিত ফাংশনকে বলে immediate function. এর প্রতিটি ডাক compile-এর সময়েই হিসাব হতে হবে, নইলে compile error. চলার সময়ের সংস্করণ বলে কিছু নেই।

consteval int checked_percent(int p) {
    if (p < 0 || p > 100) throw "bad percent";
    return p;
}

int vat = checked_percent(15);          // ঠিক: 15 যাচাই হলো compile-এর সময়েই
int oops = checked_percent(115);        // compile error
int user_rate = read_rate();
int r = checked_percent(user_rate);     // compile error: user_rate ধ্রুবক নয়

লক্ষ করুন প্রথম লাইনে vat একটি সাধারণ int, constexpr নয় — তবু ডাকটি compile-এর সময়েই হয়েছে, কারণ ফাংশনটি consteval. constexpr হলে এখানে কোনো নিশ্চয়তা থাকত না, আর 115-এর ভুলটিও চলার সময় পর্যন্ত লুকিয়ে থাকত। consteval কাজে লাগে যখন চলার সময় চলাটাই ভুল — যেমন ফরম্যাট-স্ট্রিং যাচাই। C++20-এর std::format("{} taka", x)-এর ফরম্যাট-স্ট্রিং ঠিক এভাবে compile-এর সময় পরীক্ষা হয়: {}-এর তুলনায় argument কম হলে, বা ফরম্যাটের নির্দেশ argument-এর টাইপের সাথে না মিললে compile error, চলার সময় নয়।

constinit — “শুরুর মান compile-এর সময়ে, পরে বদলানো যাবে”

global আর static ভ্যারিয়েবল (static storage duration) main() শুরুর আগেই তৈরি হয়। তাদের শুরুর মান বসে দুইভাবে। মানটি ধ্রুবক হলে compiler সেটি সরাসরি প্রোগ্রাম ফাইলে লিখে দেয় — একে বলে constant initialization, আর এতে কোনো কোড চলে না। মানটি কোনো ফাংশন-ডাক থেকে এলে main()-এর আগে সেই ফাংশন চালাতে হয় — একে বলে dynamic initialization. সমস্যাটা এখানেই: ভিন্ন translation unit-এর (ভিন্ন .cpp ফাইলের) global-গুলোর dynamic initialization কোন ক্রমে হবে, standard তা ঠিক করে দেয় না।

এই অনিশ্চয়তা থেকে যে কুখ্যাত বাগ জন্মায়, তার নাম static initialization order fiasco. ধাপে ধাপে দেখুন:

Config load();               // ফাইল পড়ে সেটিং আনে
Config cfg = load();         // main()-এর আগে চালাতে হবে

extern Config cfg;
Logger lg{cfg.level};        // cfg কি তৈরি হয়ে গেছে?

বিল্ড A:  cfg = load()  →  lg{cfg.level}     ঠিকঠাক চলে
বিল্ড B:  lg{cfg.level}  →  cfg = load()     cfg তখনো তৈরি হয়নি!

ফাইলের ক্রম বা linker বদলালেই ফল বদলায়।

constinit int log_level = 2;        // বিল্ডের সময়ই ফাইলে লেখা
constinit int retries = read_env(); // error: compile-এর সময় মান নেই

log_level = 3;                      // ঠিক: constinit মানে const নয়

constinit তাই একটি নিশ্চয়তা চাওয়া, নতুন কোনো ক্ষমতা নয়। int counter = 0; আজও constant initialization পায়; constinit শুধু নিশ্চিত করে যে কেউ পরে অজান্তে int counter = compute(); লিখে সেটিকে dynamic বানিয়ে ফেললে compiler চেঁচাবে। যে global সত্যিই চলার সময়ের মানের ওপর নির্ভর করে, তার জন্য পুরোনো, পরীক্ষিত সমাধান হলো ফাংশনের ভেতরের static ভ্যারিয়েবল — প্রথমবার ডাকার সময় তৈরি হয়, C++11 থেকে thread-safe ভাবে।

৬ · if constexpr — template-এ শাখা ছেঁটে ফেলা

পর্ব ২৮-এ আপনি template দেখেছেন — একই ফাংশন নানা টাইপের জন্য। কিন্তু প্রায়ই টাইপ অনুযায়ী কাজ একটু আলাদা হতে হয়। ধরুন একটি describe ফাংশন: পূর্ণসংখ্যা হলে “এটি জোড় না বিজোড়” বলবে, ভগ্নাংশ হলে দুই ঘর দশমিকে দেখাবে, string হলে দৈর্ঘ্য বলবে। সাধারণ if দিয়ে লিখলে কী হয়?

template <typename T>
std::string describe(const T& v) {
    if constexpr (std::is_integral_v<T>)
        return v % 2 == 0 ? "even" : "odd";          // শুধু integer-এ % চলে
    else if constexpr (std::is_floating_point_v<T>)
        return std::format("{:.2f}", v);
    else
        return "text of " + std::to_string(v.size()); // শুধু string-এ .size()
}

সাধারণ if-এ সব শাখা প্রতিটি টাইপের জন্য compile হয়, শর্ত মিথ্যা হলেও। তখন describe(3.5)-এর জন্য compiler v % 2-ও compile করতে চাইবে, আর double-এ % নেই — error. if constexpr-এর (C++17) শর্ত compile-এর সময় হিসাব হয়, আর template-এর ভেতরে মিথ্যা শাখাটি সেই টাইপের জন্য বাদ পড়ে যায় — একে বলে discarded statement. বাদ পড়া কোড instantiate হয় না, তাই সেখানে এমন কোড থাকতে পারে যা এই টাইপে অর্থহীন। ধাপে ধাপে দেখুন:

1if constexpr (std::is_integral_v<T>)2    return v % 2 == 0 ? "even" : "odd";3else if constexpr (std::is_floating_point_v<T>)4    return std::format("{:.2f}", v);5else6    return "text of " + std::to_string(v.size());

দুটি সতর্কতা। এক, শাখা বাদ পড়ে শুধু template-এর ভেতরে, যেখানে শর্তটি template parameter-এর ওপর নির্ভর করে। সাধারণ (non-template) ফাংশনে if constexpr-এর মিথ্যা শাখাও পুরোপুরি বৈধ কোড হতে হয়। দুই, বাদ পড়া শাখাও ব্যাকরণগতভাবে ঠিক হতে হয় — বানান ভুল বা বন্ধনী না মেলা চলবে না। আর “বাকি কোনো টাইপ চলবে না” বলতে শেষ else-এ static_assert(false, "...") লেখা C++23 থেকে বৈধ (GCC 13, Clang 17 এবং পরের সংস্করণে কাজ করে); তার আগে sizeof(T) == 0-এর মতো T-নির্ভর একটি শর্ত লিখতে হতো।

ফাংশনটি এখন কোথায় চলছে? — std::is_constant_evaluated আর if consteval

কখনো একটি constexpr ফাংশন চায় দুই জায়গায় দুই রকম পথ নিতে — compile-এর সময় সরল, বহনযোগ্য লুপ; চলার সময় CPU-র বিশেষ নির্দেশনা বা দ্রুত লাইব্রেরি, যা compile-এর সময় চলে না। C++20 এজন্য দিয়েছে std::is_constant_evaluated(), আর C++23 দিয়েছে আরও পরিষ্কার if consteval:

constexpr int popcount32(unsigned x) {
    if consteval {                    // C++23: constant evaluation চলছে
        int c = 0;
        for (; x; x &= x - 1) ++c;    // সরল লুপ, compile-এর সময়ে চলে
        return c;
    } else {
        return std::popcount(x);      // চলার সময় দ্রুত পথ
    }
}
// ফাঁদ: if constexpr (std::is_constant_evaluated()) — সবসময় true!

শেষ লাইনের ফাঁদটি AI-এর কোডে প্রায়ই দেখা যায়। if constexpr-এর শর্ত নিজেই একটি constant evaluation, তাই তার ভেতরে std::is_constant_evaluated() সবসময় true দেয় — চলার সময়ের শাখা কখনো চলে না। GCC এখানে warning দেয়। (উদাহরণটি সরল রাখতে else শাখায় std::popcount রাখা হয়েছে, যদিও সেটি নিজেও constexpr; বাস্তবে সেখানে থাকে compiler-এর বিশেষ ফাংশন বা CPU-নির্দেশনা, যা compile-এর সময় চলে না। দুটি পথের ফল অবশ্যই এক হতে হবে; নইলে একই ফাংশন দুই জায়গায় দুই উত্তর দেবে।)

৭ · compile-time lookup table — একবার বানান, সবসময় পড়ুন

এবার শুরুর কুইজ অ্যাপে ফিরি। অ্যাপটি প্রশ্ন বানায় “এই সংখ্যাটি কি মৌলিক?” — আর উত্তর যাচাইয়ে লাগে ৫০-এর নিচের মৌলিক সংখ্যার একটি টেবিল। এমন আগে থেকে হিসাব করে রাখা উত্তরের তালিকাকে বলে lookup table. constexpr ফাংশন দিয়ে টেবিলটি বানিয়ে std::array-এ রাখলে পুরো কাজ হয় compile-এর সময়ে। পদ্ধতিটি প্রাচীন: Eratosthenes-এর ছাঁকনি — ২ থেকে শুরু করে প্রতিটি মৌলিক সংখ্যার গুণিতক কেটে দেওয়া।

#include <array>
#include <print>

constexpr int N = 50;
constexpr std::array<bool, N> make_sieve() {
    std::array<bool, N> is_prime{};             // সব false
    for (int i = 2; i < N; ++i) is_prime[i] = true;
    for (int i = 2; i * i < N; ++i)
        if (is_prime[i])
            for (int j = i * i; j < N; j += i) is_prime[j] = false;
    return is_prime;
}
constexpr auto prime = make_sieve();            // compiler বানায় টেবিলটি
static_assert(prime[47] && !prime[49]);         // 47 মৌলিক, 49 = 7 x 7

int main() {
    int count = 0;
    for (int i = 0; i < N; ++i)
        if (prime[i]) { std::print("{} ", i); ++count; }
    std::println("\ncount = {}", count);
}

একই কৌশল বাস্তবের বড় টেবিলেও। ফাইল বা নেটওয়ার্কের ডেটা ঠিক আছে কি না যাচাই করতে বহুল ব্যবহৃত CRC-32 হিসাব দ্রুত হয় একটি ২৫৬ ঘরের টেবিল দিয়ে। পুরোনো কোডে এই টেবিল হাতে কপি করা ২৫৬টি hex সংখ্যা — একটি অঙ্ক ভুল হলে খুঁজে পাওয়া প্রায় অসম্ভব। constexpr দিয়ে টেবিলটি নিয়ম থেকেই তৈরি হয়:

constexpr std::array<std::uint32_t, 256> make_crc_table() {
    std::array<std::uint32_t, 256> t{};
    for (std::uint32_t i = 0; i < 256; ++i) {
        std::uint32_t c = i;
        for (int k = 0; k < 8; ++k)
            c = (c & 1) ? 0xEDB88320u ^ (c >> 1) : c >> 1;
        t[i] = c;
    }
    return t;
}
constexpr auto crc_table = make_crc_table();
static_assert(crc_table[1] == 0x77073096u);   // প্রচলিত টেবিলের সাথে মিল

টেবিল যতই বড় হোক, চলার সময়ের খরচ শূন্য — আর static_assert প্রমাণ দেয় যে হিসাবটি প্রচলিত CRC-32 টেবিলের সাথে মেলে। একই ধাঁচে বানানো যায় একক-রূপান্তরের টেবিল (মিটার থেকে ফুট, টাকা থেকে পয়সা), বর্গ বা ঘাতের টেবিল, গেমের sine টেবিল, বা একটি ছোট parser-এর অক্ষর-শ্রেণির টেবিল।

constexpr-এ কী কী চলে — একটি ক্রমবর্ধমান তালিকা

উপরের ছাঁকনির ফাংশনটি C++11-এ লেখা যেত না। constexpr শুরু হয়েছিল খুব কড়া নিয়মে, আর প্রতিটি নতুন standard-এ এর সীমা বেড়েছে:

C++20-এর new-এর নিয়মটি ভালো করে বুঝুন — একে বলে transient allocation (ক্ষণস্থায়ী বরাদ্দ)। compile-এর সময় heap-এ মেমরি নেওয়া যায়, কিন্তু constant evaluation শেষ হওয়ার আগে সেটি ফেরত দিতে হয়। কারণটি স্বাভাবিক: compiler-এর heap চলার সময়ের প্রোগ্রামে নেই, তাই সেখানের কোনো ঠিকানা প্রোগ্রামে “বেঁচে” থাকতে পারে না। ফলে:

constexpr int count_words(std::string_view s) {
    std::vector<std::string> words;              // C++20: ভেতরে vector চলে
    /* ... s ভেঙে words-এ রাখা ... */
    return static_cast<int>(words.size());       // vector এখানেই মুছে যায়: ঠিক
}
constexpr int n = count_words("ami banglay gaan gai");   // ঠিক
constexpr std::vector<int> v{1, 2, 3};          // error: মেমরি constant evaluation-এর পরেও বেঁচে থাকত

ফল যদি একটি তালিকা হয়, তাহলে ভেতরে std::vector-এ কাজ করে শেষে একটি নির্দিষ্ট মাপের std::array-এ কপি করে ফেরত দিন — যেমন ছাঁকনির উদাহরণে।

৮ · compiler যখন বাগ ধরে — UB নিষেধ, আর এর দাম

constant evaluation-এর সবচেয়ে কম আলোচিত, কিন্তু সবচেয়ে দামি গুণটি হলো: সেখানে undefined behavior নিষিদ্ধ। standard বলে, যে হিসাবে ভাষার স্তরের UB ঘটে, সেটি constant expression নয়। তাই constexpr প্রসঙ্গে signed integer overflow, array-র সীমার বাইরে পড়া, শূন্য দিয়ে ভাগ, null pointer অনুসরণ, মুছে ফেলা মেমরি পড়া — সবই compile error হয়ে ধরা পড়ে। চলার সময় এগুলো নীরবে ভুল ফল দিত, বা কখনো কিছুই না দেখিয়ে চলে যেত। ধাপে ধাপে তুলনা করুন:

constexpr int square(int x) { return x * x; }

// int সাধারণত 32-বিট: সর্বোচ্চ 2147483647
// square(50000) = 2500000000  — int-এ ধরে না

constexpr int area = square(50000);

error: overflow in constant expression [-fpermissive]
  in 'constexpr' expansion of 'square(50000)'

int side = read_side();       // ব্যবহারকারী দিলেন 50000
int area = square(side);      // UB: standard কোনো নিশ্চয়তা দেয় না

সাধারণত দেখা যায়: area = -1794967296
কখনো optimizer ধরে নেয় overflow হয়ই না, আর পরের if-ও উধাও।

static_assert(square(46340) == 2147395600);   // ঠিক: সীমার ভেতরে
static_assert(square(46341) > 0);             // error: overflow ধরা পড়ল

=> ফাংশনের সীমা খুঁজে পাওয়া গেল প্রোগ্রাম চালানোর আগেই

একটি সূক্ষ্ম ব্যতিক্রম জেনে রাখুন: নিয়মটি ভাষার নিজের UB-এর জন্য বাধ্যতামূলক। standard library-র ফাংশনের পূর্বশর্ত ভাঙা (যেমন খালি vector-এ front()) compiler compile-এর সময়ে ধরতে পারে, কিন্তু standard সেটি বাধ্যতামূলক করেনি। বাস্তবে GCC আর Clang অনেকগুলোই ধরে।

দাম কত — compile-এর সময়ের হিসাব বিনামূল্যে নয়

• বিল্ড ধীর হয়। compiler আসলে একটি interpreter চালিয়ে আপনার কোড চালায়, যা মেশিন কোডের চেয়ে অনেক ধীর। ৫০ ঘরের টেবিল কিছুই না, কিন্তু ১০ লাখ ঘরের টেবিল বিল্ডে উল্লেখযোগ্য সময় নিতে পারে। আর header-এ থাকলে প্রতিটি .cpp ফাইল নতুন করে হিসাব করে।
• compiler-এর সীমা আছে। লুপের পাক, recursion-এর গভীরতা আর মোট ধাপের একটি সীমা compiler নিজে বসায়; ছাড়ালে error. GCC-তে -fconstexpr-loop-limit, -fconstexpr-ops-limit; Clang-এ -fconstexpr-steps দিয়ে বদলানো যায়।
• ডিবাগ কঠিন। compile-এর সময়ের হিসাবে breakpoint বসানো যায় না, std::println দিয়ে মান ছাপানো যায় না। কৌশল: ফাংশনটি আগে চলার সময়ে চালিয়ে debugger-এ ঠিক করুন, তারপর constexpr-এ ব্যবহার করুন — একই কোড দুই জায়গায় চলে বলেই এটি সম্ভব।
• প্রোগ্রাম বড় হতে পারে। বড় টেবিল প্রোগ্রাম ফাইলেই থাকে। কখনো চলার সময় একবার বানানো বা ফাইল থেকে পড়াই ভালো।

নিয়মটা তাই: যে মান সত্যিই ধ্রুবক আর ছোট থেকে মাঝারি হিসাবের, সেখানে constexpr. যে ফাংশন সরল আর বিশুদ্ধ (বাইরের অবস্থা পড়ে না), তাকে constexpr করা প্রায় বিনামূল্যে — কিন্তু “সব কিছুতে constexpr” লক্ষ্য নয়। ফাইল, নেটওয়ার্ক, সময় বা random-নির্ভর কিছু কখনো constexpr হবে না।

৯ · AI-এর যুগে — compile-time কোডের ভুল ধরা

AI টুল compile-time কোডে দুই বিপরীত দিকে ভুল করে। একদিকে, অনলাইনে C আর পুরোনো C++-এর বিপুল কোড আছে, তাই AI এখনো প্রায়ই #define দিয়ে ধ্রুবক লেখে, বা ২৫৬টি সংখ্যার টেবিল হাতে বসিয়ে দেয়। অন্যদিকে, “আধুনিক C++” বললে কখনো কখনো সবকিছুতে constexpr বসিয়ে দেয় — এমন ফাংশনেও, যা ফাইল পড়ে বা কখনো compile-এর সময়ে ডাকা হবে না। আর C++11-যুগের template metaprogramming-এর কৌশল প্রায়ই সেখানে আসে, যেখানে একটি সাধারণ constexpr ফাংশন যথেষ্ট। সাধারণ ভুলগুলো:

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

• কোথাও ধ্রুবকের জন্য #define নেই; নাম দেওয়া constexpr ধ্রুবক আছে
• যেখানে compile-time মান দরকার (array-র মাপ, static_assert, টেবিল), সেখানে constexpr, শুধু const নয়
• “compile-এর সময় হিসাব হবে” দাবিটি সত্যি — ফল constexpr ভ্যারিয়েবলে, বা ফাংশন consteval
• ফাইল, সময়, random বা I/O-নির্ভর কোনো ফাংশনে constexpr নেই
• টেবিল আর গুরুত্বপূর্ণ ফাংশনের জন্য অন্তত কয়েকটি static_assert আছে, আর আমি একটিকে ইচ্ছা করে ভুল বানিয়ে দেখেছি বিল্ড থামে কি না
• recursive template-এর কৌশল থাকলে জিজ্ঞেস করেছি — লুপসহ constexpr ফাংশনে কি সহজ হতো?