``

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.

``

Iterator neden geçersiz olur?

Iterator, çoğu zaman bir elemana ulaşmayı sağlayan adres benzeri bir nesnedir. Bir eleman silindiğinde konteyner, belleğini yeniden düzenleyebilir. Iterator artık yaşayan bir elemana işaret etmiyorsa onu karşılaştırmak, artırmak veya dereference etmek güvenli değildir.

Örneğin vector, elemanlarını ardışık bellekte tutar. İndisi $i$ olan eleman silindiğinde arkasındaki yaklaşık

eleman sola taşınır. Böylece silinen elemanı ve sonrasını gösteren iterator’lar geçersizleşir. İşlemin zaman karmaşıklığı da bu taşıma nedeniyle genel olarak $O(n)$ olur.

std::vector<int> sayilar{1, 2, 3, 4, 5};
auto it = sayilar.begin() + 2; // 3

sayilar.erase(it);
// it artık geçersizdir!
// std::cout << *it; // Tanımsız davranış

Buradaki yaygın yanılgı, it değişkeninin otomatik olarak sıradaki elemana geçeceğini düşünmektir. Oysa erase, eski iterator’ı onarmaz; bunun yerine geçerli olan sonraki iterator’ı döndürür.

Güvenli silme deseni

Dolaşma sırasında silme yapılacaksa erase dönüş değeri kullanılmalıdır:

std::vector<int> sayilar{1, 2, 3, 4, 5, 6};

for (auto it = sayilar.begin(); it != sayilar.end(); ) {
    if (*it % 2 == 0) {
        it = sayilar.erase(it); // Sonraki geçerli konumu al
    } else {
        ++it;                   // Yalnızca silinmediyse ilerle
    }
}

Döngünün üçüncü bölümü özellikle boş bırakılmıştır. Hem erase sonrasında hem de döngü sonunda ++it çalıştırılsaydı bir eleman atlanabilirdi.

Konteynerlere göre kurallar

list düğüm tabanlı olduğu için bir düğümün çıkarılması diğer düğümlerin adreslerini değiştirmez. map ve set gibi ağaç tabanlı yapılarda da benzer bir güvence vardır. Buna rağmen silinen iterator’ın kendisini kullanmak her durumda hatadır.

deque daha dikkatli ele alınmalıdır: Baştan veya sondan silmenin kuralları daha sınırlı etkiler doğurabilirken ortadan silme, iterator’ları geniş ölçüde geçersizleştirir. Kodun taşınabilir ve anlaşılır olması için daima erase dönüş değerini kullanmak en güvenli yaklaşımdır.

Modern C++ ile erase_if

Amaç yalnızca koşula uyan elemanları temizlemekse C++20, iterator yönetimini gizleyen daha okunaklı bir araç sunar:

#include <algorithm>
#include <vector>

std::vector<int> sayilar{1, 2, 3, 4, 5, 6};

std::erase_if(sayilar, [](int deger) {
    return deger % 2 == 0;
});

Eski standartlarda vector için erase-remove deyimi kullanılır:

sayilar.erase(
    std::remove_if(sayilar.begin(), sayilar.end(),
                   [](int x) { return x % 2 == 0; }),
    sayilar.end()
);

remove_if fiziksel silme yapmaz; korunacak elemanları öne taşır ve mantıksal yeni sonu döndürür. Asıl küçültmeyi erase gerçekleştirir.

Kısa kural şudur: Bir silme işleminden sonra eski iterator’ın hâlâ geçerli olduğunu varsayma. Konteynerin geçersizleştirme kurallarını kontrol et, mümkünse erase tarafından döndürülen iterator’ı kullan ve toplu koşullu silmelerde std::erase_if tercih et. Böylece iterator’ların hayaletlere dönüşmesini engellersin.

Tür çıkarımı ile örnekleme aynı şey değildir

Bir fonksiyon şablonu çağrıldığında süreç kabaca üç aşamadan geçer:

1. Tür çıkarımı: Şablon parametreleri, fonksiyon argümanlarından belirlenir.
2. Yerine koyma: Çıkarılan türler bildirimdeki ilgili konumlara yazılır.
3. Örnekleme: Gerekli fonksiyon veya sınıf gövdesi gerçek türlerle üretilir.

Bunu basitleştirilmiş biçimde şöyle gösterebiliriz:

Sorun, hatanın hangi aşamada oluştuğuna bağlıdır. Yerine koyma sırasında oluşan bazı hatalar SFINAE veya constraint mekanizmasıyla adayın elenmesini sağlar. Şablon gövdesinin örneklenmesi sırasında oluşan hata ise çoğunlukla doğrudan derleme hatasıdır.

auto dönüş türünün hazırladığı sürpriz

Aşağıdaki kod, bir türün foo() fonksiyonuna sahip olup olmadığını kontrol ediyor gibi görünür:

#include <concepts>

template<class T>
auto probe(T value) {
    return value.foo();
}

template<class T>
concept HasFoo = requires(T value) {
    probe(value);
};

static_assert(!HasFoo<int>);

Fakat probe<int> fonksiyonunun dönüş türünü bulabilmek için derleyici gövdeyi örneklemek zorundadır. int üzerinde foo() bulunmadığından hata, güvenli bir constraint başarısızlığı yerine fonksiyon gövdesinde patlayabilir. Derleyici adeta “Sadece bakacaktım, bütün evi inşa ettim” der.

Kontrol edilmesini istediğimiz ifadeyi dönüş türüne taşıyarak hatayı uygun bağlama alabiliriz:

template<class T>
auto probe(T value) -> decltype(value.foo()) {
    return value.foo();
}

template<class T>
concept HasFoo = requires(T value) {
    probe(value);
};

Artık decltype(value.foo()), fonksiyon bildirimindeki immediate context içinde değerlendirilir. İfade geçersizse aday kullanılabilir sayılmaz; gereksiz gövde örneklemesi yapılmaz.

Tembel olmayan tür seçimi

std::conditional_t de sık rastlanan bir tuzaktır. Koşul yalnızca bir dalı seçse bile iki tür argümanının da önce geçerli olması gerekir:

#include <type_traits>

template<class T>
using ValueOrSelf = std::conditional_t<
    requires { typename T::value_type; },
    typename T::value_type,
    T
>;

// ValueOrSelf<int> x; // int::value_type geçersizdir

Burada koşul false olsa bile typename T::value_type oluşturulmaya çalışılır. Çözüm, seçimi uzmanlaşmalarla tembel hâle getirmektir:

template<class T, class = void>
struct value_or_self {
    using type = T;
};

template<class T>
struct value_or_self<T, std::void_t<typename T::value_type>> {
    using type = typename T::value_type;
};

template<class T>
using value_or_self_t = typename value_or_self<T>::type;

Hataları kontrol altında tutmak

Şablon kodunda şu alışkanlıklar hata mesajlarını ciddi ölçüde iyileştirir:

• Gereksinimleri fonksiyon gövdesi yerine requires, concept veya decltype ile bildirimde ifade edin.
• Seçilmeyecek kodu if constexpr içinde tutun.
• Tür seçiminin gerçekten tembel olup olmadığını sorgulayın.
• Şablonları yalnızca geçerli türlerle değil, özellikle geçersiz türlerle de test edin.
• Derleyicinin hata izinde ilk kullanıcı kodunu bulun; standart kütüphane satırlarında kaybolmayın.

Kısacası tür çıkarımı yalnızca doğru anahtarı bulur; instantiation ise kapının arkasındaki odanın gerçekten var olup olmadığını kontrol eder. Sağlam template tasarımı, bu kontrolü mümkün olduğunca erken ve kontrollü yapmaktır.

``

Nesne neden “yarım” kalır?

Bir nesnenin yaşam süresi, kurucusu başarıyla tamamlandığında başlar. Kurucu istisna ile sonlanırsa dışarıdan kullanılabilecek geçerli bir nesne yoktur. Dolayısıyla aşağıdaki yıkıcı çalıştırılmaz:

class RiskliTampon {
    int* veri_;

public:
    explicit RiskliTampon(std::size_t adet)
        : veri_(new int[adet]) {
        if (adet > 1000) {
            throw std::runtime_error("Tampon çok büyük");
        }
    }

    ~RiskliTampon() {
        delete[] veri_;
    }
};

new int[adet] başarılı olduktan sonra istisna fırlatılırsa ~RiskliTampon() çağrılmaz. Sonuç olarak veri_ tarafından gösterilen dizi serbest bırakılamaz. Ham işaretçi üyesinin yok edilmesi yalnızca işaretçi değerini ortadan kaldırır; gösterdiği belleğe delete[] uygulamaz.

Basit bir risk modeli şu şekilde düşünülebilir:

Burada $P(E)$ kurucunun kaynak edinildikten sonra istisna fırlatma olasılığı, $K$ ise temizlenmeden kalan kaynağın maliyetidir. Dosya tanıtıcısı veya mutex gibi sınırlı kaynaklarda $K$, birkaç baytlık bellekten çok daha yüksek olabilir.

Hangi parçalar otomatik temizlenir?

C++ önemli bir güvence sağlar: Kurucu başarısız olduğunda, yapımı başarıyla tamamlanmış taban sınıflar ve üye nesneler ters sırada yok edilir. Henüz kurulmamış üyeler içinse yıkıcı çağrılmaz.

İşte RAII’nin özü budur: Kaynağın ömrünü bir nesnenin ömrüne bağlamak. “Resource Acquisition Is Initialization” adı biraz uzun, yaptığı iş ise oldukça pratiktir: Temizlik kodunu unutulamaz hâle getirir.

