মডুলার প্রোগ্রাম — বড় প্রজেক্টকে ফাইলে ফাইলে সাজানো

১ · এক ফাইলে তিন হাজার লাইন — কেন আর চলে না

পর্ব ২৩-এ নাদিয়া রহিম চাচার দোকানের জন্য একটি খাতা-প্রোগ্রাম বানিয়েছিলেন — একটিমাত্র ফাইল, প্রায় ২২০ লাইন। চাচা খুশি। খবর ছড়াল, পাশের দুটি দোকানও চাইল। এবার নতুন চাহিদা এলো একের পর এক: মাসিক রিপোর্ট, বাকির তালিকা, ফাইলে সেভ (পর্ব ২৪), দিনের শেষে SMS. কাজ ভাগ করতে নাদিয়ার বন্ধু রাফি রিপোর্টের অংশটি লেখার দায়িত্ব নিলেন।

ছয় মাস পর shop.c ফাইলটি দাঁড়াল প্রায় তিন হাজার লাইনে। তখন যা যা ঘটতে লাগল:

• খুঁজে পাওয়া যায় না। “মোট হিসাবের ফাংশনটা কোথায়?” — প্রতিবার স্ক্রল করে বা সার্চ করে খুঁজতে হয়।
• দুজন একসাথে কাজ করতে পারেন না। নাদিয়া আর রাফি একই ফাইল বদলান, তাই git-এ প্রায় প্রতিদিন দুজনের পরিবর্তনে সংঘাত (conflict) হয়।
• একটি লাইন বদলালেও পুরো ফাইল আবার compile হয়। পর্ব ০৩-এর separate compilation-এর সুবিধা পুরোপুরি হারিয়ে গেছে।
• সবাই সবকিছু ছুঁতে পারে। রাফির রিপোর্ট-কোড সরাসরি lg.count বদলে দিল, আর নাদিয়ার হিসাব ভেঙে গেল — কেউ টেরও পেল না কোথা থেকে।
• আবার ব্যবহার করা যায় না। খাতার যুক্তিটুকু একটি মোবাইল অ্যাপে লাগাতে চাইলে পুরো ফাইল থেকে কেটে আলাদা করতে হবে।

সমাধান হলো প্রোগ্রামকে module-এ ভাগ করা। প্রতিটি মডিউল একটি নির্দিষ্ট দায়িত্ব নেয়, আর তার দুটি অংশ থাকে: বাইরের দরজা, অর্থাৎ interface — অন্যরা কী ব্যবহার করতে পারবে; আর ঘরের ভেতর, অর্থাৎ implementation — কাজটা আসলে কীভাবে হয়। পর্ব ২৩-এ শেখা separation of concerns এতদিন ছিল ফাংশনের স্তরে; এবার সেটি উঠে আসছে ফাইলের স্তরে।

২ · খাতাকে তিন ফাইলে ভাগ — ledger.h, ledger.c, main.c

পর্ব ২৩-এ নাদিয়া প্রোগ্রামটিকে তিন স্তরে ভেবেছিলেন: UI (মেনু, প্রশ্ন, ছাপা), logic (ledger_ ফাংশনগুলো) আর ডেটা। সেই নকশাই এখন ফাইলের ভাগ ঠিক করে দেয় — আর logic স্তরে কোনো printf/scanf নেই বলেই ভাগটা এত পরিষ্কার।

প্রথম ফাইল — interface. এখানে আছে শুধু সেটুকু, যা অন্য ফাইলের জানা দরকার:

/* ledger.h - public interface of the ledger module */
#ifndef LEDGER_H
#define LEDGER_H

#include <stddef.h>                      /* for size_t */

typedef enum { PAY_CASH, PAY_BKASH, PAY_DUE } PayMethod;

typedef struct {
    char      item[32];
    int       qty;
    long      price;                       /* paisa: 72.50 Tk = 7250 */
    PayMethod pay;
} Sale;

