``

Önce bellek haritasını anlayalım

Bir süreç çalıştırıldığında işletim sistemi ona geniş ve kesintisiz görünen bir sanal adres alanı sunar. Programın kullandığı adresler doğrudan fiziksel RAM adresleri değildir. Sayfa tabloları, sanal sayfaları fiziksel çerçevelere eşler.

Bir adres alanı kabaca kod, global veriler, stack ve heap bölgelerinden oluşur. malloc ile istediğimiz alan heap üzerinde yönetilir; ancak her malloc çağrısının anında yeni bir fiziksel sayfa ayırması gerekmez. İşletim sistemi sayfaları ihtiyaç anında eşleyebilir.

Bellek kullanımını basitleştirerek şöyle ifade edebiliriz:

Garbage collector’ın amacı, artık kök nesnelerden erişilemeyen $M_{erişilemeyen}$ bölümünü bulup yeniden kullanılabilir hâle getirmektir.

Mark-and-sweep nasıl çalışır?

Algoritma iki temel aşamadan oluşur:

1. Mark: Stack, global değişkenler veya çalışma zamanı tarafından tutulan köklerden başlanır. Ulaşılabilen bütün nesneler işaretlenir.
2. Sweep: Ayrılmış nesneler taranır. İşaretlenmemiş olanlar erişilemez kabul edilerek serbest bırakılır.

Bu örnekte gerçek stack taraması yapmayacağız. Bunun yerine kökleri açıkça kaydedeceğiz. Böylece algoritmanın özü, platforma özgü ayrıntılar arasında kaybolmayacak.

#include <stdio.h>
#include <stdlib.h>

typedef struct Object {
    int marked;
    int value;
    struct Object *ref;
    struct Object *next;
} Object;

static Object *heap = NULL;

Object *gc_alloc(int value) {
    Object *obj = malloc(sizeof(Object));
    if (!obj) {
        perror("malloc");
        exit(EXIT_FAILURE);
    }

    obj->marked = 0;
    obj->value = value;
    obj->ref = NULL;
    obj->next = heap;
    heap = obj;
    return obj;
}

void mark(Object *obj) {
    if (obj == NULL || obj->marked)
        return;

    obj->marked = 1;
    mark(obj->ref);
}

void sweep(void) {
    Object **cursor = &heap;

    while (*cursor) {
        Object *obj = *cursor;
        if (!obj->marked) {
            *cursor = obj->next;
            printf("Silindi: %d\n", obj->value);
            free(obj);
        } else {
            obj->marked = 0;
            cursor = &obj->next;
        }
    }
}

void collect(Object **roots, size_t count) {
    for (size_t i = 0; i < count; i++)
        mark(roots[i]);
    sweep();
}

heap listesi ayrılan tüm nesnelerin envanteridir. ref, bir nesneden diğerine referans oluşturarak küçük bir nesne grafiği kurar. mark fonksiyonu bu grafiği derinlik öncelikli dolaşır. Döngüsel referanslarda sonsuz özyinelemeyi marked kontrolü engeller.

Collector’ı deneyelim

int main(void) {
    Object *a = gc_alloc(10);
    Object *b = gc_alloc(20);
    Object *orphan = gc_alloc(99);

    a->ref = b;

    Object *roots[] = { a };
    collect(roots, 1);

    roots[0] = NULL;
    collect(roots, 1);
    return 0;
}

İlk koleksiyonda a köktür; b nesnesine a->ref üzerinden ulaşılır. orphan ise hiçbir kökten erişilemediği için silinir. İkinci koleksiyonda kök kaldırıldığından hem a hem b temizlenir. Referans döngüsü kurulsa bile kökten ulaşılamayan nesneler toplanabilir; bu, referans sayımına göre önemli bir avantajdır.

Gerçek sistemlerden farkı

Bu oyuncak collector thread güvenliği, bellek sıkıştırma, nesil tabanlı toplama ve stack taraması sunmaz. Ayrıca özyinelemeli mark, çok derin grafiklerde stack taşmasına yol açabilir. Üretim sistemleri iş listesinden yararlanan yinelemeli tarama, tri-color marking ve eşzamanlı toplama gibi yöntemler kullanır.

Yine de proje kritik fikri gösterir: free işlemini otomatikleştirmek yalnızca adresleri takip etmek değildir; programın canlı nesne grafiğini anlamaktır. Sanal bellek bize adres alanını sağlar, allocator blokları dağıtır, garbage collector ise bu bloklardan hangilerinin artık hikâyede rolü kalmadığına karar verir.

``

Derleme süreci nasıl çalışır?

C/C++ kaynak kodu doğrudan işlemci tarafından anlaşılmaz. Yazdığımız .c veya .cpp dosyaları birkaç aşamadan geçer:

