``

Değer Değil, Adres Saklamak

Normal bir değişken doğrudan veri taşır. Gösterici ise bu verinin bulunduğu konumu taşır. Örneğin int sayi = 42; ifadesi bellekte bir tamsayı oluşturur. &sayi, bu değişkenin adresini verir; *ptr ise göstericinin tuttuğu adrese giderek oradaki değere erişir.

#include <stdio.h>

int main(void) {
    int sayi = 42;
    int *ptr = &sayi;

    printf("Deger: %d\n", sayi);
    printf("Adres: %p\n", (void *)ptr);
    printf("Pointer uzerinden deger: %d\n", *ptr);

    *ptr = 99; /* Adresteki gerçek değeri değiştirir. */
    printf("Yeni deger: %d\n", sayi);
    return 0;
}

Burada int *ptr, ptr değişkeninin bir int adresi taşıyacağını belirtir. *ptr = 99 işlemi kopyayı değil, doğrudan sayi değişkenini değiştirir. Göstericilerin fonksiyonlara “dışarıdaki” veriyi değiştirme gücü vermesi de bu mantığa dayanır.

Bellek ve Tür Bilgisi

Bir adresi yalnızca sayı gibi düşünmek eksik kalır. Göstericinin türü, derleyiciye o adreste kaç baytlık ve nasıl yorumlanacak bir veri bulunduğunu söyler. Tipik bir sistemde char 1 bayt, int 4 bayt olabilir; ancak kesin boyutlar platforma bağlıdır ve sizeof ile öğrenilmelidir.

Bir dizinin başlangıç adresi $A$, eleman boyutu $s$ ve erişilecek indis $i$ olsun. İlgili elemanın adresi şu şekilde hesaplanır:

Bu nedenle işaretçi aritmetiği sıradan tam sayı aritmetiğinden farklıdır. ptr + 1, adresi bir bayt değil, gösterilen türün boyutu kadar ilerletir.

#include <stdio.h>

int main(void) {
    int sayilar[] = {10, 20, 30, 40};
    int *ptr = sayilar;

    for (size_t i = 0; i < 4; i++) {
        printf("%zu: %d\n", i, *(ptr + i));
    }
    return 0;
}

*(ptr + i) ile ptr[i] eşdeğerdir. Hatta sayilar[i] ifadesi de temelde başlangıç adresinden uygun miktarda ilerleyip değeri çözme işlemidir.

NULL ve Tehlikeli Göstericiler

Başlatılmamış bir gösterici rastgele bir adres taşıyabilir. NULL, göstericinin geçerli bir nesneyi göstermediğini açıkça belirtir. Ancak NULL göstericiyi çözmek, yani *ptr kullanmak tanımsız davranıştır.

int *ptr = NULL;

if (ptr != NULL) {
    /* Yalnızca geçerli adres varsa erişilir. */
    *ptr = 5;
}

Benzer şekilde yaşam süresi bitmiş yerel değişkenlerin adresleri ve free ile serbest bırakılmış bölgeleri gösteren işaretçiler “sarkan gösterici” oluşturur. Dizi sınırını aşmak da komşunun posta kutusunu kendi kutunuz sanmaya benzer: Adres vardır, fakat erişim hakkınız yoktur.

Sonuç

Göstericiler C’nin performans ve kontrol gücünün merkezindedir. & adres alır, * adresteki veriyi çözer, tür bilgisi ise aritmetik adımların boyutunu belirler. Güvenli kullanım için göstericileri başlatmak, NULL kontrolü yapmak, nesnelerin yaşam süresini izlemek ve dizi sınırlarını korumak gerekir. Bu kurallar oturduğunda belleğin karanlık sokakları, tabelaları gayet okunaklı bir mahalleye dönüşür.

Derlemeden önce neler olur?

Tipik bir C programının üretim süreci kabaca dört aşamaya ayrılır:

Bu süreci sembolik olarak şöyle gösterebiliriz:

GCC kullanırken yalnızca önişlemci çıktısını görmek için şu komut çalıştırılabilir:

gcc -E program.c -o program.i

Oluşan program.i dosyası genellikle oldukça uzundur; çünkü eklenen başlıkların içeriği de bu dosyada görünür.

#include: Başlık dosyalarını eklemek

#include, belirtilen dosyanın içeriğini mevcut kaynak dosyaya metinsel olarak ekler:

#include <stdio.h>
#include "hesaplama.h"

Aynı başlığın birden fazla kez eklenmesi tanım çakışmalarına yol açabilir. Bu nedenle include guard kullanılır:

#ifndef HESAPLAMA_H
#define HESAPLAMA_H

int topla(int a, int b);

#endif

İlk eklemede HESAPLAMA_H tanımlanır. Sonraki eklemelerde #ifndef koşulu yanlış olacağı için dosyanın gövdesi atlanır.

#define: Metinsel dönüşüm yapan makrolar

Nesne benzeri makrolar sabit değerleri temsil edebilir:

#define PI 3.141592653589793
#define MAKSIMUM_KULLANICI 100

Örneğin dairenin alanı $A = \pi r^2$ bağıntısıyla hesaplanabilir:

#define PI 3.141592653589793
#define KARE(x) ((x) * (x))

double alan(double yaricap) {
    return PI * KARE(yaricap);
}

Parantezler önemlidir. #define KARE(x) x * x yazılsaydı KARE(a + 1) ifadesi a + 1 * a + 1 biçiminde genişleyerek işlem önceliği hatası oluştururdu.

Makroların tür denetimi yapmadığı ve yalnızca metin değiştirdiği unutulmamalıdır. Ayrıca KARE(i++) gibi bir kullanım, argümanı iki kez değerlendirebilir. Bu durumda beklenmeyen yan etkiler ortaya çıkar. Tür güvenliği ve tek değerlendirme gerektiğinde inline fonksiyon genellikle daha iyi bir seçimdir.

Koşullu derleme

Koşullu direktifler, platforma veya yapılandırmaya göre farklı kodların derlenmesini sağlar:

#ifdef DEBUG
    printf("Hata ayıklama modu etkin\n");
#endif

#if defined(_WIN32)
    printf("Windows üzerinde çalışıyor\n");
#elif defined(__linux__)
    printf("Linux üzerinde çalışıyor\n");
#else
    printf("Bilinmeyen platform\n");
#endif

Komut satırından bir makro tanımlamak da mümkündür:

gcc -DDEBUG program.c -o program

#undef DEBUG ise daha önce tanımlanmış makroyu kaldırır. Önişlemci ifadelerinde defined, mantıksal operatörler ve tamsayı sabitleri kullanılabilir; ancak normal C değişkenleri kullanılamaz. Çünkü değişkenler henüz derleyici tarafından işlenmemiştir.

Sonuç olarak C önişlemcisi güçlü fakat dikkatsiz kullanıldığında şaşırtıcıdır. Makroları küçük ve parantezli tutmak, include guard kullanmak, koşullu derlemeyi belgeli yürütmek ve mümkün olduğunda sabitler ile inline fonksiyonları tercih etmek daha okunabilir, taşınabilir ve güvenli programlar üretir.

Şablonların temel mantığı

Şablon, henüz kesinleşmemiş bir türü veya değeri parametre olarak alan kod kalıbıdır. T gibi bir şablon parametresi başlangıçta gerçek bir tür değildir; derleme sırasında int, double veya kullanıcı tarafından tanımlanmış bir sınıfla değiştirilir.

Bunu matematikteki genel bir fonksiyona benzetebiliriz:

Burada toplama işlemi, $x$ ve $y$ değerlerinin türünden çok + operatörünü destekleyip desteklemediğiyle ilgilenir. Şablonlar da benzer biçimde çalışır. Bir tür, şablonun kullandığı işlemleri sağlıyorsa o şablonla kullanılabilir.

Fonksiyon şablonları

