İstisna nedir?

İstisna, program çalışırken normal akışı bozan olağan dışı bir durumu temsil eden nesnedir. C# içerisindeki bütün istisnalar doğrudan veya dolaylı olarak System.Exception sınıfından türetilir.

Bir işlemin başarısız olma olasılığını $P(E)$, hatanın sisteme vereceği zararı da $C(E)$ ile gösterirsek basitleştirilmiş risk hesabı şöyle yazılabilir:

İstisna yönetimi hatanın oluşma ihtimalini her zaman azaltmaz; fakat $C(E)$ değerini düşürerek hatanın uygulamanın tamamına yayılmasını engeller.

try-catch-finally mimarisi

Aşağıdaki örnek bir dosyayı okumayı dener, olası hataları türlerine göre izole eder ve işlem sonunda bilgi verir:

try
{
    string metin = File.ReadAllText("ayarlar.json");
    Console.WriteLine(metin);
}
catch (FileNotFoundException ex)
{
    Console.WriteLine($"Dosya bulunamadı: {ex.FileName}");
}
catch (UnauthorizedAccessException)
{
    Console.WriteLine("Dosyaya erişim yetkiniz yok.");
}
catch (IOException ex)
{
    Console.WriteLine($"Girdi/çıktı hatası: {ex.Message}");
}
finally
{
    Console.WriteLine("Dosya okuma denemesi tamamlandı.");
}

catch blokları özelden genele doğru sıralanmalıdır. Önce Exception yakalanırsa daha özel bloklara sıra gelmez. Ayrıca her yerde genel Exception yakalayıp hatayı sessizce yutmak, yangın alarmının pilini çıkarmaya benzer: ortam sessizleşir ama yangın devam eder.

Bir istisnayı aynı çağrı yığını bilgisiyle yeniden göndermek için throw; kullanılmalıdır. throw ex; ifadesi yığın izini değiştirerek hatanın gerçek kaynağını bulmayı zorlaştırabilir.

Özel hata sınıfları

İş kuralları için hazır istisnalar her zaman yeterince açıklayıcı değildir. Örneğin stok miktarının yetersiz olması teknik değil, alan odaklı bir problemdir:

public class YetersizStokException : Exception
{
    public int MevcutStok { get; }

    public YetersizStokException(string mesaj, int mevcutStok)
        : base(mesaj)
    {
        MevcutStok = mevcutStok;
    }
}

public static void SiparisVer(int istenen, int stok)
{
    if (istenen > stok)
    {
        throw new YetersizStokException(
            "İstenen miktar stoktan fazla.", stok);
    }
}

Bu sınıf, hataya yalnızca mesaj değil, MevcutStok gibi yapılandırılmış bağlam da ekler. Üst katman böylece kullanıcıya uygun bildirim gösterebilir veya işlemi başka bir depoya yönlendirebilir.

Sağlam kullanım ilkeleri

• İstisnaları yalnızca gerçekten olağan dışı durumlarda kullanın; normal kontrol akışını throw ile kurmayın.
• ArgumentException, InvalidOperationException ve FileNotFoundException gibi uygun hazır türleri tercih edin.
• Hataları bağlam bilgisiyle loglayın; parola ve erişim anahtarı gibi hassas verileri kaydetmeyin.
• IDisposable kaynaklarında mümkünse using kullanın; derleyici gerekli temizliği güvenli biçimde oluşturur.
• Kullanıcıya sade mesaj, geliştiriciye ise ayrıntılı log sağlayın.

Doğru tasarlanmış istisna yönetimi hataları yok etmez; onları sınırlar, görünür kılar ve uygulamanın güvenli biçimde toparlanmasına yardımcı olur. Kısacası try-catch-finally, kodun emniyet kemeridir: kazayı engellemeyebilir ama sonucunu ciddi ölçüde kontrol eder.

``

Bağlama tam olarak nedir?

Bağlama, bir çağrı ifadesinin çalıştırılacak fonksiyon gövdesiyle eşleştirilmesidir. Statik bağlamada karar, değişkenin derleme zamanındaki türüne göre verilir. Dinamik bağlamada ise virtual mekanizması üzerinden nesnenin çalışma zamanındaki gerçek türü kullanılır.

Bunu kabaca şöyle düşünebiliriz:

Fonksiyon sanal değilse çoğunlukla $T_{statik}$ belirleyicidir. Sanal fonksiyon çağrısında ise uygun koşullarda $T_{dinamik}$ devreye girer.

Hata 1: Sanal olmayan yıkıcı

Polimorfik bir taban sınıfın yıkıcısını sanal yapmamak, en tehlikeli karışıklıklardan biridir:

#include <iostream>

class Kaynak {
public:
    ~Kaynak() { std::cout << "Kaynak kapandı\n"; }
};

class Dosya : public Kaynak {
public:
    ~Dosya() { std::cout << "Dosya kapandı\n"; }
};

int main() {
    Kaynak* kaynak = new Dosya;
    delete kaynak; // Tanımsız davranış!
}

delete işlemi taban işaretçisi üzerinden yapıldığı için yıkıcının dinamik davranması gerekir. Çözüm basittir:

virtual ~Kaynak() = default;

Bir sınıfta sanal metot varsa yıkıcının da genellikle sanal olması beklenir.

Hata 2: Varsayılan argümanların sanal olduğunu sanmak

Sanal fonksiyonun gövdesi dinamik, varsayılan argümanı ise statik olarak seçilir:

#include <iostream>

struct Bildirim {
    virtual void gonder(int oncelik = 1) {
        std::cout << oncelik << '\n';
    }
};

struct Alarm : Bildirim {
    void gonder(int oncelik = 9) override {
        std::cout << oncelik << '\n';
    }
};

int main() {
    Alarm alarm;
    Bildirim& b = alarm;
    b.gonder(); // Alarm::gonder çalışır, fakat argüman 1 olur.
}

Ortaya hibrit bir sonuç çıkar: gövde alt sınıftan, değer taban sınıftan gelir. Varsayılan değeri tek yerde tanımlamak veya parametresiz ayrı bir sanal olmayan arayüz kullanmak daha güvenlidir.

Hata 3: Kurucuda sanal çağrı

Kurucu sırasında nesnenin alt sınıf bölümü henüz hazır değildir. Bu nedenle taban kurucusundan yapılan sanal çağrı, alt sınıf sürümüne gitmez:

struct Motor {
    Motor() { baslat(); }
    virtual void baslat() { /* taban davranışı */ }
};

struct TurboMotor : Motor {
    void baslat() override { /* turbo henüz hazır olmayabilir */ }
};

Nesneyi oluşturduktan sonra çağrılan bir initialize() metodu veya fabrika fonksiyonu kullanmak daha açık bir yaşam döngüsü sağlar.

Hata 4: Nesne dilimleme

Alt sınıf nesnesini değer olarak taban türe kopyalamak dinamik tür bilgisini keser:

void calistir(Motor motor) { // Kopyalama ve dilimleme
    motor.baslat();
}

Bunun yerine Motor&, Motor* veya uygun bir akıllı işaretçi kullanılmalıdır.

Sağlam tasarım kontrol listesi

• Ezilen her metoda override ekleyin.
• Polimorfik tabanlarda sanal yıkıcı kullanın.
• Sanal metotlarda farklı varsayılan argümanlardan kaçının.
• Kurucu ve yıkıcılarda sanal dispatch’e güvenmeyin.
• Polimorfik nesneleri değer yerine referans veya işaretçiyle taşıyın.
• Overload ile override kavramlarını aynı şey sanmayın.

Kısacası virtual, tasarıma sihir serpiştiren bir kelime değildir. Hangi kararın derleyiciye, hangisinin çalışma zamanına bırakıldığını açıkça belirlemek gerekir; aksi hâlde kod derlenir, çalışır ve tam en kötü anda yanlış şeyi yapar.

MRO tam olarak nedir?

MRO, bir özellik veya metot aranırken sınıfların hangi sırayla ziyaret edileceğini belirtir. Python 3 bu sırayı oluşturmak için C3 doğrusallaştırma algoritmasını kullanır. Amaç; çocuk sınıfları ebeveynlerden önce tutmak, sınıf bildirimindeki soldan sağa önceliği korumak ve kalıtım ağında tutarlı bir sıra üretmektir.

Bir C sınıfı, B1, B2, ..., Bn sınıflarından türetiliyorsa sıralama kabaca şöyle ifade edilir:

Buradaki merge, başka listelerin kuyruklarında bulunmayan uygun bir baş elemanı seçer. Bu kural, bir sınıfın kendi alt sınıfından önce aranmasını engeller.

Beklenmedik davranış örneği

Aşağıdaki örnekte iki ara sınıf aynı metodu değiştirir:

class Temel:
    def mesaj(self):
        return "Temel"

class A(Temel):
    def mesaj(self):
        return "A -> " + super().mesaj()

class B(Temel):
    def mesaj(self):
        return "B -> " + super().mesaj()

class C(A, B):
    pass

nesne = C()
print(nesne.mesaj())
print(C.mro())

Çıktı şu yapıdadır:

A -> B -> Temel
[C, A, B, Temel, object]

Şaşırtıcı nokta, A içindeki super() çağrısının doğrudan Temel sınıfına gitmemesidir. super(), “ebeveynimi çağır” anlamına gelmez; mevcut MRO’da benden sonraki sınıfa geç demektir. Dolayısıyla C(A, B) için A sonrasında B çalışır.

Ebeveynlerin sırasını değiştirirsek sonuç da değişir:

class D(B, A):
    pass

print(D().mesaj())
# B -> A -> Temel

Yalnızca sınıf bildirimindeki sıra değişmesine rağmen davranış tersine dönmüştür. Özellikle mixin kullanılan büyük projelerde bu durum sessiz ve zor bulunan hatalar doğurabilir.

super() zinciri nasıl güvenli kurulur?

İşbirlikçi çoklu kalıtımda zincire katılan bütün sınıflar uyumlu davranmalıdır. Her sınıf super() çağırmalı, metot imzaları birbiriyle çelişmemeli ve zincir doğrudan sınıf adıyla kesilmemelidir.

