``

Temel mekanik düzen

Bu robotlarda aynı eksen üzerinde bulunan iki bağımsız tahrik tekerleği vardır. Tekerlekler arasındaki mesafeye iz genişliği veya dingil uzunluğu denir ve genellikle $L$ ile gösterilir. Sol tekerleğin doğrusal hızı $v_l$, sağ tekerleğinki ise $v_r$ olsun.

Robotun merkezinin ileri yönlü doğrusal hızı iki tekerlek hızının ortalamasıdır:

Açısal hız ise tekerlekler arasındaki hız farkıyla belirlenir:

Bu ikinci denklem robotun dönüş mantığını özetler. Hız farkı büyüdükçe robot daha hızlı döner. Tekerlekler arası mesafe büyüdükçe aynı hız farkıyla elde edilen açısal hız azalır; çünkü geniş bir robotu çevirmek daha zordur.

Buradaki sağ ve sol yön işaretleri, kullanılan koordinat sistemine göre ters tanımlanabilir. Önemli olan yazılımın ve matematiksel modelin aynı işaret kuralını kullanmasıdır.

Görünmez dönüş merkezi: ICC

Robot viraj alırken iki tekerlek aynı merkez çevresinde fakat farklı yarıçaplarda yay çizer. Bu ortak noktaya Anlık Dönüş Merkezi ya da ICC denir. İç taraftaki tekerlek daha kısa, dış taraftaki tekerlek daha uzun yol aldığı için dış tekerlek daha hızlı dönmelidir.

Robot merkezinin dönüş yarıçapı $R$, açısal hız sıfır değilken şöyle bulunabilir:

Tekerlek hızları birbirine yaklaştığında paydadaki fark küçülür ve $R$ büyür; robot geniş bir yay çizer. Hızlar eşit olduğunda yarıçap teorik olarak sonsuza gider, yani hareket düz bir çizgiye dönüşür. Hızlar eşit büyüklükte ve zıt yönlü olduğundaysa $v=0$ olur; dönüş merkezi robotun tam ortasına gelir.

Basit bir hız hesabı

Aşağıdaki Python fonksiyonu, tekerlek hızlarından robotun doğrusal ve açısal hızını hesaplar:

def robot_hizi(sol_hiz, sag_hiz, tekerlek_araligi):
    dogrusal_hiz = (sag_hiz + sol_hiz) / 2
    acisal_hiz = (sag_hiz - sol_hiz) / tekerlek_araligi
    return dogrusal_hiz, acisal_hiz

v, omega = robot_hizi(0.20, 0.40, 0.30)
print(v, omega)

Bu örnekte robotun doğrusal hızı $0.30\ m/s$, açısal hızı yaklaşık $0.67\ rad/s$ olur. Sağ tekerlek daha hızlı olduğu için robot sola yönelir.

Motorlar genellikle doğrusal hız yerine açısal tekerlek hızıyla kontrol edilir. Tekerlek yarıçapı $r$ ve motor açısal hızı $ω_w$ ise doğrusal hız:

bağıntısıyla bulunur. Böylece enkoderden ölçülen dönüş hızı, robot kinematiğinde kullanılabilir.

Gerçek dünya neden formüllerden daha huysuzdur?

Teorik model tekerleklerin kaymadığını varsayar. Gerçekte zemin sürtünmesi, motor farklılıkları, pil gerilimi ve ağırlık dağılımı dönüşü etkiler. Aynı PWM değeri iki motorda aynı hızı üretmeyebilir. Bu nedenle enkoder geri bildirimi ve PID kontrolü kullanılarak her tekerleğin hedef hızı ayrı ayrı korunur.

Kısacası diferansiyel sürüş, mekanik olarak sade fakat matematiksel olarak güçlüdür: ortalama hız robotu ilerletir, hız farkı ise döndürür. İki motorun uyumlu anlaşmazlığı, robotun tüm yön kabiliyetini oluşturur.

``

Tek Bir Sensör Neden Yetmez?

Her sensör çevreyi farklı bir fiziksel ilkeye göre gözlemler. Kameralar görünür ışığı, radar elektromanyetik dalgaların yansımasını, LiDAR ise lazer darbelerinin dönüş süresini kullanır. Bu çeşitlilik aynı zamanda hata çeşitliliği demektir. Kamera sisi yoğun bir duvar gibi görebilirken radar sisin içinden çalışmayı sürdürebilir. Buna karşılık radar, nesnenin bisiklet mi yoksa trafik levhası mı olduğunu kamera kadar başarılı sınıflandıramaz.

Güven, Ağırlık ve Olasılık

Füzyonun temel fikri, bütün sensörlere eşit oy hakkı vermek değildir. Sistem, mevcut koşullara göre her ölçümün güvenilirliğini değerlendirir. Bir sensörün ölçümü $z_i$, güven ağırlığı $w_i$ ise basit bir birleşik tahmin şöyle yazılabilir:

Yoğun siste kameranın $w$ değeri azaltılırken radarın ağırlığı artırılabilir. Daha gelişmiş sistemlerde Kalman filtresi, genişletilmiş Kalman filtresi, parçacık filtresi veya Bayesçi çıkarım kullanılır. Bayes yaklaşımı, yeni bir ölçüm geldiğinde önceki inancı günceller:

Burada $P(x)$ önceki tahmini, $P(z\vert x)$ ölçümün bu tahmin altında görülme olasılığını, $P(x\vert z)$ ise güncellenmiş sonucu temsil eder. Böylece araç, “Radar önümde bir şey olduğunu söylüyor ama kamera emin değil” durumunu matematiksel olarak çözebilir.

Basit Bir Uyarlanabilir Füzyon Örneği

Aşağıdaki Python kodu, hava durumuna göre kamera ve radar ölçümlerinin ağırlıklarını değiştirir. Gerçek araçlarda belirsizlik kovaryans matrisleri ve zaman senkronizasyonu kullanılır; bu örnek temel mantığı görünür kılar.

def fuse_distance(camera, radar, weather):
    # Açık havada kamera daha güvenilirken siste radar öne çıkar.
    weights = {
        "clear": (0.6, 0.4),
        "rain":  (0.3, 0.7),
        "fog":   (0.15, 0.85)
    }

    camera_w, radar_w = weights.get(weather, (0.5, 0.5))
    return camera * camera_w + radar * radar_w

result = fuse_distance(camera=24.0, radar=21.5, weather="fog")
print(f"Tahmini mesafe: {result:.2f} metre")

Burada sisli havada radar ölçümü sonuca daha fazla yön verir. Fakat yalnızca hava etiketi kullanmak yeterli değildir. Kamera kontrastı, LiDAR dönüş yoğunluğu, radar sinyal-gürültü oranı ve sensör sıcaklığı gibi anlık kalite göstergeleri de ağırlıkları dinamik biçimde değiştirmelidir.

Füzyonun Gizli Kahramanları

Başarılı bir sistem için sensörlerin kalibrasyonu ve zaman eşlemesi kritiktir. Milisaniyelik gecikme, hızlı hareket eden bir aracın farklı konumlarda algılanmasına yol açabilir. Ayrıca sensörler ortak koordinat sistemine dönüştürülmelidir. Aksi hâlde radarın “ön sağ” dediği nesne, kamera görüntüsünde yanlış piksele bağlanır.

Sonuç olarak sensör füzyonu kötü havayı ortadan kaldırmaz; belirsizliği yönetilebilir hâle getirir. Güvenilir otonomi, en parlak sensöre sahip olmak değil, hangi sensöre ne zaman güvenileceğini bilmektir. Robotik aracın süper gücü kusursuz görmek değil, şüphe etmeyi matematikle öğrenmektir.

Java Neden Katı Tipli Bir Dildir?

Java, statik ve güçlü tipli bir programlama dilidir. Statik tipleme, değişken tiplerinin derleme aşamasında bilinmesi anlamına gelir. Güçlü tipleme ise uyumsuz tipler arasında kontrolsüz işlem yapılmasını engeller.

Örneğin aşağıdaki kod derlenemez:

int yas = 25;
yas = "yirmi beş"; // Hata: String, int değişkenine atanamaz

Derleyicinin bu itirazı aslında dostça bir uyarıdır. Aksi hâlde program, çalışma sırasında beklenmedik sonuçlarla karşılaşabilirdi. Tip güvenliği sayesinde bir değişkenin hangi değerleri taşıyabileceği ve üzerinde hangi işlemlerin uygulanabileceği bellidir.

İlkel Veri Tipleri

Java’da doğrudan değer saklayan sekiz adet primitive, yani ilkel veri tipi bulunur. Bunlar nesne değildir ve genellikle hızlı, düşük maliyetli veri işlemleri için kullanılır.

$n$ bitlik işaretli bir tam sayının teorik değer aralığı şu şekilde hesaplanır:

Dolayısıyla 8 bitlik byte, $-128$ ile $127$ arasında değer alabilir. Daha büyük bir değer atamaya çalışmak derleme hatasına neden olur.

Değişken Tanımlama ve Tür Dönüşümü

Bir değişken; tip, isim ve isteğe bağlı başlangıç değerinden oluşur:

int ogrenciSayisi = 24;
double sicaklik = 21.5;
char seviye = 'A';
boolean aktifMi = true;

Küçük kapsamlı bir tipten daha geniş kapsamlı tipe geçiş çoğunlukla otomatik yapılır. Buna widening conversion denir. Tersi yönde ise veri kaybı oluşabileceği için açık dönüşüm gerekir.

