``

Standart giriş ve çıkış nedir?

C, konsol işlemlerini birer akış olarak ele alır. Program başladığında standart giriş stdin, standart çıkış stdout ve hata çıkışı stderr otomatik olarak açılır. Klavye çoğunlukla stdin akışına, terminal ekranı ise stdout akışına bağlıdır.

Bu fonksiyonları kullanmak için başlık dosyası eklenir:

#include <stdio.h>

Bir giriş/çıkış işleminin basit modeli şöyle düşünülebilir:

printf ile formatlı çıktı

printf, metin içindeki format belirteçlerini ilgili değişkenlerin değerleriyle değiştirir.

#include <stdio.h>

int main(void) {
    char ad[] = "Ada";
    int yas = 25;
    double ortalama = 87.456;

    printf("Ad: %s\n", ad);
    printf("Yas: %d\n", yas);
    printf("Ortalama: %.2f\n", ortalama);

    return 0;
}

Burada %s karakter dizisini, %d tam sayıyı ve %.2f ondalıklı değeri virgülden sonra iki basamakla yazdırır. \n ise imleci yeni satıra taşır.

Alan genişliği de çıktıyı hizalamayı sağlar. Örneğin %8d, sayıyı sekiz karakterlik alanda sağa yaslar; %-8d sola yaslar. Sayısal bir değeri $w$ genişliğinde göstermek, tablo biçimindeki çıktılarda sütunların düzenli kalmasını sağlar.

scanf ile klavyeden veri okuma

scanf, girilen karakterleri belirtilen türe dönüştürerek değişkenlere yazar. Değişkenin bellekteki adresi gerektiğinden çoğu kullanımda & operatörü zorunludur.

#include <stdio.h>

int main(void) {
    int adet;
    double fiyat;

    printf("Adet ve birim fiyat girin: ");

    if (scanf("%d %lf", &adet, &fiyat) == 2) {
        double toplam = adet * fiyat;
        printf("Toplam: %.2f TL\n", toplam);
    } else {
        fprintf(stderr, "Gecersiz veri girdiniz.\n");
    }

    return 0;
}

scanf başarıyla doldurduğu alanların sayısını döndürür. İki değer bekleniyorsa dönüş değerinin 2 olması gerekir. Matematiksel olarak hesaplanan sonuç:

Önemli bir ayrıntı: printf içinde double için %f, scanf içinde ise %lf kullanılır. Yanlış belirteç seçmek tanımsız davranışa yol açabilir.

Metin okurken daha güvenli yaklaşım

scanf("%s", metin) boşlukta durur ve genişlik belirtilmezse taşma riski doğurur. Tam bir satır okumak için fgets daha güvenlidir:

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

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

    printf("Ad ve soyad: ");
    if (fgets(ad, sizeof ad, stdin) != NULL) {
        ad[strcspn(ad, "\n")] = '\0';
        printf("Hos geldin, %s!\n", ad);
    }

    return 0;
}

sizeof ad, okunabilecek karakter miktarını sınırlar. strcspn ise fgets tarafından saklanabilen satır sonunu bulup \0 ile değiştirir. Kısacası printf sunum ustası, scanf hızlı veri dönüştürücüsü, fgets ise metin girişlerinin emniyet kemeridir.

``

Derleme bağımlılığı neden oluşur?

Bir başlık dosyasında başka sınıfları doğrudan üye olarak kullandığımızı düşünelim:

#include <string>
#include <vector>
#include "DatabaseConnection.hpp"
#include "Logger.hpp"

class UserService {
public:
    void createUser(const std::string& name);

private:
    DatabaseConnection database;
    Logger logger;
    std::vector<std::string> cache;
};

Derleyici, UserService nesnesinin boyutunu hesaplayabilmek için bütün veri üyelerinin tanımlarını bilmelidir. Bu nedenle başlıklar içeri alınır. Logger.hpp değiştiğinde UserService.hpp dosyasını kullanan kaynaklar da yeniden derlenebilir.

Basitleştirilmiş biçimde toplam derleme maliyetini şöyle düşünebiliriz:

Burada $D_i$, bir başlığa bağımlı çeviri birimi sayısını; $C_i$ ise ilgili birimin derleme maliyetini temsil eder. Pimpl özellikle $D_i$ değerinin oluşturduğu zincirleme etkiyi küçültür.

Pimpl yapısı

Başlık dosyasında uygulama sınıfı yalnızca ileri bildirilir ve ona bir akıllı işaretçi tutulur:

// UserService.hpp
#pragma once

#include <memory>
#include <string>

class UserService {
public:
    UserService();
    ~UserService();

    UserService(UserService&&) noexcept;
    UserService& operator=(UserService&&) noexcept;

    void createUser(const std::string& name);

private:
    class Impl;
    std::unique_ptr<Impl> impl;
};

Gerçek üyeler .cpp dosyasına taşınır:

// UserService.cpp
#include "UserService.hpp"
#include "DatabaseConnection.hpp"
#include "Logger.hpp"