Güvenli çözüm: Kaynakları üyelere emanet etmek

Riskli sınıf std::vector kullanılarak şöyle düzeltilebilir:

class GuvenliTampon {
    std::vector<int> veri_;
    std::ofstream gunluk_;

public:
    explicit GuvenliTampon(std::size_t adet)
        : veri_(adet), gunluk_("tampon.log") {
        if (!gunluk_) {
            throw std::runtime_error("Günlük açılamadı");
        }

        if (adet > 1000) {
            throw std::runtime_error("Tampon çok büyük");
        }
    }
};

İstisna ikinci kontrolda fırlatılsa bile gunluk_ dosyayı kapatır, ardından veri_ belleğini bırakır. Sınıfa özel bir yıkıcı yazmak bile gerekmez. Bu yaklaşım aynı zamanda Rule of Zero ilkesine uyar: Kaynak yöneten standart sınıfları kullan, kopyalama, taşıma ve yıkım ayrıntılarını derleyiciye bırak.

Dinamik ve tekil bir nesne gerekiyorsa std::unique_ptr tercih edilebilir:

class MotorYoneticisi {
    std::unique_ptr<Motor> motor_;

public:
    MotorYoneticisi()
        : motor_(std::make_unique<Motor>()) {
        ayarlariYukle(); // Fırlatsa bile Motor yok edilir.
    }
};

Kurucu gövdesindeki try/catch ile elle temizlik yapmak mümkündür; ancak birden fazla çıkış yolu olduğunda kırılgandır. Kurucuya ait function-try-block da genellikle istisnayı kaydetmek veya başka türe çevirmek içindir; RAII’nin yerini almamalıdır.

Pratik kural nettir: Kurucuda new, fopen, lock veya benzeri çıplak kaynak edinimleri görüyorsanız alarm zilleri çalsın. Kaynağı hemen std::vector, std::unique_ptr, dosya akışı ya da kilit koruyucusu gibi bir RAII nesnesine teslim edin. Böylece nesne yarım kalsa bile temizlik tam olur.

``

Problemi Bir Örnekle Görelim

Aşağıdaki programda hem temel hem de türetilmiş sınıf aynı sanal fonksiyon için farklı varsayılan değerler tanımlıyor:

#include <iostream>

class Base {
public:
    virtual void yazdir(int adet = 1) const {
        std::cout << "Base: " << adet << '\n';
    }

    virtual ~Base() = default;
};

class Derived : public Base {
public:
    void yazdir(int adet = 5) const override {
        std::cout << "Derived: " << adet << '\n';
    }
};

int main() {
    Derived nesne;
    Base* ptr = &nesne;

    ptr->yazdir();
}

Pek çok geliştirici çıktının Derived: 5 olmasını bekler. Gerçek çıktı ise şöyledir:

Derived: 1

Burada Derived::yazdir çalıştırılmış, fakat Base::yazdir bildirimindeki 1 değeri kullanılmıştır. C++ bize adeta “Fonksiyonu dinamik, parametreyi statik seçtim!” demektedir.

Statik ve Dinamik Bağlama

Sanal fonksiyonun hangi gövdesinin çalışacağı, nesnenin gerçek çalışma zamanı türüne göre belirlenir. ptr, Base* türünde olmasına rağmen bir Derived nesnesini gösterdiği için sanal çağrı Derived::yazdir fonksiyonuna yönlendirilir.

Varsayılan parametreler ise polimorfik değildir. Derleyici, eksik argümanı çağrı noktasında ve ifadenin statik türüne bakarak doğrudan ekler. Kavramsal olarak şu dönüşüm yapılır:

ptr->yazdir();

// Derleyicinin çağrı noktasındaki yaklaşımı:
ptr->yazdir(1);

Ardından sanal çağrı mekanizması hangi fonksiyon gövdesinin çalışacağını seçer. Süreci basitçe şöyle ifade edebiliriz:

Aynı nesneyi doğrudan çağırırsak sonuç değişir:

nesne.yazdir(); // Derived::yazdir(5)
ptr->yazdir();  // Derived::yazdir(1)

Çünkü ilk ifadenin statik türü Derived, ikincisininki Base* üzerinden Base sınıfıdır.

Neden Böyle Tasarlanmıştır?

Varsayılan argüman, fonksiyonun çalışma zamanı davranışının değil, bildirimin sunduğu arayüzün parçasıdır. Derleyici çağrı noktasını işlerken nesnenin gelecekte hangi gerçek türe sahip olacağını bilmek zorunda değildir. Ayrıca varsayılan değerlerin sanal tabloya eklenmesi daha karmaşık bir çağrı modeli ve ek çalışma zamanı maliyeti oluştururdu.