int puan = 95;
double ondalikliPuan = puan; // Otomatik dönüşüm

double fiyat = 49.99;
int tamFiyat = (int) fiyat;   // Açık dönüşüm: sonuç 49

Diziler: Aynı Tipten Verilerin Takımı

Dizi, aynı veri tipindeki birden fazla değeri sabit uzunlukta saklar. Java dizileri nesnedir; ancak içlerinde ilkel değerler veya nesne referansları bulunabilir.

int[] notlar = {85, 90, 72, 100};

System.out.println(notlar[0]); // 85
System.out.println(notlar.length); // 4

Dizi indeksleri sıfırdan başlar. Uzunluğu $n$ olan bir dizinin geçerli indeks aralığı $0$ ile $n-1$ arasındadır. Bu sınırın dışına çıkılması ArrayIndexOutOfBoundsException üretir.

Diziler sonradan da oluşturulabilir:

String[] diller = new String[3];
diller[0] = "Java";
diller[1] = "Kotlin";
diller[2] = "Python";

for (String dil : diller) {
    System.out.println(dil);
}

Buradaki geliştirilmiş for döngüsü, indeks yönetmeden her elemanı sırayla okur. Dizinin uzunluğu oluşturulduktan sonra değişmez; dinamik boyut gerekiyorsa ArrayList tercih edilir.

Sonuç olarak Java’nın katı tip sistemi, programcıyı kısıtlamak için değil güvenilir kod üretmeye yönlendirmek için vardır. Doğru veri tipini seçmek belleği ve niyeti netleştirirken diziler, benzer verileri düzenli biçimde yönetmenin temelini oluşturur.

Python’daki *args ve **kwargs, fonksiyonlara değişken sayıda argüman gönderme özgürlüğü sağlar. Ancak bu özgürlük kontrolsüz kullanıldığında fonksiyon imzası, ne beklediğini söylemeyen gizemli bir kapıya dönüşebilir. Fonksiyon çalışır, testler geçer; fakat onu ilk kez gören geliştirici kendini “Buraya ne göndermem gerekiyor?” diye sorarken bulur.

``

*args ve **kwargs aslında ne yapar?

*args, fazladan konumsal argümanları bir tuple içerisinde toplar. **kwargs ise fazladan anahtar kelimeli argümanları bir dict olarak saklar. Buradaki args ve kwargs isimleri zorunlu değildir; özel davranışı oluşturan yıldızlardır.

def rapor_olustur(baslik, *satirlar, **ayarlar):
    print(f"Rapor: {baslik}")
    print(f"Satır sayısı: {len(satirlar)}")
    print(f"Ayarlar: {ayarlar}")

rapor_olustur(
    "Aylık Satış",
    "Ocak: 120",
    "Şubat: 145",
    renk="mavi",
    pdf=True
)

Bu örnekte satirlar, iki elemanlı bir tuple; ayarlar ise renk ve pdf anahtarlarını taşıyan bir sözlüktür. Teknik olarak oldukça kullanışlıdır. Sorun, fonksiyon imzasının hangi ayarların geçerli olduğunu açıklamamasıdır.

Bir fonksiyonun anlaşılabilirliğini kabaca şu ilişkiyle düşünebiliriz:

Burada $O$ okunabilirliği, $B$ imzada açıkça belirtilen bilgiyi, $G$ ise gizli veya belirsiz parametre sayısını temsil eder. Bu gerçek bir yazılım metriği değildir; fakat önemli fikri gösterir: Beklentiler imzadan sözlük içine taşındıkça okunabilirlik azalır.

Açık imza ile karşılaştırma

Şu fonksiyon kısa görünür, ancak kullanıcı açısından yeterince açıklayıcı değildir:

def kullanici_olustur(**kwargs):
    # Parametreleri doğrudan veri katmanına iletiyor.
    return veritabani.ekle(kwargs)

Fonksiyon ad, eposta, yas veya bambaşka alanlar mı bekliyor? Yanlışlıkla eposta yerine epost yazılırsa hata hemen mi alınacak, yoksa problem veritabanına kadar mı ilerleyecek? Kısa imza her zaman sade tasarım anlamına gelmez.

Açık parametreler çoğu durumda daha güvenlidir:

def kullanici_olustur(
    ad: str,
    eposta: str,
    *,
    aktif: bool = True
) -> dict:
    return {
        "ad": ad,
        "eposta": eposta,
        "aktif": aktif,
    }

Tek başına kullanılan *, sonraki parametrelerin yalnızca isimleriyle gönderilmesini zorunlu kılar. Böylece aktif değerinin yanlışlıkla üçüncü konumsal argüman olarak verilmesi engellenir. Ayrıca IDE otomatik tamamlama sunabilir ve statik tip denetleyicileri hataları daha erken yakalayabilir.

Yapılandırma nesnesi ne zaman kullanılmalı?