1. Ön işleme: #include ve #define ifadeleri işlenir.
2. Derleme: Kod, assembly diline dönüştürülür.
3. Assembly: Makine kodunu içeren nesne dosyası üretilir.
4. Bağlama: Nesne dosyaları ve kütüphaneler tek programda birleştirilir.

Basitleştirilmiş dönüşüm şöyledir:

Donanıma yakınlık özellikle veri boyutlarında hissedilir. Örneğin $N$ bitlik işaretsiz bir tamsayı, $0$ ile $2^N-1$ arasındaki değerleri temsil edebilir. Belleğin sınırlı olduğu gömülü sistemlerde seçilen veri türü bu nedenle önemlidir.

Derleyici kurulumu

Ubuntu ve Debian tabanlı sistemlerde GCC araç zinciri şu komutla kurulabilir:

sudo apt update
sudo apt install build-essential gdb

Clang kullanmak isteyenler ayrıca şunu çalıştırabilir:

sudo apt install clang lldb

macOS üzerinde Terminal’den xcode-select --install komutu Apple Clang araçlarını kurar. Windows’ta ise MSYS2 kurulup UCRT64 terminalinde aşağıdaki komut kullanılabilir:

pacman -S mingw-w64-ucrt-x86_64-gcc mingw-w64-ucrt-x86_64-gdb

Ardından MSYS2’nin ucrt64/bin klasörü PATH değişkenine eklenmelidir. Kurulumu doğrulamak için gcc --version, g++ --version veya clang --version çalıştırılır.

İlk program ve manuel derleme

main.cpp adında bir dosya oluşturalım:

#include <iostream>

int main() {
    int sayi = 42;
    std::cout << "Bellekteki değer: " << sayi << '\n';
    return 0;
}

Programı GCC ile derlemek için şu komut yeterlidir:

g++ -std=c++20 -Wall -Wextra -g main.cpp -o uygulama

Burada -std=c++20 dil standardını seçer, -Wall -Wextra olası hatalar için uyarıları açar, -g ise hata ayıklama bilgisi ekler. Linux/macOS üzerinde program ./uygulama, Windows’ta uygulama.exe komutuyla çalıştırılır.

VS Code yapılandırması

VS Code’a C/C++ uzantısını kurduktan sonra proje klasöründe .vscode/tasks.json dosyası oluşturulur:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "C++ Derle",
      "type": "shell",
      "command": "g++",
      "args": [
        "-std=c++20",
        "-Wall",
        "-Wextra",
        "-g",
        "${file}",
        "-o",
        "${fileDirname}/${fileBasenameNoExtension}"
      ],
      "group": { "kind": "build", "isDefault": true },
      "problemMatcher": ["$gcc"]
    }
  ]
}

Bu görev, açık olan dosyayı Ctrl+Shift+B ile derler. Clang tercih ediliyorsa command alanı clang++ yapılabilir.

Hata ayıklama sırasında breakpoint kullanmak, değişkenlerin bellekteki değişimini adım adım izlemeyi sağlar. VS Code’un Run and Debug bölümünden C++ yapılandırması seçildiğinde GDB veya LLDB çalıştırılır. Böylece yalnızca programın sonucunu değil; çağrı yığınını, işaretçileri ve bellek adreslerini de inceleyebilirsiniz.

Son olarak derleyici uyarılarını düşman değil, ücretsiz kod inceleme ekibi olarak görün. C/C++ öğrenirken -Wall -Wextra kullanmak ve küçük programları hata ayıklayıcıyla yürütmek, bellek yönetimi ile donanım arasındaki ilişkiyi çok daha görünür hâle getirir.

Statik tip sisteminin ana fikri şudur: Her ifadenin bir tipi vardır ve işlemler yalnızca uyumlu tipler arasında gerçekleşir. Örneğin int32 ile float64 aynı sayısal dünyada yaşasa da bit düzeyindeki anlamları farklıdır. Birincisi tam sayıyı ikinin tümleyeniyle, ikincisi yaklaşık reel sayıyı işaret, üs ve kesir alanlarıyla saklar. Bu nedenle tip dönüşümü sadece etiketi değiştirmek değildir; çoğu zaman bitlerin yeniden yorumlanması veya yeni bir temsile dönüştürülmesidir.

Bir veri türünün teorik kapasitesi, bit sayısıyla doğrudan ilişkilidir. İşaretsiz $n$ bitlik bir tamsayı için olası değer sayısı $2^n$ ve aralık $[0, 2^n-1]$ olur. İşaretli, ikinin tümleyeni kullanan bir tamsayıda ise aralık genellikle $[-2^{n-1}, 2^{n-1}-1]$ şeklindedir. Sekiz bitlik uint8 bu yüzden 256 farklı değer taşır; 255’ten sonra ne olacağı ise dilin taşma kurallarına bağlıdır.