class KayitMixin:
    def kaydet(self, **kwargs):
        print("Kayıt günlüğü oluşturuldu")
        return super().kaydet(**kwargs)

class DogrulamaMixin:
    def kaydet(self, **kwargs):
        if not kwargs.get("ad"):
            raise ValueError("ad gerekli")
        return super().kaydet(**kwargs)

class Depo:
    def kaydet(self, **kwargs):
        return f"Kaydedildi: {kwargs['ad']}"

class Servis(KayitMixin, DogrulamaMixin, Depo):
    pass

Bu tasarımda her katman yalnızca kendi görevini yapar ve kontrolü sıradaki sınıfa bırakır. Servis.mro() çağrısı, gerçek yürütme yolunu incelemenin en pratik yöntemidir.

Akılda tutulması gerekenler

MRO’yu bir soy ağacından çok, Python’ın önceden hazırladığı bir ziyaret listesi gibi düşünün. super() bu listede tek adım ilerler. Beklenmedik bir sonuçla karşılaştığınızda Sinif.__mro__ veya Sinif.mro() çıktısını kontrol edin; ebeveyn sırasını bilinçli belirleyin ve doğrudan A.metot(self) çağrılarından kaçının. Çoklu kalıtım güçlüdür, fakat MRO okunmadan kullanıldığında kod tabanına küçük bir labirent yerleştirebilir.

``

Kararlılık neden bu kadar önemli?

Bir dinamik sistemi genel olarak

şeklinde ifade edebiliriz. Burada $x$ sistemin durumu, $u$ ise kontrol girişidir. Kontrolcünün görevi, örneğin robotun eklem açılarını hedeflenen denge noktasına taşımaktır.

Klasik yaklaşımda $u=K(x)$ seçilir ve kapalı çevrim sisteminin davranışı matematiksel olarak incelenir. Lyapunov teorisi bunun en güçlü araçlarından biridir. Pozitif tanımlı bir $V(x)$ fonksiyonu için

koşulları sağlanıyorsa sistemin denge noktasına doğru ilerlediği gösterilebilir. Başka bir ifadeyle enerji benzeri bir değer sürekli azalır. Robot, matematiksel bir yokuştan aşağı yuvarlanarak hedefe yaklaşır.

Sinir ağı kontrolcüsünde ise giriş genellikle

biçimindedir. Çok katmanlı ve doğrusal olmayan $\pi_\theta$ fonksiyonu, milyonlarca parametre içerebilir. Bu nedenle tüm durum uzayında $\dot{V}(x)<0$ olduğunu kanıtlamak oldukça zordur.

Klasik ve öğrenen kontrolcü karşılaştırması

Buradaki temel sorun sinir ağlarının mutlaka kararsız olması değildir. Sorun, eğitim başarısının kanıt anlamına gelmemesidir. Bir kontrolcünün milyonlarca simülasyonda hata yapmaması, henüz denenmemiş bir durumda güvenli kalacağını garanti etmez. Özellikle dağılım kayması, sensör arızası, model belirsizliği ve dış bozucular robotu eğitim verisinin dışına taşıyabilir.

Simülasyon testi neden yeterli değildir?

Aşağıdaki basit Python kodu, öğrenilmiş bir kontrolcüyü farklı başlangıç durumlarında deneyerek son durum normunu ölçer:

import numpy as np

def controller(x):
    # Gerçekte burada eğitilmiş sinir ağı çalıştırılır.
    return -1.8 * x + 0.15 * np.tanh(4 * x)

def simulate(x, dt=0.01, steps=1000):
    for _ in range(steps):
        u = controller(x)
        x = x + dt * (-0.4 * x + u)
    return x

for x0 in np.linspace(-5, 5, 21):
    final_state = simulate(x0)
    print(x0, abs(final_state))

Bu deney faydalıdır; çünkü başarısız başlangıç bölgelerini ortaya çıkarabilir. Ancak yalnızca 21 nokta test edilir. Sürekli durum uzayında sonsuz sayıda olasılık bulunduğundan, başarılı sonuçlar biçimsel bir ispat oluşturmaz. Test güven verir, kanıt ise sınırları tanımlar.

Garantiyi güçlendiren yaklaşımlar

Araştırmacılar bu açığı kapatmak için birkaç yöntemi birlikte kullanıyor:

• Lyapunov tabanlı öğrenme: Ağ, yalnızca görev ödülünü değil, $\dot{V}(x)<0$ koşulunu da dikkate alarak eğitilir.
• Control Barrier Function: Kontrol girişleri güvenli durum kümesinde kalacak şekilde filtrelenir.
• Hibrit mimari: Sinir ağı yüksek performanslı komut üretirken klasik kontrolcü güvenlik katmanı olarak çalışır.
• Doğrulama araçları: Aralık analizi, erişilebilirlik analizi ve karma tamsayılı programlama ile ağın belirli bölgelerdeki çıktıları sınırlandırılır.
• Gürbüzlük analizi: Bozucular altında durumun sınırlı kaldığını göstermek için input-to-state stability gibi kavramlardan yararlanılır.

