``

Nesne neden “dilimlenir”?

Bir türetilmiş sınıf nesnesini kavramsal olarak iki parçalı düşünebiliriz:

Temel sınıf türünde değer saklayan bir değişkenin kapasitesi ise yalnızca temel bölüme uygundur. Dolayısıyla aşağıdaki atamada Calisan nesnesinin Yazilimci sınıfına özgü kısmı hedef nesneye sığmaz. C++ bu kısmı hata vermeden dışarıda bırakır.

#include <iostream>
#include <string>

class Calisan {
public:
    std::string ad;

    virtual void tanit() const {
        std::cout << ad << ": Calisan\n";
    }
};

class Yazilimci : public Calisan {
public:
    std::string dil;

    void tanit() const override {
        std::cout << ad << ": " << dil << " gelistiricisi\n";
    }
};

int main() {
    Yazilimci y;
    y.ad = "Ada";
    y.dil = "C++";

    Calisan c = y; // Nesne dilimlenir
    c.tanit();     // Ada: Calisan
}

tanit() sanal olmasına rağmen sonuç değişmez. Çünkü c, artık bağımsız ve gerçek bir Calisan nesnesidir. İçinde Yazilimci kimliği bulunmadığından sanal fonksiyon mekanizmasının çağırabileceği türetilmiş davranış da kalmamıştır. virtual, dilimlenmeyi önlemez; yalnızca nesneye referans veya işaretçi üzerinden erişildiğinde dinamik türü kullanır.

Fonksiyon parametrelerindeki gizli tuzak

Dilimlenme yalnızca açık atamalarda oluşmaz. Temel sınıfı değer olarak kabul eden fonksiyonlar da aynı soruna yol açar:

void bilgiYaz(Calisan calisan) { // Değer ile alınıyor
    calisan.tanit();
}

Yazilimci y;
bilgiYaz(y); // Parametre oluşturulurken dilimlenir

Çözüm, parametreyi çoğunlukla sabit referansla almaktır:

void bilgiYaz(const Calisan& calisan) {
    calisan.tanit(); // Gerçek türe göre çağrı yapılır
}

Bu yöntem hem türetilmiş kimliği korur hem de gereksiz nesne kopyasını engeller. Fonksiyon nesneyi değiştirmeyecekse const kullanılması niyeti açıkça belirtir.

Koleksiyonlarda doğru tür seçimi

std::vector<Calisan> içine Yazilimci eklemek de nesneyi dilimler. Farklı türetilmiş türleri aynı koleksiyonda polimorfik olarak saklamak için akıllı işaretçiler kullanılabilir:

#include <memory>
#include <vector>

std::vector<std::unique_ptr<Calisan>> ekip;
ekip.push_back(std::make_unique<Yazilimci>());

for (const auto& kisi : ekip) {
    kisi->tanit();
}

Burada vektör nesnelerin kendilerini değil, temel sınıf türündeki sahiplik işaretçilerini saklar. Gerçek nesneler türetilmiş türleriyle yaşamaya devam eder. Temel sınıf üzerinden silme yapılacağı için yıkıcının da sanal olması gerekir:

virtual ~Calisan() = default;

Özetle, değer semantiği bilinçli bir temel sınıf kopyası istendiğinde uygundur; polimorfik davranış istendiğinde ise referanslar, işaretçiler ve akıllı işaretçiler tercih edilmelidir. Derleyicinin sessiz kalması işlemin zararsız olduğu anlamına gelmez: Nesnenin yalnızca üst dilimini servis edip geri kalanını mutfakta unutmuş olabilirsiniz.

``

Sorun yalnızca delete unutmak değildir

Manuel kaynak yönetiminde genellikle kaynağın yaşam süresini zihnimizde takip ederiz: kaynağı edin, kullan ve serbest bırak. İdeal akış şöyle düşünülebilir:

Ancak bir exception oluştuğunda fonksiyon normal dönüş noktasına ulaşmaz. C++ çalışma zamanı stack unwinding işlemini başlatır; yani çağrı yığınındaki yerel nesneler geriye doğru yok edilir. Ham işaretçinin kendisi yok olur fakat işaret ettiği dinamik nesne otomatik olarak silinmez.

#include <stdexcept>

void veriyiIsle() {
    int* sayilar = new int[1000];

    sayilar[0] = 42;
    throw std::runtime_error("Dosya okunamadı");

    delete[] sayilar; // Bu satıra hiçbir zaman ulaşılamaz.
}

Buradaki sızıntının matematiksel özeti basittir:

Fonksiyon her çağrıldığında yeni bir blok ayrılır. Hata tekrarlanırsa kayıp miktarı birikir. Tek çağrıdaki sızıntı $M$ bayt ve hatalı çağrı sayısı $n$ ise toplam kayıp yaklaşık $n \times M$ olur.

try-catch ile temizlik yeterli mi?

Kaynağı catch bloğunda temizlemek mümkündür, fakat çözüm hızla kırılganlaşır:

