C++ şablonlarında özelleştirme ve aşırı yükleme aynı hedefe gidiyormuş gibi görünür: belirli türlerde farklı davranmak. Fakat derleyicinin gözünde bunlar iki ayrı mekanizmadır. Overloading adaylar arasındaki yarışı belirlerken specialization, yarışı kazanan şablonun özel bir sürümünün bulunup bulunmadığına bakar. Küçük görünen bu sıra farkı, şaşırtıcı sonuçların kaynağıdır.

``

İki mekanizmanın temel anlamı

Bir fonksiyon şablonunu aşırı yüklediğimizde derleyicinin aday listesine yeni bir fonksiyon şablonu ekleriz. Açık özelleştirme ise yeni ve bağımsız bir aday oluşturmaz; mevcut birincil şablonun belirli argümanlar için alternatif uygulamasını tanımlar.

#include <iostream>

template<typename T>
void goster(T) {
    std::cout << "Genel sürüm\n";
}

template<>
void goster<int>(int) {
    std::cout << "int özelleştirmesi\n";
}

template<typename T>
void goster(T*) {
    std::cout << "İşaretçi overload'u\n";
}

Burada üç bildirim varmış gibi görünse de overload çözümlemesinde yalnızca goster(T) ve goster(T*) yarışır. goster<int> ise ilk şablona bağlı bir açık özelleştirmedir.

Derleyicinin seçim sırası

Basitleştirilmiş süreç şöyledir:

1. Görünür fonksiyonlar ve fonksiyon şablonları aday kümeye alınır.
2. Şablon argüman çıkarımı yapılır.
3. Dönüşüm kalitesi ve şablonların kısmi sıralaması değerlendirilir.
4. En iyi overload seçilir.
5. Kazanan bir fonksiyon şablonuysa ona ait açık özelleştirme aranır.

Bunu kabaca

şeklinde düşünebiliriz. Buradaki $C$, uygun adaylar kümesidir. İşlemlerin sırası ters değildir; specialization önce yarışıp overload’u yenemez.

Klasik işaretçi sürprizi

int* p = nullptr;
goster(p);

İlk bakışta T = int* olduğundan genel şablonun int* özelleştirmesinin aranacağı düşünülebilir. Ancak goster(T*), int* argümanı için goster(T) şablonundan daha özeldir. Dolayısıyla pointer overload’u yarışı kazanır. Derleyici artık yalnızca bu kazanan şablona bağlı bir explicit specialization olup olmadığına bakar; diğer birincil şablonun özelleştirmesine geri dönmez.

Bu nedenle bir specialization’ın hangi birincil şablona bağlı olduğu kritik önemdedir. Bildirim sırası ve specialization bildiriminin çağrıdan önce görünür olması da ayrı derleme birimlerinde ciddi farklar yaratabilir. Açık özelleştirme, örtük örneklemeye yol açan ilk kullanımdan önce bildirilmelidir.

Neden fonksiyon şablonları kısmen özelleştirilemez?

Sınıf şablonlarında kısmi özelleştirme geçerlidir:

template<typename T>
struct Bilgi;

template<typename T>
struct Bilgi<T*> {
    static constexpr bool pointer = true;
};

Fakat aşağıdaki fonksiyon biçimi geçersizdir:

template<typename T>
void isle<T*>(T*); // Geçersiz kısmi specialization

Fonksiyonlarda aynı niyet overload ile ifade edilir:

template<typename T>
void isle(T*) {
    // Türetilen her işaretçi türü için ortak davranış
}

Bunun önemli nedeni, fonksiyonlarda zaten overload çözümlemesi bulunmasıdır. Kısmi specialization da eklenseydi iki ayrı sıralama sistemi birbiriyle çakışabilirdi.

Pratik tercih rehberi

Bir tür ailesini yakalamak istiyorsanız overload kullanın. Yalnızca tek ve kesin bir şablon argümanı kombinasyonunda davranışı değiştirecekseniz explicit specialization düşünülebilir. Bununla birlikte fonksiyonlarda overload çoğu zaman daha okunabilir ve öngörülebilirdir.

Modern C++ kodunda if constexpr, kavramlar ve requires ifadeleri de güçlü alternatiflerdir. Özellikle kısıtlı overload’lar, niyeti doğrudan tür sistemi üzerinden anlatır. Altın kural şudur: specialization’ı bağımsız yarışmacı sanmayın; o, ancak bağlı olduğu şablon yarışı kazandığında sahneye çıkan yedek oyuncudur.

Artıklılık ne anlama gelir?

Bir manipülatörün eklem değişkenlerini $q \in R^n$, uç efektör görevini ise $x \in R^m$ ile gösterelim. İleri kinematik ilişki

şeklindedir. Eğer eklem sayısı görev uzayının boyutundan büyükse, yani $n > m$ ise sistem redundant kabul edilir. Örneğin üç boyutlu uzayda yalnızca uç noktanın konumunu kontrol etmek için üç bağımsız değişken yeterliyken yedi eklemli bir kol dört adet fazladan serbestlik derecesine sahiptir.