Pratikte en güvenli yaklaşım, sinir ağını tek başına direksiyona oturtmak yerine ona matematik bilen bir yardımcı pilot vermektir. Öğrenen kontrolcü çeviklik ve uyarlanabilirlik sağlarken klasik katman fiziksel sınırları, tork kısıtlarını ve güvenli çalışma bölgesini korur.

Sonuç olarak robotikte başarı ölçütü yalnızca görevi tamamlamak değildir. Kontrolcünün hangi koşullarda güvenli olduğunu bilmek de gerekir. Sinir ağları güçlü sürücülerdir; fakat kararlılık kanıtı olmadan emniyet kemerleri henüz tam bağlanmış sayılmaz.

Bir robot fabrikadan kusursuz kalibre edilmiş biçimde çıksa bile bu durum sonsuza kadar sürmez. Kamera, LiDAR, IMU, enkoder ve GPS gibi sensörlerin ölçümleri; sıcaklık, titreşim, mekanik aşınma ve elektronik yaşlanma nedeniyle zamanla birbirinden uzaklaşır. Robot hâlâ veri topluyor gibi görünür, ancak artık dünyayı hafifçe “yamuk” algılıyordur. İşte bu yavaş bozulmaya kalibrasyon kayması, yani drift denir.

``

Çoklu sensör kalibrasyonu nedir?

Çoklu sensörlü bir sistemde yalnızca her sensörün kendi doğruluğu değil, sensörlerin birbirleriyle olan geometrik ve zamansal ilişkileri de önemlidir. Örneğin kamera ile LiDAR arasındaki dönüşüm genellikle şu katı cisim dönüşümüyle gösterilir:

Burada $\mathbf{R}$ dönme matrisini, $\mathbf{t}$ ise öteleme vektörünü temsil eder. Sensör yuvasının bir vida kadar oynaması bile bu dış parametreleri değiştirir. Benzer şekilde kameranın odak uzaklığı veya mercek bozulması gibi iç parametreler de sıcaklık ve darbe etkisiyle sapabilir.

Zamansal kalibrasyon da en az geometrik kalibrasyon kadar kritiktir. Kamera görüntüsü ile IMU ölçümü arasında $\Delta t$ gecikmesi varsa hızlı hareket sırasında aynı fiziksel an karşılaştırılmaz. Açısal hız $\omega$ olduğunda yaklaşık yönelim hatası şöyle büyür:

Robot hızlandıkça küçücük bir saat farkının büyük konum hatasına dönüşmesinin nedeni budur.

Drift neden oluşur?

Drift her zaman doğrusal ilerlemez. Robot soğukken farklı, çalışma sıcaklığına ulaştığında farklı davranabilir. Bu nedenle yalnızca “ayda bir kalibre et” yaklaşımı her sistem için yeterli değildir.

Yeniden kalibrasyon zamanı nasıl anlaşılır?

Kalibrasyon sağlığı, sensörlerin ortak gözlemleri arasındaki residual, yani artık hata üzerinden izlenebilir. Ölçülen değer $z_i$, modelin tahmini $h_i(\mathbf{x})$ ise toplam hata:

şeklinde tanımlanabilir. $J$ değerinin sürekli yükselmesi, sensör ilişkisinin bozulduğuna işaret eder. Ancak hareketli nesneler, yağmur veya kirli mercek de residual değerini artırabileceğinden tek ölçümle karar verilmemelidir.

Aşağıdaki Python örneği, hata serisinin hareketli ortalamasını izleyerek basit bir yeniden kalibrasyon uyarısı üretir:

from collections import deque

class CalibrationMonitor:
    def __init__(self, window=30, threshold=1.5):
        self.errors = deque(maxlen=window)
        self.threshold = threshold

    def update(self, residual):
        self.errors.append(residual)
        if len(self.errors) < self.errors.maxlen:
            return False

        mean_error = sum(self.errors) / len(self.errors)
        return mean_error > self.threshold

monitor = CalibrationMonitor(window=30, threshold=1.5)

for error in [0.8] * 20 + [1.9] * 30:
    if monitor.update(error):
        print("Yeniden kalibrasyon öneriliyor!")
        break

Bu kod ani bir sıçrama yerine son 30 ölçümün ortalamasını kullanır. Gerçek sistemlerde sıcaklık, robot hızı ve titreşim seviyesi de karara eklenerek yanlış alarmlar azaltılabilir.

Takvim mi, koşul bazlı bakım mı?

Güvenlik kritik robotlarda en sağlam çözüm genellikle hibrittir: residual değerleri sürekli izlenir, eşik aşılırsa erken bakım yapılır ve buna rağmen belirli aralıklarla doğrulama kalibrasyonu uygulanır. Ayrıca kalibrasyon parametreleri sıcaklıkla birlikte kaydedilmeli, sensör montajları işaretlenmeli ve her bakım sonrası referans veri setiyle test edilmelidir.

Sonuç olarak kalibrasyon tek seferlik bir kurulum adımı değil, robotun yaşam döngüsü boyunca yönetilmesi gereken bir sağlık göstergesidir. Robotun dünyayı doğru görmesini istiyorsak yalnızca sensörlerin çalışıp çalışmadığını değil, hâlâ aynı dünyaya bakıp bakmadıklarını da sorgulamalıyız.