*Donanım ve dil uygulamasına göre yerleşim değişebilir. Özellikle bool, yapılar içinde hizalama nedeniyle beklenenden fazla alan etkisi yaratabilir.

Bellek, byte byte adreslenen büyük bir dizi gibi düşünülebilir. Ancak işlemci bazı verilerin belirli adres sınırlarında başlamasını tercih eder; buna hizalama denir. Dört baytlık bir int32 çoğunlukla 4’ün katı bir adreste, sekiz baytlık bir float64 ise 8’in katında konumlanır. Yapıların içinde derleyicinin eklediği görünmez boşluklar, yani padding, bu yüzden ortaya çıkar. Küçük bir alan tasarrufu umarken bellekte fazladan baytlarla karşılaşmak oldukça klasik bir programcı sürprizidir.

#include <stdint.h>

struct SensorA {
    uint8_t active;
    int32_t reading;
    uint16_t id;
};

struct SensorB {
    int32_t reading;
    uint16_t id;
    uint8_t active;
};

Bu C örneğinde iki yapı aynı mantıksal alanları taşır, fakat alan sırası bellek boyutunu değiştirebilir. SensorA içinde active sonrasında int32_t hizalamak için boşluk eklenebilir. SensorB, geniş alanları önce yerleştirerek padding’i azaltma şansına sahiptir. Kesin sonuç derleyiciye, mimariye ve ABI kurallarına bağlıdır; sizeof ile ölçmek en güvenli yoldur.

Statik tip, belleğin sahibini tek başına belirlemez. Örneğin Rust’ta tip sistemi sahiplik ve ödünç alma kurallarıyla bellek güvenliğine güçlü katkı sunar; C++’ta RAII nesnenin ömrünü kapsamla ilişkilendirir; Java ve C# ise çöp toplayıcıyla erişilemeyen heap nesnelerini geri kazanır. Buna karşılık C’de malloc ile alınan alanın free edilmesi programcının sorumluluğundadır.

Sonuçta değişken tanımı, derleyiciye verilmiş bir niyet beyanıdır: Kaç bayt gerektiğini, bitlerin nasıl yorumlanacağını ve hangi işlemlerin anlamlı olduğunu söyler. Tip sınırlarını, taşmayı, hizalamayı ve yaşam süresini anlayan geliştirici; hem daha güvenli kod yazar hem de “Neden bu yapı 12 değil 16 bayt?” sorusuna paniklemeden cevap verir.

``

Ardışık bellek fikri

int sayilar[5] tanımlandığında derleyici, beş int değerini yan yana saklayacak kadar yer ayırır. Eğer bir int 4 bayt ise, dizinin kapladığı alan teorik olarak $5 \times 4 = 20$ bayttır. İlk elemanın adresi $B$ ve eleman türünün boyutu $S$ ise, $i$. elemanın adresi şu formülle bulunur:

Bu nedenle sayilar[3], aslında *(sayilar + 3) ile eşdeğerdir. Dizi adı çoğu ifadede ilk elemana işaretçiye dönüşür; yani sayilar pratikte &sayilar[0] gibi davranır. Ancak dizi adı değiştirilebilir bir işaretçi değildir: sayilar++ geçersizdir, fakat int *p = sayilar; p++; tamamen geçerlidir.

İşaretçi neden bayt bayt ilerlemez?

Bir char * işaretçisinde p + 1 tipik olarak 1 bayt ilerler; çünkü char bir bayttır. Buna karşılık double * için aynı işlem çoğu sistemde 8 baytlık bir sıçramadır. Bu davranış, kaynak kodunu hem okunabilir hem de tür güvenliği açısından daha anlamlı yapar. C’nin yaptığı hesap şudur:

Aşağıdaki örnek, indeksleme ile işaretçi aritmetiğinin aynı veriyi nasıl dolaştığını gösterir:

#include <stdio.h>

int main(void) {
    int notlar[] = {72, 85, 91, 64, 78};
    size_t adet = sizeof notlar / sizeof notlar[0];
    int *p = notlar;
    int toplam = 0;

    for (size_t i = 0; i < adet; i++) {
        toplam += *(p + i);       // notlar[i] ile aynıdır
        printf("%zu. not: %d, adres: %p\n",
               i, *(p + i), (void *)(p + i));
    }

    printf("Ortalama: %.2f\n", (double)toplam / adet);
    return 0;
}