Bu fazlalık gereksiz değildir. Aynı uç efektör konumunu üreten birden fazla eklem yapılandırması bulunabilir. Robot böylece ana görevi bozmadan dirseğini bir engelden uzaklaştırabilir, eklem sınırlarından kaçabilir veya daha rahat bir duruş seçebilir.

Jacobian ve sıfır uzayı

Eklem hızları ile uç efektör hızı arasındaki ilişki Jacobian matrisiyle kurulur:

Redundant bir sistemde ters çözüm tek değildir. Yaygın hız çözümü şöyledir:

Burada $J^+$ Jacobian’ın sözde tersidir. İlk terim uç efektörü hedeflenen yönde hareket ettirir. İkinci terim ise Jacobian’ın sıfır uzayında kalır; başka bir deyişle uç efektör hareketini değiştirmeden eklemleri oynatır. Engel kaçınma sihrinin büyük bölümü bu ikinci terimdedir.

$z$ vektörü, robotu engelden uzaklaştıran bir maliyet fonksiyonunun negatif gradyanı olarak seçilebilir:

$H(q)$ robot ile engel arasındaki mesafe azaldıkça büyüyen bir ceza fonksiyonu olabilir. Böylece robot bir eliyle hedefe ilerlerken “dirseğini içeri çekebilir.”

Basit bir hesaplama örneği

Aşağıdaki Python kodu, ana uç efektör hızına sıfır uzayı üzerinden ikincil bir kaçınma hareketi ekler:

import numpy as np

def redundant_velocity(J, target_velocity, avoidance_gradient, gain=0.4):
    J_pinv = np.linalg.pinv(J)
    identity = np.eye(J.shape[1])

    primary = J_pinv @ target_velocity
    null_space = identity - J_pinv @ J
    secondary = null_space @ (-gain * avoidance_gradient)

    return primary + secondary

primary hedefe ulaşma görevini gerçekleştirir. secondary ise engel maliyetini azaltmaya çalışır. null_space izdüşümü sayesinde ikincil hareket, ideal matematiksel koşullarda uç efektörün istenen hızını bozmaz.

Potansiyel alan yaklaşımı

Engeller çoğu zaman itici potansiyel alanlarla modellenir. Engel ile robot noktası arasındaki mesafe $d$, etkinin başladığı güvenli mesafe $d_0$ olsun:

Robot engelden uzaktaysa ceza sıfırdır; yaklaştıkça hızla büyür. Bu yöntem sezgiseldir fakat yerel minimumlara takılabilir. Ayrıca yalnızca uç efektörü değil, dirsek ve bağlantılar üzerindeki örnek noktaları da kontrol etmek gerekir.

Sonuç olarak fazladan serbestlik derecesi, robota yalnızca daha fazla hareket değil, aynı hedefe giderken daha iyi hareket seçme özgürlüğü verir. Doğru kontrol algoritmasıyla redundant kol; engellerden kaçınabilir, eklem sınırlarını koruyabilir ve çalışma alanında çok daha güvenli davranabilir.

Operatörler: Programın hesaplama araçları

Operatörler, bir veya daha fazla değer üzerinde işlem yapan sembollerdir. Örneğin + toplama yaparken > iki değeri karşılaştırır. Bir ifadenin sonucu başka bir operatörün girdisi olabilir. Bu nedenle işlem önceliğini anlamak önemlidir.

Örneğin aşağıdaki matematiksel ifade Java’da da aynı öncelik mantığıyla değerlendirilir:

Çarpma önce çalışır. Sonucun 28 olması isteniyorsa parantez kullanılmalıdır: (10 + 4) * 2.

Mod alma operatörü %, özellikle çift-tek kontrolünde kullanışlıdır. Bir $n$ sayısı için $n \bmod 2 = 0$ ise sayı çifttir.

Karar yapıları: Yol ayrımındaki Java

if, else if ve else, koşullara göre farklı kod blokları çalıştırır. Koşulun sonucu mutlaka true veya false olmalıdır.

int puan = 78;

if (puan >= 85) {
    System.out.println("Pekiyi");
} else if (puan >= 50) {
    System.out.println("Geçti");
} else {
    System.out.println("Kaldı");
}

Bu kod, karşılaştırma operatörleriyle puanı sınıflandırır. Koşullar yukarıdan aşağıya sınanır ve ilk doğru bloğun ardından yapı sona erer. Dolayısıyla daha özel veya yüksek eşikli koşulların önce yazılması önemlidir.

Sabit seçeneklerin bulunduğu durumlarda switch daha okunaklı olabilir:

String rol = "editor";

switch (rol) {
    case "admin" -> System.out.println("Tam yetki");
    case "editor" -> System.out.println("İçerik düzenleme yetkisi");
    default -> System.out.println("Sınırlı yetki");
}

Üçlü operatörün biçimi koşul ? doğruDeğer : yanlışDeğer şeklindedir. Örneğin yas >= 18 ? "Yetişkin" : "Çocuk" ifadesi kısa bir karar üretir; ancak iç içe kullanılırsa okunabilirliği hızla düşürür.