İki değerden büyük olanı döndüren jenerik bir fonksiyon yazalım:

#include <iostream>
#include <string>

template <typename T>
T buyukOlan(const T& a, const T& b) {
    return (a > b) ? a : b;
}

int main() {
    std::cout << buyukOlan(12, 7) << '\n';
    std::cout << buyukOlan(3.4, 8.1) << '\n';
    std::cout << buyukOlan(std::string("Ali"), std::string("Zeynep"));
}

template <typename T> ifadesi, T adlı bir tür parametresi tanımlar. Derleyici ilk çağrıda T = int, ikinci çağrıda T = double kabul eder. Bu işleme şablon örnekleme denir. Kabaca üretilen fonksiyon sayısını şöyle düşünebiliriz:

Parametreleri const T& ile almak, özellikle büyük nesnelerin gereksiz yere kopyalanmasını önler. Ancak kullanılan türün > operatörünü desteklemesi gerekir; aksi hâlde derleme hatası alınır.

Birden fazla tür parametresi

Bazen giriş türleri birbirinden farklı olabilir:

template <typename T, typename U>
auto topla(const T& a, const U& b) {
    return a + b;
}

int main() {
    auto sonuc = topla(10, 2.5); // Sonuç double olur
}

auto dönüş türünü a + b ifadesinden çıkarır. Böylece int ve double birlikte kullanılabilir. Yine de sonuç, ilgili türlerin birbirleriyle toplanabilmesine bağlıdır.

Sınıf şablonları

Şablonlar yalnızca fonksiyonlar için değildir. Farklı türlerde değer saklayabilen basit bir kutu sınıfı oluşturalım:

#include <utility>

template <typename T>
class Kutu {
private:
    T deger;

public:
    explicit Kutu(T yeniDeger)
        : deger(std::move(yeniDeger)) {}

    const T& getir() const {
        return deger;
    }

    void ayarla(const T& yeniDeger) {
        deger = yeniDeger;
    }
};

int main() {
    Kutu<int> puan(100);
    Kutu<std::string> mesaj("Merhaba şablon!");
}

Kutu<int> ve Kutu<std::string>, aynı sınıf şablonundan üretilmiş farklı sınıf türleridir. Derleyici bunların her biri için uygun alanları ve metotları oluşturur.

Dikkat edilmesi gerekenler

Şablon tanımları çoğunlukla başlık dosyalarında bulunur. Çünkü derleyicinin belirli bir tür için kod üretirken şablonun tüm gövdesini görmesi gerekir. Ayrıca her tür, şablonda kullanılan operatörleri sağlamalıdır. Modern C++20 projelerinde bu beklentiler concept yapılarıyla açıkça ifade edilebilir.

Şablonlar; std::vector, std::map ve std::sort gibi Standart Kütüphane araçlarının temelidir. Kısacası doğru kullanıldıklarında daha az tekrar, güçlü tür güvenliği ve genişletilebilir kod sunarlar. Derleyici biraz daha çalışır, fakat programcı çok daha az terler!

``

C# nereden geldi?

C#, Microsoft tarafından .NET platformunun temel dillerinden biri olarak geliştirildi. Dilin baş mimarı Anders Hejlsberg’dir; ilk sürüm 2000 yılında duyurulmuş, .NET Framework ile birlikte 2002 yılında yaygın kullanıma açılmıştır. C++, Java ve Delphi gibi dillerden fikirler taşısa da zamanla kendine özgü, modern bir kimlik kazanmıştır.

C# başlangıçta Windows uygulamalarıyla özdeşleşse de günümüzde açık kaynaklı ve platformlar arası .NET üzerinde çalışır. Web uygulamalarından oyunlara, masaüstü yazılımlarından bulut servislerine kadar geniş bir kullanım alanına sahiptir.

Bu ayrım önemlidir: C# bir dildir, .NET bir platformdur, CLR ise bu platformun çalışma zamanı motorudur.

Derleme süreci nasıl işler?