Burada sizeof notlar / sizeof notlar[0] kalıbı, sabit boyutlu dizideki eleman sayısını hesaplar. p + i her turda bir sonraki int bloğuna gider; * operatörü de o adresteki değeri okur. Adresler ekranda sayısal olarak ardışık görünmeyebilir, fakat aralarındaki fark sizeof(int) kadardır.

Sınırlar: hızlı olmak, sınırsız olmak değildir

İşaretçi aritmetiği yalnızca aynı dizi nesnesinin sınırları içinde tanımlıdır. Dizinin son elemanından bir sonraki konumu gösteren dizi + adet adresini hesaplamak yasaldır; buna one-past-the-end denir. Fakat bu adresin içeriğini okumak, yani *(dizi + adet) yapmak tanımsız davranıştır. Aynı şekilde, farklı dizilere ait işaretçileri çıkarma veya karşılaştırma girişimleri taşınabilir değildir.

Özetle dizi, bellekteki düzenli blok planıdır; işaretçi ise bu planın koordinat aracıdır. İndeksleme çoğu zaman daha okunaklıdır, ancak işaretçi aritmetiğini anlamak fonksiyon parametreleri, tamponlar, metinler ve yüksek performanslı C kodu için vazgeçilmezdir.

Önce problemi modelleyelim

Örnek düşmanımız dört temel eylem gerçekleştirsin: devriye gezme, oyuncuyu kovalama, saldırma ve kaçma. Karar verirken oyuncuya olan $d$ mesafesini, düşmanın $h$ sağlık oranını ve oyuncunun görülüp görülmediğini kullanalım.

Saldırı koşulu basitçe şöyle ifade edilebilir:

Kaçma kararı ise $h < 0.2$ olduğunda etkinleşsin. Buradaki önemli ayrım şudur: Sonlu Durum Makinesi, karakterin hangi durumda bulunduğuna; Davranış Ağacı ise hedefe ulaşmak için hangi kararların hangi sırayla sınanacağına odaklanır.

Sonlu Durum Makinesi

Sonlu Durum Makinesi veya FSM, durumlar ve bu durumlar arasındaki geçişlerden oluşur. Düşman aynı anda yalnızca bir etkin durumda bulunur. Matematiksel olarak FSM, $M=(S,\Sigma,\delta,s_0)$ biçiminde gösterilebilir. Burada $S$ durum kümesi, $\Sigma$ girdiler, $\delta$ geçiş fonksiyonu ve $s_0$ başlangıç durumudur.

Aşağıdaki C# örneği temel karar döngüsünü uygular:

enum EnemyState { Patrol, Chase, Attack, Flee }

EnemyState state = EnemyState.Patrol;

void UpdateAI(bool visible, float distance, float health)
{
    if (health < 0.2f)
        state = EnemyState.Flee;
    else if (!visible)
        state = EnemyState.Patrol;
    else if (distance <= attackRange)
        state = EnemyState.Attack;
    else
        state = EnemyState.Chase;

    ExecuteState();
}

void ExecuteState()
{
    switch (state)
    {
        case EnemyState.Patrol: FollowPatrolRoute(); break;
        case EnemyState.Chase: MoveToPlayer(); break;
        case EnemyState.Attack: UseWeapon(); break;
        case EnemyState.Flee: MoveAwayFromPlayer(); break;
    }
}

Davranış Ağacı

Davranış Ağacı, kökten yapraklara doğru değerlendirilen hiyerarşik düğümler kullanır. Her düğüm Success, Failure veya Running sonucu döndürür. Selector, başarılı olan ilk çocuğu seçerken Sequence, bütün çocukların sırayla başarılı olmasını bekler.

Selector
├── Sequence: Kaç
│   ├── Sağlık %20 altında mı?
│   └── Oyuncudan uzaklaş
├── Sequence: Saldır
│   ├── Oyuncu görünür mü?
│   ├── Menzilde mi?
│   └── Silah kullan
├── Sequence: Kovala
│   ├── Oyuncu görünür mü?
│   └── Oyuncuya ilerle
└── Devriye gez

Basitleştirilmiş düğüm mantığı şöyledir:

Node root = new Selector(
    new Sequence(IsLowHealth, FleeFromPlayer),
    new Sequence(CanSeePlayer, IsInRange, AttackPlayer),
    new Sequence(CanSeePlayer, ChasePlayer),
    Patrol
);

void UpdateAI() => root.Tick();

Ağaç her güncellemede öncelikli davranışları yukarıdan aşağı sınar. Böylece kaçma davranışı saldırıdan önce değerlendirilir. Yeni bir “yardım çağır” dalı eklemek, çoğu zaman mevcut düğümlerin içini değiştirmeden mümkündür.

Karşılaştırma

Hangisini seçmeli?