``

Açık kaynak erişilebilirliği nasıl artırıyor?

Açık kaynaklı donanımda devre şemaları, yazılım araçları, kütüphaneler ve örnek projeler toplulukla paylaşılır. Kullanıcı yalnızca hazır bir ürünü tüketmez; sistemin nasıl çalıştığını inceleyebilir, değiştirebilir ve yeniden üretebilir. Bu yaklaşım erişilebilirliği üç yönden güçlendirir:

• Ekonomik erişim: Düşük maliyetli kartlar ve uyumlu yan ürünler kullanılabilir.
• Bilgiye erişim: Ücretsiz belgeler, videolar ve topluluk forumları öğrenme sürecini destekler.
• Deneysel erişim: Öğrenci, hata yapmaktan korkmadan devreyi ve kodu değiştirebilir.

Robotik sistemlerin temelinde algılama, karar verme ve hareket etme döngüsü bulunur. Sensör çevreden veri toplar, kontrol birimi bu veriyi işler ve aktüatörler fiziksel tepki üretir:

Örneğin ultrasonik sensörün gönderdiği ses dalgasının geri dönüş süresi $t$, ses hızı $v$ ve engel uzaklığı $d$ arasındaki ilişki şöyledir:

İkiye bölünmesinin nedeni, ölçülen sürenin sesin engele gidişini ve geri dönüşünü birlikte içermesidir. Böyle bir formül, fizik bilgisini doğrudan çalışan bir robot üzerinde görünür hâle getirir.

Arduino mu, Raspberry Pi mı?

Her iki platform da robotik eğitiminde değerlidir; ancak aynı işi yapmak üzere tasarlanmamıştır.

Arduino, çizgi izleyen veya engelden kaçan bir robot için güçlü bir başlangıçtır. Raspberry Pi ise kamera görüntüsünden nesne tanıyan ya da web arayüzüyle yönetilen robotlarda öne çıkar. İki kart birlikte de kullanılabilir: Raspberry Pi yüksek seviyeli kararları verirken Arduino motorları zamanlamaya duyarlı biçimde kontrol edebilir.

Küçük bir robot refleksi

Aşağıdaki Arduino kodu, bir dijital sensör engel algıladığında motor kontrol çıkışını durdurur. Bu örnek, algılama-karar-hareket döngüsünün en sade hâlidir:

const int sensorPin = 2;
const int motorPin = 9;

void setup() {
  pinMode(sensorPin, INPUT);
  pinMode(motorPin, OUTPUT);
}

void loop() {
  bool engelVar = digitalRead(sensorPin);

  if (engelVar) {
    analogWrite(motorPin, 0);    // Motoru durdur
  } else {
    analogWrite(motorPin, 180);  // Orta-yüksek hızda ilerle
  }

  delay(20); // Sensörü saniyede yaklaşık 50 kez kontrol et
}

Kod yalnızca programlamayı değil, giriş-çıkış mantığını ve geri beslemeyi de öğretir. Öğrenci 180 değerini değiştirerek hızın davranışa etkisini gözlemleyebilir. Elbette gerçek bir motor doğrudan karta bağlanmamalı; motor sürücü devresi ve uygun güç kaynağı kullanılmalıdır.

Erişilebilirlik yalnızca düşük fiyat değildir

Ucuz kartlar tek başına eşit eğitim fırsatı oluşturmaz. İnternet erişimi, yerelleştirilmiş içerik, öğretmen eğitimi, yedek parça bulunabilirliği ve güvenli çalışma ortamı da önemlidir. Ayrıca açık kaynak projelerde belgelerin güncelliği değişebilir ve Raspberry Pi gibi kartların toplam maliyetine güç kaynağı, hafıza kartı ve çevre birimleri eklenebilir.

Buna rağmen bu platformların en büyük katkısı, öğrenciyi pasif kullanıcıdan üreticiye dönüştürmesidir. Bir LED’i yakmakla başlayan yolculuk; otonom araçlara, tarım robotlarına veya yapay zekâ destekli sistemlere uzanabilir. Robotik böylece ulaşılmaz bir gelecek teknolojisi değil, parçalarına ayrılıp anlaşılabilen ve yeniden tasarlanabilen bir öğrenme alanı hâline gelir.

``

Stream mantığı nedir?

C, dosya ve aygıtlarla iletişimi stream, yani veri akışı soyutlaması üzerinden gerçekleştirir. Program açısından stream, sırayla okunabilen veya yazılabilen karakter ve bayt dizisidir. Bunun arkasında SSD, terminal ya da başka bir aygıt bulunabilir; temel işlemler büyük ölçüde aynı kalır.

<stdio.h> kütüphanesindeki FILE yapısı bir stream’i temsil eder. Bu yapı dosyanın konumu, erişim modu, tampon bilgisi ve hata durumu gibi ayrıntıları yönetir. Genellikle yapının iç alanlarına doğrudan dokunulmaz; onun yerine fopen, fclose, fprintf ve fread gibi fonksiyonlar kullanılır.