typedef struct {
    Sale  *items;
    size_t count, capacity;
} Ledger;

void ledger_init(Ledger *lg);
int  ledger_add(Ledger *lg, Sale s);       /* 0 = ok, -1 = no memory */
long ledger_total(const Ledger *lg, int pay); /* pay = -1 means all */
void ledger_free(Ledger *lg);

#endif /* LEDGER_H */

দ্বিতীয় ফাইল — implementation. ফাংশনগুলোর আসল কোড, আর একটি নিজস্ব helper, যাকে বাইরের কেউ দেখতে পাবে না:

/* ledger.c - how the ledger actually works */
#include <stdlib.h>
#include "ledger.h"           /* own header: compiler checks they match */

static int grow(Ledger *lg)   /* private: invisible outside this file */
{
    size_t ncap = lg->capacity ? 2 * lg->capacity : 2;
    Sale *t = realloc(lg->items, ncap * sizeof *t);
    if (t == NULL) return -1;
    lg->items = t;
    lg->capacity = ncap;
    return 0;
}

void ledger_init(Ledger *lg) { lg->items = NULL; lg->count = lg->capacity = 0; }

int ledger_add(Ledger *lg, Sale s)
{
    if (lg->count == lg->capacity && grow(lg) != 0) return -1;
    lg->items[lg->count++] = s;
    return 0;
}

long ledger_total(const Ledger *lg, int pay)
{
    long sum = 0;
    for (size_t i = 0; i < lg->count; i++)
        if (pay < 0 || lg->items[i].pay == (PayMethod)pay)
            sum += lg->items[i].qty * lg->items[i].price;
    return sum;
}

void ledger_free(Ledger *lg) { free(lg->items); ledger_init(lg); }

তৃতীয় ফাইল — UI. এটি খাতা ব্যবহার করে, কিন্তু realloc বা grow সম্পর্কে কিছুই জানে না:

/* main.c - talks to the user, uses the ledger only through ledger.h */
#include <stdio.h>
#include "ledger.h"

static int  ui_menu(void);            /* private to main.c */
static void ui_add(Ledger *lg);
static void ui_totals(const Ledger *lg);

int main(void)
{
    Ledger lg;
    ledger_init(&lg);
    int choice;
    while ((choice = ui_menu()) != 0) {
        if (choice == 1) ui_add(&lg);
        else if (choice == 4) ui_totals(&lg);
        else puts("No such option.");
    }
    ledger_free(&lg);
    return 0;
}
/* ui_menu, ui_add, ui_totals: same as in lesson 23 */

খেয়াল করুন দুটি ছোট বিষয়। #include <stdio.h>-এ কোণ বন্ধনী মানে “system-এর ফোল্ডারে খোঁজো”, আর #include "ledger.h"-এ উদ্ধৃতিচিহ্ন মানে “আগে আমার প্রজেক্টের ফোল্ডারে খোঁজো”। আর ledger.c নিজের header নিজেই include করে — এতে header-এর prototype আর .c-এর সংজ্ঞায় কোনো অমিল থাকলে compiler সঙ্গে সঙ্গে ধরে ফেলে।

এবার build. পর্ব ০৩-এ দেখেছেন, -c মানে “শুধু .o পর্যন্ত যাও, link কোরো না”:

gcc -Wall -Wextra -g -c ledger.c     # ledger.c  -> ledger.o
gcc -Wall -Wextra -g -c main.c       # main.c    -> main.o
gcc main.o ledger.o -o shop          # linker joins them -> shop

কিন্তু main.c compile করার সময় compiler তো ledger.c দেখেইনি — তাহলে ledger_add ডাকাটা সে মানল কীভাবে? আর শেষে linker কীভাবে ঠিক ফাংশনটি খুঁজে পেল? নিচের ডায়াগ্রামে পুরো পথটি ধাপে ধাপে দেখুন:

#include <stdio.h>
#include "ledger.h"