Döngüler: Tekrarın kontrollü hâli

Döngüler, aynı işlemi belirli bir koşul sağlandığı sürece tekrarlar. for tekrar sayısı bilindiğinde, while koşul ön planda olduğunda, do-while ise bloğun en az bir kez çalışması gerektiğinde tercih edilir.

int toplam = 0;

for (int i = 1; i <= 5; i++) {
    toplam += i;
}

System.out.println(toplam); // 15

Bu döngü $1+2+3+4+5=15$ toplamını hesaplar. Başlangıç değeri, devam koşulu ve artış işlemi aynı satırda görüldüğü için akış kolayca izlenebilir.

break döngüyü tamamen sonlandırırken continue yalnızca mevcut turu atlar. Bunlar güçlü araçlardır; gereğinden fazla kullanılmaları akışı takip etmeyi zorlaştırabilir.

Kısa devre değerlendirmesi

Mantıksal && operatörü ilk koşul yanlışsa ikinci koşulu çalıştırmaz. || ise ilk koşul doğruysa devamını değerlendirmez:

if (kullanici != null && kullanici.isActive()) {
    System.out.println("Giriş başarılı");
}

Burada önce null kontrolü yapılır. Böylece var olmayan bir nesne üzerinde metot çağrılması ve NullPointerException oluşması engellenir.

Sonuç olarak operatörler veriyi dönüştürür, karar ifadeleri uygun yolu seçer ve döngüler tekrarları yönetir. Sağlam bir Java programında bu üçlü birlikte çalışır: doğru koşul kurulur, akış bilinçli biçimde yönlendirilir ve her tekrarın ne zaman biteceği açıkça tanımlanır.

``

Önce problem uzayını tanıyalım

Yol planlamada robotun bulunabileceği tüm durumlar konfigürasyon uzayı, yani $C$-space ile temsil edilir. İki boyutlu hareket eden noktasal bir robot için durum $(x,y)$ olabilir. Robotun yönü de önemliyse durum $(x,y,\theta)$ hâline gelir. Eklemli bir robot kolunda ise her eklem açısı yeni bir boyut ekler.

Engellerin kapladığı durumlar $C_{obs}$, güvenli durumlar ise $C_{free}$ olarak gösterilir. Amaç, başlangıç $q_{start}$ ile hedef $q_{goal}$ arasında tamamen $C_{free}$ içinde kalan bir yol bulmaktır.

A* çoğunlukla ayrıklaştırılmış grafiklerde çalışır. RRT ise sürekli ve yüksek boyutlu uzayları örnekleyerek grafik oluşturur. Temel ayrım burada başlar.

A*: Maliyeti ve hedefi birlikte düşünmek

A*, incelenecek düğümleri şu puana göre seçer:

Burada $g(n)$ başlangıçtan $n$ düğümüne kadar ödenen gerçek maliyet, $h(n)$ ise hedeften ne kadar uzakta olunduğunu tahmin eden sezgisel fonksiyondur. Izgara haritalarda Öklid uzaklığı $h(n)=\sqrt{(x_g-x_n)^2+(y_g-y_n)^2}$ olarak kullanılabilir.

Eğer $h(n)$ gerçek kalan maliyeti abartmıyorsa A*, en düşük maliyetli yolu bulmayı garanti eder. Ancak büyük veya çok boyutlu haritalarda bellekte tuttuğu açık ve kapalı düğüm kümeleri hızla büyüyebilir.

from heapq import heappush, heappop

def astar(start, goal, neighbors, heuristic):
    queue = [(0, start)]
    cost = {start: 0}
    parent = {start: None}

    while queue:
        _, current = heappop(queue)
        if current == goal:
            return parent

        for nxt, step_cost in neighbors(current):
            new_cost = cost[current] + step_cost
            if nxt not in cost or new_cost < cost[nxt]:
                cost[nxt] = new_cost
                priority = new_cost + heuristic(nxt, goal)
                heappush(queue, (priority, nxt))
                parent[nxt] = current

Bu sade uygulama, komşuları değerlendirerek en umut verici düğümü öncelik kuyruğundan seçer. Dönen parent sözlüğü geriye doğru izlenerek yol oluşturulur.

RRT: Boşluğa rastgele dallar uzatmak

RRT başlangıç durumunu ağacın kökü yapar. Ardından uzaydan rastgele bir $q_{rand}$ noktası seçer, ağaçtaki en yakın $q_{near}$ düğümünü bulur ve ona doğru sınırlı bir adım atarak $q_{new}$ üretir. Bağlantı engelle çakışmıyorsa yeni düğüm ağaca eklenir.

def rrt(start, goal, sample, nearest, steer, collision_free):
    tree = [start]
    parent = {start: None}

    for _ in range(5000):
        random_state = sample(goal)
        near = nearest(tree, random_state)
        new = steer(near, random_state)

        if collision_free(near, new):
            tree.append(new)
            parent[new] = near
            if collision_free(new, goal):
                parent[goal] = new
                return parent