void veriyiIsle() {
    int* sayilar = new int[1000];

    try {
        riskliIslem(sayilar);
    } catch (...) {
        delete[] sayilar;
        throw; // Orijinal exception yeniden gönderilir.
    }

    delete[] sayilar;
}

Bu kod sızıntıyı önleyebilir; ancak hem normal hem de hatalı yol için aynı temizlik işlemi yazılmıştır. Fonksiyona dosya tanıtıcısı, kilit veya ikinci bir bellek bloğu eklendiğinde olası çıkış yolları çoğalır. Ayrıca yanlış sırada temizlik yapmak ya da bir kaynağı iki kez serbest bırakmak mümkündür.

Güvenli çözüm: RAII

RAII, kaynağın yaşam süresini bir nesnenin yaşam süresine bağlar. Kullanıcı manuel olarak yıkıcı çağırmaz; kapsam sona erdiğinde yıkıcı dil tarafından otomatik çağrılır. Exception oluşması da bu davranışı bozmaz.

#include <memory>
#include <stdexcept>

void veriyiIsle() {
    auto sayilar = std::make_unique<int[]>(1000);
    sayilar[0] = 42;

    throw std::runtime_error("İşlem başarısız");
}

std::unique_ptr, dizinin tek sahibidir. Stack unwinding sırasında sayilar nesnesinin yıkıcısı çalışır ve dinamik dizi serbest bırakılır. Açık bir delete[] satırına ihtiyaç kalmaz.

Çoğu durumda dinamik dizi için daha doğal seçenek std::vector kullanmaktır:

#include <vector>

void veriyiIsle() {
    std::vector<int> sayilar(1000);
    sayilar.at(0) = 42;
    riskliIslem(sayilar.data());
}

RAII yalnızca bellek için değildir. Dosyalar, mutex kilitleri, soketler ve veritabanı bağlantıları da aynı ilkeyle kapsüllenebilir. Temel kural şudur: Kaynağı edinen nesne, onu bırakmaktan da sorumlu olmalıdır. Böylece exception geldiğinde temizlik bir dilek değil, kapsam mekanizmasının garantisi olur.

``

Tek Sunucu Neden Yetmez?

Her oyuncu hareket, yetenek kullanımı, envanter yönetimi ve sohbet gibi olaylar üretir. Oyuncu başına saniyede ortalama $r$ mesaj, eşzamanlı oyuncu sayısı da $N$ ise sistemin karşılaması gereken yaklaşık mesaj yükü şöyledir:

Örneğin 10.000 oyuncunun saniyede 15 mesaj ürettiği bir dünyada sunucular saniyede yaklaşık 150.000 mesajı işlemelidir. Üstelik bazı hareketler çevredeki diğer oyunculara da gönderilir. Her veriyi herkese yayınlamak maliyeti hızla $O(N^2)$ seviyesine taşıyabileceğinden MMORPG mimarileri dünyayı mantıksal parçalara ayırır.

Sunucu Katmanları

Oyuncu genellikle doğrudan oyun dünyasının merkezine bağlanmaz. İstek, uzmanlaşmış servislerden oluşan bir yolculuk yapar.

Bu ayrım sayesinde sohbet sistemindeki yoğunluk savaş hesaplamalarını durdurmaz. Ayrıca her servis bağımsız biçimde ölçeklenebilir.

Shard, Zone ve Instance Farkı

Shard, aynı oyunun ayrı bir kopyasıdır; oyuncular bunu genellikle “sunucu seçimi” olarak görür. Zone, tek dünyanın coğrafi bölümlere ayrılmasıdır. Instance ise zindan gibi belirli bir grup için geçici oluşturulan özel alandır.

Bir karakter bölge sınırını geçtiğinde eski zone sunucusu karakter durumunu yeni sunucuya aktarır. Bu handoff işlemi sırasında iki sunucunun kısa süreli koordinasyon kurması gerekir; aksi hâlde karakter kopyalanabilir veya kaybolabilir.

Interest Management: Herkesi Herkese Gösterme

Bir oyuncunun kıtanın diğer ucundaki hareketleri bilmesine gerek yoktur. Sunucu, dünyayı hücrelere böler ve yalnızca görüş alanındaki nesneleri gönderir. Görüş yarıçapı $d$ olan bir oyuncu için ilgi alanı kabaca $A = \pi d^2$ olur.

Basitleştirilmiş bir yayın mantığı şöyle yazılabilir:

def broadcast_movement(player, spatial_grid):
    nearby = spatial_grid.query(player.position, radius=80)

    for entity in nearby:
        if entity.id != player.id:
            entity.connection.send({
                "type": "movement",
                "player_id": player.id,
                "position": player.position
            })

Bu kod, hareket paketini yalnızca yakındaki varlıklara göndererek bant genişliği ve işlemci tüketimini azaltır. Gerçek sistemlerde grid, quadtree veya spatial hashing kullanılabilir.

Sunucu Otoritesi ve Tutarlılık