C# kaynak kodu doğrudan işlemcinin anlayacağı makine koduna çevrilmez. Önce Roslyn derleyicisi tarafından Common Intermediate Language olarak bilinen CIL’e dönüştürülür. CIL, işlemciden büyük ölçüde bağımsız bir ara dildir. Derleme sonucunda .dll veya .exe uzantılı bir assembly oluşur.

Bir assembly yalnızca CIL komutlarını içermez. Türler, metotlar, sürüm bilgileri ve bağımlılıklar gibi metadata bilgilerini de taşır. Çalıştırma sırasında CLR içindeki Just-In-Time derleyicisi, ihtiyaç duyulan metotların CIL kodunu hedef işlemcinin makine koduna çevirir.

Süreci şöyle özetleyebiliriz:

C# kaynak kodu
      ↓ Roslyn
CIL + metadata içeren assembly
      ↓ CLR ve JIT
Makine kodu
      ↓
İşlemci

Toplam çalışma maliyeti basitleştirilmiş biçimde şu şekilde düşünülebilir:

JIT maliyeti ilk çağrıda hissedilebilir; ancak üretilen yerel kod sonraki çağrılarda yeniden kullanılabilir. .NET ayrıca uygulamayı önceden yerel koda yaklaştıran ReadyToRun ve Native AOT gibi seçenekler de sunar.

CLR hangi işleri üstlenir?

CLR, yalnızca kodu çalıştıran pasif bir katman değildir. Bellek yönetimi, hata işleme, güvenlik kontrolleri, iş parçacıkları ve tür güvenliği gibi sorumlulukları üstlenir. En bilinen bileşenlerinden biri Garbage Collector, yani çöp toplayıcıdır. Artık erişilemeyen nesnelerin belleğini otomatik olarak geri kazanır.

using System;

public sealed class Urun
{
    public string Ad { get; }
    public decimal Fiyat { get; }

    public Urun(string ad, decimal fiyat)
    {
        Ad = ad;
        Fiyat = fiyat;
    }

    public decimal KdvliFiyat(decimal oran) => Fiyat * (1 + oran);
}

var urun = new Urun("Klavye", 1200m);
Console.WriteLine(urun.KdvliFiyat(0.20m));

Bu örnekte Urun nesnesi yönetilen bellekte oluşturulur. CLR nesnenin yaşam döngüsünü izler; nesneye erişim kalmadığında ayrılan alan GC tarafından temizlenebilir. Geliştiricinin çoğu durumda belleği elle serbest bırakması gerekmez.

CTS ve CLS neden önemlidir?

Common Type System, .NET dillerinin ortak tür modelini tanımlar. Örneğin C# dilindeki int, CLR düzeyinde System.Int32 türüne karşılık gelir. Common Language Specification ise farklı .NET dillerinin birbiriyle uyumlu çalışabilmesi için takip etmesi gereken kuralları belirler.

Sonuç olarak C# kodu tek başına yolculuk etmez. Roslyn, CIL, assembly, JIT ve CLR katmanları birlikte çalışarak taşınabilir, güvenli ve yönetilebilir bir yürütme ortamı oluşturur. Bu mimariyi bilmek, yalnızca kod yazmayı değil, kodun gerçekte nasıl hayata geçtiğini de anlamaktır.

Aynı kullanıcı, neden farklı sonuç?

Terminal açtığımızda Bash genellikle .bashrc, .profile veya .bash_profile gibi başlangıç dosyalarını okuyabilir. Bu dosyalar PATH, dil ayarları, alias’lar ve uygulamalara özel değişkenler tanımlar. Cron ise öngörülebilir olmak amacıyla oldukça sade bir ortam oluşturur ve interaktif shell yapılandırmasını kendiliğinden yüklemez.

Shell bir komutun içinde / görmezse çalıştırılabilir dosyayı PATH dizinlerinde sırayla arar. Bunu basitçe şöyle düşünebiliriz:

Örneğin terminalinizde /usr/local/bin mevcutken cron’un PATH değerinde bu dizin yoksa node, python, docker veya özel bir CLI bulunamayabilir. Sonuç genellikle command not found olur; çıktı yönlendirilmediyse hatayı görmeyebilirsiniz bile.

Güvenilir çözüm: ortamı açıkça tanımlamak

Crontab içinde ihtiyaç duyulan shell ve PATH değerlerini belirtmek ilk savunma hattıdır:

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin

*/10 * * * * /home/ada/scripts/rapor.sh >> /home/ada/logs/rapor.log 2>&1

Buradaki 2>&1, standart hata akışını standart çıktıyla aynı log dosyasına gönderir. Böylece cron’un sessizliğini bozup gerçek hatayı yakalayabilirsiniz. Ancak SHELL=/bin/bash yazmak Bash’i otomatik olarak login veya interaktif shell yapmaz; .bashrc dosyasının okunacağı anlamına gelmez.

Script içinde kritik komutlar için mutlak yollar kullanmak daha da sağlamdır:

#!/usr/bin/env bash
set -euo pipefail

DATE=/usr/bin/date
PG_DUMP=/usr/bin/pg_dump
GZIP=/usr/bin/gzip

backup="/var/backups/app-$($DATE +%F).sql.gz"
$PG_DUMP appdb \vert  $GZIP > "$backup"

Bu script, hangi programların çalışacağını belirsiz PATH aramasına bırakmaz. set -euo pipefail ise başarısız komutları, tanımsız değişkenleri ve boru hattı hatalarını görünür kılar.

Göreli yolların gizli tehlikesi

Script’in ./config.json dosyasını okuması, cron’un doğru dizinde başladığını garanti etmez. Önce script dizinine geçmek güvenlidir:

#!/usr/bin/env bash
set -euo pipefail

SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
cd "$SCRIPT_DIR"

/usr/bin/python3 generate_report.py --config ./config.json

Böylece script nereden çağrılırsa çağrılsın dosya yolları tutarlı kalır.

Ortamı karşılaştırarak hata ayıklama

Cron’un gördüğü ortamı dosyaya yazdırabilirsiniz:

* * * * * /usr/bin/env | /usr/bin/sort > /tmp/cron-env.txt 2>&1

Terminalde de env | sort > /tmp/shell-env.txt çalıştırıp iki dosyayı diff ile karşılaştırın. Ayrıca command -v python3, command -v node gibi komutlarla gerçek çalıştırılabilir yolları bulun.

.bashrc dosyasını zorla yüklemek kısa vadede işe yarayabilir, fakat interaktif terminale özel komutlar cron altında yeni sorunlar çıkarabilir. En iyi yaklaşım; bağımlılıkları, yolları, çalışma dizinini ve loglamayı açıkça tanımlayan, kendi ortamını bilen bağımsız script’ler yazmaktır. Cron sürpriz yapmaz; yalnızca bizim terminalde fark etmeden taşıdığımız görünmez bagajı yanında getirmez.

Const doğruluğu gerçekte ne söyler?

Bir nesneye const erişim, gözlemlenebilir durumunun değiştirilmeyeceği sözünü verir. Üye fonksiyonun sonundaki const ise bu sözün fonksiyon arayüzündeki karşılığıdır:

class User {
public:
    const std::string& name() const {
        return name_;
    }

private:
    std::string name_;
};

Burada ilk const, döndürülen referans üzerinden metnin değiştirilemeyeceğini; ikinci const ise name() çağrısının User nesnesini değiştirmediğini belirtir. İki kullanım farklı soruları yanıtlar: “Sonuç değiştirilebilir mi?” ve “İşlem nesneyi değiştiriyor mu?”

Bunu kabaca bir durum geçişiyle ifade edebiliriz. Salt okunur işlem için beklenen ilişki:

Burada $S$ nesnenin başlangıç durumu, $R$ sonuçtur. Değiştirici bir işlemdeyse yeni durum $S’$ oluşabilir:

const, ilk davranışı tür sistemi seviyesinde ilan eder ve derleyicinin bu sözleşmeyi denetlemesini sağlar.