sample(goal) zaman zaman doğrudan hedefi seçerse goal bias uygulanır ve arama hızlanabilir. RRT bir çözümü çabuk bulabilir; fakat bulunan yol genellikle zikzaklıdır ve en kısa yol garantisi yoktur. Bu nedenle sonradan yol yumuşatma yapılır veya asimptotik olarak optimum çözüme yaklaşan RRT* kullanılır.

Hızlı karşılaştırma

Hangisini seçmeli?

Depo robotu gibi iki boyutlu, bilinen bir maliyet haritasında çalışan sistemlerde A* güçlü ve öngörülebilir bir tercihtir. Robot kolu, insansız hava aracı veya karmaşık hareket kısıtları bulunan bir araç söz konusuysa RRT daha doğal olabilir. Pratik sistemler ikisini birleştirebilir: RRT ile uygulanabilir bir koridor bulunup A* veya optimizasyon yöntemleriyle yol iyileştirilebilir. Kısacası A* haritayı dikkatle okuyan bir kâşif, RRT ise hızla farklı yönlere dal uzatan bir öncüdür.

Denetimli öğrenmenin temel mantığı

Denetimli öğrenmede model, giriş ve doğru çıktı çiftlerinden oluşan bir veri kümesiyle eğitilir. Bir kamera görüntüsü $x$, görüntüdeki nesnenin etiketi ise $y$ olsun. Modelin amacı, görüntüyü etikete dönüştüren yaklaşık bir $f_\theta$ fonksiyonu öğrenmektir:

Buradaki $\theta$, sinir ağının eğitim sırasında ayarlanan parametrelerini temsil eder. Model tahmini ile gerçek etiket arasındaki fark bir kayıp fonksiyonuyla ölçülür:

Kısacası model, yaptığı hataları azaltarak öğrenir. Fakat doğru cevapları gösteren $y_i$ etiketleri azsa, hatalıysa veya gerçek çalışma ortamını temsil etmiyorsa robot sağlam bir algı geliştiremez.

Robotikte etiket neden pahalıdır?

İnternetteki kedi fotoğraflarını sınıflandırmak görece kolaydır. Robotik verilerde ise yalnızca “bu bir kutudur” demek yetmeyebilir. Kutunun piksel düzeyindeki sınırı, üç boyutlu konumu, yönelimi, uzaklığı ve tutulabilir bölgeleri de işaretlenebilir. LiDAR nokta bulutları, termal kameralar ve kuvvet sensörleri gibi farklı kaynaklar işi daha da zorlaştırır.

Üstelik fabrikada toplanan veriler, açık havada çalışan bir robotu temsil etmeyebilir. Bu durum dağılım kayması olarak adlandırılır. Eğitim verisi $P_{train}(x)$ ile gerçek ortam $P_{real}(x)$ farklı olduğunda yüksek laboratuvar başarısı sahada hızla düşebilir.

Az etiketin model üzerindeki etkileri

Etiketli veri eksikliği yalnızca doğruluğu azaltmaz. Nadir nesneler yeterince görülmediği için sınıf dengesizliği oluşur. Model arka plan, renk veya ışık gibi yanıltıcı ipuçlarını ezberleyebilir. Yeni bir kamera açısı karşısında şaşırabilir ve belirsiz olduğu durumlarda bile aşırı güvenli tahminler üretebilir. Otonom araç veya cerrahi robot gibi güvenlik kritik sistemlerde bu, basit bir yazılım hatasından çok daha ciddi sonuçlar doğurur.

Darboğazı aşma yöntemleri

Aktif öğrenmede model, en kararsız olduğu görüntüleri insana gönderir. Aşağıdaki basitleştirilmiş örnek, en düşük güvene sahip tahminleri seçer:

def etiketlenecekleri_sec(model, etiketsiz_veri, adet=20):
    # Her örnek için sınıf olasılıklarını hesaplar.
    olasiliklar = model.predict_proba(etiketsiz_veri)

    # En yüksek olasılık düşükse model kararsız kabul edilir.
    guvenler = olasiliklar.max(axis=1)
    indeksler = guvenler.argsort()[:adet]
    return indeksler

Bu yöntem, her görüntüyü etiketlemek yerine öğrenmeye en fazla katkı sağlayacak örneklere odaklanır. Sentetik veriyle birleştiğinde maliyet daha da düşürülebilir. Alan rastgeleleştirme kullanılarak simülasyondaki ışık, doku, kamera açısı ve nesne konumu sürekli değiştirilir; böylece model tek bir yapay görünüme bağlanmaz.

Sonuç

Robotik algılamanın sınırı çoğu zaman model mimarisi değil, verinin kalitesi ve çeşitliliğidir. Daha büyük bir sinir ağı, eksik dünya bilgisini sihirli biçimde tamamlayamaz. Başarılı sistemler; az sayıdaki kaliteli etiketi, bol miktarda etiketsiz veri, simülasyon, aktif öğrenme ve dikkatli saha testleriyle birleştirir. Robotlara görmeyi öğretirken asıl soru “Kaç görüntümüz var?” değil, “Bu görüntüler robotun karşılaşacağı dünyayı ne kadar iyi anlatıyor?” olmalıdır.