Kapı, tuzak veya üç-dört davranışlı sıradan düşmanlar için FSM yalın ve hızlıdır. Boss karakterleri, takım koordinasyonu ya da önceliği sık değişen kararlar için Davranış Ağacı daha sürdürülebilirdir. İki yaklaşım rakip olmak zorunda da değildir: Üst seviyede FSM ile “Savaş” ve “Keşif” kipleri yönetilirken, her kipin ayrıntıları bir Davranış Ağacıyla çalıştırılabilir. En iyi oyun yapay zekâsı, en karmaşık sistem değil; tasarım ekibinin davranışı rahatça anlayıp değiştirebildiği sistemdir.

Yığın neden gereklidir?

Programın belleği kavramsal olarak kod, global veri, heap ve stack gibi bölümlere ayrılır. Heap dinamik olarak oluşturulan ve ömrü programcının ya da çöp toplayıcının kontrolündeki nesneler içindir. Stack ise fonksiyon çağrılarının doğal LIFO (Last In, First Out — son giren ilk çıkar) düzenini izler. main() içinden A(), onun içinden de B() çağrılırsa, önce B() bitmek zorundadır.

Her çağrıda stack üzerinde bir stack frame (çağrı çerçevesi) oluşturulur. Bu çerçeve tipik olarak dönüş adresini, parametreleri, yerel değişkenleri, kaydedilmiş kayıtçıları ve hizalama için ayrılan alanı içerir. Stack işaretçisi $SP, yığının güncel tepesini; frame pointer ise çoğu mimaride mevcut çerçevenin sabit bir referans noktasını gösterir.

Bir çağrının anatomisi

Örneğin aşağıdaki C kodunda topla, iki parametre alır ve sonucu çağırana döndürür:

int topla(int a, int b) {
    int araSonuc = a + b;
    return araSonuc;
}

int main(void) {
    int sonuc = topla(7, 5);
    return sonuc;
}

main, topla(7, 5) çağrısını hazırlarken parametreleri ilgili kayıtçılara veya mimarinin çağrı sözleşmesine göre stack’e yerleştirir. Ardından dönüş adresini saklayarak topla koduna dallanır. Fonksiyon kendi yerel alanını ayırır, toplamayı yapar ve dönüş değerini genellikle belirlenmiş bir kayıtçıyla iletir. Son olarak frame temizlenir; işlemci dönüş adresine gider.

Basitleştirilmiş yığın görünümü şöyledir:

Yüksek adresler
+-------------------+
| main'in frame'i   |
+-------------------+
| dönüş adresi      |
| kaydedilmiş kayıt |
| yerel: araSonuc   | <- topla'nın frame'i
+-------------------+
Düşük adresler

Çoğu modern sistemde stack düşük adreslere doğru büyür. Bu evrensel bir zorunluluk değildir; önemli olan derleyici, ABI (Application Binary Interface) ve işlemcinin aynı sözleşmeyi izlemesidir. Bir frame için kabaca şu ilişki düşünülebilir:

Burada $P$ parametre alanı, $L$ yerel değişkenler, $R$ saklanan kayıtçılar ve $A$ hizalama boşluğudur.

Parametreler nasıl aktarılır?

Çağrı sözleşmesi, parametrelerin nerede duracağını ve kimin temizleme yapacağını belirler. Güncel 64-bit mimariler ilk birkaç parametreyi kayıtçılarla aktararak bellek erişimini azaltır; fazlası stack’e taşar. Kayıtçıların sınırlı olması, büyük yapıların veya çok sayıda argümanın stack kullanımını hâlâ gerekli kılar.

Özyinelemeli fonksiyonlar stack’in önemini dramatik biçimde gösterir. Her faktoriyel(n) çağrısı ayrı bir frame açar; dolayısıyla bellek tüketimi yaklaşık olarak $O(n)$ olur. Kontrolsüz derinlik, stack overflow üretir. Ayrıca bir fonksiyondan yerel dizinin adresini döndürmek tehlikelidir: Fonksiyon bittiğinde frame geçersizdir.

Özetle stack, modüler programlamanın görünmez sahne amiridir. Fonksiyonlar arası geçişi, dönüşü ve geçici verileri disiplinli biçimde düzenler. Bu yapıyı anlamak; performans analizi, hata ayıklama, güvenli kod yazımı ve assembly seviyesindeki davranışı yorumlama için güçlü bir temel sağlar.

Stack ve heap neden farklıdır?

Yerel değişkenler çoğunlukla stack üzerinde tutulur. Fonksiyon sona erdiğinde stack çerçevesi otomatik temizlenir. Heap ise daha uzun ömürlü veriler için uygundur: Belleği bir fonksiyonda ayırıp başka bir yerde kullanabiliriz. Ancak bu esneklik, yaşam döngüsünü yönetme zorunluluğu getirir.