İstemciye tamamen güvenilirse oyuncu “Ben ışınlandım ve boss’u tek vuruşta yendim” diyebilir. Bu nedenle çoğu MMORPG server-authoritative çalışır: İstemci niyeti bildirir, sonucu sunucu hesaplar. İstemci gecikmeyi gizlemek için tahmin yapabilir; ancak son söz sunucudadır.

Tüm veriler aynı tutarlılık seviyesine ihtiyaç duymaz. Hasar ve eşya transferi güçlü tutarlılık isterken oyuncunun birkaç santimetrelik konumu eventual consistency ile yönetilebilir. Kritik ekonomi işlemlerinde idempotency anahtarları ve veritabanı transaction’ları, aynı satın alma paketinin iki kez işlenmesini önler.

Gecikme, Tick ve Dayanıklılık

Zone sunucuları dünyayı belirli aralıklarla günceller. Tick hızı $f$ ise bir tick süresi yaklaşık $T = 1/f$ saniyedir. 20 Hz çalışan bir sistem dünyayı her 50 milisaniyede bir hesaplar.

Sunucu çökmesine karşı karakter durumu periyodik kaydedilir; kritik olaylar mesaj kuyruğuna veya event log’a yazılır. Load balancer yeni bağlantıları sağlıklı sunuculara gönderirken izleme araçları CPU, gecikme ve paket kaybını takip eder. Sonuçta kesintisiz görünen fantastik dünya; bölümlendirme, ilgi alanı filtreleme, otoriter simülasyon ve dikkatli veri yönetiminin birlikte yaptığı oldukça gerçek bir mühendislik büyüsüdür.

Bir finansal piyasayı yalnızca son işlem fiyatından izlemek, futbol maçını sadece skor tabelasından takip etmeye benzer. Order book, yani emir defteri ise sahanın tamamını gösterir: Hangi fiyatlarda alıcılar bekliyor, satıcılar nerede yoğunlaşıyor ve likidite hangi tarafta inceliyor? Doğru algoritmalarla bu hareketli tabloyu inceleyerek piyasanın kısa vadeli yapısı hakkında değerli ipuçları çıkarabiliriz.

``

Emir defterinin temel mantığı

Emir defteri, gerçekleşmeyi bekleyen limit alış ve satış emirlerinin fiyat seviyelerine göre sıralanmış hâlidir. En yüksek alış fiyatına best bid, en düşük satış fiyatına ise best ask denir. Bu iki fiyat arasındaki fark spread olarak tanımlanır:

Spread küçüldükçe piyasanın genellikle daha likit olduğu düşünülür. Ancak tek başına spread yeterli değildir. En iyi fiyat seviyesinde yalnızca birkaç birim emir varsa büyük bir piyasa emri fiyatı hızla kaydırabilir.

Çoğu borsada eşleştirme motoru fiyat-zaman önceliği kullanır. Daha iyi fiyat önceliklidir; aynı fiyattaki emirler arasında önce giren emir önce gerçekleşir. Piyasa emirleri ise beklemez, defterdeki uygun limit emirlerini tüketir.

Dengesizlik ve mikro fiyat

Defter analizinin popüler ölçülerinden biri order book imbalance değeridir. En iyi seviyedeki alış miktarı $B$, satış miktarı $A$ olsun:

$I$ değeri $1$ seviyesine yaklaştığında alış tarafı, $-1$ seviyesine yaklaştığında satış tarafı daha ağırdır. Sıfıra yakın değerler dengeli bir görünüm sunar. Bununla birlikte büyük alış miktarı kesin yükseliş anlamına gelmez; emir gerçekleşmeden iptal edilebilir.

Bir başka ölçü olan mikro fiyat, orta noktayı mevcut miktarlarla ağırlıklandırır:

Mikro fiyat orta fiyattan yukarıdaysa alış baskısının, aşağıdaysa satış baskısının daha güçlü olduğu düşünülebilir.

Python ile basit analiz

Aşağıdaki fonksiyon, en iyi alış ve satış seviyelerinden spread, orta fiyat, dengesizlik ve mikro fiyat hesaplar:

def book_metrics(bids, asks):
    # Her eleman: (fiyat, miktar)
    best_bid, bid_qty = max(bids, key=lambda x: x[0])
    best_ask, ask_qty = min(asks, key=lambda x: x[0])

    spread = best_ask - best_bid
    midpoint = (best_bid + best_ask) / 2
    total_qty = bid_qty + ask_qty

    imbalance = (bid_qty - ask_qty) / total_qty
    microprice = (
        best_ask * bid_qty + best_bid * ask_qty
    ) / total_qty

    return {
        'spread': spread,
        'midpoint': midpoint,
        'imbalance': imbalance,
        'microprice': microprice
    }

bids = [(99.90, 12), (99.80, 25)]
asks = [(100.00, 5), (100.10, 18)]
print(book_metrics(bids, asks))

Bu örnek yalnızca ilk seviyeyi inceler. Gerçek sistemlerde ilk 5, 10 veya 20 fiyat seviyesi ağırlıklı olarak değerlendirilir. Yakın seviyelere daha fazla önem vermek için $w_i=e^{-\lambda i}$ gibi azalan bir ağırlık kullanılabilir.