#include <vector>

class UserService::Impl {
public:
    void createUser(const std::string& name) {
        logger.info("Kullanıcı oluşturuluyor: " + name);
        database.insert(name);
        cache.push_back(name);
    }

private:
    DatabaseConnection database;
    Logger logger;
    std::vector<std::string> cache;
};

UserService::UserService()
    : impl(std::make_unique<Impl>()) {}

UserService::~UserService() = default;
UserService::UserService(UserService&&) noexcept = default;
UserService& UserService::operator=(UserService&&) noexcept = default;

void UserService::createUser(const std::string& name) {
    impl->createUser(name);
}

Yıkıcının .cpp içinde tanımlanması önemlidir. std::unique_ptr, işaret ettiği nesneyi yok ederken Impl türünün tamamlanmış olmasına ihtiyaç duyar. Başlık içinde otomatik üretilen bir yıkıcı bazı derleyici bağlamlarında eksik tür hatasına neden olabilir.

Pimpl öncesi ve sonrası

ABI avantajı

Pimpl yalnızca derleme süresini değil, ikili uyumluluğu da destekler. Doğrudan üye eklemek sınıfın sizeof değerini değiştirir. Pimpl kullanılan sınıfta ise dışarıdan görünen veri çoğunlukla tek bir işaretçidir:

Impl içine yeni alanlar eklense bile açık sınıfın yerleşimi değişmez. Bu durum özellikle paylaşımlı kütüphanelerde değerlidir.

Bedelsiz bir sihir değil

Pimpl; ek dinamik bellek tahsisi, işaretçi dolayımı ve daha fazla yardımcı kod getirir. Küçük, yalnızca dahili kullanılan veya şablon ağırlıklı sınıflarda kazancı maliyetinden düşük olabilir. Buna karşılık sık değişen özel üyeleri bulunan, geniş kitlelere sunulan ya da kararlı ABI gerektiren sınıflarda oldukça etkilidir.

Özetle Pimpl, her sınıfa serpilecek bir performans baharatı değil; derleme sınırlarını bilinçli biçimde yönetme aracıdır. Doğru yerde kullanıldığında başlık dosyalarını hafifletir, değişikliklerin yayılmasını sınırlar ve kütüphanenin perde arkasını özgürce yenilemenize imkân verir.

Rijit eklemler neden terk ediliyor?

Geleneksel robotlarda hareket, motorların döndürdüğü rijit bağlantılar ve eklemler üzerinden gerçekleşir. Bu yapı otomobil fabrikası gibi kontrollü ortamlarda yüksek hız ve hassasiyet sağlar. Ancak robot bir insanla temas edecek, düzensiz bir zeminde ilerleyecek veya çilek tutacaksa sertlik dezavantaja dönüşebilir.

Yumuşak robotlar, doğadaki kasları ve dokuları taklit eder. Bir fil hortumu yüzlerce ayrı metal ekleme sahip değildir; malzemesinin sürekli biçimde değişmesi sayesinde bükülür. Bu yaklaşım sürekli deformasyon olarak adlandırılır. Robotun hareketi tek bir menteşede değil, gövdesinin tamamına dağılır.

Esnekliğin arkasındaki fizik

Bir elastik malzemenin temel davranışı basitleştirilmiş Hooke yasasıyla açıklanabilir:

Burada $\sigma$ gerilmeyi, $\varepsilon$ şekil değiştirme oranını ve $E$ Young modülünü temsil eder. Young modülü küçüldükçe malzeme daha kolay esner. Çelik yaklaşık $200\,GPa$ mertebesindeyken bazı silikon elastomerler $MPa$ düzeyindedir. Aradaki dev fark, silikon bir robot kolun neden adeta makarna gibi bükülebildiğini açıklar.

Fakat büyük deformasyonlarda Hooke yasası tek başına yeterli değildir. Yumuşak robotların bilgisayar modellerinde hiperelastik malzeme denklemleri ve sonlu elemanlar analizi kullanılır. Başka bir deyişle, robotun nereye kıvrılacağını hesaplamak metal bir kolun açısını bulmaktan daha zahmetlidir.

Hareket nasıl üretiliyor?

En yaygın yöntemlerden biri pnömatik eyleyicilerdir. Silikon gövde içindeki odacıklara hava basıldığında bir taraf diğerinden fazla genişler ve parça bükülür. Hidrolik sıvılar, şekil hafızalı alaşımlar, elektroaktif polimerler ve çekme kabloları da kullanılabilir.

Basıncın oluşturduğu yaklaşık kuvvet şu ilişkiyle düşünülebilir:

$P$ iç basınç, $A$ ise basıncın etkilediği alandır. Alan veya basınç arttıkça kuvvet büyür; ancak fazla basınç robotu güçlü bir balon gibi patlatabilir. Mühendisliğin eğlenceli kısmı tam da güç ile esneklik arasındaki bu dengedir.