int main(void) {
    Ledger lg;
    ledger_init(&lg);
    Sale s = { "Rice 1kg", 2, 7250, PAY_CASH };
    ledger_add(&lg, s);
    ...

/* stdio.h থেকে আনা কয়েকশো লাইন ... */
typedef enum { PAY_CASH, PAY_BKASH, PAY_DUE } PayMethod;
typedef struct { ... } Sale;
typedef struct { ... } Ledger;
void ledger_init(Ledger *lg);
int  ledger_add(Ledger *lg, Sale s);   /* শুধু ঘোষণা, শরীর নেই */
...
int main(void) {
    ...
    ledger_add(&lg, s);

U ledger_add     U = undefined: দরকার, কিন্তু আমার কাছে নেই
U ledger_free
U ledger_init
T main           T = text: এই ফাংশনের কোড আমার ভেতরে আছে
t ui_menu        ছোট হাতের t = static, শুধু এই ফাইলের

t grow           static: linker-এর কাছে অদৃশ্য
T ledger_add     এই সেই কোড, যা main.o খুঁজছে
T ledger_free
T ledger_init
T ledger_total
U free
U realloc        এগুলো আসবে C library থেকে

$ gcc main.o ledger.o -o shop
main.o: U ledger_add  ⟷  ledger.o: T ledger_add  ✓
ledger.o: U realloc   ⟷  libc: realloc           ✓
$ ./shop
1) Add  2) List  4) Totals  0) Exit

$ gcc main.o -o shop
/usr/bin/ld: main.o: in function `main':
main.c:(.text+0x2b): undefined reference to `ledger_init'
main.c:(.text+0x5e): undefined reference to `ledger_add'
collect2: error: ld returned 1 exit status

৩ · Header-এর নিয়ম — কী থাকবে, কী কখনো থাকবে না

একটি header অনেকগুলো .c ফাইলে include হয়। খাতার header ঢুকবে main.c-এ, রাফির report.c-এ, পরে হয়তো sms.c-তেও। তাই নিয়ম একটাই: header-এ এমন কিছু রাখা যাবে না, যা প্রতিটি ফাইলে কপি হলে সমস্যা করে। Declaration (“এই নামে একটি জিনিস আছে”) যত জায়গায় খুশি থাকতে পারে; কিন্তু definition (“এই সেই জিনিস, এর জন্য মেমরি নাও”) পুরো প্রোগ্রামে থাকবে ঠিক একবার।

ভুলটি করলে কী হয়? ধরুন রাফি সুবিধার জন্য header-এ লিখে দিলেন int ledger_debug = 0;. main.c আর report.c — দুটিই header include করে, তাই দুটি .o-তেই একটি করে ledger_debug তৈরি হলো। প্রতিটি ফাইল আলাদাভাবে compile হয়, তাই compiler কিছুই টের পায় না। ধরা পড়ে link করার সময়:

/usr/bin/ld: report.o:(.bss+0x0): multiple definition of `ledger_debug'; main.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status

ইচ্ছা করে ভাগ করা global — extern

পর্ব ১৩-এ দেখেছেন, global ভ্যারিয়েবল যত কম, তত ভালো। তবু কখনো সত্যিই একটি মান সব মডিউলের দেখা দরকার — যেমন “debug বার্তা ছাপব কি না”। সঠিক নিয়ম: header-এ extern দিয়ে ঘোষণা, আর ঠিক একটি .c ফাইলে আসল সংজ্ঞা।

/* in ledger.h : a promise, no memory */
extern int ledger_debug;

/* in ledger.c : the one and only real variable */
int ledger_debug = 0;

ফাইলের নিজস্ব জিনিস — static

