Rust Dili C veya C++'a Alternatif Olabilir mi?

Rust
, ,
21

Sittin senedir aktif olarak kullanilan, bunun bilmemkac yili default sistem programlama dili, dillerin lingua franca’si olan dili bilmek, hatta ustune 10-20 yil da kullanmak niye pismanlik olsun? Ileride bu topraklarda baska memleket kurulursa bu ulkede yasadigina pisman mi olacaksin mesela?

Tabi ki oyle. Blub paradox’u da okumak isteyebilirsin.

Arastirmana hangi diller olduklarindan baslayabilirsin :slight_smile: D geliyo aklima. P, C* filan diye salliycam. Belki Go.

Readme’sinin ilk cumlesi daha buyuk bir projeye link veriyor.

5 Beğeni
22

Ben @aib’in bunu demek istediğini sanmıyorum. Bu yaşadığınız daha çok dile alışık olmamanızdan kaynaklı olabilir. Ben bu kodu birkaç dakikada yazabiliyorum, ki ben de çok Rust kodu yazdığımı söyleyemem:

struct Fibonacci {
    previous: u128,
    current: u128,
}

impl Fibonacci {
    fn new() -> Self {
        Self {
            previous: 0,
            current: 1,
        }
    }
}

impl Iterator for Fibonacci {
    type Item = u128;

    fn next(&mut self) -> Option<Self::Item> {
        let result = self.previous;
        self.previous = self.current;
        self.current = result + self.previous;
        Some(result)
    }
}

fn main() {
    let mut fib = Fibonacci::new();
    let num39: f64 = fib.nth(39 - 1).unwrap() as _;
    let num40: f64 = fib.next().unwrap() as _;
    println!("{}", num40 / num39);
}

Bunun bir örneğini görmek isteyenler buraya bakabilir. Bu da compiler explorer linki.

Bağımsız programların hafızaları hiçbir modern işletim sisteminde kesişmez. Eğer başka bir programa ait hafıza adresine erişmeye çalışırsanız segfault alırsınız.

Undefined behaviour’un başka uygulamaların hafızasını etkilemek ile hiçbir alakası yok.

Eğer bir array’ın veya vector’un kendisine ait olmayan adresini indekslemeye çalışırsanız Python’da olduğu gibi Rust’ta da çalışma anında bir hata alırsınız. Bu hatalara Rust’ta panic deniliyor ve uygulamanın durmasını gerektirecek kadar önemli hatalar gerçekleştiğinde panic oluşuyor.

Safe Rust’ta mümkün değil. unsafe kullanılırsa mümkün.

Undefined behaviour. Henüz hiçbir değer atamadığınız bir hafıza adresini (uninitialized memory) okumaya çalışıyorsunuz.

Malloc’un böyle bir garantisi yok, hatta hafızanın uninitialized olacağını söylüyor:

The malloc() function allocates size bytes and returns a pointer
to the allocated memory. The memory is not initialized.

Uninitialized memory ile alakalı bu yazıyı tavsiye ederim:

İşletim sistemi bunu yapsa bile sadece hafızayı bizim process’imize ilk verdiğinde yapar. Ondan sonrasında malloc aynı hafızayı fazlasına ihtiyaç duymadığı sürece kullanmaya devam edecek. Kesinlikle malloc’un her zaman 0 dolu bir hafıza döndürmesi gibi bir durum yok.

Kod yazarken hata yapabiliriz, yapıyoruz. Bu yüzden out of bounds olup olmadığını program kontrol ediyor. En azından geliştirme aşamasında bu kontrolü yapmak lazım. Yoksa hata yapsanız bile farkına varamayabilirsiniz.

5 Beğeni
23

Burada uninitialized memory konusunda bir örnek daha vermek istiyorum:

C:\Users\Ekrem\Desktop\Yeni klasör>type deney.c
#include <stdio.h>

int main() {
    int x;
    if(x == 0) {
        printf("x is zero");
    }
    if(x != 0) {
        printf("x is not zero");
    }
}
C:\Users\Ekrem\Desktop\Yeni klasör>clang deney.c -O3 -o deney && deney.exe

C:\Users\Ekrem\Desktop\Yeni klasör>

Bu kodda eğer x değişkenine herhangi bir değer atarsanız değeri ya 0 olacağı ya da 0 olmayacağı için ekrana illaki ya "x is zero" ya da "x is not zero" yazılır. Ancak kodu bu haliyle derleyip çalıştırınca ekrana hiçbir şey yazılmadığını görüyoruz. Yani iki if de çalışmıyor. Çünkü hiçbir değer atamadığımız bir hafıza adresini okumaya çalışıyoruz, bu da bir undefined behaviour’dur. Kodumuzda undefined behaviour bulunması uygulamanın herhangi bir şey yapmasına sebep olabilir. Undefined behaviour içeren bir kodun çalıştırıldığında ne yapacağı hakkında dilin kuralları çerçevesinde bir mantık yürütülemez. Undefined behaviour içeren bir C kodu artık geçerli bir C kodu değildir.