Event loop gerçekte ne yapar?

asyncio event loop, çalışmaya hazır görevleri sırayla ilerleten bir koordinatördür. Bir coroutine await ile kontrolü gönüllü biçimde bıraktığında loop başka bir göreve geçebilir. Buradaki kritik nokta şudur: Görev kontrolü bırakmazsa event loop onu zorla kenara çekmez.

Yaklaşık toplam bekleme süresini şöyle düşünebiliriz:

Bu avantaj yalnızca görevler uygun noktalarda kontrolü event loop’a iade ederse geçerlidir. Bloklayan işlemler seri biçimde yürütülürse süre şu modele yaklaşır:

Masum görünen hata

Aşağıdaki örnekte fonksiyon async olsa da içindeki time.sleep bloklayıcıdır:

import asyncio
import time

async def is_yap(no: int):
    print(f'{no} başladı')
    time.sleep(2)  # Event loop burada tamamen durur.
    print(f'{no} bitti')

async def main():
    await asyncio.gather(*(is_yap(i) for i in range(3)))

asyncio.run(main())

Üç görev oluşturulmasına rağmen yaklaşık altı saniye beklenir. Çünkü ilk görev time.sleep(2) çalıştırırken diğer coroutine’ler işlemciye ulaşamaz. Fonksiyon başındaki async ifadesi, içindeki senkron kodu sihirli biçimde asenkronlaştırmaz.

Uyku yalnızca beklemeyi temsil ediyorsa doğru çözüm asyncio.sleep kullanmaktır:

async def is_yap(no: int):
    print(f'{no} başladı')
    await asyncio.sleep(2)  # Kontrol event loop'a geri verilir.
    print(f'{no} bitti')

Bu sürümde görevler birlikte ilerler ve toplam süre yaklaşık iki saniye olur.

Senkron kütüphaneyi çöpe mi atalım?

Her bloklayan kütüphanenin asenkron alternatifi bulunmayabilir. Python 3.9 ve sonrasında asyncio.to_thread, bloklayan I/O işlemini ayrı bir iş parçacığında çalıştırmayı kolaylaştırır:

import asyncio
import time

def eski_raporu_uret():
    time.sleep(3)
    return 'Rapor hazır'

async def main():
    sonuc = await asyncio.to_thread(eski_raporu_uret)
    print(sonuc)

asyncio.run(main())

Burada event loop beklerken donmaz; başka görevleri yürütmeye devam eder. Ancak to_thread özellikle dosya, ağ veya eski SDK çağrıları gibi I/O ağırlıklı işler için uygundur.

CPU ağırlıklı işler farklıdır

Büyük görüntü işleme, asal sayı arama veya karmaşık veri dönüşümü gibi CPU ağırlıklı işler de event loop’u bloke eder. Bunları bir thread’e taşımak, Python’ın GIL davranışı nedeniyle her zaman gerçek paralellik sağlamaz. Böyle durumlarda ProcessPoolExecutor daha doğru seçim olabilir:

import asyncio
from concurrent.futures import ProcessPoolExecutor

def agir_hesaplama(n: int):
    return sum(i * i for i in range(n))

async def main():
    loop = asyncio.get_running_loop()
    with ProcessPoolExecutor() as havuz:
        sonuc = await loop.run_in_executor(
            havuz, agir_hesaplama, 20_000_000
        )
    print(sonuc)

asyncio.run(main())

Kısacası async/await, bloklamayı ortadan kaldıran bir büyü değil, bekleme anlarını yönetme protokolüdür. Kod incelemesinde time.sleep, senkron HTTP istemcileri, ağır dosya işlemleri ve uzun döngüler özellikle aranmalıdır. Event loop’un sağlıklı kalmasının altın kuralı basittir: Ya kontrolü hızla geri verin ya da bloklayan işi uygun bir thread veya process havuzuna taşıyın.

``

Akış Mantığı Nedir?

Bir stream, sıralı biçimde taşınan karakter veya baytların oluşturduğu soyut bir kanaldır. Program çoğu zaman gerçek cihazla doğrudan ilgilenmez; akış nesnesine veri gönderir veya ondan veri ister. std::cin, std::cout, std::cerr ve dosya sınıfları bu yaklaşımın örnekleridir.

Akışların nesne yönelimli yapısı sınıf hiyerarşisine dayanır. std::ios biçimlendirme ve durum bilgisini taşırken std::istream okuma, std::ostream yazma davranışlarını sunar. std::iostream ise ikisini birleştirir. Dosya tarafındaki sınıflar aynı arayüzleri dosya tamponlarıyla ilişkilendirir.

Tamponlama, her küçük işlemde diske erişilmesini engeller. Kabaca toplam maliyet

şeklinde düşünülebilir. Tampon kullanıldığında pahalı G/Ç sayısı olan $k$ azalır. flush işlemi tamponu zorla hedefe aktarır; gereksiz kullanılması performansı düşürebilir.

Nesne Yönelimli Dosya Okuma ve Yazma