উল্টো দিকে, grow-এর মতো helper বা ui_menu-এর মতো ফাংশন অন্য কারও জানার দরকার নেই। পর্ব ১৩-এর static ও extern অংশে দেখেছেন, ফাংশনের বাইরে static লিখলে নামটি শুধু সেই ফাইলের হয়ে যায় — একে বলে internal linkage. এতে দুটি লাভ: অন্য ফাইল ভুল করে এটিকে ডাকতে পারে না, আর দুটি মডিউলে একই নামের helper (যেমন দুই ফাইলেই static int grow) থাকলেও কোনো সংঘাত হয় না।

একই header দুবার ঢুকলে — include guard

রাফির report.h-ও ledger.h include করে (রিপোর্টে Ledger টাইপ লাগে)। এখন main.c যদি দুটিই include করে, তাহলে ledger.h-এর লেখা ঢুকবে দুবার — আর একই typedef struct {…} Sale; দুবার দেখে compiler বলবে redefinition. এর সমাধান পর্ব ২৭-এর preprocessor অংশ থেকে আপনার চেনা: include guard. ledger.h-এর প্রথম দুই লাইন আর শেষ লাইন আবার দেখুন:

#ifndef LEDGER_H      /* first time: LEDGER_H is not defined, so enter */
#define LEDGER_H      /* now it is defined */
/* ... types and prototypes ... */
#endif                /* second time: the whole body is skipped */

অনেক compiler #pragma once-ও বোঝে — এক লাইনেই একই কাজ। প্রধান compiler-গুলো মানে, তবে এটি C standard-এর অংশ নয়। যেটিই নিন, প্রতিটি header-এ একটি guard থাকা বাধ্যতামূলক অভ্যাস।

৪ · Information hiding — ভেতরটা লুকিয়ে রাখা

অংশ ১-এর সেই সমস্যাটি মনে করুন: রাফির রিপোর্ট-কোড সরাসরি lg.count বদলে দিয়েছিল। ফাইল ভাগ করার পরও এটি সম্ভব! কারণ Ledger struct-এর পুরো গঠন ledger.h-এ লেখা আছে — যে-ই header include করে, সে-ই items, count, capacity দেখতে ও বদলাতে পারে। দরজা আছে, কিন্তু দেয়ালে কাচ লাগানো আর জানালা খোলা।

আরও বড় সমস্যা: নাদিয়া খাতাকে অ্যারে থেকে linked list-এ (পর্ব ৩৩) বদলাতে চাইলে, যে দশটি ফাইল সরাসরি lg.items[i] পড়ে, দশটিই বদলাতে হবে।

C-তে এই লুকানোর কৌশলের নাম opaque pointer (অস্বচ্ছ পয়েন্টার)। Header-এ struct-এর শুধু নাম থাকে, গঠন থাকে .c ফাইলে। বদলটা দেখুন:

/* BEFORE: everyone sees and can touch the fields
typedef struct { Sale *items; size_t count, capacity; } Ledger; */

/* AFTER: only the name is public */
typedef struct Ledger Ledger;

Ledger *ledger_new(void);                   /* NULL if no memory   */
void    ledger_delete(Ledger *lg);
int     ledger_add(Ledger *lg, Sale s);
long    ledger_total(const Ledger *lg, int pay);
size_t  ledger_count(const Ledger *lg);     /* read-only access    */
const Sale *ledger_get(const Ledger *lg, size_t i);

#include <stdlib.h>
#include "ledger.h"

struct Ledger {                /* the full shape lives ONLY here */
    Sale  *items;
    size_t count, capacity;
};

Ledger *ledger_new(void)    { return calloc(1, sizeof(Ledger)); }
void    ledger_delete(Ledger *lg) { if (lg) free(lg->items); free(lg); }
size_t  ledger_count(const Ledger *lg) { return lg->count; }

typedef struct Ledger Ledger; লাইনটি compiler-কে বলে: “struct Ledger নামে একটি টাইপ আছে।” কিন্তু তার ভেতরে কী আছে বা আকার কত, তা বলে না। এমন টাইপকে বলে incomplete type. এর পয়েন্টার রাখা যায় (পয়েন্টারের আকার সবসময় জানা), কিন্তু এর field পড়া বা এর ভ্যারিয়েবল বানানো যায় না। ধাপে ধাপে দেখুন main.c কী পারে আর কী পারে না:

main.c   →  দেখে: struct Ledger নামে কিছু একটা আছে
            জানে না: আকার কত, ভেতরে কী
ledger.c →  দেখে: struct Ledger { Sale *items; size_t count, capacity; }

main.c:14:7: error: invalid use of incomplete typedef 'Ledger'
   14 |     lg->count = 0;
      |       ^~
(পুরোনো GCC-তে: dereferencing pointer to incomplete type)

main.c:9:12: error: storage size of 'lg' isn't known
    9 |     Ledger lg;
      |            ^~
আকার না জানলে কত byte জায়গা নেবে, compiler বুঝবে কীভাবে?

Ledger *lg = ledger_new();          /* খাতা বানায় ledger.c */
if (lg == NULL) return 1;
ledger_add(lg, s);
printf("%zu sales\n", ledger_count(lg));
ledger_delete(lg);                  /* ফেরতও দেয় ledger.c */

struct Ledger {
    Sale  *items;
    size_t count, capacity;
    long   cash_total;            /* নতুন: মোট আগেই হিসাব করা */
};
$ make
gcc -Wall -Wextra -g -c ledger.c   ← শুধু এটি
gcc main.o ledger.o report.o -o shop

এবার নিজে চালিয়ে দেখুন। অনলাইন compiler একটিমাত্র ফাইল নেয়, তাই নিচে তিনটি “ফাইল” একটি ফাইলে পরপর রাখা হয়েছে — আর কৌশলটি হলো main-কে রাখা হয়েছে struct-এর গঠনের আগে. ফলে main লেখার মুহূর্তে compiler সত্যিই শুধু নামটি জানে, ঠিক আলাদা main.c-এর মতো:

#include <stdio.h>
#include <stdlib.h>
/* ---- ledger.h: the only part main() can see ---- */
typedef struct Ledger Ledger;               /* opaque: name only, no fields */
Ledger *ledger_new(void);
void    ledger_add(Ledger *lg, long paisa);
long    ledger_total(const Ledger *lg);
void    ledger_delete(Ledger *lg);
int main(void) {                            /* ---- main.c ---- */
    Ledger *lg = ledger_new();
    if (lg == NULL) return 1;
    ledger_add(lg, 14500); ledger_add(lg, 15600);
    printf("Total: %ld paisa\n", ledger_total(lg));
    /* printf("%d\n", lg->count); */          /* try: remove the comment marks */
    ledger_delete(lg);
    return 0;
}
struct Ledger { long sum; int count; };     /* ---- ledger.c: hidden ---- */
Ledger *ledger_new(void) { return calloc(1, sizeof(Ledger)); }
void ledger_add(Ledger *lg, long p) { lg->sum += p; lg->count++; }
long ledger_total(const Ledger *lg) { return lg->sum; }
void ledger_delete(Ledger *lg) { free(lg); }

এই কৌশল আপনি প্রথম দিন থেকেই ব্যবহার করছেন, হয়তো খেয়াল করেননি। পর্ব ২৪-এর FILE *fp = fopen(...) — FILE-এর ভেতরে কী আছে, C standard কখনো বলেনি। প্রতিটি অপারেটিং সিস্টেমের library নিজের মতো করে সাজায়, আর আপনি শুধু fopen, fgets, fclose ব্যবহার করেন। তাই একই কোড Windows আর Linux দুই জায়গাতেই চলে।

৫ · Make — শুধু যা বদলেছে, তা-ই আবার বানানো

