``

Fonksiyon aşırı yükleme nedir?

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

#include <iostream>
#include <string>

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

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

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

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

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

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

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

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

Neler overload oluşturur?

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

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

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

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

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

Belirsizlik tuzağı

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

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

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

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

Ne zaman kullanmalıyız?

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

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

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

``

Önce terminolojiyi netleştirelim

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

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

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

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

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

#include <string>
#include <utility>

class Profile {
    std::string name;

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

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

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

Temel garanti: Dağınık ama hayatta

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

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

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

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

Zayıf veya garantisiz kod: Sürpriz kutusu

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

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

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

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

Hangi seviyeyi seçmeliyiz?

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

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

İstisna yönetiminin temel mantığı

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

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

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

Temel try, throw ve catch kullanımı

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

#include <iostream>
#include <stdexcept>

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

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

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

Standart mı, özel istisna mı?

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

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

#include <stdexcept>
#include <string>

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

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

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

Yakalama sırası ve yeniden fırlatma

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

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

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

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

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

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

``

C string’inin temel yapısı

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

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

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

#include <stdio.h>

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

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

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

Dizi mi, işaretçi mi?

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

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

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

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

Uzunluk ve kapasite aynı şey değildir

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

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

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

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

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

Güvenli girdi alma

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

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

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

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

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

Akılda tutulacaklar

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

``

Operatörlerin temel mantığı

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

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

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

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

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

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

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

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

Console.WriteLine(gorunenAd); // Misafir

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

if-else ile karar vermek

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

int not = 82;

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

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

Döngüsel iterasyon mekanizmaları

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

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

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

    Console.WriteLine(dil);
}

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

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.

``

String neden değiştirilemez?

Java’daki String nesneleri immutable, yani değiştirilemez yapıdadır. Bir String oluşturulduktan sonra içindeki karakter dizisi aynı nesne üzerinde değiştirilemez. Yapılan her değişiklik yeni bir String nesnesi üretir.

String mesaj = "Merhaba";
mesaj = mesaj + " Java";

System.out.println(mesaj); // Merhaba Java

Burada ilk nesne büyütülmez. "Merhaba Java" değerini taşıyan yeni bir nesne oluşturulur ve mesaj değişkeni artık onu gösterir. Eski nesneye başka bir referans yoksa nesne daha sonra çöp toplayıcı tarafından temizlenebilir.

Değiştirilemezlik; güvenlik, çok iş parçacıklı kullanım ve hash kodunun önbelleğe alınması açısından avantaj sağlar. Ayrıca Java, aynı sabit metinleri String Pool içinde paylaşabilir:

String a = "kahve";
String b = "kahve";

System.out.println(a == b); // Genellikle true
System.out.println(a.equals(b)); // true

== referansları, equals() ise metinsel içeriği karşılaştırır. İçerik karşılaştırmalarında doğru tercih çoğunlukla equals() metodudur.

Birleştirme maliyeti

Tek tük birleştirmelerde + kullanmak okunaklı ve uygundur. Fakat bir döngüde sürekli kullanıldığında çok sayıda geçici nesne oluşturabilir. Her adımda büyüyen metnin yeniden kopyalandığını düşünürsek yaklaşık maliyet şu toplamla ifade edilebilir:

Derleyici basit ifadeleri optimize edebilse de dinamik döngülerde StringBuilder daha güvenilir bir performans seçeneğidir.

StringBuilder: Hızlı ve dinamik

StringBuilder, değiştirilebilir bir karakter tamponu tutar. append(), insert(), delete() ve reverse() gibi metotlar çoğunlukla aynı nesne üzerinde çalışır.

StringBuilder sonuc = new StringBuilder();

for (int i = 1; i <= 5; i++) {
    sonuc.append("Ürün ")
         .append(i)
         .append("\n");
}

String metin = sonuc.toString();
System.out.println(metin);

Bu kod, ürün satırlarını tek bir dinamik tamponda biriktirir. İşlem tamamlandığında toString() ile normal bir String elde edilir. Başlangıç boyutu biliniyorsa kapasite vermek yeniden boyutlandırma sayısını azaltabilir:

StringBuilder rapor = new StringBuilder(1024);
rapor.append("Aylık rapor: ").append(2026);

Kapasite, metnin gerçek uzunluğundan farklıdır. Uzunluk kullanılan karakter sayısını, kapasite ise yeni bellek ayrılmadan tutulabilecek yaklaşık karakter miktarını belirtir.

StringBuffer: Kilitli ama güvenli

StringBuffer, kullanım biçimi bakımından StringBuilder ile neredeyse aynıdır. Temel fark, metotlarının eşzamanlı erişime karşı senkronize edilmesidir. Birden fazla iş parçacığı aynı tamponu değiştiriyorsa bu koruma faydalı olabilir. Buna karşılık kilitleme maliyeti nedeniyle tek iş parçacıklı kodlarda genellikle daha yavaştır.

Hangisini seçmeliyiz?