Aşağıdaki Python kodu, basınç arttıkça ideal bir eyleyicinin kuvvetini hesaplar:

areas = 0.0008  # Etkin yüzey alanı: metrekare
pressures = [20_000, 40_000, 60_000, 80_000]  # Pascal

for pressure in pressures:
    force = pressure * areas
    print(f"{pressure / 1000:.0f} kPa -> {force:.1f} N")

Bu basit model kayıpları ve malzeme doğrusal olmayanlığını hesaba katmaz; yine de eyleyici boyutlandırmasının ilk adımını gösterir.

Nerelerde kullanılıyor?

Yumuşak tutucular gıda sektöründe domates, yumurta ve meyve toplayabilir. Tıp alanında vücuda uyum sağlayan rehabilitasyon eldivenleri ve minimal invaziv cerrahi araçları geliştirilmektedir. Arama-kurtarma robotları ise dar boşluklardan geçmek için gövdelerini sıkıştırabilir.

Elbette teknoloji kusursuz değildir. Esnek malzemeler zamanla yorulabilir, delinmeler oluşabilir ve konum kontrolü zorlaşabilir. Buna rağmen sensörlerin doğrudan malzemeye gömülmesi ve kendi kendini onaran polimerlerin gelişmesi önemli ilerlemeler vadediyor. Geleceğin robotu muhtemelen yalnızca daha zeki değil, aynı zamanda daha yumuşak olacak.

``

Düğüm nedir?

Düğüm, belirli bir sorumluluğu yerine getiren çalışan süreçtir. Örneğin bir mobil robotta şu düğümler bulunabilir:

• Kamera görüntüsünü yayımlayan kamera düğümü
• Engelleri belirleyen algılama düğümü
• Hedefe rota oluşturan planlama düğümü
• Tekerlek hızlarını yöneten motor düğümü

Bu yaklaşım tek sorumluluk ilkesini robotik dünyasına taşır. Bir düğümün iç algoritması değiştirildiğinde, iletişim sözleşmesi aynı kaldığı sürece diğer düğümlerin değiştirilmesi gerekmez. Başka bir deyişle modülerliği sağlayan şey yalnızca kodun bölünmesi değil, parçaların standart mesajlarla haberleşmesidir.

Mesajlaşma modülerliği nasıl oluşturur?

ROS’ta bir mesaj, alanları önceden tanımlanmış veri paketidir. Örneğin hız komutu doğrusal ve açısal hız içerebilir:

Burada $v$ doğrusal, $\omega$ ise açısal hızdır. Motor düğümü bu değerlerin hangi algoritmayla hesaplandığını bilmez; yalnızca mesajı alıp uygular. Böylece rota planlayıcı A* yerine başka bir algoritmaya geçirilse bile motor katmanı çalışmaya devam eder.

Gönderici ve alıcı arasındaki bağımlılık şu şekilde düşünülebilir:

İyi tasarlanmış bir ROS sisteminde düğümler birbirlerinin iç uygulamasını değil, yalnızca mesaj tipini ve iletişim kanalını bilir.

Topic ile gevşek bağlı iletişim

Topic sisteminde yayıncı, mesajı hangi düğümün dinlediğini bilmez. Abone de verinin iç sistemde nasıl üretildiğiyle ilgilenmez. Örneğin ROS 2 üzerinde basit bir hız yayıncısı şöyle yazılabilir:

import rclpy
from rclpy.node import Node
from geometry_msgs.msg import Twist

class HizYayinci(Node):
    def __init__(self):
        super().__init__('hiz_yayinci')
        self.publisher = self.create_publisher(Twist, '/cmd_vel', 10)
        self.timer = self.create_timer(0.5, self.hiz_gonder)

    def hiz_gonder(self):
        mesaj = Twist()
        mesaj.linear.x = 0.4
        mesaj.angular.z = 0.1
        self.publisher.publish(mesaj)

def main():
    rclpy.init()
    node = HizYayinci()
    rclpy.spin(node)
    node.destroy_node()
    rclpy.shutdown()

Bu düğüm her yarım saniyede /cmd_vel konusuna hız komutu gönderir. Aynı konuya gerçek motor sürücüsü, simülatör veya test düğümü abone olabilir. Yayıncı kodunun bunların hangisinin kullanıldığını bilmesine gerek yoktur. Bu özellik donanımın simülasyonla değiştirilmesini ve birim testlerinin hazırlanmasını kolaylaştırır.

ROS 1 ve ROS 2 açısından fark

ROS 1 merkezi keşif için roscore kullanırken ROS 2, DDS tabanlı dağıtık keşiften yararlanır. ROS 2 ayrıca QoS ayarlarıyla güvenilirlik, mesaj geçmişi ve teslim davranışını yapılandırabilir. Örneğin kamera görüntüsünde en güncel kare tercih edilirken kritik kontrol komutlarında güvenilir teslim seçilebilir.