অংশ ২-এ তিনটি কমান্ড হাতে লিখে build করেছিলেন। রাফির report.c যোগ হলে চারটি, SMS যোগ হলে পাঁচটি। আর প্রতিবার ভাবতে হবে: “কোনটি বদলেছি? কোনটি আবার compile করতে হবে?” একটি ভুলে যাওয়া মানে পুরোনো .o দিয়ে তৈরি প্রোগ্রাম — যেখানে আপনার নতুন সংশোধনটাই নেই। এই হিসাবের কাজটি মানুষের নয়, একটি build system-এর। সবচেয়ে পুরোনো আর এখনো বহুল ব্যবহৃত build system হলো Make.

Make পড়ে একটি ফাইল — Makefile. এতে প্রতিটি নিয়মের তিনটি অংশ:

দোকানের খাতা প্রজেক্টের একটি ছোট কিন্তু আসল Makefile দেখুন (রাফির report.c আর report.h-সহ):

# Makefile - shop ledger  (every recipe line starts with a TAB)
CC     = gcc
CFLAGS = -Wall -Wextra -g
OBJS   = main.o ledger.o report.o

shop: $(OBJS)
	$(CC) $(OBJS) -o shop

main.o: main.c ledger.h report.h
	$(CC) $(CFLAGS) -c main.c

ledger.o: ledger.c ledger.h
	$(CC) $(CFLAGS) -c ledger.c

report.o: report.c report.h ledger.h
	$(CC) $(CFLAGS) -c report.c

clean:
	rm -f shop $(OBJS)

.PHONY: clean

লাইন ধরে পড়ুন। উপরের তিনটি লাইন ভ্যারিয়েবল — $(CFLAGS) লিখলে সেখানে বসে যায় -Wall -Wextra -g, পর্ব ০৩-এর সেই প্রতিদিনের flag. পরের নিয়মগুলো বলছে: shop তৈরি হয় তিনটি .o থেকে; প্রতিটি .o তৈরি হয় তার .c আর যে header-গুলো সে include করে, সেগুলো থেকে। clean কোনো ফাইল নয়, একটি কাজের নাম — তাই .PHONY দিয়ে Make-কে জানিয়ে রাখা হলো। টার্মিনালে শুধু make লিখলে Make প্রথম target (shop) বানাতে চেষ্টা করে।

Makefile:7: *** missing separator.  Stop.

Make কীভাবে ঠিক করে কী আবার বানাতে হবে

Make-এর পুরো বুদ্ধি একটি সহজ প্রশ্নে: “target কি তার কোনো prerequisite-এর চেয়ে পুরোনো?” প্রতিটি ফাইলের সাথে অপারেটিং সিস্টেম শেষ বদলানোর সময় (timestamp) রাখে। Prerequisite target-এর চেয়ে নতুন হলে বুঝতে হবে target বানানোর পর সেটি বদলেছে — তাই আবার বানাও। না হলে বাদ। ধরুন সকাল ১০টায় সব build করা ছিল, তারপর ১০:৩০-এ আপনি শুধু ledger.c-তে একটি সংশোধন করে সেভ করলেন। এবার make:

প্রতিদিনের Make কমান্ড

বড় প্রজেক্টে প্রতিটি .o-এর আলাদা নিয়মের বদলে একটি pattern rule লেখা হয়: %.o: %.c, যার recipe-তে $< মানে প্রথম prerequisite আর $@ মানে target. AI-এর Makefile-এ দেখলে চিনতে পারলেই যথেষ্ট।

CMake — সব প্ল্যাটফর্মের জন্য একটি বর্ণনা

Makefile মূলত Unix-ধাঁচের পরিবেশের জন্য; Windows-এর Visual Studio নিজের ধরনের প্রজেক্ট ফাইল চায়। বড় C ও C++ প্রজেক্ট তাই প্রায়ই CMake ব্যবহার করে। CMake নিজে build করে না — আপনি একবার প্রজেক্টের বর্ণনা লেখেন, আর CMake প্রতিটি প্ল্যাটফর্মের জন্য উপযুক্ত build ফাইল (Makefile, Ninja ফাইল বা Visual Studio প্রজেক্ট) তৈরি করে দেয়। একে বলে build generator:

cmake_minimum_required(VERSION 3.13)
project(shop_ledger C)

add_library(ledger STATIC src/ledger.c src/report.c)
target_include_directories(ledger PUBLIC include)

add_executable(shop src/main.c)
target_link_libraries(shop PRIVATE ledger)

cmake -S . -B build        # read CMakeLists.txt, generate build files in build/
cmake --build build        # run the real build (make, ninja, or MSVC)

CMake header-এর নির্ভরতা নিজেই হিসাব রাখে। তবু শুরুতে Make শিখুন — ভেতরের ধারণাটি সেখানেই সবচেয়ে পরিষ্কার।

৬ · Library — মডিউলকে প্যাকেট করে বিলি করা

পাশের দোকানের জন্য আরেকজন প্রোগ্রামার একটি SMS-রিপোর্ট টুল বানাতে চান, যেটিও খাতা ব্যবহার করবে। সোর্স কোড কপি করে দিলে আপনার পরের সংশোধন তাঁর কাছে পৌঁছাবে না। সাধারণ পথ হলো মডিউলকে একটি library বানিয়ে দেওয়া — compile করা কোড আর সাথে header. পর্ব ০৩-এ দেখেছেন library দুইভাবে জোড়া যায়: static আর dynamic. এবার নিজে বানিয়ে দেখি:

$ gcc -Wall -Wextra -g -c ledger.c report.c
$ ar rcs libledger.a ledger.o report.o
$ ar t libledger.a          # ভেতরে কী আছে?
ledger.o
report.o

$ gcc main.c -L. -lledger -o shop
  -L.       → library খোঁজার তালিকায় এই ফোল্ডারও যোগ করো
  -lledger  → "lib" + ledger + ".so" বা ".a" নামের ফাইল খোঁজো
$ rm libledger.a
$ ./shop                    # তবু চলে — কোড shop-এর ভেতরে ঢুকে গেছে

$ gcc -fPIC -Wall -Wextra -g -c ledger.c report.c
$ gcc -shared -o libledger.so ledger.o report.o
$ gcc main.c -L. -lledger -o shop
$ ldd ./shop
    libledger.so => not found
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

$ ./shop
./shop: error while loading shared libraries: libledger.so:
cannot open shared object file: No such file or directory
$ LD_LIBRARY_PATH=. ./shop   # loader-কে বলা হলো এই ফোল্ডারেও খোঁজো
1) Add  2) List  4) Totals  0) Exit

✓ বাগ ঠিক করা ledger_total  → shop, sms_report … সবাই পরের বার খুললেই পায়
✗ Sale-এ নতুন field যোগ       → পুরোনো shop ধরে নেয় Sale 56 byte,
                               নতুন library ধরে নেয় 64 byte → ভুল হিসাব
সমাধান: ভেতরটা opaque রাখা, নইলে নতুন version নম্বর (libledger.so.2)

ABI — compile হয়ে যাওয়া কোডের চুক্তি

Header হলো সোর্স কোডের স্তরে চুক্তি (API): কোন নাম, কোন টাইপ। কিন্তু compile হওয়ার পর আরেকটি চুক্তি তৈরি হয়, যাকে বলে ABI — struct-এর আকার কত byte, কোন field কত নম্বর byte থেকে শুরু, ফাংশনে argument কোন register-এ যায়, symbol-এর নাম কী। ধরুন ৬৪-bit Linux-এ পুরোনো shop compile হয়েছিল এই ধারণায় যে Sale ৫৬ byte, আর pay field শুরু হয় ৪৮ নম্বর byte থেকে। নতুন library-তে price-এর পরে একটি long discount যোগ হলো — এখন Sale ৬৪ byte, আর pay সরে গেছে ৫৬ নম্বর byte-এ। পুরোনো প্রোগ্রাম সেটা জানে না, তাই ভুল জায়গা থেকে ভুল মান পড়ে — কোনো error ছাড়াই। তাই shared library-র লেখকেরা খুব সাবধানে ABI রক্ষা করেন: struct-কে opaque রাখেন (তখন আকার শুধু library জানে), পুরোনো ফাংশন না বদলে নতুন ফাংশন যোগ করেন, আর ABI ভাঙতেই হলে library-র নামে নতুন version নম্বর দেন (যেমন libledger.so.1 থেকে libledger.so.2), যাতে পুরোনো প্রোগ্রাম পুরোনো version-ই খোঁজে।