Seçenek sayısı arttığında bütün bilgileri **kwargs içine saklamak yerine dataclass tercih edilebilir:

from dataclasses import dataclass

@dataclass
class RaporAyarlari:
    renk: str = "mavi"
    pdf: bool = False
    sayfa_boyutu: str = "A4"


def rapor_olustur(baslik: str, ayarlar: RaporAyarlari) -> None:
    print(baslik, ayarlar)

Bu yapı geçerli seçenekleri görünür kılar, varsayılan değerleri tek yerde toplar ve yanlış alan adlarının sessizce dolaşmasını önler.

Elbette *args ve **kwargs kötü değildir. Dekoratörlerde, başka bir fonksiyona çağrı aktarırken veya gerçekten değişken sayıda değer kabul eden toplama benzeri işlemlerde son derece uygundurlar. Temel ölçüt şudur: Esnekliğin kendisi fonksiyonun amacıysa yıldızlı parametreler mantıklıdır; yalnızca uzun bir imzayı saklamak için kullanılıyorsa okunabilirlik borcu oluştururlar. Python bize yıldızları verir, fakat her fonksiyonu galaksiye çevirmek zorunda değiliz.

``

Şaşırtıcı örnek

Aşağıdaki kodun 0, 1, 2 yazdırmasını beklemek oldukça doğaldır:

fonksiyonlar = []

for i in range(3):
    fonksiyonlar.append(lambda: i)

for fonksiyon in fonksiyonlar:
    print(fonksiyon())

Gerçek çıktı şöyledir:

2
2
2

Çünkü lambda, oluşturulduğu anda i değişkeninin değerini kopyalamaz. Bunun yerine, çevresindeki kapsamda bulunan i değişkenine erişir. Fonksiyonlar çalıştırıldığında döngü çoktan bitmiştir ve i değişkeninin son değeri 2 olmuştur.

Bu davranış late binding, yani geç bağlama olarak adlandırılır. Bağlamanın fonksiyon tanımlanırken değil, fonksiyon çağrılırken gerçekleştiğini düşünebiliriz.

Matematiksel olarak üç fonksiyon oluşturduğumuzu varsayalım. Beklentimiz:

Fakat fonksiyonların tamamı aynı değişken hücresine başvurduğu için gerçekte:

olur.

Closure tam olarak neyi saklar?

Closure, dış kapsamdaki değişkenlere erişebilen iç fonksiyondur. Önemli ayrıntı şudur: Python çoğu durumda değişkenin o anki değerini değil, değişkenin bulunduğu hücreyi saklar. Hücrenin içeriği sonradan değişirse closure yeni içeriği görür.

Python isimleri ararken kabaca LEGB sırasını kullanır:

Döngüdeki i, lambda’nın yerel parametresi değildir. Bu nedenle çağrı sırasında dış kapsamdan okunur.

En yaygın çözüm: varsayılan parametre

Değeri lambda oluşturulurken sabitlemek için varsayılan parametre kullanılabilir:

fonksiyonlar = []

for i in range(3):
    fonksiyonlar.append(lambda i=i: i)

for fonksiyon in fonksiyonlar:
    print(fonksiyon())

Bu kez çıktı 0, 1, 2 olur. Çünkü varsayılan parametre ifadeleri fonksiyon tanımlandığı anda değerlendirilir. Sağ taraftaki i, mevcut döngü değerini alır; sol taraftaki i ise lambda’nın yerel parametresidir.

Factory fonksiyonu kullanmak

Daha karmaşık işlemlerde varsayılan parametre numarası yerine açıklayıcı bir üretici fonksiyon tercih edilebilir:

def carpani_uret(carpan):
    def carp(sayi):
        return sayi * carpan
    return carp

fonksiyonlar = [carpani_uret(i) for i in range(3)]

print([fonksiyon(10) for fonksiyon in fonksiyonlar])
# [0, 10, 20]

Her carpani_uret çağrısı yeni bir yerel kapsam oluşturur. Böylece her iç fonksiyon farklı bir carpan hücresine sahip olur. Bu yaklaşım daha uzun olsa da okunabilirliği yüksektir.

Alternatif olarak functools.partial, bir fonksiyonun belirli argümanlarını önceden bağlamak için kullanılabilir:

from functools import partial

def carp(sayi, carpan):
    return sayi * carpan

fonksiyonlar = [partial(carp, carpan=i) for i in range(3)]

Late binding özellikle buton callback’lerinde, zamanlayıcılarda, olay dinleyicilerinde ve asenkron görevlerde ortaya çıkar. Kısa kural şudur: Döngü değişkenini daha sonra çalışacak bir fonksiyonda kullanıyorsanız, değeri varsayılan parametreyle, factory fonksiyonuyla veya partial ile açıkça bağlayın. Böylece lambda’lar sürpriz kutusu olmaktan çıkar.