Bir dosyanın toplam boyutu kabaca

ile düşünülebilir. Burada $n$ kayıt sayısını, $b$ ise her kaydın bayt cinsinden ortalama boyutunu gösterir. Metin dosyalarında karakter kodlaması ve ayraçlar nedeniyle gerçek boyut değişebilir.

C programları açıldığında üç standart stream hazırdır:

Dosya açma modları

Dosya işlemi, fopen ile bir stream açarak başlar. Fonksiyon başarısız olursa NULL döndürür; bu kontrolü atlamak, programı hata festivaline dönüştürebilir.

İkili dosyalarda moda b eklenebilir: rb, wb veya ab gibi.

Metin dosyasına yazma ve okuma

Aşağıdaki örnek, bir puanı dosyaya yazar ve ardından geri okur:

#include <stdio.h>

int main(void) {
    FILE *dosya = fopen("puan.txt", "w");

    if (dosya == NULL) {
        perror("Dosya acilamadi");
        return 1;
    }

    fprintf(dosya, "%s %d\n", "Ada", 95);
    fclose(dosya);

    dosya = fopen("puan.txt", "r");
    if (dosya == NULL) {
        perror("Dosya okunamadi");
        return 1;
    }

    char isim[32];
    int puan;

    if (fscanf(dosya, "%31s %d", isim, &puan) == 2) {
        printf("Ogrenci: %s, puan: %d\n", isim, puan);
    }

    fclose(dosya);
    return 0;
}

fprintf, biçimlendirilmiş veriyi stream’e gönderir. fscanf ise veriyi belirtilen formata göre ayrıştırır. %31s sınırı, 32 elemanlı dizide taşmayı önlemek için en fazla 31 karakter okur. Her açılan dosyanın fclose ile kapatılması tamponlanmış verilerin diske aktarılmasını ve sistem kaynaklarının serbest bırakılmasını sağlar.

Metin mi, ikili dosya mı?

İkili yazmada temel denklem aktarılan bayt miktarı için $B = adet \times sizeof(tür)$ biçimindedir. Örneğin fwrite(dizi, sizeof(int), 10, dosya) on tamsayıyı yazar.

Son olarak feof akış sonunu, ferror ise okuma veya yazma hatasını denetler. Sağlam bir File I/O kodu yalnızca mutlu senaryoyu değil; eksik dosyayı, bozuk veriyi ve başarısız yazmayı da hesaba katar. Böylece veriler program kapandığında buharlaşmak yerine diskte güvenle yaşamaya devam eder.

Eşzamanlılık ve paralellik aynı şey değildir

Eşzamanlılık, birden fazla işin zaman aralıkları iç içe geçecek şekilde ilerlemesidir. Paralellik ise bu işlerin gerçekten aynı anda, örneğin farklı işlemci çekirdeklerinde çalışmasıdır.

Bir işin tek çekirdekte tamamlanma süresi $T_1$, $p$ çekirdekteki süresi $T_p$ ise teorik hızlanma şöyle ifade edilir:

İdeal durumda $S_p \approx p$ beklenir. Gerçekte görev oluşturma maliyeti, senkronizasyon ve paylaşılan kaynaklar nedeniyle bu değere nadiren ulaşılır.

TPL ile CPU ağırlıklı işleri çalıştırmak

TPL, görevlerin uygun iş parçacıklarına dağıtılmasını ThreadPool üzerinden yönetir. Böylece her iş için elle Thread oluşturmak gerekmez.

using System;
using System.Linq;
using System.Threading.Tasks;

int[] sayilar = Enumerable.Range(1, 8).ToArray();

Parallel.ForEach(sayilar, sayi =>
{
    double sonuc = Math.Sqrt(sayi) * Math.Pow(sayi, 3);
    Console.WriteLine($"{sayi}: {sonuc} - Thread: {Environment.CurrentManagedThreadId}");
});

Parallel.ForEach, koleksiyondaki hesaplamaları mümkün olduğunda farklı iş parçacıklarında yürütür. Ancak çok küçük işlemleri paralelleştirmek, yönetim maliyeti yüzünden normal bir döngüden daha yavaş olabilir. Önce ölçmek, sonra paralelleştirmek altın kuraldır.

Bağımsız görevleri başlatıp hepsinin bitmesini beklemek için Task.WhenAll kullanılabilir:

Task<int> hesap1 = Task.Run(() => Enumerable.Range(1, 1_000_000).Sum());
Task<int> hesap2 = Task.Run(() => Enumerable.Range(1, 500_000).Sum());

int[] sonuclar = await Task.WhenAll(hesap1, hesap2);
Console.WriteLine($"Toplam: {sonuclar.Sum()}");

Task.Run, CPU ağırlıklı senkron kodu ThreadPool üzerinde çalıştırır. Buna karşılık zaten asenkron olan HTTP veya veritabanı çağrılarını ayrıca Task.Run içine koymak genellikle gereksizdir.

async/await ile beklerken kaynak tüketmemek

async, metodun asenkron işlem içerebildiğini; await ise işlem tamamlanana kadar kontrolün çağırana geri verilebileceğini belirtir. Bu sırada iş parçacığının bloklanması gerekmez.