৭ · প্রজেক্টের ফোল্ডার, README আর git

ফাইল বাড়তে থাকলে একটি ফোল্ডারে সব ফেলে রাখাও আরেক রকম এলোমেলো। পেশাদার C প্রজেক্টে একটি প্রচলিত সাজানো আছে; যেকোনো GitHub প্রজেক্ট খুললে প্রায় এরকমই দেখবেন:

shop-ledger/
├── README.md          কী, কীভাবে build, কীভাবে চালাবেন
├── Makefile
├── .gitignore         build/ যেন git-এ না যায়
├── include/
│   ├── ledger.h       public interface — বাইরের জগৎ শুধু এটুকু দেখে
│   └── report.h
├── src/
│   ├── ledger.c
│   ├── report.c
│   └── main.c
├── tests/
│   └── test_ledger.c  ledger মডিউলের নিজস্ব টেস্ট
└── build/             .o, libledger.a, shop — তৈরি হওয়া জিনিস

এবার পুরো প্রজেক্টকে git-এর অধীনে আনুন। মডিউল ভাগের পর git আরও কাজের — নাদিয়া src/ledger.c আর রাফি src/report.c বদলালে তাঁদের পরিবর্তন আলাদা ফাইলে, তাই merge প্রায় সবসময় নিজে থেকেই হয়ে যায়। একটি নিয়ম মনে রাখুন: git-এ রাখুন যা মানুষ লেখে (source, header, Makefile, README), রাখবেন না যা মেশিন বানায় (.o, .a, shop).

git init
echo "build/" > .gitignore
git add README.md Makefile .gitignore include src tests
git commit -m "Split ledger into modules: ledger, report, main"

৮ · AI-এর যুগে মডুলার প্রোগ্রাম

AI-কে “একটি দোকানের হিসাবের প্রোগ্রাম লেখো” বললে প্রায় সবসময় একটি লম্বা ফাইল আসে — সব ফাংশন, সব global, একটি বিশাল main. একবার চালানোর জন্য ঠিক আছে; কিন্তু সেটিই যদি প্রজেক্টের ভিত হয়, ছয় মাস পর আপনি সেই দেয়ালহীন বাড়িতে আটকে যাবেন। আর “ফাইলে ভাগ করো” বললে সে প্রায়ই এমন ভুল করে, যা ধরা পড়ে শুধু link বা build-এর সময়।

AI সাধারণত যেসব মডিউল-ভুল করে

AI-এর মডিউল ভাগ হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি header-এ include guard আছে, আর কোনো header-এ = দিয়ে মান বসানো ভ্যারিয়েবল বা { }-সহ ফাংশন নেই
• প্রতিটি .c নিজের header সবার আগে বা শুরুর দিকে include করে, আর header-এর বাইরের সব ফাংশন static
• make clean তারপর make — একটিও warning নেই; তারপর একটি header-এ ফাঁকা লাইন যোগ করে make চালিয়ে দেখেছি, ঠিক যে ফাইলগুলো আবার compile হওয়ার কথা সেগুলোই হলো
• মডিউলের নির্ভরতার ছবি এঁকেছি — কোথাও বৃত্ত নেই, আর logic মডিউল কখনো UI মডিউলকে ডাকে না
• প্রতিটি public ফাংশন কেন public, নিজের ভাষায় বলতে পারি; যেটির কারণ বলতে পারি না, সেটি static করে দেখেছি কিছু ভাঙে কি না