``

Fonksiyon aşırı yükleme nedir?

Function overloading, aynı kapsam içerisinde aynı isimli fakat farklı parametre listelerine sahip birden fazla fonksiyon tanımlamaktır. Parametre listesindeki tür, sayı veya sıralama değiştiğinde yeni bir overload meydana gelir.

#include <iostream>
#include <string>

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

double topla(double a, double b) {
    return a + b;
}

std::string topla(const std::string& a, const std::string& b) {
    return a + b;
}

int main() {
    std::cout << topla(4, 7) << '\n';
    std::cout << topla(2.5, 1.8) << '\n';
    std::cout << topla(std::string("Merhaba "), std::string("C++"));
}

Burada topla(4, 7) çağrısı int sürümünü, ondalıklı argümanlar double sürümünü seçer. Son sürüm ise iki metni birleştirir. const std::string& kullanılması, metinlerin gereksiz yere kopyalanmasını önler.

Derleyici doğru fonksiyonu nasıl seçer?

Derleyici, çağrıdaki argümanları mevcut adayların parametreleriyle karşılaştırır. Bu sürece overload resolution denir. Basitleştirilmiş biçimde her aday için bir dönüşüm maliyeti düşünülebilir:

Burada $C_i$, ilgili argümanın parametre türüne dönüştürülme maliyetidir. En düşük $S$ değerine sahip aday seçilir. Tam eşleşme genellikle standart tür dönüşümünden, standart dönüşüm de kullanıcı tanımlı dönüşümden daha güçlüdür.

Neler overload oluşturur?

Aşağıdaki fonksiyonlar geçerli biçimde aşırı yüklenebilir:

void yazdir(int deger);
void yazdir(double deger);
void yazdir(int deger, int tekrar);
void yazdir(const std::string& metin);

Birincisi ve ikincisi parametre türüyle, üçüncüsü parametre sayısıyla ayrılır. Ancak yalnızca dönüş türünü değiştirmek yeterli değildir:

int hesapla(int x);
// double hesapla(int x); // Hata: Parametre listesi aynı!

Çağıran kod yalnızca hesapla(5) yazdığında hangi dönüş türünü istediğini derleyici kesin olarak anlayamaz. Bu nedenle dönüş türü, fonksiyon aşırı yükleme imzasının ayırt edici parçası değildir.

Belirsizlik tuzağı

Dönüşümler eşit derecede uygun olduğunda derleyici seçim yapamaz:

void goster(long deger) {}
void goster(double deger) {}

int main() {
    // goster(10); // Belirsiz çağrı
    goster(10L);   // long sürümü
    goster(10.0);  // double sürümü
}

10, int türündedir ve hem long hem de double türüne dönüştürülebilir. L ve .0 ekleriyle niyet açıkça belirtilir. Benzer sorunlar varsayılan parametrelerle de oluşabilir.

Ne zaman kullanmalıyız?

Aşırı yüklenen fonksiyonlar kavramsal olarak aynı işi yapmalıdır. yazdir, hesapla veya ekle gibi işlemler bunun için uygundur. Bir overload dosya silerken diğeri matematiksel hesap yapıyorsa ortak isim geliştiriciyi şaşırtır.

Kısacası function overloading, C++ arayüzlerini esnek ve okunabilir hâle getirir. Parametre listelerini belirgin tuttuğunuz, örtük dönüşümleri sınırladığınız ve her sürüme aynı kavramsal sorumluluğu verdiğiniz sürece tek bir isim gerçekten birçok yeteneği zarifçe taşıyabilir.

Bir C++ fonksiyonunun istisna fırlatabilmesi tek başına korkutucu değildir; asıl mesele, istisna sonrasında programın hangi durumda kaldığıdır. Sepete ürün eklerken bellek tahsisi başarısız olursa eski sepet hâlâ kullanılabilir mi, yoksa nesne yarı güncellenmiş bir zombiye mi dönüşür? İstisna garantileri tam olarak bu soruya cevap verir.

``

Önce terminolojiyi netleştirelim

C++ literatüründe yaygın olarak no-throw, güçlü, temel ve garantisiz olmak üzere dört seviye bulunur. “Zayıf garanti” standartlaşmış ayrı bir seviye değildir. Bazı kaynaklar bu ifadeyi temel garantinin eş anlamlısı olarak, bazılarıysa hiçbir durum garantisi vermeyen kod için kullanır. Bu yazıda karışıklığı önlemek amacıyla zayıf/garantisiz ifadesini son anlamda kullanacağız.

Güçlü garantiyi bir işlem dönüşümüyle ifade edebiliriz. Başlangıç durumu $S$, işlem $f$ ise:

Yani sonuç ya tamamen yeni durumdur ya da tamamen eski durumdur. Bu yaklaşım veritabanlarındaki atomik işlemlere benzer.