Modülerliğin korunması için düğümleri küçük tutmak, standart mesaj tiplerini tercih etmek ve topic adlarını anlamlı belirlemek gerekir. Her şeyi yapan dev bir “mega node”, ROS kullanılsa bile sıkı bağımlılık yaratır. İyi bir ROS mimarisinde düğümler bağımsız müzisyenler, mesajlar notalar, topic’ler ise orkestranın iletişim kanallarıdır; uyum doğru arayüzlerden doğar.

``

Değişken genişletmesi nedir?

Shell bir komutu çalıştırmadan önce satır üzerinde çeşitli dönüşümler gerçekleştirir. $HOME veya ${USER} gibi ifadelerin değerleriyle değiştirilmesine parametre genişletmesi denir.

Bu süreci basitçe şöyle gösterebiliriz:

Örneğin USER=ada ise $USER ifadesinin genişletilmiş sonucu ada olur. Ancak bunun gerçekleşip gerçekleşmeyeceğini kullanılan tırnak türü belirler.

\vert Yazım \vert Değişken genişler mi? \vert Komut ikamesi çalışır mı? \vert Boşluklar korunur mu? \vert \vert —\vert —:\vert —:\vert —:\vert \vert $USER | Evet | Evet | Her zaman değil | | "$USER" \vert Evet \vert Evet \vert Evet \vert \vert '$USER' | Hayır | Hayır | Evet |

Tek tırnak: Her şey olduğu gibi

Tek tırnaklar arasındaki karakterler shell tarafından değişmez metin olarak değerlendirilir. $, ters eğik çizgi ve komut ikamesinde kullanılan karakterler özel anlamlarını kaybeder.

name="Deniz"

echo '$name'
echo 'Kullanıcı: $name'
echo 'Bugün: $(date)'

Çıktı şöyledir:

$name
Kullanıcı: $name
Bugün: $(date)

Shell burada değişkeni genişletmez ve date komutunu çalıştırmaz. Bu davranış düzenli ifadeler, SQL parçaları veya dolar işareti içeren sabit metinler yazarken oldukça kullanışlıdır.

Tek tırnağın küçük bir huysuzluğu vardır: Tek tırnak içinde başka bir tek tırnak doğrudan kullanılamaz. Parçaları birleştirmek gerekir:

echo 'Bugün hava güzel, değil mi?'
echo 'Ali'"'"'nin dosyası'

İkinci komut; tek tırnaklı Ali, çift tırnaklı tek tırnak karakteri ve yeniden tek tırnaklı metin olmak üzere üç bitişik parçayı birleştirir.

Çift tırnak: Kontrollü genişletme

Çift tırnaklar metni tek argüman olarak korurken değişken genişletmesine, komut ikamesine ve bazı kaçışlara izin verir.

name="Ada Lovelace"
project_count=3

echo "Merhaba, $name"
echo "Proje sayısı: ${project_count}"
echo "Tarih: $(date +%F)"

Burada $name genişler, fakat içindeki boşluk nedeniyle iki ayrı argümana bölünmez. ${project_count} yazımı ise değişken adının sınırlarını açıkça gösterir.

file="rapor final.txt"

rm $file      # İki ayrı dosya adı gibi yorumlanabilir
rm "$file"    # Tek bir dosya adı olarak gönderilir

Genel kural şudur: Özellikle dosya adlarında değişkenleri çift tırnakla kullanın. Bir değişkenin ürettiği sözcük sayısını kabaca şöyle düşünebiliriz:

Boş veya özel durumlar dışında çift tırnak, genişletilmiş değerin tek argüman kalmasını sağlar.

Tırnaksız kullanım neden riskli?

Tırnaksız değişkenler word splitting ve dosya adı genişletmesine maruz kalabilir:

pattern="*.log"
printf '<%s>\n' $pattern
printf '<%s>\n' "$pattern"

İlk komut mevcut .log dosyalarını listeleyebilir. İkincisi ise kelimesi kelimesine *.log yazdırır. Yani çift tırnak yalnızca estetik değil, davranışı öngörülebilir kılan bir güvenlik kemeridir.

Hızlı seçim rehberi

Özetle tek tırnak shell’e “hiçbir şeye dokunma”, çift tırnak ise “değişkenleri aç ama sonucu parçalama” der. Emin olmadığınızda "$variable" kullanmak çoğu shell betiğinde en güvenli ve en az sürprizli seçimdir.

Asıl sorun: Disk erişimi pahalıdır

RAM üzerindeki verilere erişmek son derece hızlıdır; ancak kalıcı veriler SSD veya sabit diskte tutulur. Diskten tek bir bayt yerine genellikle sayfa ya da blok adı verilen sabit boyutlu veri parçaları okunur. Bir sayfanın boyutu örneğin 4 KB, 8 KB veya 16 KB olabilir.

Bu nedenle disk tabanlı bir veri yapısında temel maliyet, yapılan karşılaştırmalar değil, okunan sayfa sayısıdır. Bir milyon kayıt arasında ikili arama teorik olarak