Bir programın heap tüketimini kabaca şöyle düşünebiliriz: $H(t) = A(t) - F(t)$; burada $A(t)$ toplam ayrılan, $F(t)$ ise toplam serbest bırakılan bellek miktarıdır. Program artık kullanmadığı verileri bırakmıyorsa $H(t)$ sürekli büyür. Bu durum memory leak olarak bilinir.

C dünyası: malloc ve free

C’de malloc, istenen bayt sayısında ham bellek ayırır ve başlangıç adresini void* olarak döndürür. Tahsis başarısızsa sonuç NULL olur. Bu nedenle dönüş değeri mutlaka kontrol edilmelidir. calloc ise ayrıca alanı sıfırlarla başlatır; realloc mevcut bloğun boyutunu değiştirmeye çalışır.

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    size_t adet = 5;
    int *sayilar = malloc(adet * sizeof *sayilar);

    if (sayilar == NULL) {
        fprintf(stderr, "Bellek tahsisi basarisiz!\n");
        return 1;
    }

    for (size_t i = 0; i < adet; i++) {
        sayilar[i] = (int)(i * i);
        printf("%d ", sayilar[i]);
    }

    free(sayilar);
    sayilar = NULL;
    return 0;
}

Burada sizeof *sayilar yazımı, işaretçinin hedef türü değişirse boyut hesabının da doğru kalmasını sağlar. free sonrasında işaretçiye NULL atamak, yanlışlıkla tekrar kullanımı görünür kılar. Fakat NULL yapmak, başka kopyalanmış işaretçileri güvenli hâle getirmez.

C++ dünyası: new ve delete

C++’ta new, belleği ayırmanın yanında nesnenin kurucusunu da çağırır; delete ise yıkıcıyı çalıştırıp alanı geri verir. Tek nesne ile dizi tahsisi için karşılık gelen silme işlemi farklıdır:

#include <iostream>

int main() {
    int* notlar = new int[3]{70, 85, 95};

    for (int i = 0; i < 3; ++i)
        std::cout << notlar[i] << ' ';

    delete[] notlar;
    notlar = nullptr;
}

malloc/free ile new/delete karıştırılmamalıdır. İlki kurucu-yıkıcı çağırmaz; ikincisi C++ nesne yaşam döngüsünü yönetir. Eşleşmeyen çiftler tanımsız davranışa, yani bazen çalışan ama en beklenmedik anda çöken kodlara davetiye çıkarır.

Sızıntıya karşı modern yaklaşım: sahiplik

C++’ta ham işaretçiyle new kullanmak çoğu zaman son çaredir. RAII ilkesi, kaynağın nesneyle birlikte edinilip nesne yok edilirken otomatik bırakılmasını söyler. std::vector ve std::unique_ptr bu fikri uygular:

#include <memory>

int main() {
    auto veri = std::make_unique<int[]>(100);
    veri[0] = 42;
} // unique_ptr kapsam bitince delete[] otomatik çağrılır

Bu yaklaşım özellikle erken return, istisna (exception) veya karmaşık kontrol akışlarında sızıntıları azaltır. C projelerinde ise her başarılı malloc için tek ve belirgin bir free yolu tasarlamak; C++ projelerinde de mümkün olduğunca standart kapları ve akıllı işaretçileri tercih etmek en sağlam savunmadır. Heap’i özgürce kullanın, ama her tahsisin dönüş biletini unutmayın.

Kararın atomu: karşılaştırma ve sıçrama

Bir if-else yapısı çoğunlukla iki temel makine işlemi üretir: bir karşılaştırma ve bunun sonucuna göre koşullu sıçrama. Kavramsal assembly karşılığı şöyledir:

cmp eax, 10        ; eax ile 10'u karşılaştır
jl  small_value    ; eax < 10 ise etikete atla
; else gövdesi
jmp end_if
small_value:
; if gövdesi
end_if:

Buradaki maliyet sabit görünse de modern işlemciler paralel çalışan boru hatlarına sahiptir. İşlemci, jl sonucunu beklemeden hangi yolun çalışacağını tahmin eder. Tahmin doğruysa sıçrama neredeyse ucuzdur; yanlışsa yanlış yola ait işler iptal edilir ve boru hattı yeniden doldurulur. Bu ceza mimariye göre değişse de yaklaşık 10–20 çevrim olabilir.

Bir koşulun beklenen maliyetini basitleştirerek şöyle düşünebiliriz:

Burada $C_{base}$ karşılaştırma ve doğru tahmin edilen sıçramanın maliyeti, $P_{miss}$ yanlış tahmin olasılığı, $C_{penalty}$ ise boru hattı temizleme cezasıdır. Örneğin rastgele dağılan bir boolean veri, tahminci için düzenli bir veriden daha pahalı olabilir.

switch-case ne zaman sıçrama tablosuna dönüşür?

switch-case, her zaman sihirli biçimde $O(1)$ değildir. Case değerleri seyrekse derleyici çoğu zaman bir karşılaştırma zinciri ya da ikili arama ağacı üretir. Değerler yoğun bir aralıktaysa, bir jump table oluşturmak mantıklı hale gelir. Girdi değeri tablonun indeksine çevrilir ve uygun adrese dolaylı atlama yapılır.

int puan_ver(int seviye) {
    switch (seviye) {
        case 1: return 100;
        case 2: return 250;
        case 3: return 500;
        case 4: return 1000;
        default: return 0;
    }
}

Bu kod, yoğun 1..4 aralığı nedeniyle jump table adayıdır. Ancak sadece case 1, case 1000 ve case 900000 olsaydı devasa ve boşluklarla dolu bir tablo anlamsız olurdu. Derleyici sürümü, optimizasyon seviyesi ve hedef işlemci bu kararı etkiler.

Döngülerin görünmeyen masrafı

Bir döngüde her turda yalnızca gövde çalışmaz. Sayaç artırılır, sınır kontrol edilir ve geri sıçrama yapılır. Basit bir toplama örneği:

long toplam(const int *veri, int n) {
    long sonuc = 0;
    for (int i = 0; i < n; i++) {
        sonuc += veri[i];
    }
    return sonuc;
}

Teorik karmaşıklık $T(n) = an + b$ olduğundan çalışma $O(n)$’dir. Fakat pratikte asıl sınırlandırıcı unsur branch olmayabilir: veri[i] bellekten gelir ve önbellek kaçırmaları işlemciyi bekletebilir. Düzenli erişimli bu örnekte CPU öngetiricisi başarılıdır; düzensiz pointer takibi yapan döngülerde ise bellek gecikmesi baskın hale gelir.

Döngü koşulu genellikle son tur dışında kolay tahmin edilir: branch çoğu kez “devam et”, bir kez “çık” sonucunu verir. Buna karşılık döngü içindeki rastgele if koşulları tahminciyi zorlayabilir. Performans kritik kodda önce ölçüm yapmak, sonra gerekirse veriyi gruplayarak branch öngörülebilirliğini artırmak en sağlıklı yaklaşımdır. Kısacası iyi kontrol akışı, yalnızca doğru yolu seçmez; işlemcinin o yolu önceden sezmesine de yardım eder.

Bir belleği numaralandırılmış evler bulunan uzun bir sokak gibi ele alalım. int sayi = 42; ifadesi, 42 değerini bir eve yerleştirir. &sayi operatörü o evin adresini verir. Pointer ise bu adresin yazılı olduğu bir not kâğıdıdır. C dilinde int *p = &sayi; yazdığımızda, p artık sayi değişkeninin bulunduğu konumu bilir. *p ise “bu adrese git ve oradaki değeri oku ya da değiştir” anlamına gelir.

Matematiksel olarak, bir değişkenin adresini $a$ ve o adresteki değeri $V(a)$ ile gösterelim. Pointer’ın tuttuğu değer $p = a$ ise dereference işlemi şu fikre karşılık gelir:

Yani pointer değerin kendisi değil, değere ulaşan rotadır. Bu ayrım özellikle büyük veri yapılarında kritiktir. Boyutu $n$ olan bir yapıyı kopyalamanın maliyeti kabaca $O(n)$ iken, adresini kopyalamak çoğu modern mimaride sabit boyutlu bir adres olduğu için $O(1)$ maliyetlidir.

Aşağıdaki C örneği, değer ve adres arasındaki ilişkiyi netleştirir:

#include <stdio.h>

void indirimUygula(double *fiyat, double oran) {
    *fiyat = *fiyat * (1.0 - oran);
}

int main(void) {
    double urunFiyati = 120.0;
    double *fiyatAdresi = &urunFiyati;

    indirimUygula(fiyatAdresi, 0.25);

    printf("Yeni fiyat: %.2f\n", urunFiyati);
    printf("Bellek adresi: %p\n", (void *)fiyatAdresi);
    return 0;
}

Burada indirimUygula, fiyatın kopyasını almak yerine adresini alır. Fonksiyon içindeki *fiyat, çağıranın belleğindeki gerçek urunFiyati değişkenidir; sonuç olarak değer 90.00 olur. Bu teknik, büyük struct nesnelerini fonksiyonlara iletirken gereksiz kopyalamayı önler.