Gürültü, spoofing ve doğru yorum

Order book bir niyet tablosudur; gerçekleşmiş işlemlerin kaydı değildir. Büyük bir emir güçlü destek gibi görünürken aniden iptal edilebilir. Spoofing, yatırımcıları yanıltmak amacıyla büyük emir gösterip bunları gerçekleşmeden kaldırma davranışıdır. Bu nedenle algoritma; emir ekleme, iptal ve gerçekleşme hızlarını birlikte izlemelidir.

Sağlam bir yaklaşım, order book verisini işlem hacmi, order flow imbalance ve fiyat değişimiyle birleştirir. Ayrıca sonuçlar farklı piyasa koşullarında geriye dönük test edilmelidir. Emir defteri geleceği söyleyen kristal küre değildir; fakat doğru ölçümlerle piyasanın kısa vadeli baskısını gösteren oldukça hassas bir radar olabilir.

Roguelike oyunlarda ölüm, kısa bir yükleme ekranından çok daha fazlasıdır. Saatlerdir geliştirdiğiniz karakterin, topladığınız eşyaların ve kurduğunuz planların tek bir hatayla silinmesi mümkündür. Kalıcı ölüm olarak bilinen bu mekanik, oyuncuya yalnızca kaybetme korkusu yaşatmaz; karar verme, öğrenme ve risk değerlendirme biçimini de kökten değiştirir. ``

Ölüm neden bu kadar önemlidir?

Geleneksel oyunlarda ölüm çoğunlukla geçici bir aksaklıktır. Oyuncu kayıt noktasına döner ve aynı bölümü küçük değişikliklerle tekrarlar. Roguelike türünde ise ölüm, mevcut koşunun sonudur. Bu nedenle oyuncu yalnızca ekrandaki düşmanla değil, verdiği kararların geri döndürülemezliğiyle de mücadele eder.

Bu fark, roguelike felsefesinin merkezindeki fikri ortaya çıkarır: Oyuncu karakteri kaybedebilir, fakat öğrendiklerini kaybetmez. Bir canavarın saldırı düzenini, zehrin etkisini veya hangi eşyanın hangi durumda değerli olduğunu öğrenmek, görünmeyen bir gelişim sistemidir.

Riskin matematiği

Oyuncu bir odaya girmeden önce çoğu zaman sezgisel bir beklenen değer hesabı yapar. Bir kararın yaklaşık değeri şöyle gösterilebilir:

Burada $P_b$ başarı olasılığını, $O$ elde edilecek ödülü, $P_k$ kayıp olasılığını ve $M$ kaybın maliyetini temsil eder. Kalıcı ölümde $M$ çok büyüktür; çünkü yalnızca birkaç sağlık puanı değil, bütün koşu tehlikededir. Bu yüzden ödül yüksek olsa bile düşük başarı olasılığı oyuncuyu geri çekilmeye yöneltebilir.

Ancak insan zihni kusursuz bir hesap makinesi değildir. Nadir bir eşya görüldüğünde açgözlülük, uzun süren başarılı bir koşuda aşırı güven veya son anda gelen panik matematiksel değerlendirmeyi bozar. Roguelike oyunlar tam da bu duygusal çatışmadan beslenir: Mantık kapıyı kapatmayı söylerken merak içeride ne olduğunu fısıldar.

Basit bir risk modeli

Bir oyunda karar puanlaması aşağıdaki gibi modellenebilir:

def risk_puani(odul, basari_ihtimali, kayip, kaynak_orani):
    beklenen_kazanc = odul * basari_ihtimali
    beklenen_kayip = kayip * (1 - basari_ihtimali)

    # Kaynaklar azaldıkça aynı tehlike daha ciddi kabul edilir.
    baski_carpani = 1 + (1 - kaynak_orani)
    return beklenen_kazanc - beklenen_kayip * baski_carpani

Bu kod, ödül ile olası kaybı karşılaştırır. kaynak_orani, oyuncunun sağlık, iksir veya mühimmat gibi kaynaklarının ne kadarının kaldığını belirtir. Sonuç negatifse çatışmadan kaçınmak mantıklı olabilir. Elbette iyi bir roguelike, bütün bilgileri açıkça sunmaz; belirsizlik, kararın heyecanını artırır.

Korkaklık mı, ustalık mı?

Kalıcı ölüm başlangıçta oyuncuyu aşırı temkinli yapabilir. Her sandık tuzak, her koridor tehdit gibi görünür. Deneyim arttıkça temkin yerini hesaplanmış cesarete bırakır. Usta oyuncu hiçbir risk almayan kişi değildir; hangi riskin gerekli olduğunu anlayan kişidir.

Bu süreçte davranışlar belirgin biçimde değişir:

• Kaynaklar hemen tüketilmek yerine kritik anlar için saklanır.
• Bilinmeyen düşmanlara doğrudan saldırmak yerine gözlem yapılır.
• Kaçış, başarısızlık değil stratejik bir araç olarak görülür.
• Kısa vadeli ödüller, uzun vadeli hayatta kalmayla karşılaştırılır.
• Her ölümden sonra neden-sonuç ilişkisi kurulmaya çalışılır.

Yenilginin anlamı

Roguelike türü, başarısızlığı oyunun karşıtı olmaktan çıkarıp oyunun parçasına dönüştürür. Adil tasarlanmış bir ölüm, oyuncuya cezadan çok ders verir: Yanlış eşya mı seçildi, gereksiz çatışmaya mı girildi, yoksa bilinmeyen bir mekanik mi gözden kaçtı?

Sonuç olarak kalıcı ölüm, yapay bir zorluk düğmesi değildir. Oyuncunun eşyalarla, zamanla ve kendi duygularıyla ilişkisini değiştiren felsefi bir tasarım tercihidir. Karakterler tekrar tekrar ölürken oyuncu giderek daha dikkatli, bilgili ve soğukkanlı hâle gelir. Roguelike deneyiminin gerçek kahramanı ekrandaki savaşçı değil, her yenilgiden sonra yeniden düşünen oyuncudur.

``

rm -rf gerçekte ne yapar?

rm, dosya ve dizinleri kaldırır. -r seçeneği dizinlerin içine özyinelemeli olarak girilmesini, -f ise uyarıların bastırılıp işlemin zorlanmasını sağlar. Başka bir deyişle komutun mantığı kabaca şöyledir:

Kök kullanıcı yetkisiyle geniş bir hedef seçildiğinde üç çarpan da büyür. Sonuç, geri dönüşüm kutusuna taşınan dosyalar değil; dosya sistemi kayıtlarının doğrudan kaldırılmasıdır.