adım gerektirir. Fakat her düğüm ayrı bir disk sayfasındaysa yaklaşık 20 disk erişimi oldukça pahalı olabilir. B-ağaçları ise bir düğümde çok sayıda anahtar saklayarak ağacın dallanma katsayısını büyütür.

B-ağacının temel mantığı

İkili arama ağacındaki her düğüm en fazla iki çocuğa sahiptir. B-ağacında ise bir düğüm onlarca, hatta yüzlerce çocuk barındırabilir. Düğüm boyutu genellikle bir disk sayfasını dolduracak şekilde seçilir.

Bir B-ağacının dallanma katsayısı $m$ ise yaklaşık yüksekliği şöyledir:

Örneğin bir düğüm 100 çocuk gösterebiliyorsa bir milyon kayıt için:

Yani teorik olarak yalnızca üç sayfa okumasıyla hedef bölgeye ulaşılabilir. Üst düğümlerin önbellekte tutulması durumunda gerçek disk erişimi daha da azalır.

Arama nasıl gerçekleştirilir?

Her düğümde anahtarlar sıralı tutulur. Aranan değer düğümdeki anahtarlarla karşılaştırılır ve uygun çocuk sayfasına geçilir. Aşağıdaki sadeleştirilmiş Python kodu, bellekteki bir B-ağacı düğümünde bu yönlendirmeyi gösterir:

class BTreeNode:
    def __init__(self, keys, children=None, leaf=False):
        self.keys = keys
        self.children = children or []
        self.leaf = leaf

    def search(self, target):
        index = 0

        while index < len(self.keys) and target > self.keys[index]:
            index += 1

        if index < len(self.keys) and target == self.keys[index]:
            return self.keys[index]

        if self.leaf:
            return None

        return self.children[index].search(target)

Kod, önce hedefin hangi anahtar aralığında bulunduğunu belirler. Düğüm yaprak değilse yalnızca ilgili çocuğa ilerler. Gerçek veritabanlarında children listesindeki öğeler çoğunlukla nesne değil, disk sayfalarının adresleridir. Ayrıca düğüm içindeki arama doğrusal tarama yerine ikili aramayla yapılabilir.

Ekleme ve bölünme

Bir düğüm dolduğunda yeni kayıt gelişigüzel başka bir yere konmaz. Düğüm iki parçaya bölünür ve ortadaki anahtar üst düğüme taşınır. Üst düğüm de dolarsa bölünme köke kadar ilerleyebilir. Kök bölündüğünde ağacın yüksekliği yalnızca bir artar.

Bu kurallar bütün yaprakların aynı seviyede kalmasını sağlar. Böylece kötü sıralanmış eklemeler bile ağacı uzun bir zincire dönüştüremez. Arama, ekleme ve silme işlemlerinin maliyeti genel olarak $O(\log_m n)$ seviyesindedir.

B+ ağaçları neden daha yaygın?

Modern veritabanları çoğunlukla B-ağacının bir türevi olan B+ ağacını kullanır. İç düğümler yalnızca yönlendirme anahtarlarını içerirken gerçek kayıtlar yapraklarda saklanır. Yapraklar birbirine bağlı olduğundan WHERE yas BETWEEN 20 AND 30 gibi aralık sorguları, ilk kayıt bulunduktan sonra sayfalar üzerinde sıralı biçimde ilerleyebilir.

Kısacası B-ağaçlarının gücü yalnızca hızlı arama yapmalarından gelmez. Disk sayfalarıyla uyumlu çalışmaları, dengelerini korumaları ve yüksek dallanma katsayıları sayesinde milyonlarca kaydı birkaç disk erişimine indirgemeleri onları veritabanı indekslerinin vazgeçilmez kahramanı yapar.

``

Arayüz: Davranışın sözleşmesi

Arayüz, onu uygulayan türlerin sunması gereken üyeleri tanımlar. Genellikle durum saklamaz ve doğrudan örneklenemez. Böylece kod, belirli bir sınıfa değil davranışa bağımlı olur. Bu yaklaşım bağımlılıkların tersine çevrilmesini ve birim testlerini kolaylaştırır.

public interface IBildirimGonderici
{
    void Gonder(string alici, string mesaj);
}

public class EpostaGonderici : IBildirimGonderici
{
    public void Gonder(string alici, string mesaj)
    {
        Console.WriteLine($"E-posta gönderildi: {alici} - {mesaj}");
    }
}

Burada IBildirimGonderici, gönderimin nasıl yapılacağını açıklamaz; yalnızca Gonder davranışını zorunlu kılar. Daha sonra SMS veya mobil bildirim sınıfları aynı arayüzü uygulayabilir. Çağıran kodun hangi somut sınıfı kullandığını bilmesine gerek kalmaz.

Modern C# sürümlerinde arayüzler varsayılan metot gövdeleri ve statik üyeler içerebilse de temel amaçları hâlâ ortak davranış sınırı oluşturmaktır. Arayüzü, “Bu etiketi taşıyorsan şu yetenekleri sunmalısın” diyen bir kulüp üyeliği gibi düşünebiliriz.