Güvenli Tasarım Yaklaşımı

En temiz çözüm, varsayılan değeri yalnızca sanal olmayan bir arayüz fonksiyonunda tutmaktır:

class Base {
public:
    void yazdir(int adet = 1) const {
        yazdirImpl(adet);
    }

    virtual ~Base() = default;

private:
    virtual void yazdirImpl(int adet) const {
        std::cout << "Base: " << adet << '\n';
    }
};

class Derived : public Base {
private:
    void yazdirImpl(int adet) const override {
        std::cout << "Derived: " << adet << '\n';
    }
};

Bu yaklaşımda varsayılan değer tek yerde tanımlanır, sanal uygulama ise yalnızca davranışı değiştirir. Böylece işaretçinin statik türüne bağlı sürprizler ortadan kalkar. Kısa kural şudur: Sanal fonksiyonlarda farklı varsayılan parametreler tanımlamayın; varsayılan seçimini arayüze, polimorfik davranışı ayrı bir sanal fonksiyona bırakın.

``

Üç aracın temel zihinsel modeli

Bu araçların hepsi standart girdiyi okuyabilir ve boru hatlarında kullanılabilir; ancak metne farklı gözlüklerle bakarlar.

• grep, satırların belirli bir desene uyup uymadığıyla ilgilenir.
• sed, metni satır satır dönüştüren bir akış düzenleyicisidir.
• awk, kayıtları alanlara ayırıp koşul, değişken ve aritmetik kullanabilen küçük bir programlama dilidir.

Bir dosyada $n$ satır, her satırda ortalama $m$ karakter varsa basit tarama maliyeti kabaca $O(nm)$ olur. Araç seçiminin asıl farkı çoğunlukla teorik karmaşıklık değil, aynı işi ifade etmek için gereken zihinsel ve sözdizimsel karmaşıklıktır.

grep ile tornavida kullanmak

grep yalnızca eşleşen satırları seçmek için mükemmeldir:

grep -i "error" app.log

Bu komut, büyük-küçük harfi önemsemeden error içeren satırları getirir. Fakat ikinci sütundaki değerleri toplamak istiyorsak grep, görevi tek başına doğal biçimde ifade edemez. Karmaşık grep, cut, paste ve bc zincirleri kurulabilir; ancak bu, market alışverişine forkliftle gitmeye benzer.

Doğal çözüm awk kullanmaktır:

awk '{ toplam += $2 } END { print toplam }' satis.txt

Burada her satır bir kayıt, boşluklarla ayrılmış parçalar ise alan kabul edilir. $2 ikinci alanı, END ise bütün kayıtlar işlendikten sonraki aşamayı temsil eder.

sed ile muhasebe yapmaya çalışmak

sed, değiştirme işlemlerinde parlar:

sed 's/http:/https:/g' adresler.txt

Komut, her satırdaki tüm http: ifadelerini https: ile değiştirir. Buna karşılık sayısal karşılaştırma, toplam veya ortalama gerektiğinde sed komutları hızla anlaşılmaz hâle gelir.

Örneğin üçüncü sütunu 100’den büyük kayıtları seçmek için doğru yaklaşım şudur:

awk '$3 > 100 { print $1, $3 }' veriler.txt

Ortalama hesaplamak da doğrudandır. Değerlerin toplamı $S$, kayıt sayısı $N$ ise ortalama

olur:

awk '{ s += $3; n++ } END { if (n) print s / n }' veriler.txt

awk ile basit aramayı büyütmek

awk '/hata/' app.log geçerli bir komuttur; fakat yalnızca eşleşen satırları istiyorsak niyetimizi grep 'hata' app.log daha açık anlatır. awk, alan seçimi veya ek mantık devreye girdiğinde anlam kazanır:

awk '$2 == "ERROR" && $4 >= 500 { print $1, $4 }' app.log

Bu örnek hem alan karşılaştırır hem sayısal koşul uygular. Yani awk burada gerçekten maaşını hak eder.

Araçlar rakip değil, ekip arkadaşıdır

Tek bir komuta bütün işi yüklemek zorunda değiliz. Önce ilgili satırları filtreleyip sonra metni dönüştürebiliriz:

grep '^WARN' app.log | sed 's/^WARN/UYARI/'

Yine de gereksiz süreçlerden kaçınmak gerekir. Aynı işlem tek ve anlaşılır bir awk programıyla yapılabiliyorsa uzun boru hattı kurmak hata ayıklamayı zorlaştırabilir.

Pratik karar kuralı basittir: Buluyorsan grep, değiştiriyorsan sed, alanlar üzerinde düşünüyor veya hesaplıyorsan awk. Görev büyüdükçe kabuk komutlarını zorlamak yerine Python gibi genel amaçlı bir dile geçmek de yenilgi değil, doğru mühendislik kararıdır.