Güçlü garanti: Ya hep ya hiç

Aşağıdaki sınıf, yeni değeri önce geçici nesnede hazırlar. Riskli işlemler tamamlanmadan mevcut veriye dokunulmaz:

#include <string>
#include <utility>

class Profile {
    std::string name;

public:
    void rename(const std::string& newName) {
        std::string temporary = newName; // Bellek ayırırken fırlatabilir
        name.swap(temporary);            // noexcept
    }
};

Kopyalama sırasında std::bad_alloc oluşursa name değişmez. Başarılı olursa swap ile yeni değer devreye alınır. Bu desen copy-and-swap veya daha genel anlamıyla “önce hazırla, sonra taahhüt et” yaklaşımıdır.

Güçlü garanti; finansal işlemler, yapılandırma güncellemeleri ve birden fazla adımın tek işlem gibi görünmesi gereken yerlerde değerlidir. Bedeli ise geçici kopyalar, ek bellek ve bazen daha karmaşık tasarımdır.

Temel garanti: Dağınık ama hayatta

Temel garanti, istisna sonrasında nesnenin kurallarını koruduğunu ve kaynak sızdırmadığını söyler. Ancak eski değerlerin korunacağını söylemez:

void normalize(std::vector<int>& values) {
    values.clear();
    values.push_back(0); // Bellek tahsisi başarısız olabilir
}

push_back başarısız olursa vektör boş kalabilir. Eski elemanlar kaybedilmiştir fakat values hâlâ geçerli bir vektördür; yeniden doldurulabilir, taşınabilir veya yok edilebilir. Bu, temel garantinin pratik özüdür.

RAII burada kritik rol oynar. std::vector, std::string, akıllı işaretçiler ve kilit sınıfları kaynaklarını yıkıcılarında bıraktığı için istisna sırasında bellek ve kilit sızıntılarını önler.

Zayıf veya garantisiz kod: Sürpriz kutusu

Ham kaynaklar ve sıralı güncellemeler tehlikeli bir kombinasyondur:

account.balance -= amount;
ledger.add(account.id, amount); // Fırlatabilir
account.lastTransfer = now();

ledger.add fırlatırsa bakiye azalmış, kayıt eklenmemiş ve zaman damgası değişmemiş olabilir. Nesneler tek tek geçerli görünse bile sistemin iş kuralı bozulmuştur. Böyle bir fonksiyon tekrar çağrılırsa para ikinci kez düşülebilir.

Çözüm; değişiklikleri geçici bir yapıda toplamak, geri alma işlemi tasarlamak veya fırlatabilen adımları mutasyondan önce tamamlamaktır.

Hangi seviyeyi seçmeliyiz?

Her fonksiyona güçlü garanti vermek gereksiz olabilir. Salt hesaplamalarda ve kritik güncellemelerde güçlü garanti hedeflenebilir; büyük koleksiyonları dönüştüren performans odaklı işlemlerde temel garanti yeterli olabilir. Yıkıcılar, kaynak bırakma fonksiyonları ve swap gibi altyapı işlemleri ise mümkünse noexcept olmalıdır.

Pratik kontrol sorusu şudur: “Bu satır fırlatırsa hangi değişiklikler yapılmış olacak?” Cevap belirsizse yalnızca bir istisna probleminiz değil, aynı zamanda bir tasarım probleminiz vardır.

İstisna yönetiminin temel mantığı

Normal koşullarda fonksiyonlar sonuçlarını return ile döndürür. Ancak bir fonksiyon görevini tamamlayamıyorsa sıradan bir sonuç döndürmek yanıltıcı olabilir. Örneğin pozitif sayı bekleyen bir karekök fonksiyonuna negatif değer verilmesi ayrı bir kontrol akışı gerektirir.

İstisna oluştuğunda program, uygun bir catch bloğu bulana kadar çağrı zincirinde geriye ilerler. Bu sürece stack unwinding denir. Matematiksel olarak bir fonksiyonun geçerli kümesini şöyle gösterebiliriz:

Burada $x < 0$ olması, fonksiyon sözleşmesinin ihlal edildiğini belirtir.

Temel try, throw ve catch kullanımı

Aşağıdaki örnek, bölme işleminden önce paydayı denetler. Sıfıra bölme tespit edildiğinde std::runtime_error nesnesi fırlatılır:

#include <iostream>
#include <stdexcept>

double bol(double pay, double payda) {
    if (payda == 0.0) {
        throw std::runtime_error("Sıfıra bölme girişimi!");
    }
    return pay / payda;
}

int main() {
    try {
        std::cout << bol(42, 0) << '\n';
    } catch (const std::runtime_error& hata) {
        std::cerr << "Hata: " << hata.what() << '\n';
    }
}