using System.Net.Http;

static async Task<int> SayfaBoyutuAsync(
    string adres,
    CancellationToken iptal)
{
    using HttpClient istemci = new();
    string icerik = await istemci.GetStringAsync(adres, iptal);
    return icerik.Length;
}

using CancellationTokenSource kaynak = new();
kaynak.CancelAfter(TimeSpan.FromSeconds(5));

try
{
    int boyut = await SayfaBoyutuAsync("https://example.com", kaynak.Token);
    Console.WriteLine($"İndirilen karakter: {boyut}");
}
catch (OperationCanceledException)
{
    Console.WriteLine("İşlem iptal edildi.");
}

Buradaki CancellationToken, uzun süren işlemin kontrollü biçimde durdurulmasını sağlar. await edilen görev hata üretirse istisna normal bir senkron metottaki gibi try/catch ile yakalanabilir.

Paylaşılan veriler ve yarış durumları

Birden fazla görev aynı değişkeni değiştirirse sonuç öngörülemez olabilir. Örneğin sayac++ atomik değildir; okuma, artırma ve yazma adımlarından oluşur. Güvenli artırma için Interlocked.Increment(ref sayac) veya daha karmaşık kritik bölgelerde lock kullanılmalıdır.

Modern C# kodunda temel yaklaşım basittir: I/O ağırlıklı işlemlerde doğal asenkron API’leri await edin, CPU ağırlıklı ve bağımsız hesaplamalarda TPL kullanın, paylaşılan durumu azaltın ve performans kararlarını mutlaka ölçümlerle doğrulayın.

C++ dünyasında bir nesne her zaman göründüğü şey olmayabilir. Elinizde Karakter* türünde bir işaretçi bulunurken, işaret edilen gerçek nesne bir Buyucu veya Savasci olabilir. Çalışma Zamanı Tür Bilgisi, yani RTTI (Run-Time Type Information), program çalışırken bu gerçek kimliği öğrenmemizi ve kalıtım hiyerarşilerinde güvenli dönüşümler yapmamızı sağlar. ``

RTTI neden gereklidir?

C++ değişkenlerinin çoğu tür bilgisi derleme zamanında bellidir. Ancak polimorfizm kullanıldığında statik tür ile dinamik tür birbirinden ayrılır:

• Statik tür: Değişkenin kaynak kodunda bildirilen türdür.
• Dinamik tür: Çalışma anında gerçekten oluşturulmuş nesnenin türüdür.

Bir Karakter* değişkeninin statik türü Karakter*, gösterdiği nesne Buyucu ise dinamik türü Buyucu olur. Bunu kabaca şu ilişkiyle gösterebiliriz:

RTTI özellikle taban sınıf üzerinden yönetilen nesnelerin alt sınıflarını ayırt etmek gerektiğinde devreye girer. Bunun çalışabilmesi için taban sınıfın polimorfik olması, yani en az bir sanal (virtual) fonksiyon içermesi gerekir. Genellikle sanal yıkıcı tanımlamak yeterlidir.

class Karakter {
public:
    virtual ~Karakter() = default;
};

class Buyucu : public Karakter {
public:
    void buyuYap() {
        std::cout << "Ateş topu!\n";
    }
};

Sanal yıkıcı hem RTTI kullanımını mümkün kılar hem de nesne taban sınıf işaretçisi üzerinden silindiğinde doğru yıkıcının çağrılmasını sağlar.

typeid ile türü incelemek

typeid operatörü bir ifade veya tür hakkında std::type_info nesnesi döndürür. İki türün aynı olup olmadığı güvenilir biçimde karşılaştırılabilir:

#include <iostream>
#include <typeinfo>

Karakter* karakter = new Buyucu();

if (typeid(*karakter) == typeid(Buyucu)) {
    std::cout << "Bu karakter gerçekten bir büyücü.\n";
}

delete karakter;

Burada typeid(*karakter) dinamik türü bulur. Buna karşılık typeid(karakter) işaretçinin kendi türünü, yani Karakter* türünü verir. type_info::name() da kullanılabilir; ancak döndürdüğü metnin biçimi derleyiciye bağlıdır ve program mantığı için güvenilir değildir.

dynamic_cast ile güvenli dönüşüm

dynamic_cast, polimorfik kalıtım hiyerarşilerinde çalışma zamanı kontrolü yapar. İşaretçi dönüşümü başarısız olursa nullptr döndürür:

Karakter* karakter = new Buyucu();

if (Buyucu* buyucu = dynamic_cast<Buyucu*>(karakter)) {
    buyucu->buyuYap();
} else {
    std::cout << "Bu karakter büyü yapamaz.\n";
}

 delete karakter;

Referanslarda başarısızlık nullptr ile bildirilemez. Bu nedenle dynamic_cast<Buyucu&> başarısız olduğunda std::bad_cast istisnası fırlatır.

Dönüşüm araçlarının karşılaştırması

static_cast ile aşağı dönüşüm yapılabilir, fakat nesne hedef türde değilse davranış tanımsız olabilir. Başka bir deyişle hız uğruna emniyet kemerini çıkarmış olursunuz.