Struct: Küçük ama ciddi bir değer tipi

struct, sınıflardan farklı olarak bir değer tipidir. Bir yapı değişkene atandığında çoğunlukla referansı değil, içindeki değerler kopyalanır.

public readonly struct Nokta
{
    public double X { get; }
    public double Y { get; }

    public Nokta(double x, double y)
    {
        X = x;
        Y = y;
    }

    public double Uzaklik() => Math.Sqrt(X * X + Y * Y);
}

Bu yapı iki boyutlu bir noktayı temsil eder. Öklid uzaklığı şu formülle hesaplanır:

readonly struct, oluşturulduktan sonra değerin değişmeyeceğini belirtir. Bu özellik hem niyeti açıklar hem de derleyicinin bazı gereksiz savunma kopyalarını azaltmasına yardımcı olabilir.

Temel farklar

\vert Özellik \vert Interface \vert Struct \vert \vert —\vert —\vert —\vert \vert Ana amacı \vert Davranış sözleşmesi tanımlamak \vert Küçük bir değeri temsil etmek \vert \vert Örneklenebilir mi? \vert Hayır \vert Evet \vert \vert Semantik \vert Uygulayan türe bağlı \vert Değer semantiği \vert \vert Kalıtım \vert Bir tür birden fazla arayüz uygulayabilir \vert Başka sınıf veya struct kalıtamaz \vert \vert Durum \vert Normal örnek alanı taşımaz \vert Alan ve özellik taşıyabilir \vert \vert null değeri \vert Referans üzerinden mümkün \vert Yalnızca Nullable<T> ile \vert

Birlikte kullanılabilirler mi?

Elbette! Bir yapı da arayüz uygulayabilir:

public interface IAlanHesaplayici
{
    double AlanHesapla();
}

public readonly struct Dikdortgen : IAlanHesaplayici
{
    public double En { get; }
    public double Boy { get; }

    public Dikdortgen(double en, double boy) => (En, Boy) = (en, boy);

    public double AlanHesapla() => En * Boy;
}

Ancak yapı, arayüz türündeki bir değişkene atanırsa boxing oluşabilir. Boxing sırasında değer, yönetilen yığında bir nesne içine sarılır. Yaklaşık maliyeti yalnızca veri boyutu $S$ değil, nesne başlığı $H$ ile birlikte kabaca $S + H$ olarak düşünülebilir. Sık çalışan döngülerde bu tahsisler çöp toplayıcı üzerinde baskı yaratır. Generic kısıtlar, bazı senaryolarda boxing maliyetini önleyebilir.

Sınırlar ve seçim rehberi

Struct; küçük, mantıksal olarak tek bir değer olan ve tercihen değişmez veri modellerinde uygundur. Koordinat, renk, tarih aralığı veya ölçü birimi iyi adaylardır. Büyük struct’lar her atamada kopyalanabileceği için performansı tersine çevirebilir. Kimliği olan, uzun yaşayan veya sık değişen nesnelerde sınıf tercih edilmelidir.

Arayüz ise farklı türlerin ortak bir yeteneği paylaşması, bağımlılıkların soyutlanması veya test doubles kullanılması gerektiğinde güçlüdür. Kısacası arayüz “ne yapabilir?”, struct ise “hangi değeri temsil eder?” sorusuna cevap verir. Bu ayrımı korumak, hem temiz mimarinin hem de bilinçli bellek kullanımının anahtarıdır.

``

Değişkenin bellekteki yaşamı

Bir değişken tanımlanırken genel olarak veri_tipi isim = değer; kalıbı kullanılır. Örneğin int yas = 25; ifadesi, yas adında bir bellek alanı oluşturur ve buraya 25 değerini yazar.

#include <stdio.h>

int main(void) {
    int yas = 25;
    float sicaklik = 22.5f;
    char seviye = 'A';

    printf("Yaş: %d\n", yas);
    printf("Sıcaklık: %.1f\n", sicaklik);
    printf("Seviye: %c\n", seviye);
    return 0;
}

Burada int tam sayıları, float ondalıklı sayıları, char ise tek bir karakteri saklar. Karakterler bellekte aslında sayısal kodlar hâlinde tutulur. Örneğin ASCII sisteminde 'A' karakterinin karşılığı 65’tir.

Temel veri tipleri

C standardı bazı tiplerin kesin boyutunu değil, asgari kapasitesini ve birbirleriyle ilişkisini tanımlar. Bu nedenle aşağıdaki boyutlar yaygın sistemlerde görülen değerlerdir; kesin sonuç için sizeof kullanılmalıdır.

Bir tip $n$ bitlik işaretsiz bir tamsayı saklıyorsa değer aralığı genellikle $0$ ile $2^n-1$ arasındadır. İki’nin tümleyeni kullanılan işaretli sistemlerde yaklaşık aralık $-2^{n-1}$ ile $2^{n-1}-1$ olur. Örneğin 8 bitlik işaretsiz değer $0$–$255$ aralığını kapsar.