Metin değişmeyecekse veya yalnızca birkaç basit işlem yapılacaksa String tercih edilmelidir. Döngü içinde JSON, SQL, rapor ya da dosya içeriği üretiliyorsa StringBuilder daha uygundur. Aynı değiştirilebilir tampon gerçekten birden fazla iş parçacığı tarafından paylaşılıyorsa StringBuffer düşünülebilir.

Kısacası, String güvenli ve sade bir kasa; StringBuilder hızlı çalışan bir atölye; StringBuffer ise kapısında güvenlik görevlisi bulunan bir atölyedir. Doğru araç, metnin ne kadar değişeceğine ve kimler tarafından kullanılacağına bağlıdır.

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.

``

Green Project ve Oak’ın Doğuşu

Java’nın hikâyesi 1991 yılında Sun Microsystems bünyesindeki Green Project ile başladı. James Gosling, Mike Sheridan ve Patrick Naughton gibi mühendisler, televizyon kutuları ve ev cihazları için güvenilir bir yazılım platformu geliştirmeye çalışıyordu. C ve C++ güçlüydü; ancak donanıma bağımlılık, elle bellek yönetimi ve işaretçi hataları bu cihazlar için ciddi risk oluşturuyordu.

Gosling tarafından geliştirilen dil önce, ofisinin önündeki ağaçtan esinlenilerek Oak adını aldı. Oak isminin başka bir şirket tarafından tescillenmiş olması nedeniyle dilin adı daha sonra Java olarak değiştirildi. Projenin cihaz pazarı beklenen hızda büyümese de internetin yükselişi, taşınabilir kod fikrine yeni bir sahne hazırladı. Java, 1995 yılında resmen tanıtıldı.

Java’nın temel felsefesi şu sloganla özetlendi: Write Once, Run Anywhere — bir kez yaz, her yerde çalıştır.

Kaynak Koddan Bayt Koda

Java derleyicisi, kaynak kodunu doğrudan belirli bir işlemcinin makine diline dönüştürmez. Bunun yerine JVM’nin anlayabileceği ara temsil olan bayt kodu üretir.

public class MerhabaJVM {
    public static void main(String[] args) {
        int javaYasi = 2026 - 1995;
        System.out.println("Java yaklaşık " + javaYasi + " yaşında!");
    }
}

Bu sınıf şu komutla derlenir:

javac MerhabaJVM.java
java MerhabaJVM

javac komutu kaynak dosyadan MerhabaJVM.class dosyasını üretir. Bu dosya işlemciye özel makine kodu değil, JVM komutları içerir. javap -c MerhabaJVM komutu kullanılarak bayt kod talimatları incelenebilir.

Süreci matematiksel bir dönüşüm gibi gösterebiliriz:

Aynı .class dosyasının farklı sistemlerde çalışabilmesinin koşulu, her sistem için uygun bir JVM bulunmasıdır. Dolayısıyla taşınabilir olan JVM’nin kendisi değil, JVM üzerinde çalışacak şekilde üretilen bayt koddur.

JVM Tam Olarak Ne Yapar?

Java Virtual Machine, fiziksel işlemci ile Java programı arasında soyut bir bilgisayar gibi davranır. Sınıfları yükler, bayt kodunu doğrular, belleği düzenler ve kodu çalıştırır. JVM’nin başlıca bileşenleri şunlardır:

• Class Loader: Gerekli sınıfları çalışma anında yükler.
• Bytecode Verifier: Talimatların güvenli ve kurallara uygun olduğunu denetler.
• Execution Engine: Bayt kodu yorumlar veya makine koduna dönüştürür.
• Garbage Collector: Kullanılmayan nesnelerin belleğini otomatik olarak geri kazanır.
• Runtime Data Areas: Heap, stack ve metot alanı gibi bellek bölgelerini yönetir.

İlk JVM’ler bayt kodu çoğunlukla yorumluyordu. Modern JVM’lerdeki JIT derleyici, sık çalışan kod bölümlerini çalışma sırasında yerel makine koduna çevirir. Basitleştirilmiş performans fikri şöyle ifade edilebilir:

Başlangıçta JIT maliyeti oluşsa da tekrar sayısı $n$ büyüdükçe optimize edilmiş kod önemli hız kazandırır.

Java’nın Evrimi

Java zaman içinde yalnızca bir dil olmaktan çıkıp büyük bir platforma dönüştü. Java 5 generics ve annotation özelliklerini, Java 8 lambda ifadelerini ve Stream API’yi getirdi. Java 9 modül sistemini tanıttı; sonraki sürümler record, sealed class, pattern matching ve virtual thread gibi modern yetenekler ekledi.

Bugün Java’nın gücü; olgun kütüphane ekosistemi, geriye dönük uyumluluk yaklaşımı ve JVM’nin gelişmiş optimizasyonlarında yatıyor. Üstelik Kotlin, Scala ve Clojure gibi diller de JVM üzerinde çalışabiliyor. Kısacası Oak’ın küçük cihazlar için filizlenen fikri, milyonlarca uygulamayı taşıyan oldukça büyük bir ormana dönüştü.