İstisnanın const referansla yakalanması gereksiz kopyalamayı engeller ve çok biçimliliği korur. what() metodu ise hatanın açıklamasını verir. Program kontrolsüz biçimde çökmek yerine kullanıcıya anlamlı bir mesaj sunar.

Standart mı, özel istisna mı?

C++ standart kütüphanesi std::exception tabanlı birçok hata türü sağlar.

Uygulamaya özgü hatalar için özel bir sınıf da tanımlanabilir:

#include <stdexcept>
#include <string>

class BakiyeHatasi : public std::runtime_error {
public:
    explicit BakiyeHatasi(const std::string& mesaj)
        : std::runtime_error(mesaj) {}
};

void paraCek(double bakiye, double miktar) {
    if (miktar > bakiye) {
        throw BakiyeHatasi("Yetersiz bakiye");
    }
}

Bu yaklaşım, çağıran kodun banka işlemlerine özgü problemi diğer çalışma zamanı hatalarından ayırmasını sağlar.

Yakalama sırası ve yeniden fırlatma

catch blokları özel türden genel türe doğru sıralanmalıdır. Aksi hâlde std::exception gibi genel bir blok, türetilmiş bütün istisnaları önce yakalayabilir.

try {
    paraCek(100, 250);
} catch (const BakiyeHatasi& hata) {
    std::cerr << hata.what() << '\n';
    throw; // Aynı istisnayı üst seviyeye iletir
} catch (const std::exception& hata) {
    std::cerr << "Genel hata: " << hata.what() << '\n';
}

Parametresiz throw;, mevcut istisnayı türünü kaybetmeden yeniden fırlatır. Bu yöntem, alt seviyede kayıt tutup üst seviyede kullanıcıya cevap vermek için kullanışlıdır.

Güvenli tasarım için kısa kurallar

İstisnaları sıradan döngü kontrolü amacıyla değil, gerçekten olağan dışı durumlar için kullanın. Kaynak yönetiminde RAII yaklaşımını tercih edin; std::vector, std::string ve akıllı işaretçiler stack unwinding sırasında otomatik olarak temizlenir. Yıkıcılar mümkünse istisna fırlatmamalıdır. Ayrıca yalnızca gerçekten garanti verebildiğiniz fonksiyonları noexcept olarak işaretleyin.

Doğru tasarlanmış istisna yönetimi hataları yok etmez; onları görünür, sınıflandırılabilir ve güvenli biçimde yönetilebilir hâle getirir. Böylece programınız ilk beklenmedik durumda havlu atmak yerine kontrollü bir iniş yapar.

``

C string’inin temel yapısı

Bir C karakter dizisinin her elemanı char türündedir. Metnin bittiği yer, sayısal değeri sıfır olan \0 karakteriyle belirtilir. Örneğin "Kod" metni bellekte şu şekilde tutulur:

Görünen karakter sayısı $n$ ise gereken en düşük bellek miktarı yaklaşık olarak şöyledir:

C standardında sizeof(char) her zaman 1 olduğundan, üç karakterli "Kod" için dört baytlık alan gerekir. Fazladan bayt, null karakterinin koltuğudur; görünmez ama yolculuk onsuz tamamlanmaz.

#include <stdio.h>

int main(void) {
    char metin[] = "Kod";

    printf("%s\n", metin);
    printf("Ilk karakter: %c\n", metin[0]);
    printf("Sonlandirici deger: %d\n", metin[3]);
    return 0;
}

Derleyici burada dizinin boyutunu otomatik olarak dört seçer ve sona \0 ekler. %s, karakterleri null sonlandırıcıya ulaşıncaya kadar ekrana yazar.

Dizi mi, işaretçi mi?

Aşağıdaki iki tanım benzer görünse de aynı davranışı garanti etmez:

char dil[] = "C dili";
dil[0] = 'c';  /* Gecerli: dizi degistirilebilir. */

const char *mesaj = "Merhaba";
/* mesaj[0] = 'm';  Hatali: string sabiti degistirilmemeli. */

İkinci kullanımda const, yanlışlıkla salt okunur veriyi değiştirmeye çalışmamızı engeller. Yalın char *mesaj = "Merhaba"; bazı derleyicilerde kabul edilse bile karakterleri değiştirmek tanımsız davranıştır.

Uzunluk ve kapasite aynı şey değildir

strlen() yalnızca \0 öncesindeki karakterleri sayar. sizeof() ise erişilebilen dizi nesnesinin toplam boyutunu verir.

#include <stdio.h>
#include <string.h>

int main(void) {
    char kutu[20] = "Merhaba";

    printf("Uzunluk: %zu\n", strlen(kutu)); /* 7 */
    printf("Kapasite: %zu\n", sizeof(kutu)); /* 20 */
    return 0;
}