#include <stdio.h>

int main(void) {
    printf("int: %zu bayt\n", sizeof(int));
    printf("double: %zu bayt\n", sizeof(double));
    printf("char: %zu bayt\n", sizeof(char));
    return 0;
}

sizeof, türün veya değişkenin kaç bayt kapladığını döndürür. Sonuç size_t tipinde olduğu için %zu biçim belirteci kullanılır.

Niteleyiciler neyi değiştirir?

short, long, signed ve unsigned, tamsayı tiplerinin kapasitesini veya işaret davranışını düzenler. const ve volatile ise erişim kurallarını belirtir.

volatile, özellikle mikrodenetleyici yazmaçlarında veya sinyal işleyicilerinde önemlidir. Derleyicinin değeri bir kez okuyup önbellekte tutmasını engeller; ancak değişkeni eşzamanlı erişime karşı güvenli yapmaz.

Sabit oluşturma yöntemleri

#include <stdint.h>

#define BUFFER_SIZE 256

enum { MAX_RETRY = 3 };

int main(void) {
    const double pi = 3.1415926535;
    uint32_t paket_no = 42U;
    double alan = pi * 5.0 * 5.0;
    return alan > 0.0 && paket_no < BUFFER_SIZE ? 0 : 1;
}

const, türü belli salt okunur bir nesne oluşturur. #define metinsel ön işlemci değişimidir ve tip denetimi sağlamaz. enum ise tamsayı sabitleri için kullanışlıdır. stdint.h içindeki uint32_t gibi tipler, mevcut olduklarında kesin bit genişliği sağlayarak taşınabilir veri formatlarında belirsizliği azaltır.

Sonuç olarak doğru veri tipi seçimi yalnızca bellek tasarrufu değildir; sayı taşmalarını, hassasiyet kaybını ve platformlar arası sürprizleri önleyen temel bir tasarım kararıdır. C, belleği gizlemek yerine size anahtarları verir; fakat hangi kapıyı açtığınıza dikkat etmek tamamen sizin sorumluluğunuzdadır.

``

Dizi Nedir?

Dizi, aynı veri türüne sahip sabit sayıda elemanın bellekte art arda tutulduğu veri yapısıdır. Beş öğrencinin notlarını saklamak için beş değişken tanımlamak yerine şöyle bir dizi oluşturabiliriz:

int notlar[5] = {78, 85, 92, 64, 90};

Burada notlar dizinin adı, int eleman türü ve 5 kapasitesidir. C dizilerinde indeksler sıfırdan başladığı için ilk eleman notlar[0], son eleman ise notlar[4] olur.

Bellekte Yerleşim Mantığı

Bir dizinin en önemli özelliği, elemanlarının ardışık adreslerde bulunmasıdır. Dizinin başlangıç adresi $B$, her elemanın boyutu $s$ bayt ise $i$ indeksli elemanın adresi şu formülle hesaplanır:

Örneğin int türünün 4 bayt olduğu bir sistemde başlangıç adresi 1000 olan dizinin A[3] elemanı şu adrestedir:

Bu doğrudan hesaplama sayesinde herhangi bir elemana erişim sabit zamanda gerçekleşir: $O(1)$. Bilgisayarın önceki elemanları tek tek gezmesi gerekmez.

#include <stdio.h>

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

    for (int i = 0; i < 4; i++) {
        printf("sayilar[%d] = %d, adres = %p\n",
               i, sayilar[i], (void *)&sayilar[i]);
    }

    return 0;
}

Bu program her elemanın değerini ve adresini gösterir. Çıktıdaki adres farklarının genellikle sizeof(int) kadar olduğunu görebilirsiniz. Böylece ardışık yerleşim yalnızca teori olmaktan çıkar, terminalde görünür hâle gelir.

Dizi Adı ve Pointer İlişkisi

Çoğu ifadede dizi adı, ilk elemanın adresine dönüşür. Bu nedenle sayilar ile &sayilar[0] aynı başlangıç konumunu gösterir. İndeksleme de pointer aritmetiğiyle yakından ilişkilidir:

int degerler[] = {5, 10, 15};
printf("%d\n", degerler[1]);
printf("%d\n", *(degerler + 1));

İki satır da 10 yazdırır. Ancak dizi ve pointer tamamen aynı kavram değildir. Dizi için ayrılmış alan sabittir; dizi adına yeni bir adres atanamaz. Pointer ise farklı adresleri gösterebilen ayrı bir değişkendir.

Dizileri Döngülerle Yönetmek

Dizilerin asıl gücü döngülerle ortaya çıkar. Aşağıdaki kod, notların toplamını ve ortalamasını hesaplar:

#include <stdio.h>

int main(void) {
    int notlar[] = {78, 85, 92, 64, 90};
    int adet = sizeof(notlar) / sizeof(notlar[0]);
    int toplam = 0;

    for (int i = 0; i < adet; i++) {
        toplam += notlar[i];
    }

    double ortalama = (double) toplam / adet;
    printf("Ortalama: %.2f\n", ortalama);
    return 0;
}

