``

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.

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.

``

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.

İstisna nedir?

İstisna, programın normal çalışma akışını bozan bir olaydır. Java’da istisnalar nesne olarak temsil edilir ve temel olarak Throwable sınıfından türetilir. Bir sorun oluştuğunda istisna “fırlatılır”; uygun bir yönetici bulunduğunda ise “yakalanır”.

Bu davranışı basitçe şöyle düşünebiliriz:

Java’daki hata hiyerarşisinin iki önemli kolu vardır:

try ve catch nasıl çalışır?

Risk oluşturabilecek kod try bloğuna yazılır. Bir istisna meydana gelirse Java, ilgili türü karşılayan catch bloğunu arar. Böylece uygulama tamamen sonlanmak yerine alternatif bir davranış gösterebilir.

public class BolmeOrnegi {
    public static void main(String[] args) {
        int bolunen = 24;
        int bolen = 0;

        try {
            int sonuc = bolunen / bolen;
            System.out.println("Sonuç: " + sonuc);
        } catch (ArithmeticException e) {
            System.out.println("Bir sayı sıfıra bölünemez.");
            System.out.println("Teknik ayrıntı: " + e.getMessage());
        }

        System.out.println("Program çalışmaya devam ediyor.");
    }
}

Burada sıfıra bölme işlemi ArithmeticException üretir. catch bloğu hatayı yakalar, kullanıcıya anlaşılır bir mesaj verir ve programın sonraki satırlara devam etmesini sağlar.

Birden fazla hata türü için birden fazla catch kullanılabilir. Ancak özel istisnalar önce, daha genel olanlar sonra yazılmalıdır. Aksi hâlde genel blok diğerlerini erişilemez yapabilir.

finally neden kullanılır?

finally bloğu, istisna oluşsa da oluşmasa da çalıştırılması gereken işlemler içindir. Dosya kapatmak, bağlantıyı sonlandırmak veya geçici kaynakları temizlemek klasik kullanım örnekleridir.

try {
    System.out.println("Veritabanı işlemi başlatıldı.");
    // Riskli sorgular burada çalıştırılır.
} catch (RuntimeException e) {
    System.out.println("İşlem başarısız: " + e.getMessage());
} finally {
    System.out.println("Bağlantı ve kaynaklar temizleniyor.");
}

Modern Java’da dosya ve benzeri AutoCloseable kaynaklar için try-with-resources daha güvenlidir:

try (var okuyucu = new java.io.BufferedReader(
        new java.io.FileReader("veriler.txt"))) {
    System.out.println(okuyucu.readLine());
} catch (java.io.IOException e) {
    System.out.println("Dosya okunamadı: " + e.getMessage());
}

Bu yapı, okuyucuyu otomatik kapatır ve unutulan kaynaklar yüzünden oluşabilecek sızıntıları azaltır.

Sağlam istisna yönetimi için ipuçları

• Boş bir catch bloğu kullanarak hatayı sessizce yutmayın.
• Kullanıcıya anlaşılır, geliştiriciye ayrıntılı günlük mesajları sağlayın.
• Yalnızca gerçekten yönetebileceğiniz istisnaları yakalayın.
• Exception gibi aşırı genel türleri gereksiz yere kullanmayın.
• İstisnaları normal karar mekanizması yerine koymayın.

İyi tasarlanmış istisna yönetimi, uygulamanın hiç hata vermemesi anlamına gelmez. Asıl başarı; hata geldiğinde paniklemeyen, kaynaklarını temizleyen, kullanıcıyı bilgilendiren ve mümkünse güvenli biçimde yoluna devam eden bir sistem kurmaktır.

Python öğrenirken is ve == bazen aynı sonucu veriyormuş gibi görünür. Özellikle küçük tam sayılarla yapılan denemelerde iki operatörün de True döndürmesi, aralarında gerçek bir fark olmadığı yanılgısını doğurabilir. Oysa biri değerleri, diğeri nesnelerin kimliğini karşılaştırır; küçük tam sayı önbelleklemesi ise bu farkı geçici olarak gizleyen küçük bir illüzyondur.

``

Eşitlik ve kimlik aynı şey değildir

== operatörü iki nesnenin değer bakımından eşit olup olmadığını denetler. Bu işlem çoğunlukla nesnenin __eq__ metodu üzerinden gerçekleştirilir. is ise iki değişkenin bellekteki aynı nesneye referans verip vermediğine bakar ve özelleştirilemez.

Tam sayılar açısından ilişkiyi kabaca şöyle gösterebiliriz:

Ancak ters yön garanti değildir:

Yani aynı değere sahip iki farklı nesne bulunabilir. İki ayrı kâğıda 1000 yazılması, kâğıtları aynı kâğıt yapmaz.

Küçük tam sayı önbelleği

Yaygın Python uygulaması CPython, sık kullanılan küçük tam sayı nesnelerini tekrar tekrar üretmemek için önceden hazır tutar. Tipik olarak $-5$ ile $256$ arasındaki tam sayılar önbelleğe alınır. Bu sınırlar CPython uygulama ayrıntısıdır; dil tarafından bütün Python uygulamaları için garanti edilmez.

a = 100
b = 100

print(a == b)  # True: değerler eşit
print(a is b)  # CPython'da çoğunlukla True: aynı önbellek nesnesi

Burada is sonucunun True olması, sayısal karşılaştırma için doğru operatörü kullandığımız anlamına gelmez. Yalnızca a ve b, CPython tarafından paylaşılmış aynı 100 nesnesine bağlanmıştır.

Daha büyük değerlerde maske düşebilir:

a = int("1000")
b = int("1000")

print(a == b)  # True
print(a is b)  # Genellikle False
print(id(a), id(b))

int çağrıları çalışma anında eşit değerli fakat ayrı nesneler oluşturabilir. id() çıktılarının farklı olması, değişkenlerin aynı nesneyi göstermediğini açıklar.

Neden bazı testler yine şaşırtır?

Aynı kod bloğunda yazılan sabitler, derleyici optimizasyonları nedeniyle paylaşılabilir. Metinlerde interning, sabit katlama ve etkileşimli kabuğun çalışma biçimi de sonuçları etkileyebilir. Bu nedenle 257 is 257 benzeri deneyler farklı Python sürümlerinde, REPL’de veya bir dosya içinde farklı davranabilir. Ayrıca modern Python sürümleri, bir literal ile is kullanılınca SyntaxWarning gösterebilir.

Güvenli kullanım kuralı

Sayıları, metinleri ve koleksiyon içeriklerini karşılaştırırken == kullanın. is operatörünü başta None olmak üzere kimliği özellikle önemli olan tekil nesnelere ayırın:

def kullaniciyi_bul(kimlik):
    kullanici = veritabaninda_ara(kimlik)

    if kullanici is None:
        return "Kullanıcı bulunamadı"

    if kullanici.yas == 18:
        return "Kullanıcı tam 18 yaşında"

    return "Kullanıcı bulundu"

İlk koşul özel None nesnesinin kimliğini, ikinci koşul ise sayısal değeri denetler. Kısacası önbelleğe güvenerek yazılan is karşılaştırması tesadüfen çalışabilir; doğru semantiğe dayanan == ise niyetinizi açık, taşınabilir ve güvenilir biçimde ifade eder.