2 Beğeni
24

Teşekkürler @EkremDincel hocam :smiling_face_with_three_hearts:

Hocam bunu derken kastettiğim şey, geliştirme aşamasında kontrol yapmamak değil. Dediğim şey, mesela Python da kod yorumlanıyor mesela, out of bounds olduğunda hata fırlatıyor. Program out of bounds kontrolü için efor harcamak zorunda(kaynağım yok, yalnızca şu var, ama ben diyorum ki, bu eforu program’a harcatacagima kendim harcarim bu eforu, daha etkili bir kod yazarım daha iyi diyorum.

Üstte yazdığım posttan bir alıntı

Aynı linkte The C++ guiding principle is "you don't pay for what you don't use". If your code is correct, you don't need bounds-checking, and you shouldn't be forced to pay for the overhead of runtime bounds-checking. demiş.

Zaten yazılım geliştirirken hep kontrol ediyorum gdb olsun valgrind olsun vs. vs. , Yoksa uzaylı değiliz :slight_smile:

Çok sağ olun, öğrendiğim yanlış bilgimi sayenizde düzelteceğim. Hocanın slayttaki kodlardan biri üzerine araştırmıştım ben de, şimdi tam anlamıyla taşlar oturdu gibi :pray:

2 Beğeni
25

Sanırım yarını düşüneyim derken bugünü ıskaladım :confused:. Bu farklı bakış açısı ile bütünü görmemi sağladığınız için teşekkür ederim.

O zaman Rust’ın kullanımının az olmasını göz ardı etmeliyiz.

Doğru sonuçlar için nasıl bir arama sorgusu yazacağımı bilemediğim için sormuştum. :slight_smile:

Bunu merak edip araştırdım ama bir şey bulamadım.

Hmm… sanırım haklısınız.

Bu konu üzerinde epey bir araştırma yapıp düşündükten ve pek çok kez fikir değiştirdikten sonra şöyle bir karar verdim:

C, bilgisayarın tüm gücünü bir sınırlama olmaksızın doğrudan programcıya veren çok güçlü bir dil. C bilmenin faydalı olduğuna katılıyorum ama şuan böyle büyük bir gücü yönetebileceğimi sanmıyorum.

Rust ise keşfettikçe daha çok hayran olduğum bir dil. Özellikle de diğer dillerle entegre olabilmesi(FFI), gerektiğinde C ile destekleyebileceğim anlamına geliyor.

Bu sebeple hem C, hem Rust öğreneceğim ama gerekmedikçe C kullanmayacağım.

Kararımda etkili olan diğer kaynaklar:

Rust FFI ile ilgili birkaç örnek:

Ayrıca bu kadar bahsi geçtikten sonra merak edip de Rust öğrenmek isteyenler için Tour of Rust’ı önerebilirim.

Benim için çok keyifli ve faydalı bir tartışma oldu, katkıda bulunan herkese çok teşekkür ederim. :slight_smile:

4 Beğeni
26

@EkremDincel hocamız böyle bir şey yazmıştı. Bence bu, tam nokta atışı bir cevap. Ben olayı yanlış anlamışım, bu cevap sayesinde bir UB’nin neden bir felakete dönüşebileceğini anladım. Bu linke bakmadiysan kesinlikle bakmanı tavsiye ediyorum.

Bu arada ben de bir iki örnek yapmak istiyorum.

Eğer wikipedia’yı bir incelemek istersen Undefined behavior - Wikipedia bu linkteki risks bölümüne göz atabilirsin.

Undefined behavior can lead to security vulnerabilities in software. For example, buffer overflows and other security vulnerabilities in the major web browsers are due to undefined behavior. The Year 2038 problem is another example due to signed integer overflow.

Şimdi burada güvenlik açıklarından bahsetmiş. Hacking ilgi alanım değil ama çok basit bir örnek yapalım. Stack Smashing Atttack

Kaynağım şu linktir.
Şimdi bizim basit bir programımız olsun.

override.c

#include <stdio.h>
#include <string.h>
int main(){
	char realPassword[20];
	char givenPassword[20];

	strncpy(realPassword, "ddddddddddddddd", 20);
	gets(givenPassword);
	
	if (0 == strncmp(givenPassword, realPassword, 20)){
		printf("SUCCESS!\n");
	}else{
		printf("FAILURE!\n");
	}
	printf("givenPassword: %s\n", givenPassword);
	printf("realPassword: %s\n", realPassword);
	return 0;
}

Bu programımızı

gcc override.c -o override -fno-stack-protector

komutuyla derleyelim.
Aşağıdaki uyarıyı verecek ama derleyecek

/usr/bin/ld: /tmp/ccLYY7Kk.o: in function `main':
my.c:(.text+0x31): warning: the `gets' function is dangerous and should not be used.

şimdi programı önce şu inputu girelim.

test

output:

FAILURE!
givenPassword: test
realPassword: ddddddddddddddd

Şimdi ise şu input’u verelim.

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

output FAILURE! olması gerekirken output:

SUCCESS!
givenPassword: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
realPassword : aaaaaaaaaaaaaaaaaaaaaaaaaaaa

Anlatmak istediğim ufak bir örnek daha var ama bu örneği de yarın edit olarak vereyim, ama link burada

1 Beğeni
27

Bu yanlış anlaşılma için özür dilerim, ben Undefined Behaviour’ları anladım(“Dilin standartları/tanımları dışına çıkan ve sonucu çoğu zaman öngörülemez, istenmeyen ve tehlikeli olan programlama hataları.” değil mi?). Benim merak ettiğim gerçenten C/C++ ile ekran kartını yakan/yakabilen birilerinin olup olmadığıydı. :slight_smile:

28

Evet.

Bunu bilmiyorum. Bu arada bu örneği postumdan kaldırdım, iyi bir örnek değil, yanlış bir örnek verdiğim için özür dilerim.

29

Bence olamaz çünkü C++ ’ a yapılan destek çok daha fazla Rust dilinden. Mesela bir sürü oyun yapma aracı var C++ için. Bir sürü ara yüz modülü var. Bir sürü güzel modüller var. Fakat bildiğim kadarıyla Rust ’ da pek fazla yok.

30

Bunun sebebi basit: Rust 6, C++ 36 yıl önce çıktı.

Hem az önce baktığım kadarıyla pek de öyle değil:

Ayrıca:

31

Evet haklısın, ama bu C++ ’ in bu konuda önde olduğu gerçeğini değiştirmiyor. Mesela bir çok oyun yapma toolu C++ kullanıyor. Bir çok arayüz geliştirme programı var (Mesela Qt designer)
Tools for C/C++ Programming (jmu.edu)

Ben geliştirilemez demedim. C++ daha üstün dedim. Ayrıca evet C++ daha üstün ama eğer Rust dili C++ ’ den kolaysa öğrenebilirsin belki işine yarar.

32

Butun (cogu) dillerin FFI’si var. C’nin olayi zaten butun dillerin FFI hedefi olmak.

33

Öncelikte tüm mesajları okuyamadığım için özür diliyorum. Sevdiğim bir katılımcı kardeşimin mesajına bakmak için girmişken konuyu gördüm. Sadece kendi fikrimce sorularına cevap vermeye çalışacağım.

Yaptığım tespitler kesinlikle mutlak doğru değil kişisel kanaatlerimden ibarettir. Bu nedenle aynı fikirde olmamanıza, itiraz etmenize saygı duyarım.

Bir çok konu bir arada olduğundan uzatırsam özür dilerim. Olabildiğince kısa tutmaya çalışacağım.

Python da güzel kullanışlı bir dildir, dolaylı olarak yürütülebilir ikili dosyaya dönüştürülebilir. Bu bir kenarda aklımızda dursun.

Neden C ve/veya C++ tavsiye edilir.

Basit, programları işletim sistemleri üzerinde çalıştırıyoruz. İşletim sistemleri de dokümantasyonunu çoğunlukla C dili üzerinden yapıyor (du). Yani işletim sistemi yeteneklerinden faydalanmak istediğimizde açıp dokümandan ilgili API’yi çağıracağımız parametre ve fonksiyonları alabiliyor ve doğrudan kodumuza aktarabiliyoruz.

Ama bu bir zorunluluk değil, aynı API leri bir dönem ihtiyaç duyduğumda Delphi dili için çevirerek kullanabileceğimi ve en az C performansında çalıştırabildiğimi gördüğümde bunu bir zorunluluk olmadığını anlayabildim.

Ve fakat bu dönüşümleri hazır yapan kütüphaneler de olmasına rağmen bazan kendimi rahat hissedemediğimden C ile çalışmaya döndüğüm oldu.

Yazılımla ilgilendiğim günden beri, hangi dil iyi yada hangisi performanslı kavgasının bittiğini görmedim. Göreceğimi de sanmıyorum.

Bu nedenle hangi dil dendiğinde hepsi derim. Yani çatalın görevi ayrı kaşığın görevi ayrı bıçağın görevi ap ayrı. Ama zorda kalırsan çatalın kenarını bıçak gibi, bıçağın yan tarafını kaşık gibi kullanabilirsin. Yani güçlü ve güçsüz olduğu yönleri var ama bu çok da sınırlayıcı güçsüzlükler diyemem.

C ve C++ öğrenmenin şu faydalarını göreceksiniz, Python, C#, java gibi aklınıza gelebilecek dilin yazım şeklinin (syntax) aşağı yukarı aynı olduğunu, ama anahtar kelimelerinin (keywords) farklı olabileceğini. Bu nedenle bunlara dil mi demek gerekir aynı dilin lehçeleri mi demek gerekir tekrar düşünmek gerekir (Bu benim teorim).

Yani C ve C++ ile ilgili çalışan biri, diğer bir çok dili okuyup kodun ne yapmak istediğini anlayabilir.

BASIC veya PASCAL gibi dillerin yazımı oldukça farklıdır. Bunlara ayrı diller demeyi tercih edebilirim. Yani küme parantezi arasına kod yazılan bir dil ile begin end kelimelerinin arasına kod yazılan bir dilin bir birine yakın olduğu söylenemezken, C,C#, Python, java gibi bir çok dil aşağı yukarı aynı şekilde yazılır/kodlanır.

Buraya kadar soruların bir kısmını cevapladığımı düşünüyorum. Konu performans olunca kavga kıyamet kopar zaten asıl benim dilim hızlı hayır onun dili yavaş.

Öncelikle şurada anlaşalım. Bilgisayarın anladığı tek dil 1 ve 0 ve sonuçta her şey 1 ve 0 a dönüştürülür. Burada diller sadece bizim anlamamız için. Anladığımızı 1 ve 0 a çeviren yazılımlar derleyiciler (compiler) ve bağlayıcılar (linker) lardır.

Bu durumda C ve C++ öğrenmenin faydalarında hemfikirsek, ikinci tavsiyem. Derleyici (IDE konusuna girmiyorum, aslında IDE nin derleyici dışındaki tüm diğer ayarlarını da öğrenin.) öğrenin. Derleyiciler sadece içine kod yazılan editörü bulunan run deyince kodda hata varsa gösteren yoksa çalıştıran yazılımlar değildir. Derleyicilerinizin ayarları size bir çok seçenek sunar derleme ve bağlama aşamalarının hangi şekilde yapılacağını ayarlayarak, optimizasyon seçeneklerini düzenleyerek herhangi bir dili başka bir dilden daha hızlı gösterebilirsiniz. Yani derleyicinizde compile like C seçeneği varsa C gibi derleyebilir dahi. Sonuçta sizin nasıl kodladığınız değil kodun nasıl 1 ve 0 lara dönüştürüldüğü önemli dediğimi hatırlatıyorum.

Bu nedenle dillerin hız ve performans verilerine çok takılmayın. Bir çok derleyici inline assembler denilen, satır içi assembly kodu girmenize bile olanak sağlayan özellikler barındırdığından, kullandığınız dilin içine assembly kodu gömerek dahi farklar yaratabilirsiniz.

En iyi dile harici dinamik kütüphaneler kullandırarak, en yavaş denilen dile inline kodlar ekleyerek hızlıyı yavaş yavaşı hızlı gösterebilirsiniz. Çatal kaşık bıçak örneğindeki gibi o kadar farklı yaklaşımları vardır ki, hıza göre sıralayacaksanız yaklaşımları modifiye etmeniz gerekir. Bıçağa çorba içirip, çatala et kestirirseniz hız konusunda beklediğinizi alamazsınız.

Burada size iki hap verirler kırmızı hapı ve mavi hapı. Mavi hapı alıp matrix te mutlu mesut yaşayabilirsiniz.

Kırmızı hap matrix ten çıkışa götürür.

Görecekleriniz artık hoşunuza gitmeyecektir.

Mavi hapı yutanlar, yüksek seviye diye sınıflandırılan (Bu sınıflandırmaya katılmıyorum ama ayrı bir yazı konusu olacak kadar uzun) dillere yönelmelidirler. Bu diller tip kontrolü yaptıkları için atama hataları, bellek taşmaları gibi derlteri olmadan zengin kütüphaneleri ile mutlu mesut yaşarlar (İstisnası derleyici hatalarından dolayı benzer sorunlar nadiren oluşur kullanıcı elinde olmadığından bir sonraki güncellemede ortadan kaldırılır) Nadiren, sınırlara yaklaşmaları gerektiğinden mutlu mesut yaşamlarına devam edebilirler.

İstisnai durumlarda bazı müdahaleleri yapamadıklarını hisseder bu durumda ancak bir alt seviye dillere geçerler. Mesela hazır bir string değişkeninin sınırına takıldıklarında bunu genişletebilecek imkanları olmadığını farkettiklerinde artık kendi string sınırlarını ayarlayabilecekleri bir dil aramaya başlayabilirler. Yada hiç kafa yormayıp bunu kendileri için hazır eden bir başkasını kodunu kullanabilirler. Yadırgamam saygı duyarım. Bazen projenin çapına göre kafa yormak istemediğimde yada asıl amacım başka olan kodları hızlıca test etmek istediğimde bu mavi hap tarafında dilleri kullanırım.

Gelelim kırmızı hapı tercih edenlere… (aslında her cümlede üç nokta kullanırdım gece yarısı bitkin ve kafam başka konularla meşgul olduğundan bu şekilde bir tek üç satırla yetineceğim.)

Kırmızı hapı yutanlar, dikey bir öğrenme çizgisine girerler. Çok öğrenir hiç ilerlemediklerini görürler, çünkü burada her şey serbesttir ve her şeyi sizin düşünüp kontrol etmeniz gerekir.Matrix teki gibi düştüğünüzde yeniden kalkamayabilirsiniz. Gerçekten ölebilirsiniz.

Hangi bellek adresine zıpladığınıza (jump) hangi işaretçileri kullandığınıza (Pointer) hangi yığın adreslerine baktığınıza emin olmanız gerekir.

Bunları bilerek yaparsanız, sınırlı güvenli yüksek seviyeli dillerin sınırlamalarının hepsi sizin için kalkmıştır. Artık verileri byte byte değil bit bit işleyebilirsiniz, string sınırlarınız, donanımsal belleğinizle sınırlı olabilir.

Bunları yapabilmeyi öğrenmekle, donanımın nasıl çalıştığını anlamaya başlarsınız, işletim sisteminizin nasıl çalıştığını kavrar, sık gerekmese de ihtiyaç olduğunda başkalarının yapamadığı yeni özelliklerine kolayca erişebilirsiniz.

Bunu şuna benzetebiliriz, kimi tuğla alıp binasını yapmayı tercih eder uymayan tuğlayı kırar, kimi ise tuğla yapmayı da öğrenmiştir ve istediği boyda tuğlalar üreterek kırmadan kullanabilir. İşte C ve Assembly gibi dillere geçtikçe kendi istediğiniz boyda tuğlalar üretebilecek hale gelmişsiniz demektir.

Ülkede hoşlanmadığım bir özellik vardır. Bir şeyin standart ve olağan halini öğrenmeden, olağan dışı veya extrem diyebilecek özelliklerini konuşmayı tercih ederler. Yani her türlü algoritmayı sindirmiş, yapısal programlamayı kavramış her şeyin sınırlarında kodlarda yetersiz kalmış OOP konuşmaya başlamışlar durumu bana komik geliyor (Şahsi kanaatim alınmaca yok.)

Dönüp yazdığınız kodalara bakın iki bin üç bin satırın üzerine kaç defa çıktınız ki tasarlama yada okuma sorunu yaşadınız da nesneye yönelik programlama ihtiyacı duydunuz desem bilmem burada bir kaç kişi dışında gerçekten sayıca fazla kişi çıkar mı?

Nesneye yönelik programlama kötü değildir, ama iyi de değildir. Aynı C öğrenme eğrisi gibi dik bir hale gelebilir. Ama öğrendiğinize değer mi tartışmaya açık. Aslında daha önce bir yerlerde rastlamış olabilirsiniz:

Amazon.com: C++ Gotchas: Avoiding Common Problems in Coding and Design: 9780321125187: Dewhurst, Stephen C.: Books

C++ dilinde bir nesne türetiyoruz ve sonra bunu mu yapar bunu mu yapar diye kafa yoruyoruz. Göreceksiniz ki gerçekten C++ da tam bir nesneye yönelik dil değil. Operatör atama, öncelikler çağırma sekansları derleyicilerin dahi kafasını karıştırabiliyor.

Nesneye yönelik programlama anlatmayı düşünmüyorum. Kapsülleme, polimorfizm (Türkçe çok şekillik demek yerine elastikiyeet desem daha Türkçe olur mu bilemediğimden olduğu gibi kullandım.) Gibi konular sayfalarca yazı bulabilirsiniz. Malum extrem olunca konuşanı çok ama bazan basit bir algoritma için bir satır açıklama yada konuşanı bulamazsınız.

Nasıl gerekti neden OOP öğrenmek zorunda kaldım. Windows işletim sisteminde saf windows c kodu yazmaya çalıştığım bir dönemde ( Şaşırmayın, windows 3.1 bir işletim sisteminde küçük ve çok yer kaplamayan bir kod yazmanız gerektiğinde olabildiğince windows API’si çağırmanız gerekiyor ve hazır kütüphaneler yerine kendi kodlarınızda pencere ve butonlar oluşturmanız gerekiyor ki küçük bir kodunuz olsun.) basit bir windos penceresi oluşturmak için bir çok yapı oluşturmam gerektiği, bazı callback fonskiyonlar tanımlamam bazı değişken ve yapılara ilk değerler atamam gerektiğini gördüm. Yani oluşturduğunuz pencerenin simge durumuna küçült butonunu bile sizin atamanız ve tanımlamanız gerekiyor. Ve arayüzü oluşturmak için verdiğim mücadele sırasında sayısız alt pencere buton ve diğer bileşenleri tek tek C kodunda tanımladığımda bunun daha kolay bir yolunun olması gerektiğine ikna oldum. İsteyen deneyebilir.

İnanmayan:
https://www.youtube.com/watch?v=6JJ8e5IZ8S4

Buradan deneyebilir.

Bununla sadece bir pencere oluşturabilirsiniz düşünün birden fazla buton ve pencere bileşenleriyle çalıştığınızda başınıza neler gelebileceğini.

Bu arada ufak not, video linkindeki koddaki class kavramının OOP ile alakası yoktur, windows kendi pencere oluşturma yapılarına class demeyi tercih etmiştir bu talihsiz tesadüf kafanızı karıştırmasın, kod tamamen c kodudur.

O kadar çok bileşen arasında kaybolduğunuzda, keşke fonksiyon gruplarını, yapıları, değişkenleri, ilk değer atamalarını bir seferde tanımlayabileceğim bir yapı olsa demeye başlarsınız.

Bu yapı ve kolaylık OOP ile sağlanır. Bir pencere oluşturmakla bir buton oluşturmak için aşağı yukarı aynı şeyleri yaptığınızı gördüğünüzde bunları değiştirip miras alarak polimorfizmin de ne olduğunu anlamaya başlarsınız.

Bu kadar uzun neden anlattım. Bazen kompakt küçük bir kod yazmak için OOP yerine kendiniz yazıp derlenmiş halini küçük tutmak isterken bazen proje büyüklüğünden kafa karışıklığı oluşmaması hızlı kodlama ve yer sıkıntısı olmamasından OOP seçebilirsiniz.

Bu birini diğerine üstün yapmadı iki seçenek sundu size. OOP mavi hap, saf C kodu ise C kodu.

Bu noktada yine kırmızı hapı seçenler artık OOP diye bir şey olmadığını kaşığı eğemeyeceklerini zihninde bu işi yaptıklarını öğrenmek zorunda kaldı. Yani teorik olarak fiilen böyle olmasada olan şey şu. Nasıl değişkenleri data segmentinde, fonksiyonları kod segmentinde tutuyorsa bellekte bilgiysayar bu sefer fonksiyonları da data segmentinde değişken gibi hayal edip, pointerlar aracılığıyla ilgili kodlara zıplayan işaretçi tabloları kullanıyor. Karışık oldu biliyorum ama kırmızı hapı yutanlar zamanla anlayacak.

Yani isterseniz bu kavramlarla C kodu ile de nesneye yönelik programlama yapabilisiniz (iddialı oldu biliyorum derleyici kısıtları var ama işaretçi tabloları üzerinden benzer yeteneklere sahip tanımlamalar yapabileceğinizi zorlarsanız çok daha farklı yetenekler kazanabileceğinizi göreceksiniz. İddialaşmayın şu ana kadar yapılamaz denilen ne varsa C de bir yolunun olduğunu gördüm. Hala ikna olmadıysanız herşeyin 1 ve 0 a dönüştürüldüğün ve hatta #define bildirimiyle mucizeler yaratıldığını gördüğümü de söyleyebilirim.) Ama C++ a tam anlamıyla nesneye yönelik bir dil değildir demişken C bunu tam hakkıyla yapar diyemem.

OOP adını duydunuz ve ihtiyacınız olduğunu anlamadıysanız muhtemelen henüz ihtiyacınız yok demektir. Ama OOP kavramak için kendinizi yorarken asıl diller konusunu ıskalayabileceğinizden çok da takılmamanızı tavsiye ederim.

Ufaktan delphi ye değinip geçeyim. Object pascal diye başlayıp kendini sürükle bırak mantığında bileşen ekleyecek kadar geliştiren bir dil. Bir çok nesne ile size kolaylık sağlar. Bazan arayüz derdi ile uğraşmak istemediğimde kodu denemek için kullandığımı belirtmiştim. Gerçekten de sürükle bırak formlarla çabucak arayüz oluşur size de bu bileşenlerin üzerine tıklayıp eventlerin içine ilgili kodu yazıp denemek kalır. Tadına bir bakın derim. Begin endlere boğulmadan eğlenemezsiniz.

Ama OPP anlamak için size oldukça güzel bir yol sunacaktır. C ve C++ ailesinin acılarını yaşamadan OOP deneyimi için delphi birebirdir. Neden tutmadı bu dil derseniz, ben çok üzüldüm aslında eli öpülesi dillerdendir türediği pascal.

Yeterince OOP konuştuğumu düşünüyorum.

Gelelim oyun geliştirme mevzuuna…

Aynı nedenle C ve C++ tercih edilir. Çünkü OpenGL de eski adı directX yeni adını takip edemediğim embeded durumdaki grafik arayüzü dokümantasyonlarının tamamı C dilindedir. Böyle olunca da bir çok kişi olduğu gibi referans kodları kullanır ve oyunları bununla yazar…

Bir hayır sahibi bu kodları diğer dillere çevirdiğinde onlar da kendi çapında performans sergilerler.

https://edn.embarcadero.com/article/26401

Not: Bazan servis cevap vermeye biliyor yukardaki link çalışmazsa google cache’inden bakabilirsiniz.

https://webcache.googleusercontent.com/search?q=cache:9MfGhTv2I5sJ:https://edn.embarcadero.com/article/26401+&cd=1&hl=tr&ct=clnk&gl=tr

Bir çok dilde performanslı kodlar yazabilirsiniz. Hatta. WebGL diye aratıp…

Web browser üzerinde html kodu ile mucizeler yaratıldığını görebilirsiniz…

https://webglsamples.org/aquarium/aquarium.html

Yani asıl işi işletim sistemi üzerinden yaptığınızda işletim sistemi ile iletişiminiz düzgün bir dilse oyun programlama da bir çok iş için gayet iyidir.

Burada tekraren özetleyeyim kısaca sonra da yazıya son vereyim.

Hangidili öğreneyim? Hepsini.

C /C++ öğrenmenin faydası ne? Diğer lehçeleri , işletim sistemlerini kolayca kavrayabilir diller arasında geçebilir hale gelirsin.

OOP önemli mi? Evet ve Hayır. İhtiyacın olduğunda ihtiyacın olur.

Hangisi hızlı? Hepsi düzgün ayarlar doğru yerde kullanırsan. Bazan hızlı kodlama, bazan az yer kaplama bazan hızlı çalışma gibi farklı özellikler gerekebilir. Çatal mı kaşık mı diye sorma çatal, kaşık, bıçak her birini ayrı ayrı kullanmayı öğren zaten ilerledikçe, tatlı çatalı ve tatlı bıçağı gibi alt ihtiyaçlarını da farkedeceksin.

Şu treni de kaçırmayın derim.

Kod yazmak zorunda değilsiniz.

Kodları görsel olarak sürükleyip bırakarak da kodlama yapılabiliyor.

https://www.postscapes.com/iot-visual-programming-tools/

Her ne kadar eskiden bizim görsel programlamadan anladığımız farklı olsa da bu kavram artık bu anlamda kullanılıyor.

Yani artık kodunuzu yazmak yerine kodunuzu çizmek gerekebilir.

Ve çok uzadı son nacizane tavsiyelerim:

Hangi dil? Hangisi hızlı? Hangisi iyi kavgalarından uzak durun. Henüz biten bir tartışma görmedim çünkü.

Bu kadar yazıyı sabırla okuyanlara kolaylıklar diliyorum. Uzamasın diye kırptığım yazmadığım atladığım hususlar oldu. Varsa yanlış anlaşılan kısımlar ihtiyaç olursa açıklamak üzere ara veriyorum.

Kendime not: Çok fazla yazım hatası var en kısa sürede elden geçirmem gerekiyor.

8 Beğeni
34

“Eğer derleyicilerin nasıl çalıştığını bilmiyorsanız, bilgisayarların nasıl çalıştığını da bilmiyorsunuz demektir. Eğer derleyicilerin tam olarak nasıl çalıştığından emin değilseniz, o halde nasıl çalıştıklarını bilmiyorsunuzdur.”— Steve Yegge

Her ne kadar doğru olsa da, acemi ile profesyonel yazılımcı arasındaki fark burada rahatça fark edilir, nasıl yazıldığının katkısı hiç yok diyemeyiz.

35

Hocam programlamaya başlamadım henüz, forumlarda dolaşıp teoriyi ve nerden başlamam gerektiğini çözmeye çalışıyorum. Çoğu forumda millet ödevini millete yaptırmaya çalışırken (Burada da var gerçi) bu konu acayip IQ içeriyor. Kaliteye bakar mısınız? Şu alıntıda demek istediğiniz koda geçse şöyle mi olurdu :

main.cpp (Yorum satırlarına takılmayın)

#include <windows.h>

/* This is where all the input to the window goes to */
LRESULT CALLBACK WndProc(HWND hwnd, UINT Message, WPARAM wParam, LPARAM lParam) {
	switch(Message) {
		
		/* Upon destruction, tell the main thread to stop */
		case WM_DESTROY: {
			PostQuitMessage(0);
			break;
		}
		
		/* All other messages (a lot of them) are processed using default procedures */
		default:
			return DefWindowProc(hwnd, Message, wParam, lParam);
	}
	return 0;
}

/* The 'main' function of Win32 GUI programs: this is where execution starts */
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
	WNDCLASSEX wc; /* A properties struct of our window */
	HWND hwnd; /* A 'HANDLE', hence the H, or a pointer to our window */
	MSG msg; /* A temporary location for all messages */

	/* zero out the struct and set the stuff we want to modify */
	memset(&wc,0,sizeof(wc));
	wc.cbSize		 = sizeof(WNDCLASSEX);
	wc.lpfnWndProc	 = WndProc; /* This is where we will send messages to */
	wc.hInstance	 = hInstance;
	wc.hCursor		 = LoadCursor(NULL, IDC_ARROW);
	
	/* White, COLOR_WINDOW is just a #define for a system color, try Ctrl+Clicking it */
	wc.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
	wc.lpszClassName = "WindowClass";
	wc.hIcon		 = LoadIcon(NULL, IDI_APPLICATION); /* Load a standard icon */
	wc.hIconSm		 = LoadIcon(NULL, IDI_APPLICATION); /* use the name "A" to use the project icon */

	if(!RegisterClassEx(&wc)) {
		MessageBox(NULL, "Window Registration Failed!","Error!",MB_ICONEXCLAMATION|MB_OK);
		return 0;
	}

	hwnd = CreateWindowEx(WS_EX_CLIENTEDGE,"WindowClass","Caption",WS_VISIBLE|WS_OVERLAPPEDWINDOW,
		CW_USEDEFAULT, /* x */
		CW_USEDEFAULT, /* y */
		640, /* width */
		480, /* height */
		NULL,NULL,hInstance,NULL);

	if(hwnd == NULL) {
		MessageBox(NULL, "Window Creation Failed!","Error!",MB_ICONEXCLAMATION|MB_OK);
		return 0;
	}

	/*
		This is the heart of our program where all input is processed and 
		sent to WndProc. Note that GetMessage blocks code flow until it receives something, so
		this loop will not produce unreasonably high CPU usage
	*/
	while(GetMessage(&msg, NULL, 0, 0) > 0) { /* If no error is received... */
		TranslateMessage(&msg); /* Translate key codes to chars if present */
		DispatchMessage(&msg); /* Send it to WndProc */
	}
	return msg.wParam;
}

Bu koca kodun çıktısı :
image

36

Merhaba sn xyz. Söyleminize katılırım anladığınız şekilde bakarsak tabi ki farklı dillerde farklı algoritmalarla aynı işi kodlarsanız, algoritması ve dilin özelliklerini düzgün kullanan daha performanslı olabilir.

Burada benim kastettiğimi tam ifade edememiş olmamdan kaynaklı sanırım. İfade etmek istediğim eşit koşullarda herhangi iki dil arasındaki durum ile biraz alakalı. Yani varsayımlarımız, dil özelliklerinin düzgün kullanıldığı, aynı algoritmaların kodlandığı gibi ideal koşullar için geçerli söylemim. Yani olabildiğince programcı/kodlayıcı bakış açısı farklılığı olmayan durumlar için konuşuyorum. Aksi halde sizin de belirttiğiniz gibi, Efsane bir dili koduyla katleden veya hantal bir dilde harikalar yaratan iki kodu da görebilmem mümkün.

Yani metnin bir yerinde ideal koşullarda şeklinde cümleye ekleme yapmam belki daha anlaşılır hale getirmemi sağlayabilir.

2 Beğeni
37

İlave windows form penceresi için bir iki çift satır da buraya ayrıca karalayayım. Evet kodun yaptığı sadece bir form oluşturmak.

Şimdi windows.h dosyasını include etmediğinizi var sayın. Ben böyle bir durumla uğraşmak zorunda kalmıştım. Asılda bu kod uzun değil, asıl arkasında sayısız yapı, değişken ve fonksiyon tanımlamaları barındıran windows.h dosyası.

Yani bir pencere oluşturmak için görünende çok daha fazla kod gerekiyor ve her seferinde bununla uğraşmak gerçekten yorucu olabilir.

Tarayıcı aramalarıyla C++ versiyonlarını da bulabilirsiniz. OOP kullandığı için hızla buton ve diğer bileşenleri de ekleyebildiğinizi hem c hem de c++ karşılıkları ile baktığınızda kolayca anlayabilirsiniz. Denemenizi tavsiye edebilirim.

Yani aslında benim linkte verdiğim, sizin de eklediğiniz koddan daha fazlası ile alakalı bir yoğunluk ve karmaşıklık var söz konusu winApi konusu ki sular seller yaz yaz bitecek bir konu değil burada.

İfade etmek istediğimi en kısa yoldan, windows.h dosyasını include etmeden tek tek tanımladığınızda kendiniz anlayabilirsiniz. (ki tavsiye etmem)

Mesela WNDCLASSEX yapısını bulup nelerden oluştuğunu bilmeniz gerekmekte.

Veya IDC_AROW aslında bir sayı o sayının ne olduğunu bilmeniz gerekmekte gibi.

Burada ilk mesajımın özünden kopmayalım. Bütün diller iyidir. Hepsi öğrenilir. Gözünüzde büyütmeyin.

Başka bir forumda yazdığım gibi. Programlama dili öğrenmek alfabe öğrenmek gibidir harfleri her öğrenen edebiyatçı olamaz. Programlamanın da edebiyatçıları var ve gördükçe saygı duyarım.

Kodlamayı herkes öğrenebilir ama kodlamanın edebiyatçısına programcı diyebilirim.

Tabi her zaman söylediğim gibi ifadelerim sadece kendi görüşüm karşıt görüşlere saygı duyarım.

2 Beğeni
38

Merhaba.

Öncelikle cevabınız için teşekkür ederim. Şu sıralar bir şeyler yazacak kadar vaktim yok. Lütfen kusura bakmayın.