Dosya nesneleri kaynak yönetimini RAII yaklaşımıyla gerçekleştirir. Nesne kapsamdan çıktığında dosya otomatik olarak kapatılır. Yine de açılışın başarılı olup olmadığını kontrol etmek gerekir.

#include <fstream>
#include <iostream>
#include <string>

int main() {
    std::ofstream cikti("notlar.txt", std::ios::app);

    if (!cikti) {
        std::cerr << "Dosya açılamadı!\n";
        return 1;
    }

    cikti << "Akışlar nesne yönelimlidir." << '\n';
}

Buradaki std::ios::app, yeni veriyi dosyanın sonuna ekler. Varsayılan davranışta ofstream, mevcut içeriği silebilir. Başlıca kipler şöyledir:

Metin dosyasını satır satır okumak için std::getline güvenli ve anlaşılır bir seçimdir:

std::ifstream girdi("notlar.txt");
std::string satir;

while (std::getline(girdi, satir)) {
    std::cout << satir << '\n';
}

if (girdi.bad()) {
    std::cerr << "Fiziksel bir okuma hatası oluştu.\n";
}

Döngü, okuma başarılı olduğu sürece çalışır. while (!girdi.eof()) yaklaşımı önerilmez; çünkü EOF bayrağı ancak başarısız bir okuma denemesinden sonra etkinleşir.

Durum Bayrakları ve Hata Yönetimi

Akış nesneleri kendi sağlık durumlarını saklar. good() sorun olmadığını, eof() dosya sonunu, fail() biçimsel veya mantıksal başarısızlığı, bad() ise daha ciddi G/Ç hatasını bildirir. Hata sonrasında clear() bayrakları sıfırlar; fakat hatalı karakterler hâlâ tampondaysa ignore() ile temizleme gerekebilir.

int sayi;
if (!(std::cin >> sayi)) {
    std::cin.clear();
    std::cin.ignore(10000, '\n');
    std::cout << "Geçersiz sayı girdiniz.\n";
}

Konumlandırma ve İkili Dosyalar

tellg() ve tellp() mevcut okuma-yazma konumunu verir; seekg() ve seekp() konumu değiştirir. Bu özellik büyük dosyalarda doğrudan belirli bir kayda erişmeyi sağlar. İkili dosyalar read() ve write() ile işlenebilir; ancak sınıfları ham baytlarla kaydetmek taşınabilir değildir. Dolgulama, endian düzeni ve işaretçi üyeleri sorun çıkarabilir. Kalıcı veriler için açık bir serileştirme biçimi tasarlamak daha güvenlidir.

Sonuç olarak C++ akış sistemi yalnızca dosya açıp kapatan bir araç değildir. Ortak arayüzler, durum yönetimi, tamponlama ve RAII sayesinde farklı veri kaynaklarını aynı zihinsel model altında birleştiren güçlü bir soyutlamadır.

Bir C++ API’sinin bir nesneyi kopyalaması mı, yoksa mevcut nesneye erişim sağlaması mı gerektiği küçük bir imza tercihi gibi görünebilir. Oysa bu karar; sahiplikten performansa, hata ayıklamadan eşzamanlılığa kadar bütün tasarımı etkiler. Kısacası Widget ile Widget& arasındaki tek karakterlik fark, bazen bakım maliyetinde destan yazdırır.

``

İki semantiğin temel fikri

Değer semantiğinde değişken, bağımsız bir değeri temsil eder. Kopyalanan iki nesne başlangıçta eşit olabilir; ancak biri değiştirildiğinde diğeri etkilenmez. int, std::string ve std::vector bu modele iyi örneklerdir.

Referans semantiğinde ise farklı değişkenler aynı nesnenin kimliğine erişebilir. Nesne üzerindeki değişiklikler tüm gözlemciler tarafından görülebilir. Burada önemli olan yalnızca içerik değil, nesnenin hangi nesne olduğudur.

Matematiksel olarak değer kopyalamayı şöyle düşünebiliriz:

Ancak sonradan b değiştirildiğinde genellikle:

Referanslarda ise a ve b aynı nesneyi gösteriyorsa durum farklıdır:

Parametrelerde seçimin anlamı

Bir fonksiyon parametresini değerle almak, fonksiyonun kendi bağımsız nesnesine sahip olacağını anlatır:

class Report {
public:
    void addPage(int page);
};

void archive(Report report) {
    report.addPage(42);
    // Çağıranın nesnesi değişmez.
}

Bu yaklaşım özellikle fonksiyon nesneyi saklayacaksa veya dönüştürecekse kullanışlıdır. Çağıran geçici bir değer ya da std::move ile taşıma sağladığında gereksiz kopyalar azaltılabilir.

Salt okuma amaçlı büyük nesnelerde const T&, kopyalama maliyetini önler:

void print(const Report& report) {
    // report okunabilir fakat değiştirilemez.
}

Buradaki const, sahiplik vermez; yalnızca bu erişim yolu üzerinden değişikliği engeller. Fonksiyon referansı saklıyorsa çağıranın nesnesi daha erken yok olabilir. API, bu yaşam süresi sözleşmesini açıkça belirtmelidir.