Bu örnekte metin uzunluğu $L=7$, dizinin kapasitesi $C=20$ bayttır. Güvenli bir string için temel koşul $L < C$ olmalıdır; çünkü bir hücre \0 için ayrılır. İşaretçi bir fonksiyona gönderildiğinde sizeof() artık dizinin kapasitesini değil, işaretçinin boyutunu verebilir. Bu nedenle kapasiteyi fonksiyona ayrıca göndermek iyi bir alışkanlıktır.

Güvenli girdi alma

scanf("%s", ...) boşlukta okumayı keser ve sınır belirtilmezse taşmaya yol açabilir. fgets() ise kapasiteyi bildiği için daha güvenli bir seçenektir.

#include <stdio.h>
#include <string.h>

int main(void) {
    char ad[32];

    printf("Adinizi girin: ");
    if (fgets(ad, sizeof ad, stdin) != NULL) {
        ad[strcspn(ad, "\n")] = '\0';
        printf("Merhaba, %s!\n", ad);
    }
    return 0;
}

fgets() satır sonunu diziye ekleyebilir. strcspn() ilk \n karakterinin konumunu bulur ve bu karakter null sonlandırıcıyla değiştirilir.

Akılda tutulacaklar

C string’leri, null karakteriyle sonlanan char dizileridir. Her zaman kapasiteyi hesaba katın, sonlandırıcı için yer bırakın ve sınır kontrollü fonksiyonları tercih edin. strlen, strcmp, strchr ve dikkatli kullanıldığında snprintf, metin işlemlerinde güçlü yardımcılarınızdır. C size emniyet kemerini zorla takmaz; fakat kemerin nerede olduğunu bilmek programınızı çöküşlerden korur.

``

Operatörlerin temel mantığı

Operatör, bir veya daha fazla değer üzerinde işlem yapan semboldür. Örneğin + iki sayıyı toplarken >= değerleri karşılaştırır. = ile == arasındaki fark özellikle önemlidir: İlki atama, ikincisi eşitlik kontrolüdür.

int puan = 75;              // Atama
bool gectiMi = puan >= 50;  // Karşılaştırma
int bonusluPuan = puan + 10;

Aritmetik operatörler matematiksel işlemleri gerçekleştirir. İki sayı $a$ ve $b$ olmak üzere kalan işlemi $a \bmod b$ biçiminde düşünülebilir. C# dilinde bunun karşılığı % operatörüdür.

Mantıksal operatörler Boolean cebirine dayanır. && için sonuç yalnızca iki ifade de doğruysa doğrudur:

|| operatöründe ise koşullardan birinin doğru olması yeterlidir. C# kısa devre değerlendirmesi uygular; A && B ifadesinde A yanlışsa B çalıştırılmaz. Bu davranış hem performans sağlar hem de bazı null hatalarını engeller.

C#’a özgü kullanışlı işleçler

C#, null değerlerle güvenli çalışmayı kolaylaştıran operatörler sunar. ?. yalnızca nesne null değilse üyeye erişir; ?? ise sol taraf null olduğunda yedek değer üretir.

string? kullaniciAdi = null;
int? uzunluk = kullaniciAdi?.Length;
string gorunenAd = kullaniciAdi ?? "Misafir";

Console.WriteLine(gorunenAd); // Misafir

is tür denetimi ve örüntü eşleştirme için, as ise güvenli tür dönüşümü için kullanılır. Ayrıca nameof(degisken) değişkenin adını metin olarak verir; böylece yeniden adlandırmalara dayanıklı hata mesajları oluşturulur.

if-else ile karar vermek

if bloğu koşul doğru olduğunda çalışır. Alternatif yollar else if ve else ile tanımlanır.

int not = 82;

if (not >= 85)
{
    Console.WriteLine("Pek iyi");
}
else if (not >= 50)
{
    Console.WriteLine("Geçti");
}
else
{
    Console.WriteLine("Tekrar dene");
}

Basit seçimlerde üçlü koşul operatörü kullanılabilir: sonuc = kosul ? dogruDeger : yanlisDeger;. Ancak iç içe üçlü ifadeler kodu bulmacaya çevirebilir; okunabilirlik her zaman kısalıktan değerlidir.

Döngüsel iterasyon mekanizmaları

Döngüler tekrar eden işleri otomatikleştirir. Hangi döngünün seçileceği, tekrar sayısının bilinip bilinmemesine bağlıdır.

string[] diller = { "C#", "Java", "Python" };

foreach (string dil in diller)
{
    if (dil == "Java")
        continue; // Bu turu atlar

    Console.WriteLine(dil);
}

continue mevcut turu atlatırken break döngüyü tamamen bitirir. Sonsuz döngülerden kaçınmak için while koşulunu etkileyen değerin gerçekten değiştiğinden emin olun. Özetle operatörler veriyi işler, koşullar yolu seçer, döngüler ise işi tekrarlar; bu üçlü, neredeyse bütün C# uygulamalarının kontrol merkezidir.