Tasarım açısından son notlar

RTTI kullanışlıdır ancak her nesnenin türünü sürekli sorgulamak tasarım kokusuna dönüşebilir. Çoğu durumda sanal fonksiyonlar daha temiz bir çözüm sunar: nesneye “Sen büyücü müsün?” diye sormak yerine doğrudan eylemYap() çağrısı yapılabilir.

Yine de eklenti sistemleri, nesne editörleri ve heterojen koleksiyonlar gibi alanlarda RTTI oldukça değerlidir. Kural basittir: Tür gerçekten belirsizse dynamic_cast, davranış polimorfik biçimde ifade edilebiliyorsa sanal fonksiyon kullanın. Böylece C++ nesneleri maskelerini çıkarsa bile programınız şaşırmaz.

``

Çok biçimlilik nedir?

Polymorphism, kelime anlamıyla çok biçimlilik demektir. Nesne yönelimli programlamada aynı fonksiyon çağrısının nesnenin gerçek tipine göre farklı sonuç üretmesini ifade eder. C++ içerisinde bunun iki temel çeşidi vardır:

Dinamik çok biçimlilik için genellikle üç bileşen gerekir: bir temel sınıf, bu sınıftan türeyen sınıflar ve virtual olarak tanımlanmış bir üye fonksiyon.

Matematiksel olarak ortak bir arayüzü $I$, farklı nesne tiplerini ise $T_1, T_2, \ldots, T_n$ ile gösterelim. Aynı işlem $f$, nesnenin dinamik tipine göre farklı uygulanır:

Yani kod f işlemini ortak arayüz üzerinden ister; hangi özel uygulamanın çalışacağına program çalışma zamanında karar verir.

Sanal fonksiyon nasıl çalışır?

Aşağıdaki örnekte bütün karakterler saldir() arayüzünü sunar, fakat her biri kendine özgü davranır:

#include <iostream>
#include <memory>
#include <vector>

class Karakter {
public:
    virtual void saldir() const {
        std::cout << "Karakter saldırdı.\n";
    }

    virtual ~Karakter() = default;
};

class Savasci : public Karakter {
public:
    void saldir() const override {
        std::cout << "Savaşçı kılıcını savurdu!\n";
    }
};

class Buyucu : public Karakter {
public:
    void saldir() const override {
        std::cout << "Büyücü ateş topu gönderdi!\n";
    }
};

virtual anahtar sözcüğü, çağrılacak fonksiyonun nesnenin gerçek tipine bakılarak seçilmesini sağlar. override ise türetilmiş sınıftaki fonksiyonun gerçekten bir sanal fonksiyonu ezdiğini derleyiciye doğrulatır. İmza yanlış yazılırsa derleyici hata verir; bu nedenle override kullanmak iyi bir güvenlik kemeridir.

Derleyiciler bu mekanizmayı çoğunlukla vtable adlı sanal fonksiyon tablosu ve nesnede tutulan gizli bir vptr işaretçisiyle gerçekleştirir. C++ standardı bu yöntemi zorunlu kılmaz, fakat yaygın uygulama budur. Sanal çağrının küçük bir dolaylı erişim maliyeti vardır; buna karşılık sağladığı esneklik çoğu uygulamada çok daha değerlidir.

Nesneleri ortak koleksiyonda yönetmek

Akıllı işaretçiler sayesinde farklı karakterleri aynı koleksiyonda güvenli biçimde saklayabiliriz:

int main() {
    std::vector<std::unique_ptr<Karakter>> takim;

    takim.push_back(std::make_unique<Savasci>());
    takim.push_back(std::make_unique<Buyucu>());

    for (const auto& karakter : takim) {
        karakter->saldir();
    }
}

Döngü yalnızca Karakter arayüzünü bilir. Buna rağmen ilk nesne kılıç kullanır, ikincisi ateş topu fırlatır. İşte dinamik çok biçimliliğin küçük ama etkileyici sihri budur.

Kritik ayrıntılar

Temel sınıf üzerinden silme yapılacaksa yıkıcı mutlaka sanal olmalıdır. Aksi hâlde türetilmiş sınıfın yıkıcısı çağrılmayabilir ve kaynak sızıntıları oluşabilir. Bu nedenle virtual ~Karakter() = default; önemli bir satırdır.

Nesneleri değer olarak kopyalamak da object slicing problemine yol açar:

Savasci savasci;
Karakter kopya = savasci; // Savasci kısmı kesilir
kopya.saldir();           // Temel sınıf davranışı çalışır

Dinamik davranışı korumak için temel sınıf referansı, işaretçisi veya std::unique_ptr gibi akıllı işaretçiler kullanılmalıdır.

Sonuç olarak sanal fonksiyonlar, kodu somut sınıflara değil ortak sözleşmelere bağlar. Yeni bir Okcu sınıfı eklediğimizde mevcut döngüyü değiştirmemiz gerekmez. Böylece C++ programı hem yeni karakterlere hem de gelecekte gelecek sürpriz gereksinimlere hazırlıklı olur.