Değiştirilebilir T& ise fonksiyonun çağıranın nesnesini değiştireceğini bildirir:

void normalize(Report& report) {
    report.addPage(1);
}

Böyle bir API etkili olsa da yan etki üretir. Sonuç döndüren değer tabanlı bir alternatif çoğu zaman daha anlaşılırdır:

Report normalized(Report report) {
    report.addPage(1);
    return report;
}

Modern C++’ta taşıma semantiği ve kopya eleme sayesinde bu sürüm, göründüğünden daha ucuz olabilir. Yaklaşık maliyeti $C_{copy}$ yerine çoğu durumda $C_{move}$ veya doğrudan $0$ olur.

Dönüş değerleri ve sahiplik

Yeni bir nesne üreten fonksiyonun T döndürmesi genellikle en güvenli seçenektir. T& döndürmek ise var olan bir nesneye takma ad verir; nesnenin yaşam süresi çağıranın kullanımından uzun olmalıdır. Yerel değişkene referans döndürmek kesinlikle hatalıdır.

Paylaşılan kimlik gerçekten gerekliyse akıllı işaretçiler sözleşmeyi görünür kılar:

• std::unique_ptr<T>: Tekil sahiplik aktarılır.
• std::shared_ptr<T>: Sahiplik paylaşılır.
• std::weak_ptr<T>: Sahip olmadan gözlem yapılır.
• T* veya T&: Genellikle sahip olunmayan erişim sunulur.

Pratik karar rehberi

Para, koordinat, tarih ve yapılandırma gibi bağımsız kavramlarda değer semantiğini tercih edin. Veritabanı bağlantısı, pencere, cihaz, aktör veya polimorfik servis gibi kimliği önemli varlıklarda referans semantiği daha doğaldır.

API’nin davranışını şu sorularla sınayın: Nesne kopyalanınca anlam bozuluyor mu? Fonksiyon sahipliği devralıyor mu? Değişiklik çağırana yansımalı mı? Referansın geçerlilik süresi açık mı? Eşzamanlı erişim mümkün mü?

En iyi seçim her zaman en hızlı görünen seçenek değildir. İyi bir C++ API’si, sahiplik ve değişebilirlik niyetini tür sistemi üzerinden anlatır. Değer semantiği varsayılan güvenli liman; referans semantiği ise kimlik, paylaşım veya polimorfizm gerçekten gerektiğinde kullanılan güçlü ama dikkat isteyen araçtır.

``

Fonksiyonun anatomisi

Bir C fonksiyonu dönüş türü, ad, parametre listesi ve gövdeden oluşur. Fonksiyon kullanılmadan önce derleyicinin onun imzasını bilmesi gerekir. Bu nedenle prototipler çoğunlukla dosyanın üst bölümünde veya bir başlık dosyasında bulunur.

#include <stdio.h>

int maksimum(int a, int b);  // Fonksiyon prototipi

int main(void) {
    int sonuc = maksimum(12, 7);
    printf("Büyük değer: %d\n", sonuc);
    return 0;
}

int maksimum(int a, int b) {
    return (a > b) ? a : b;
}

Burada a ve b birer parametre, çağrıdaki 12 ve 7 ise argümandır. int dönüş türü, fonksiyonun çağırana bir tam sayı göndereceğini belirtir. Değer döndürmeyen fonksiyonlarda void kullanılır.

C’de argüman aktarımı

C, argümanları varsayılan olarak değer ile aktarır. Yani fonksiyon, özgün değişkenin kendisini değil kopyasını alır. Matematiksel olarak bunu $p = x$ biçiminde düşünebiliriz: p başlangıçta x ile aynı değere sahiptir, ancak ayrı bir saklama alanıdır.

void arttir(int sayi) {
    sayi++;
}

Bu fonksiyon çağıranın değişkenini değiştirmez. Kalıcı değişiklik için değişkenin adresi, yani bir işaretçi aktarılır:

void arttir(int *sayi) {
    (*sayi)++;
}

int main(void) {
    int puan = 10;
    arttir(&puan);  // puan artık 11
    return 0;
}

&puan değişkenin adresini verir; *sayi ise o adresteki değere erişir. Diziler fonksiyonlara gönderildiğinde ilk elemanlarının adresine dönüştükleri için yapılan değişiklikler özgün dizi üzerinde görülebilir.

İşaretçiler güçlüdür; fakat NULL adresler ve geçersiz bellek erişimleri kontrol edilmezse programı beklenmedik bir maceraya çıkarabilir.

Özyineleme: Fonksiyonun kendisini çağırması

Özyinelemeli bir fonksiyon problemi daha küçük bir örneğine dönüştürerek kendisini çağırır. Her özyinelemede iki parça zorunludur: çağrıları durduran taban durum ve problemi küçülten özyinelemeli adım.

Faktöriyel matematiksel olarak şöyle tanımlanır:

unsigned long long faktoriyel(unsigned int n) {
    if (n == 0) {              // Taban durum
        return 1;
    }
    return n * faktoriyel(n - 1); // Daha küçük problem
}

faktoriyel(4) çağrısı, $4 \times 3 \times 2 \times 1$ sonucunu üretir. Her çağrı dönüş adresi ve yerel değişkenleriyle çağrı yığınına eklenir. Taban durum unutulursa çağrılar sürer ve sonunda stack overflow oluşabilir.

Bu örneğin zaman karmaşıklığı $T(n)=T(n-1)+O(1)$ olduğundan $O(n)$, çağrı yığını kullanımı da $O(n)$ olur. Döngülü sürüm aynı zaman karmaşıklığıyla genellikle $O(1)$ ek bellek tüketir. Buna karşılık ağaç dolaşma, böl-ve-yönet ve iç içe geçmiş yapılar özyineleme ile daha doğal ifade edilebilir.

Fonksiyon tasarlarken tek sorumluluk ilkesini benimsemek, açıklayıcı adlar seçmek ve gereksiz küresel değişkenlerden kaçınmak önemlidir. Kısacası fonksiyonlar yalnızca kod tekrarını azaltmaz; programın düşünce haritasını da oluşturur. İyi bölünmüş bir C programı, hem derleyicinin hem de gelecekteki sizin teşekkür edeceği bir programdır.

``

Generic yapı nedir?

Generic yapı; sınıf, metot, arayüz veya temsilcinin çalışacağı veri türünü baştan sabitlemek yerine bir tür parametresiyle tanımlamaktır. En yaygın gösterim olan T, İngilizce type kelimesinden gelir; ancak zorunlu bir isim değildir.

public class Kutu<T>
{
    public T Deger { get; set; }

    public Kutu(T deger)
    {
        Deger = deger;
    }
}

var sayiKutusu = new Kutu<int>(42);
var metinKutusu = new Kutu<string>("Merhaba");

Burada aynı Kutu<T> sınıfı hem int hem de string ile kullanılabilir. Buna rağmen iki kutunun kuralları birbirinden ayrıdır. Örneğin sayiKutusu.Deger özelliğine metin atanması derleme aşamasında engellenir.

Eski yaklaşım ve tür güvenliği

Generic koleksiyonlardan önce farklı türleri saklamak için sıklıkla ArrayList kullanılırdı. Bu koleksiyon elemanları object olarak tuttuğu için hemen her şeyi kabul eder.

using System.Collections;

var liste = new ArrayList();
liste.Add(10);
liste.Add("yirmi");

int toplam = (int)liste[0] + (int)liste[1]; // Çalışma zamanı hatası

Kod derlenir; fakat ikinci eleman int olmadığı için InvalidCastException oluşur. List<int> kullanıldığında yanlış değer daha program çalışmadan yakalanır:

var sayilar = new List<int>();
sayilar.Add(10);
// sayilar.Add("yirmi"); // Derleme hatası

int toplam = sayilar[0]; // Dönüşüm gerekmiyor

Performans neden artar?

int, double ve bool gibi değer türleri doğrudan değer taşır. Bunların object değişkenine yerleştirilmesine boxing, yeniden özgün türe çevrilmesine unboxing denir. Her boxing işlemi yönetilen bellekte ek bir nesne oluşturabilir ve dönüşüm maliyeti doğurabilir.

Basitleştirilmiş biçimde, $n$ elemanın boxing maliyeti $b$, unboxing maliyeti $u$ ise ek işlem yükü şöyle düşünülebilir:

Generic bir List<int> için bu dönüşümlerin çoğu ortadan kalktığından yaklaşık ek yük:

Gerçek performans donanıma, .NET sürümüne ve kullanım şekline bağlıdır; dolayısıyla bu eşitlik bir ölçüm değil, maliyet farkını anlatan zihinsel modeldir.

Generic metotlar ve kısıtlar

Generics yalnızca koleksiyonlara özgü değildir. Metotlar da tür parametresi alabilir:

static T IlkElemaniGetir<T>(IEnumerable<T> kaynak)
{
    return kaynak.First();
}

int ilkSayi = IlkElemaniGetir(new[] { 7, 8, 9 });
string ilkAd = IlkElemaniGetir(new[] { "Ada", "Linus" });

Bazen T tamamen serbest bırakılmamalıdır. where kısıtları, kabul edilen türlerin sahip olması gereken özellikleri belirtir:

static T YeniOlustur<T>() where T : class, new()
{
    return new T();
}

Bu metot yalnızca referans türleriyle çalışır ve parametresiz kurucu ister. Yaygın kısıtlar arasında class, struct, notnull, new() ve belirli bir arayüz bulunur.

Hangi koleksiyon seçilmeli?

Generics; tekrar kullanılabilirliği, tür güvenliğini ve okunabilirliği aynı yapıda buluşturur. En önemli kazanç yalnızca hız değildir: Hataları kullanıcıya ulaşmadan derleyicide durdurmaktır. Kısacası T, küçük bir harf olsa da C# dünyasında oldukça büyük bir güvenlik görevlisidir.