sizeof(notlar) / sizeof(notlar[0]) ifadesi toplam dizi boyutunu tek elemanın boyutuna bölerek eleman sayısını bulur. Bu yöntem yalnızca gerçek dizi aynı kapsamdayken güvenilirdir; fonksiyona aktarılan dizi parametresi pointer gibi davranır.

Sınırların Dışına Çıkma Tehlikesi

C, indeksleri otomatik olarak denetlemez. Beş elemanlı bir dizide notlar[5] kullanmak tanımsız davranıştır. Program çökebilir, yanlış sonuç üretebilir veya çalışıyor gibi görünebilir. En sinsi ihtimal de sonuncusudur!

Bu nedenle döngü koşullarında i < adet tercih edilmeli, i <= adet hatasından kaçınılmalıdır. Diziler hızlı ve verimlidir; fakat güvenlik kemerini programcı takar.

``

Fonksiyon çözümlemesinin iki perdesi

Niteliksiz bir f(x) çağrısında adaylar temel olarak iki kaynaktan gelir:

1. Normal niteliksiz isim araması: Çağrının bulunduğu kapsam, üst kapsamlar ve ilgili using bildirimleri incelenir.
2. Argument-Dependent Lookup (ADL): Argüman türleriyle ilişkili namespace ve sınıflardaki fonksiyonlar aranır.

Bunu kavramsal olarak şöyle gösterebiliriz:

Ardından overload resolution, uygulanabilir adaylar arasından dönüşümler bakımından en iyi olanı seçer. Yani ADL doğrudan kazananı belirlemez; yarışa yeni fonksiyonlar ekler.

ADL’nin sahneye çıkışı

Aşağıdaki fonksiyon çağrı noktasında açıkça içeri alınmamıştır:

#include <iostream>

namespace grafik {
    struct Nokta {
        int x;
        int y;
    };

    void yazdir(const Nokta& n) {
        std::cout << n.x << ", " << n.y << '\n';
    }
}

int main() {
    grafik::Nokta n{3, 7};
    yazdir(n); // ADL, grafik::yazdir fonksiyonunu bulur.
}

Nokta, grafik namespace’ine ait olduğu için bu namespace çağrıyla ilişkilendirilir. Argüman int olsaydı kullanıcı tanımlı ilişkili bir namespace bulunmayacağından aynı numara işe yaramazdı.

Çağrıyı ::yazdir(n) biçiminde nitelendirmek ise yalnızca global kapsamdaki ismi istemek anlamına gelir ve ADL katkısını ortadan kaldırır. Bu ayrım, hata ayıklarken oldukça değerlidir.

Gizli arkadaşlar: Kontrollü görünürlük

ADL’nin en güçlü kullanım alanlarından biri sınıf içinde tanımlanan friend fonksiyonlardır:

#include <compare>

namespace matematik {
    class Kesir {
        int pay;
        int payda;

    public:
        Kesir(int p, int q) : pay(p), payda(q) {}

        friend bool operator==(const Kesir& a, const Kesir& b) {
            return a.pay * b.payda == b.pay * a.payda;
        }
    };
}

Bu operatör normal namespace aramasında kolayca görünmez; fakat Kesir argümanlarıyla yapılan a == b ifadesinde ADL tarafından bulunur. Böylece namespace yüzeyi gereksiz fonksiyonlarla kirletilmeden türe ait işlem sunulur. Buna hidden friend idiomu denir.

swap kalıbı neden önemlidir?

Genel kodda yalnızca std::swap(a, b) yazmak, kullanıcı türünün kendi optimize edilmiş swap fonksiyonunu engelleyebilir. Geleneksel çözüm şöyledir:

using std::swap;
swap(a, b);

İlk satır standart sürümü yedek aday yapar. İkinci satır niteliksiz çağrı olduğu için ADL’ye izin verir. Türün namespace’inde daha uygun bir swap varsa overload resolution onu seçer; yoksa std::swap kullanılır.

Sürprizlerden korunma rehberi

Aynı isimli fonksiyonları geniş namespace’lere gelişigüzel yerleştirmek beklenmeyen belirsizlikler oluşturabilir. Özellikle bir çağrının argüman türü değiştiğinde ilişkili namespace kümesi de değişebilir. Şablonlarda bu etki daha belirgindir; bağımlı çağrıların bazı adayları ancak şablon örneklendiğinde belirlenir.

Kütüphane tasarlarken işlemleri ilgili türle aynı namespace’e koymak, global kapsamı kirletmemek ve özelleştirilebilir işlemlerde niteliksiz çağrı kullanmak iyi bir dengedir. Bir çağrının gizemli davrandığı durumlarda ise şu soruyu sorun: “Bu fonksiyon normal aramayla mı geldi, yoksa argümanlardan biri ADL için gizli bir kapı mı açtı?”