Burada önemli bir düzeltme var: rm -rf / ile rm -rf /* arasındaki fark yalnızca boşluk değildir; yıldız karakteri kabuk tarafından genişletilir. Modern GNU rm, / hedefini genellikle --preserve-root korumasıyla reddeder. Ancak /*, kabuk tarafından /etc, /home, /usr gibi ayrı hedeflere dönüştürülebildiğinden bu korumayı aşabilir. Yani iki komut da güvenli değildir.

Boşluk hatası nasıl felakete dönüşür?

Shell, boşluğu argüman ayırıcı olarak kullanır. Örneğin amaç /tmp/proje içeriğini silmekken yanlışlıkla yolun ortasına boşluk eklenirse komut iki farklı hedef algılayabilir. Benzer şekilde boş bir değişken de beklenmeyen bir hedef meydana getirir:

# TEHLİKELİ ÖRNEK: Değişken boşsa hedef beklenenden farklılaşabilir.
rm -rf "$TARGET"/*

TARGET boş olduğunda ifade /* biçimine yaklaşır. Bu nedenle değişken kullanmadan önce hem doluluk hem de izin verilen kök yol denetlenmelidir.

Daha güvenli bir silme deseni

Aşağıdaki yaklaşım hedefi doğrular, mutlak yola dönüştürür ve yalnızca belirlenmiş çalışma alanı içindeki dizinlere izin verir:

#!/usr/bin/env bash
set -euo pipefail

target="${1:-}"
allowed_root="/srv/builds"

if [[ -z "$target" ]]; then
  echo "Hata: Hedef boş olamaz." >&2
  exit 1
fi

resolved="$(realpath -- "$target")"

if [[ "$resolved" != "$allowed_root"/* ]]; then
  echo "Hata: İzin verilen alanın dışında: $resolved" >&2
  exit 1
fi

printf 'Silinecek hedef: %s\n' "$resolved"
rm -rf -- "$resolved"

set -u, tanımsız değişkenleri hata kabul eder. realpath, .. ve sembolik bağlantı kaynaklı belirsizlikleri azaltır. -- ise tireyle başlayan bir dosya adının seçenek sanılmasını engeller. Yine de bu kod, yedeklemenin yerini tutmaz.

Kazayı önlemek için pratik kurallar

1. Komutu çalıştırmadan önce hedefi printf '%q\n' "$target" ile görüntüleyin.
2. Önce ls veya find kullanarak kapsamı inceleyin.
3. Betiklerde set -euo pipefail etkinleştirin.
4. Kritik işlemleri root yerine sınırlı yetkili kullanıcıyla yürütün.
5. Snapshot ve çevrimdışı yedek bulundurun; aynı diskteki kopya gerçek yedek değildir.
6. Etkileşimli kullanımda rm -I seçeneğini değerlendirin.

Yanlış silme gerçekleşirse sistemi hemen kullanmayı bırakmak, diske yeni veri yazmamak ve profesyonel kurtarma araçlarına yönelmek gerekir. En iyi kurtarma stratejisi ise hâlâ kazadan önce hazırlanmış, düzenli olarak test edilen bir yedektir.

``

Önce problem: Sil, sonra kopyala

Dinamik dizi yöneten basit bir sınıf düşünelim. Tehlikeli bir atama operatörü eski belleği önce silebilir, ardından yeni bellek ayırmaya çalışabilir:

Buffer& operator=(const Buffer& other) {
    delete[] data_;
    size_ = other.size_;
    data_ = new int[size_]; // std::bad_alloc fırlatabilir
    std::copy(other.data_, other.data_ + size_, data_);
    return *this;
}

new başarısız olduğunda eski veri çoktan kaybedilmiştir. Üstelik data_, silinmiş belleği gösterebilir. Nesne artık yalnızca yanlış değil, yıkıcısı çalıştığında ikinci kez silme yapabilecek kadar tehlikelidir.

İstisna güvenliği genellikle üç seviyede değerlendirilir:

Güçlü garantiyi matematiksel olarak bir durum geçişi gibi ifade edebiliriz. Eski durum $S$, hedef durum $T$ ise:

Yani yarım kalmış, garip bir $S’$ durumuna izin verilmez.

Copy-and-swap nasıl çalışır?

Teknik üç adımdan oluşur:

1. Sağ taraftaki nesnenin geçici bir kopyasını oluştur.
2. Geçici nesne ile mevcut nesnenin kaynaklarını değiştir.
3. Geçici nesne kapsam dışına çıkınca eski kaynakları otomatik olarak yok etsin.

#include <algorithm>
#include <cstddef>
#include <utility>

class Buffer {
public:
    explicit Buffer(std::size_t size = 0)
        : size_(size), data_(size ? new int[size]{} : nullptr) {}

    Buffer(const Buffer& other)
        : size_(other.size_),
          data_(size_ ? new int[size_] : nullptr) {
        std::copy(other.data_, other.data_ + size_, data_);
    }

    Buffer(Buffer&& other) noexcept
        : size_(std::exchange(other.size_, 0)),
          data_(std::exchange(other.data_, nullptr)) {}

    ~Buffer() {
        delete[] data_;
    }

    friend void swap(Buffer& a, Buffer& b) noexcept {
        using std::swap;
        swap(a.size_, b.size_);
        swap(a.data_, b.data_);
    }

    Buffer& operator=(Buffer other) {
        swap(*this, other);
        return *this;
    }

private:
    std::size_t size_{};
    int* data_{};
};

Buradaki kritik ayrıntı, parametrenin const Buffer& yerine değerle alınmasıdır. Bir lvalue gönderildiğinde kopya kurucu, rvalue gönderildiğinde ise taşıma kurucu geçici other nesnesini hazırlar. Böylece tek operatör hem kopyalama hem taşıma atamasını karşılayabilir.

Kopyalama sırasında new istisna fırlatırsa fonksiyon gövdesine henüz girilmez; *this değişmeden kalır. Kopya başarıyla oluşursa swap yalnızca boyut ve işaretçi gibi ucuz üyeleri değiştirir. Bu nedenle swap fonksiyonunun noexcept olması güçlü garantinin merkezidir. Değişimden sonra other, hedef nesnenin eski belleğini taşır ve yıkıcısı bu belleği temizler. RAII burada temizlik ekibidir; hem de fazla mesai ücreti istemez.

Geleneksel atama ile karşılaştırma

Copy-and-swap temiz ve güvenlidir; ancak her zaman en hızlı çözüm değildir. Büyük tamponlarda mevcut kapasiteyi yeniden kullanmak önemliyse özel bir atama operatörü daha verimli olabilir. Ayrıca sınıf yalnızca std::vector, std::string ve akıllı işaretçiler gibi RAII türlerinden oluşuyorsa en iyi seçenek çoğu zaman Rule of Zero, yani özel atama operatörü yazmamaktır.

Özetle copy-and-swap, işlemi önce hazırla, sonra tek ve güvenli adımla yayımla yaklaşımıdır. swap gerçekten noexcept olduğu sürece atama işlemini bir veritabanı işlemi gibi davranmaya yaklaştırır: ya commit gerçekleşir ya da nesne eski hâlinde kalır.

``

Dizilerin temel mantığı

Dizi, aynı türden belirli sayıda elemanı ardışık indekslerle saklayan veri yapısıdır. İndeksler sıfırdan başladığı için uzunluğu $n$ olan bir dizinin geçerli indeks aralığı $0 \le i < n$ şeklindedir. Bir elemana indeksle erişmenin zaman karmaşıklığı sabittir:

Buna karşılık aranan değerin konumu bilinmiyorsa tüm elemanların gezilmesi gerekebilir ve doğrusal aramanın maliyeti $O(n)$ olur.

int[] notlar = { 75, 90, 68, 100 };
int toplam = 0;

foreach (int not in notlar)
{
    toplam += not;
}

double ortalama = (double)toplam / notlar.Length;
Console.WriteLine($"Ortalama: {ortalama:F2}");

Bu örnek tek boyutlu diziyi dolaşır. Tür dönüşümü yapılmasaydı iki int değerin bölümü tam sayı üretirdi; (double) dönüşümü küsuratı korur.

Çok boyutlu ve düzensiz diziler

Çok boyutlu diziler satır ve sütunları eşit olan dikdörtgen tabloları temsil eder. Düzensiz, yani jagged diziler ise her satırında farklı sayıda eleman taşıyabilen dizilerin dizisidir.

int[,] harita =
{
    { 1, 0, 1 },
    { 0, 1, 0 }
};

int[][] gruplar =
{
    new[] { 10, 20 },
    new[] { 30, 40, 50 },
    new[] { 60 }
};

Console.WriteLine(harita[1, 1]); // 1
Console.WriteLine(gruplar[1][2]); // 50

int[,] tek bir dikdörtgen bloktur. int[][] içindeki her satır ise bağımsız bir dizidir. Bu esneklik bellek kullanımını azaltabilir; ancak satırların ayrı ayrı oluşturulması ve kontrol edilmesi gerekir.

String: Karakter dizisinden daha fazlası

string, kavramsal olarak karakter dizisine benzese de immutable, yani değiştirilemez bir referans türüdür. Birleştirme veya değiştirme işlemi mevcut metni düzenlemez; yeni bir string üretir.

string mesaj = "  C# diziler eğlencelidir  ";
string temiz = mesaj.Trim();
string[] kelimeler = temiz.Split(' ', StringSplitOptions.RemoveEmptyEntries);
string sonuc = string.Join(" | ", kelimeler).ToUpperInvariant();

Console.WriteLine(sonuc);

Burada Trim kenar boşluklarını kaldırır, Split metni parçalara ayırır, Join parçaları yeniden birleştirir. ToUpperInvariant, sonucu kullanıcının bölgesel dil ayarlarından bağımsız biçimde büyük harfe dönüştürür.

Çok sayıda birleştirmede StringBuilder

Döngü içinde + kullanmak çok sayıda geçici nesne oluşturabilir. Bu durumda StringBuilder, değiştirilebilir bir karakter tamponu sunar:

using System.Text;

var rapor = new StringBuilder();
foreach (int not in notlar)
{
    rapor.Append("Not: ").AppendLine(not.ToString());
}

Console.WriteLine(rapor.ToString());

Az sayıdaki birleştirmede string interpolation okunaklıdır; yoğun işlemlerde ise StringBuilder daha verimlidir. Özetle doğru dizi türünü veri şekline, doğru metin aracını da işlem yoğunluğuna göre seçmek hem performansı hem kod okunabilirliğini artırır.

``

Temel zihinsel model

Referans, var olan bir nesne için alternatif bir ad gibi düşünülebilir. İşaretçi ise bir nesnenin adresini tutan ayrı bir değerdir. Bir nesnenin adresi $A$ ise işaretçi kabaca $p = A$ ilişkisini taşır; *p ifadesi de o adresteki nesneye erişir. Referansta ise r, doğrudan aynı nesneyi temsil eder:

Bu benzerlik, ikisinin aynı semantiğe sahip olduğu anlamına gelmez.

Fonksiyon parametrelerindeki asıl belirsizlik

Aşağıdaki iki fonksiyon teknik olarak aynı nesneyi değiştirebilir:

void increase(int& value) {
    ++value;
}

void increase(int* value) {
    if (value != nullptr) {
        ++(*value);
    }
}

Çağrı biçimleri ise farklı niyetler taşır:

int score = 10;
increase(score);   // Değişiklik ihtimali çağrı noktasında az görünür.
increase(&score);  // Adres verilmesi değişiklik sinyalini güçlendirir.

Referans kullanan ilk çağrı, değer ile aktarılıyormuş gibi görünebilir. Fonksiyon bildirimi görülmüyorsa okuyucu score değişecek mi diye duraksar. İşaretçili çağrı daha görünürdür; fakat bu kez başka sorular doğar: nullptr geçerli mi, fonksiyon belleği serbest bırakacak mı, adres daha sonra saklanacak mı?

Dolayısıyla belirsizlik sözdiziminden çok, belgelenmemiş sözleşmeden kaynaklanır.

const pusulasını kullanmak

const, fonksiyonun niyetini belirginleştiren en önemli araçlardan biridir:

Özellikle T*& sık karıştırılır. Burada fonksiyon yalnızca nesneyi değil, çağıranın işaretçisini de başka bir adrese yöneltebilir:

void selectDefault(User*& current, User& fallback) {
    if (current == nullptr) {
        current = &fallback;
    }
}

Bu davranış gerçekten gerekiyorsa bildirim anlamlıdır. Yalnızca nesneyi değiştirmek isteniyorsa User* veya User& daha doğru olur.

Sahiplik tuzağı

Ham işaretçi sahipliği açıklamaz. Widget* gören kişi nesnenin kim tarafından yok edileceğini bilemez. Modern C++’ta sahiplik için akıllı işaretçiler tercih edilmelidir:

void inspect(const Widget& widget);             // Ödünç alır, null olamaz.
void inspect(const Widget* widget);             // Ödünç alır, null olabilir.
void consume(std::unique_ptr<Widget> widget);   // Sahipliği devralır.
void share(std::shared_ptr<Widget> widget);      // Ortak sahiplik kurar.

Buradaki isimler ve türler birlikte okununca API’nin sözleşmesi büyük ölçüde anlaşılır.

Pratik seçim rehberi

Parametre zorunluysa ve sahiplik aktarılmıyorsa referans kullanın. Yokluğu anlamlı bir durumsa işaretçi veya daha açık bir soyutlama seçin. Salt okuma için const T&, küçük ve ucuz türler için değer aktarımı tercih edin. Sahiplik aktarımını ham işaretçiyle gizlemeyin; std::unique_ptr ya da std::shared_ptr ile görünür kılın.

Kısacası referans ve işaretçi birbirinin süslü yazılmış hâli değildir. İyi tasarlanmış bir fonksiyon imzası, yalnızca derleyiciye tür bilgisi vermez; okuyucuya null, değişiklik ve sahiplik hakkında küçük ama güvenilir bir hikâye anlatır.

Bir projede yalnızca birkaç değişken ve sınıf varken isim bulmak kolaydır. Ancak kod tabanı büyüdükçe farklı geliştiricilerin aynı Logger, Config veya User adını kullanması kaçınılmaz hâle gelir. C++ isim alanları, yani namespace yapıları, bu isimleri mantıksal gruplara ayırarak derleyiciye hangi varlığı kastettiğimizi söyler. Kısacası namespace, kod dünyasının mahalle adresidir: Aynı isimli iki kişi olabilir, yeter ki farklı adreslerde yaşasın!

``

İsim çakışması neden oluşur?

C++ dilinde bir ismin hangi bölgeden erişilebilir olduğunu belirleyen kurallara kapsam, yani scope denir. Global kapsamda tanımlanan isimler projenin birçok noktasından görülebildiği için çakışma olasılığı yükselir. Bir projede birbirinden bağımsız $n$ bileşen ve her bileşende ortalama $k$ genel isim bulunduğunu düşünelim. Karşılaştırılabilecek isim çiftlerinin sayısı yaklaşık olarak şöyledir:

Bu ifade doğrudan kesin çakışma sayısını vermez; proje büyüdükçe riskin neden hızla arttığını gösterir. İsimleri namespace gruplarına bölmek, karşılaştırma alanını küçültür.

Temel namespace kullanımı

Bir isim alanı namespace anahtar sözcüğüyle tanımlanır. Aynı sınıf adı farklı alanlarda güvenle bulunabilir:

#include <iostream>
#include <string>

namespace Database {
    class Connection {
    public:
        void open() const {
            std::cout << "Veritabanı bağlantısı açıldı.\n";
        }
    };
}

namespace Network {
    class Connection {
    public:
        void open() const {
            std::cout << "Ağ bağlantısı açıldı.\n";
        }
    };
}

int main() {
    Database::Connection database;
    Network::Connection network;

    database.open();
    network.open();
}

Buradaki :: operatörüne kapsam çözümleme operatörü denir. Database::Connection, derleyiciye yalnızca Connection sınıfını değil, sınıfın tam adresini verir.

using kullanırken dikkat

Uzun isimleri sürekli yazmamak için using bildirimi kullanılabilir:

using Database::Connection;

int main() {
    Connection connection;
    connection.open();
}

Bu yöntem yalnızca ihtiyaç duyulan ismi mevcut kapsama taşır. Buna karşılık aşağıdaki kullanım özellikle başlık dosyalarında risklidir:

using namespace std;

Bu ifade std içindeki çok sayıda ismi görünür yapar. Projede başka bir count, distance veya begin tanımı varsa belirsizlik oluşabilir.

İç içe ve anonim namespace

Modern C++ ile iç içe isim alanları daha kısa yazılabilir:

namespace company::project::logging {
    void write(const std::string& message) {
        std::cout << message << '\n';
    }
}

Fonksiyonun tam adı company::project::logging::write olur. Bu yapı şirket, ürün ve modül katmanlarını ifade etmek için kullanışlıdır.

Anonim namespace ise bir kaynak dosyasındaki isimleri yalnızca o çeviri birimine özel tutar:

namespace {
    int calculateSecretValue() {
        return 42;
    }
}

Bu fonksiyona başka bir .cpp dosyasından erişilemez. Böylece uygulama içi yardımcı fonksiyonlar dış dünyaya sızmaz.

Pratik kurallar

• Namespace adlarını modül sınırlarına göre seçin.
• Başlık dosyalarında using namespace kullanmayın.
• Çok genel Utils veya Common adları yerine anlamlı alanlar oluşturun.
• Genel API’lerde kısa ama ayırt edici isimler tercih edin.
• Aynı namespace’i birden fazla dosyada genişletebileceğinizi unutmayın.

Doğru namespace tasarımı yalnızca derleyici hatalarını önlemez; kodun sahibini, amacını ve mimari konumunu da anlatır. Büyük bir C++ projesinde düzen, iyi seçilmiş isimlerle; güvenlik ise o isimlere doğru adresleri vermekle başlar.