Küçük ihmal, büyük arayüz problemi

Aşağıdaki fonksiyon nesneyi değiştirmese bile const olarak işaretlenmemiştir:

class Report {
public:
    std::string summary() { // Aslında değişiklik yapmıyor
        return title_ + ": " + body_;
    }

private:
    std::string title_;
    std::string body_;
};

Bu eksiklik yüzünden const Report& alan kodlar summary() metodunu çağıramaz. Sorunu geçici olarak aşmak isteyen geliştiriciler nesneleri gereksiz yere kopyalayabilir, parametrelerden const niteliğini kaldırabilir veya daha kötüsü const_cast kullanabilir. Böylece yerel bir ihmal, çağrı zinciri boyunca yayılır.

Sonradan eklemek neden pahalıdır?

Bir metoda sonradan const eklemek kaynak kod düzeyinde küçük görünür:

std::string summary() const;

Fakat gerçek projede bu değişiklik; çağrılan yardımcı metotların, kullanılan işaretçilerin ve önbelleklerin de incelenmesini gerektirir. Ayrıca üye fonksiyonun const niteliği türünün parçasıdır. Sanal fonksiyonlarda taban ve türetilmiş sınıfların imzaları eşleşmelidir:

struct Document {
    virtual std::string title() const = 0;
};

struct Invoice : Document {
    std::string title() const override {
        return "Fatura";
    }
};

Taban sınıfa sonradan const eklemek, bütün türetilmiş sınıfları değiştirebilir. Paylaşılan kütüphanelerde bu durum kaynak ve ikili uyumluluk planlarını da etkiler.

Mantıksal const ve önbellekleme

Bazen bir sorgu sonucu önbelleğe alınır. Kullanıcının gözünde nesne değişmezken içeride teknik bir güncelleme gerekir. Bunun için mutable bilinçli biçimde kullanılabilir:

class Calculator {
public:
    int result() const {
        if (!cached_) {
            cache_ = expensiveCalculation();
            cached_ = true;
        }
        return cache_;
    }

private:
    int expensiveCalculation() const { return 42; }
    mutable bool cached_ = false;
    mutable int cache_ = 0;
};

Bu yaklaşım fiziksel değil, mantıksal değişmezliği temsil eder. Yine de mutable, eşzamanlı erişimi otomatik olarak güvenli yapmaz; gerekirse kilit veya atomik tür kullanılmalıdır.

Sağlam arayüz için pratik ölçüt

Bir metot tasarlarken önce “Bu işlem nesnenin kullanıcı tarafından gözlemlenen anlamını değiştiriyor mu?” diye sorun. Yanıt hayırsa metodu const yapın. Parametrelerde mümkün olduğunda const T&, sahiplik aktarılmıyorsa salt okunur işaretçi veya görünüm türleri kullanın. const doğruluğunu baştan kurmak birkaç saniye; yıllar sonra bütün API ağında düzeltmek ise pahalı bir mimari operasyondur. Kısacası const, kısıtlama değil, gelecekteki kullanım biçimlerine açılan güvenli bir kapıdır.

C++’ta const T& gördüğümüzde genellikle “güvenli, değiştirilemez referans” diye düşünürüz. Ancak geçici nesneler devreye girdiğinde konu yalnızca değiştirilebilirlikten ibaret değildir. Referansın neye, nerede ve nasıl bağlandığı; geçici nesnenin hemen yok edilmesini de kapsam sonuna kadar yaşamasını da sağlayabilir. Kısacası const, bazen nesneye adeta fazladan can verir.

``

Geçici nesne nedir?

Bir ifadenin sonucunu taşımak için oluşturulan, genellikle adı olmayan nesneye geçici nesne denir. Örneğin std::string("merhaba") bir geçici nesne üretir. Normal koşullarda bu nesne, içinde oluşturulduğu tam ifadenin sonunda yok edilir. Çoğu zaman bu nokta noktalı virgüldür.

