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.

``

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.

``

Üç 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.

``

Hareket kısıtı ne demektir?

Bir robotun konfigürasyonu genellikle

ile gösterilir. Burada $x$ ve $y$ konumu, $\theta$ ise yönelimi temsil eder. Robot üç boyutlu bir konfigürasyon uzayında bulunsa da her yönde anlık hız üretemeyebilir.

Bir kısıt yalnızca konfigürasyon değişkenleriyle

şeklinde yazılabiliyorsa holonomik kabul edilir. Kısıt hızlara bağlıysa ve konum düzeyinde bütünleştirilemiyorsa non-holonomik davranış ortaya çıkar. Bu tür kısıtların yaygın gösterimi şöyledir:

Örneğin diferansiyel sürüşlü bir robotun yana kaymama koşulu:

biçimindedir. Denklem basitçe şunu söyler: Robotun tekerlek ekseni doğrultusunda yanal hızı yoktur. Yani robot araba park eder gibi birkaç manevra yapmak zorunda kalabilir.

İki hareket dünyasının karşılaştırması

Holonomik bir platform için A* algoritması iki boyutlu ızgarada kısa bir yol bulabilir. Robot, gerektiğinde yönünü değiştirmeden yana kayabilir. Non-holonomik bir araçta ise aynı yol üzerindeki doksan derecelik köşe fiziksel olarak uygulanamayabilir.

Yol planlamasına etkisi

Non-holonomik planlamada yalnızca engellerden kaçmak yetmez. Planlayıcı; yönelim, minimum dönüş yarıçapı, geri hareket izni ve direksiyon sınırı gibi değişkenleri de değerlendirmelidir. Bu nedenle klasik A* yerine Hybrid A*, state lattice, RRT, RRT* veya Dubins ve Reeds–Shepp eğrileri kullanılabilir.

Dubins aracı yalnızca ileri hareket eder ve eğriliği sınırlıdır. Reeds–Shepp modeli ise geri vitese de izin verir. Böylece iki durum arasındaki mesafe, Öklid uzaklığından daha gerçekçi hesaplanır:

Çünkü kuş uçuşu en kısa çizgi, otomobil sürüşü açısından her zaman uygulanabilir değildir.

Basit bir kısıt kontrolü

Aşağıdaki Python fonksiyonu, diferansiyel robotun verilen dünya hızlarında yanal kayma üretip üretmediğini denetler:

import math

def hareket_gecerli_mi(theta, vx, vy, tolerans=1e-3):
    # Robot gövdesine göre yanal hız bileşenini hesaplar.
    yanal_hiz = -math.sin(theta) * vx + math.cos(theta) * vy
    return abs(yanal_hiz) < tolerans

print(hareket_gecerli_mi(0.0, 1.0, 0.0))  # True: ileri hareket
print(hareket_gecerli_mi(0.0, 0.0, 1.0))  # False: doğrudan yana kayma

Gerçek bir planlayıcı, komşu durum üretirken yalnızca bu koşulu test etmekle kalmaz; robotun hareket modelini kısa bir süre boyunca simüle eder. Örneğin

modeliyle farklı $v$ ve $\omega$ komutları denenerek erişilebilir yeni düğümler oluşturulur. Böylece arama ağacındaki her bağlantı gerçekten uygulanabilir olur.

Sonuç

Holonomik planlama geometrik olarak “Nereden geçebilirim?” sorusuna odaklanırken non-holonomik planlama buna “Oraya hangi yönelim ve manevrayla ulaşabilirim?” sorusunu ekler. Daha gerçekçi kısıtlar daha fazla hesaplama gerektirir; ancak uygulanamayan kısa bir yol yerine güvenli, pürüzsüz ve sürülebilir bir rota üretir. Robotik dünyasında en kısa yol bazen düz çizgi değil, doğru kıvrımdır.

``

History expansion nedir?

Bash, etkileşimli kullanımda önceki komutları hızlıca çağırmak için ! ile başlayan ifadeleri yorumlayabilir. Örneğin !! son komutu, !42 geçmişteki 42 numaralı komutu, !git ise git ile başlayan son komutu temsil eder.

Bunu basitçe şu dönüşümle düşünebiliriz:

Buradaki $H$, history expansion etkinse ünlem ifadelerini geçmişteki komutlarla değiştiren fonksiyondur. Özellik kapalıysa $H(x)=x$ olur; yani metin değişmeden kalır.

Bash’in etkileşimli olmayan betiklerinde history expansion normalde kapalıdır. Ancak betik source ile etkileşimli bir kabuğa yüklenirse, bash -H ile başlatılırsa veya kod içinde set -H çalıştırılırsa özellik devreye girebilir. Bu yüzden “Betikte asla olmaz” varsayımı güvenli değildir.

Çifte tırnak her zaman korumaz

Shell programlamasında çifte tırnağın özel karakterleri tamamen etkisizleştirdiği sanılır. Oysa history expansion etkin olduğunda !, çifte tırnak içinde de yorumlanabilir:

#!/usr/bin/env bash
set -H

password="Guclu!Parola"
echo "$password"

Bash, !Parola için uygun bir geçmiş olayı arayabilir ve event not found hatası üretebilir. Üstelik expansion, değişkenin değerinden çok kaynak satırı okunurken önem kazanır. Bu nedenle davranış kabuk sürümüne, çalışma biçimine ve bağlama göre şaşırtıcı görünebilir.

En güvenli çözüm: Özelliği kapatmak

History expansion gerekmeyen bir betiğin başında özelliği açıkça kapatabilirsiniz:

#!/usr/bin/env bash
set +H
# Aynı işlemin daha açıklayıcı karşılığı:
set +o histexpand

message="Dağıtım tamamlandı!"
printf '%s\n' "$message"

set +H, histexpand seçeneğini kapatır. Buradaki artı işaretinin seçeneği kapatması ilk bakışta ters gelebilir: Bash’te set -H açar, set +H kapatır.

Sabit bir değer söz konusuysa tek tırnak da kullanılabilir:

printf '%s\n' 'İşlem başarılı!'
printf '%s\n' 'api-token: abc!123'

Ancak tek tırnak içinde değişken genişletmesi yapılmaz. Örneğin 'Merhaba $USER!', kullanıcı adını değil, doğrudan $USER metnini yazdırır.

Durumu teşhis etmek

Seçeneğin mevcut durumunu aşağıdaki komutla görebilirsiniz:

set -o | grep histexpand

Çıktıda histexpand on görülüyorsa ünlem genişletmesi açıktır. Betik source script.sh biçiminde çalıştırılıyorsa aynı kabuğun seçeneklerini miras alabileceğini unutmayın. Bağımsız çalıştırma için yürütme izni verip ./script.sh kullanmak daha öngörülebilir olabilir.

Özetle ünlem kaynaklı hatalarda yalnızca kaçış karakterleriyle boğuşmayın. Önce kabuğun türünü, betiğin nasıl çalıştırıldığını ve histexpand durumunu kontrol edin. Otomasyon kodunda geçmiş komut sihrine ihtiyaç yoksa set +H diyerek sürprizi daha perde açılmadan bitirin.

``

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.