Pointer aritmetiği de belleğin ardışık düzeninden yararlanır. Bir int *p için p + 1, adresi bir bayt değil, sizeof(int) kadar ilerletir. Genel ifade şöyledir:

Bu nedenle diziler ve pointer’lar yakın akrabadır: dizi[i] ifadesi kavramsal olarak *(dizi + i) ile eşdeğerdir. Ancak bu güç dikkat ister. Başlatılmamış pointer kullanmak, serbest bırakılmış belleğe erişmek (dangling pointer) veya dizi sınırının dışına taşmak tanımsız davranış üretir.

Özetle pointer, “veriyi taşıma” yerine “verinin yerini paylaşma” aracıdır. Doğru kullanıldığında performans ve esneklik kazandırır; dikkatsiz kullanıldığında ise programı mayın tarlasına çevirebilir. Adresi bilmek güçtür, ama o gücün yanında mutlaka sorumluluk da gelir.

Temel ayrım: kontrol mü, ifade gücü mü?

C, işletim sistemi arayüzlerinin doğal dilidir. Linux çekirdeğinin C ile yazılması tesadüf değildir: dilin çalışma zamanı yükü çok küçüktür, bellek düzeni öngörülebilirdir ve üretilen makine koduna yaklaşmak kolaydır. Bir struct, bellekteki verinin açık bir tarifidir; bir işaretçi ise doğrudan adresle konuşur.

C++ ise C’nin düşük seviyeli alanını terk etmeden, kaynak yönetimi ve büyük ölçekli tasarım için araçlar ekler. Sınıflar, şablonlar, RAII ve tür güvenliği doğru kullanıldığında “sıfır maliyetli soyutlama” hedefler. İdeal durumda kullanılmayan özelliğin bedeli yoktur; kullanılan soyutlama da elle yazılmış C koduna yakın maliyet üretir.

Bu yaklaşım kabaca şöyle modellenebilir:

C’de geliştirici son terimi elle azaltır. C++’ta ise iyi tasarlanmış bir soyutlama ile $T_{soyutlama} \approx 0$ olmaya çalışır. Ancak sanal fonksiyonlar, kontrolsüz dinamik tahsis ve istisnalar bazı senaryolarda bu maliyeti görünür hâle getirebilir.

C: donanımla pazarlıksız konuşmak

Bir sürücü, önyükleyici veya mikrodenetleyici kodunda başlangıç maliyeti, ikili boyut ve davranışın kesinliği kritiktir. C burada güçlüdür. Aşağıdaki örnek, bir bellek eşlemeli yazmacı temsil eder:

#include <stdint.h>

#define GPIO_OUT (*(volatile uint32_t *)0x40020014u)

void led_yak(void) {
    GPIO_OUT |= (1u << 5);
}

volatile, derleyiciye bu belleğin donanım tarafından değişebileceğini söyler; bu yüzden okuma veya yazma işlemini “gereksiz” diye silemez. Bu kodun etkisi nettir: belirli adresteki yazmacın beşinci biti etkinleşir. Fakat bu güç sorumluluk getirir: yanlış adres, taşan dizi veya unutulan free, doğrudan hata üretir.

C++: kaynakları nesne ömrüne bağlamak

İşletim sistemi seviyesinde her şey sınıf olmak zorunda değildir. Fakat dosya tanıtıcısı, kilit veya soket gibi sahipliği olan kaynaklar, C++ için çok uygundur. RAII’nin fikri basittir: kaynak kurucuda alınır, nesne yok edilirken bırakılır.

#include <unistd.h>
#include <stdexcept>

class DosyaTanıtıcısı {
    int fd_ = -1;
public:
    explicit DosyaTanıtıcısı(int fd) : fd_(fd) {
        if (fd_ < 0) throw std::runtime_error("dosya acilamadi");
    }
    ~DosyaTanıtıcısı() { if (fd_ >= 0) close(fd_); }
    DosyaTanıtıcısı(const DosyaTanıtıcısı&) = delete;
};

Bu sınıfın amacı dosya okumak değil, close çağrısının unutulmasını zorlaştırmaktır. Kopyalamayı kapatması da aynı tanıtıcının iki kez kapatılmasını önler. Gerçek zamanlı veya çekirdek kodunda istisnalar tercih edilmeyebilir; yine de RAII, istisnasız bir C++ tarzında da değerlidir.

Karar rehberi

Sonuçta C “her ayrıntıyı ben yönetirim” felsefesidir; C++ ise “ayrıntıyı yönetirim, ama tekrar eden hataları dile devrederim” yaklaşımıdır. İyi sistem yazılımı dil savaşından değil, gecikme bütçesi, hata toleransı, ekip deneyimi ve hedef platformun gerçeklerinden doğar.