std::string("merhaba"); // Nesne bu satırın sonunda yok edilir.

Basitleştirilmiş biçimde geçici nesnenin olağan ömrünü şöyle düşünebiliriz:

Fakat uygun bir yerel referansa doğrudan bağlama yapılırsa ömür, referansın kapsamına kadar uzatılabilir:

const referans neden özel?

Lvalue referansları normalde geçici nesnelere bağlanamaz:

std::string& a = std::string("C++"); // Hata

Bunun nedeni, kısa ömürlü ve isimsiz bir değerin değiştirilebilir bir lvalue referansı üzerinden kullanılmasının riskli kabul edilmesidir. Buna karşılık const lvalue referansı bağlanabilir:

const std::string& a = std::string("C++");
std::cout << a; // Güvenli: geçicinin ömrü a'nın kapsamına uzatıldı.

Son satır kritik bir ayrıntıdır. Bir fonksiyon parametresine bağlanan geçici, fonksiyon çağrısı bittikten sonra saklanamaz.

const std::string* adres;

void sakla(const std::string& metin) {
    adres = &metin;
}

sakla(std::string("kaybolacak"));
// Bu noktadan sonra adres dangling pointer!

metin, fonksiyon içinde geçerlidir; fakat çağrının bulunduğu tam ifade sona erince geçici nesne yok edilir.

Referansı döndürmek ömrü uzatmaz

En tehlikeli sürprizlerden biri, fonksiyondan const referans döndürmektir:

const std::string& üret() {
    return std::string("geçici"); // Hatalı: yok edilecek nesneye referans
}

const burada koruyucu kalkan değildir. Fonksiyon sona erdiğinde geçici nesne yok edilir ve dönen referans boşa çıkar. Doğru yaklaşım değeri döndürmektir:

std::string üret() {
    return std::string("güvenli");
}

Modern C++, kopya eleme ve taşıma sayesinde bu kodu çoğunlukla ek maliyet oluşturmadan çalıştırır.

İkinci referans ikinci bir ömür vermez

Ömür uzatma aktarılabilir bir özellik değildir:

const std::string& ilk = std::string("örnek");
const std::string& ikinci = ilk;

Nesnenin ömrü ilk nedeniyle uzatılmıştır. ikinci, aynı nesneye başka bir takma ad verir; ömrü yeniden başlatmaz veya kendi kapsamına göre genişletmez. Eğer ikinci, ilkten daha uzun yaşarsa dangling referansa dönüşebilir.

const dönüş değeri her zaman yararlı değildir

Eski kodlarda const T döndüren fonksiyonlar görülebilir:

const std::string oluştur();

Bu kullanım, modern C++’ta taşıma işlemlerini engelleyebilir; çünkü taşıma kurucuları çoğunlukla T&& bekler, const T&& değil. Değer döndüren fonksiyonlarda genellikle yalnızca T tercih edilmelidir.

Özet kural şudur: Yerel const T& ve T&&, doğrudan bağlandıkları geçicinin ömrünü uzatabilir. Parametreler, döndürülen referanslar ve başka bir referans üzerinden yapılan bağlamalar için aynı güvenceyi varsaymayın. const, değişikliği sınırlar; her durumda ömür yönetmez.

C++’ta dinamik bellek yönetirken delete ile delete[] arasındaki iki köşeli parantez küçük görünebilir. Ancak yanlış silme ifadesini kullanmak; bellek sızıntısı, eksik yıkıcı çağrıları, heap bozulması ve yalnızca üretim ortamında ortaya çıkan gizemli çökmeler gibi ciddi sonuçlara yol açabilir. ``

Temel eşleştirme kuralı

C++’ta bellek ayırma ve serbest bırakma işlemleri doğru biçimde eşleştirilmelidir:

Başka bir ifadeyle şu eşitlik korunmalıdır:

new[] ile oluşturulan bir diziyi normal delete ile silmek tanımsız davranıştır. Tanımsız davranış, programın mutlaka anında çökeceği anlamına gelmez. Program düzgün çalışıyor gibi görünebilir, rastgele sonuç üretebilir veya başka bir noktada çökebilir. Tehlikeli olan da budur.

Neden iki farklı silme işlemi var?

Tek bir nesne oluşturulduğunda çalışma zamanı yalnızca o nesnenin yıkıcısını çağırır ve belleği serbest bırakır. Dizilerde ise her elemanın ayrı ayrı yok edilmesi gerekir.

Bir dizi $n$ elemandan oluşuyorsa beklenen yıkıcı çağrısı sayısı şöyledir:

Bazı C++ çalışma zamanı uygulamaları, ayrılan bloğun başında eleman sayısını saklayan ve halk arasında array cookie denilen ek bilgiler tutar. delete[], bu bilgiyi kullanarak kaç yıkıcı çağrılması gerektiğini belirleyebilir. Standart, bu mekanizmanın nasıl uygulanacağını zorunlu kılmaz; fakat programcıya doğru silme ifadesini kullanma sorumluluğunu verir.

class Sensor {
public:
    Sensor() = default;

    ~Sensor() {
        // Dosya, soket veya başka bir kaynak burada kapatılabilir.
    }
};

int main() {
    Sensor* sensors = new Sensor[4];

    // Dört elemanın da yıkıcısını çalıştırır.
    delete[] sensors;
}

Burada delete sensors; kullanılsaydı sonuç tanımsız olurdu. Yalnızca ilk elemanın yıkıcısının çağrılacağını varsaymak bile güvenli değildir; standart böyle bir garanti sunmaz.

İlkel türlerde sorun yok mu?

int veya double gibi türlerin yıkıcısı olmadığı için yanlış kullanımın zararsız olduğu düşünülebilir:

int* scores = new int[100];
delete scores; // Hatalı: delete[] kullanılmalıydı.

Bu kod yine tanımsız davranıştır. Bellek yöneticisi dizi tahsisini farklı biçimde izleyebilir. Hata hemen görünmese bile heap yapısı bozulabilir. Doğru kullanım şöyledir:

int* scores = new int[100];
delete[] scores;
scores = nullptr;

İşaretçiyi nullptr yapmak, aynı işaretçinin yanlışlıkla tekrar silinmesi riskini azaltabilir. Ayrıca delete nullptr ve delete[] nullptr güvenlidir; ikisi de işlem yapmaz.

Hataları nasıl yakalarız?

AddressSanitizer, Valgrind ve benzeri araçlar tahsis-silme uyumsuzluklarını bulabilir. GCC veya Clang ile örnek bir kontrol derlemesi şöyledir:

g++ -std=c++20 -Wall -Wextra -fsanitize=address main.cpp
./a.out

Derleyici uyarıları yardımcı olsa da işaretçi farklı fonksiyonlara taşındığında hatayı her zaman yakalayamaz.

Modern C++ çözümü

En güvenli yaklaşım, çıplak new[] kullanmaktan kaçınmaktır. Boyutu çalışma zamanında belirlenen diziler için std::vector, sabit boyutlular için std::array tercih edilmelidir:

#include <vector>

int main() {
    std::vector<int> scores(100);
    scores[0] = 42;
} // Bellek otomatik olarak temizlenir.

Dinamik bir diziye gerçekten ihtiyaç varsa std::unique_ptr<T[]> kullanılabilir. Böylece doğru delete[] otomatik olarak çağrılır. Kısacası, new gördüğünüzde delete, new[] gördüğünüzde delete[] düşünün; daha iyisi, bu işi RAII kapsayıcılarına bırakın.

``

Temel mekanik düzen

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

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

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

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

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

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

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

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

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

Basit bir hız hesabı

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

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

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

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

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

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

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

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

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

``

Tek Bir Sensör Neden Yetmez?

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

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

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

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

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

Basit Bir Uyarlanabilir Füzyon Örneği

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

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

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

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

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

Füzyonun Gizli Kahramanları

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

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