dev c++'ı nasıl bilirsiniz?

[acehreli]

Ama dur!

Zaten Guru of the Week'leri (GoW) okuyorsan belki de kitabı almaya gerek yok. Çünkü GoW'ların düzenlenip kitap haline getirilmişidir.

Bu arada, toy olduğum dönemlerde (11 yıl olmuş!) GoW sorularından birisini doğru yanıtlamış ve anılmıştım:

http://groups.google.com/group/comp....b614e9e21bf563

Ali

[_Onk@_]

GotW üçüncü kez karşıma çıkıyor: Birincisi sizin define ile ilgili verdiğiniz bilgilerde (http://www.ceviz.net/makrolar-neler-...zlar_a395.html), ikincisi birkaç dakika önce araştırma yaparken, üçüncüsü ise şimdi.

Hocam ne yazık ki sahip olduğum İngilizce seviyesi GotW'u orjinal dilinde okuyacak kadar yeterli değil. En azından baskılı kitap üzerinde çeviri yapabilirim o yüzden basılı materyale sahip olmak istemiştim.

Sonuç olarak vardığım karar: C++'nin istisnaları ve kural esneklikleri yüzünden programınızın doğru şekilde yazıldığına ve çalışacağına hiçbir zaman tam anlamıyla emin olamazsınız. Hangi hataların göz ardı edileceği bilgisini ise ancak tecrübe ile kazanabilirsiniz. Tecrübe ise ihtiyacınız olduğunda yanınızda olmayan şeydir. O'nu o'nsuz elde etmelisiniz. Belki şimdiki çabamı D'ye yöneltsem çok daha iyi olacak http://www.ceviz.net/c-c/neden-d_a1290.html Tabi "İŞÇİ" teorime uyacağına karar verdiğim zaman.

Not: 'Ç' harfini yemişler, bari C++ehreli diye yazsalarmış

[acehreli]

Sonuç olarak vardığım karar: C++'nin istisnaları ve kural esneklikleri yüzünden programınızın doğru şekilde yazıldığına ve çalışacağına hiçbir zaman tam anlamıyla emin olamazsınız.

Söylediklerin ancak "exception-safety" gözardı edilmişse doğrudur. Hatalar karşısında da doğru çalışan kod yazmak mümkündür. Toplam 5 tane öğüt yeter:

- sonlandırıcı işlevlerden hata kaçmasına izin verme (sen atma, ve ya atan işlev çağırma ya da çağıracaksan hatayı yut)

- hiçbir zaman kod içinde açıkça kaynak geri verme; kaynaklar yalnızca ve yalnızca o kaynaktan sorumlu bir sonlandırıcı işlevde geri verilmelidir (RAII yöntemi C++'ça düşünmenin temelidir)

- işini önce yan tarafta hallet; nesnenin veya programın durumuna ancak o iş doğru çalışmışsa dokun

- hataları hiçbir zaman sonraya bırakma; sınıfları tasarlarken de akılda olsun

- işlevlere birden fazla görev verme

Hepsi o kadar. Benim aslında bunları içeren bir sunum var:

http://acehreli.org/turkcecpp/exception_safety.pdf

Türkiye'ye geldiğimde seve seve Türkçesini vermek isterim.

Bu arada, en son gösterdiğin iki 'int*' üye kullanan programın benzeri o sununun 41'inci sayfasında geçiyor. Neden çalışmadığı 42'inci sayfada anlatılıyor.

Hangi hataların göz ardı edileceği bilgisini ise ancak tecrübe ile kazanabilirsiniz.

C++'nın en büyük sorunlarından birisi o. Bilinecek çok şey var. :/

Tecrübe ise ihtiyacınız olduğunda yanınızda olmayan şeydir. O'nu o'nsuz elde etmelisiniz.

Ben zaten hep düşünmüşümdür: Haber grupları, forumlar, kitaplar, vs. olmasa; C++'nın gerektirdiği bilgiyi bir insanın kendi başına toparlaması bana çok zor geliyor.

Belki şimdiki çabamı D'ye yöneltsem çok daha iyi olacak http://www.ceviz.net/c-c/neden-d_a1290.html Tabi "İŞÇİ" teorime uyacağına karar verdiğim zaman.

Not: 'Ç' harfini yemişler

Bugüne kadar dürüst olarak insanları D konusunda hep uyardım: daha hazır değil diye. Ben kendi adıma yaptığım zaman yatırımından memnunum; ama başkalarını sanki D yaygın olacakmış gibi kandırmak istemedim.

Ama Andrei Alexandrescu'nun "The D Programming Language" adlı kitabı ufak tefek eksikleri dışında tamamlandı. Şu anda gözden geçme aşamasında ve Mayıs'ta çıkacak.

Bu, D2'nin tanımının da büyük ölçüde tamamlandığı anlamına geliyor. Bence D2 çok güzel, dinamik, ve olgun bir dil haline geldi. Eğer tutarsa Türkçe sitemiz var...

Ali

[_Onk@_]

Şimdi Hocam uygunsanız hatalar ile ilgili edindiğim bilgiler ve çıkardığım sonuçları birlikte ele alalım. Tamam bunu istemekle tembellik yaptığımın farkındayım fakat "çalışkan bir insan" olduğumu hiçbir zaman iddia etmedim

Hata: Uygulamanın çalışmasına engel olacak herhangi bir olgudur. İkiye ayrılırlar:
1. Ölümcül olan hatalar: Uygulamanın çökmesine ve sistem kaynak yönetiminin bozulmasına neden olan hatalardır. Erişilmemesi gereken bir bellek alanına erişim, platform için tanımlanmamış bir işlem (örneğin 0'a bölme) vs.
2. Ölümcül olmayan hatalar: Bir mantık ya da algoritma hatası oluşmasına rağmen uygulamanın çökmesine neden olmayan hatalardır. Büyük oranda "verinin" bozulması ve/veya yanlış çıktı verilmesi gibi.

Potansiyel hata kaynakları:
1. Dinamik bellek yerleşimi: Uygulama işletim sisteminden boş bellek alanı ister, eğer boş alan tahsis edilemezse malloc işlevi NULL değer döndürür. Mantık olarak uygulamanın istediği bellek alanı daha sonra kullanılacağı için dönen NULL değerinin yakalanması gereklidir. Ayrıca dinamik olarak istenilen alanın "işi bittiğinde" geri verilmesi gereklidir. Geri verilmeyen bellek alanı "memory leak - hafıza sızıntısı"na neden olabilmektedir.
2. Olmayan bir şeye erişmeye çalışmak.
3. Platform için tanımsız bir işlem yapmak.
4. Bir işleve ya da sınıfa "üzerinde işlem yapamayacağı" veriler göndermek.
5. Bu madde ve sonrası hakkında bir fikrim ne yazık ki yok

O zaman:
1. Aldığımız belleği "alabilmiş" olup olmadığımızı test etmeliyiz.
2. Aldığımız bellekle işimiz bitince geri vermeliyiz.
3. Erişeceğimiz dosyanın gerçekte orda olup olmadığına emin olmalıyız.
4. Verinin değişmesine gerek olmayacak alanlarda veriyi sabit (const) olarak nitelendirmeliyiz.
5. İşleve ve sınıfa değer ya da referans geçirirken verinin "işlenebilecek olduğundan" emin olmalıyız.
6. Bu madde ve sonrası hakkında bir fikrim yine yok

*Yaklaşık bir yıldır ceviz forumdaki tüm C/C++ konularını okumama rağmen istisna işlenmesi konusunda bu kadar az soru olmasına şaşırdığımı belirtmeliyim.

[acehreli]

Hata: Uygulamanın çalışmasına engel olacak herhangi bir olgudur. İkiye ayrılırlar:
1. Ölümcül olan hatalar: Uygulamanın çökmesine ve sistem kaynak yönetiminin bozulmasına neden olan hatalardır. Erişilmemesi gereken bir bellek alanına erişim, platform için tanımlanmamış bir işlem (örneğin 0'a bölme) vs.

Onları programcı hatası olarak değerlendirmeliyiz. Saydıklarının hepsi de yapılmaması gereken işlemler sonucunda oluşur. Yani programda bir hata var...

2. Ölümcül olmayan hatalar: Bir mantık ya da algoritma hatası oluşmasına rağmen uygulamanın çökmesine neden olmayan hatalardır. Büyük oranda "verinin" bozulması ve/veya yanlış çıktı verilmesi gibi.

Örneğin bir nükleer santralın kontrol programının ürettiği bir ara değer... Tam tersine, programın çalışmaya devam etmesi tam anlamıyla bir ölümcül hatadır.

Programın yanlış sonuçlarla devam etmemesi gerekir.

Potansiyel hata kaynakları:
1. Dinamik bellek yerleşimi: Uygulama işletim sisteminden boş bellek alanı ister, eğer boş alan tahsis edilemezse malloc işlevi NULL değer döndürür. Mantık olarak uygulamanın istediği bellek alanı daha sonra kullanılacağı için dönen NULL değerinin yakalanması gereklidir.

Her işlev, kendisini çağıranla bir sözleşme imzalamıştır: bana geçerli parametreler verirsen, ben de sana geçerli bir sonuç vereceğim.

Örneğin karekök alan bir işlev, "bana sıfır veya daha büyük bir değer verirsen ben de sana sıfır veya daha büyük bir sonuç vereceğim" der. Bu, sözleşmedir.

Bu sözleşme bozuk olduğunda hata atılmasından başka bir çare yoktur. Çünkü işlev, ya işini yapamaz; ya da sözleşmenin sonucunu garanti edememiştir.

malloc gibi C işlevlerinde sözleşmenin tanımı bile doğru dürüst yapılamaz: "benden bir miktar bellek iste, ben de sana o kadar belleği gösteren bir gösterge vereceğim... ama... bazen de vermeyeceğim." Bana pek bir sözleşme gibi gelmiyor...

C++'da ise hata atma düzeneği olduğu için, new hata atar ve sözleşmenin tanımı kolaydır.

Yani malloc'un başka işlevlerden özel bir farkını göremiyorum. NULL döndürdüğü zaman aslında "benden isteneni yapamadım" diyor.

C++'ta ise, "benden dönüldüğü zaman, benden isteneni yapmışımdır" denir. "Dönüldüğü zaman" çok önemli bir ifade... Ya dönülür ve sözleşme tamamlanmıştır, ya da sözleşme başarılamamıştır ve hata atılmıştır.

O yüzden C++'da C'deki gibi dönüş değeri denetimleri olmaz. Kod tertemizdir.

Daha önce bahsettiğim sunudan bir C, bir de eşdeğeri C++ işlevi:

// C islevi
int bar(Kaynak ** in_out)
{
    int hata = 0;

    Kaynak * r0 = NULL;
    Kaynak * r1 = NULL;

    hata = allocate_kaynak(&r0);
    if (hata) goto cikis;

    hata = allocate_kaynak(&r1);
    if (hata) goto cikis;

    /* ... r0 ve r1 burada kullanilsin ... */
    if (hata) goto cikis;

    /* sahipligi devret */
    *in_out = r0;
    r0 = NULL;

cikis:

    deallocate_kaynak(&r1);
    deallocate_kaynak(&r0);

    return hata;
}

// C++ esdegeri
Kaynak bar()
{
    Kaynak r0(/* ... */);
    Kaynak r1(/* ... */);

    /* ... r0 ve r1 burada kullanilsin ...  */

    /* sahipligi devret */
    return r0;
}

Bu farkı, C++'nın üstünlüğünü için göstermiyorum. Amacım, işlevin nasıl hiçbir hataya dikkat etmeden "kendi işini" yapıyor olması. Eğer işinin bir adımını becerememişse bundan kendi haberi bile olmuyor; hata atılıyor ve işlevden kısa yoldan çıkılıyor.

Yani, malloc'un NULL döndürmesi gibi davranışların yerini C++'da hata düzeneği alıyor.

4. Bir işleve ya da sınıfa "üzerinde işlem yapamayacağı" veriler göndermek.

Evet, sözleşmenin giriş tarafının bozulması o...

5. Bu madde ve sonrası hakkında bir fikrim ne yazık ki yok

Bu madde, yukarıda da değindiğim gibi, işlevin kendi işini yapamamasıdır.

zarf_hazirla() diye bir işlevdeyiz. Bu işlevin veritabanından adres satırını okuması gerekiyor. Adres satırının boş olması olanaksız; zarfı hazırlayamayız... Diyelim adres satırı boş geldi... Ne yapabiliriz? Nasıl zarf hazırlayabiliriz?

Olanaksız olduğu için tek yapabileceğimiz şey, hata atmaktır.

O zaman:
1. Aldığımız belleği "alabilmiş" olup olmadığımızı test etmeliyiz.

Eğer C gibi bir kütüphane kullanıyorsak, evet... Ama new kullanıyorsak denetleyemeyiz bile.

int * p = new int(42);
if (!p) {
    cerr << "hata";   // bu satir hicbir zaman isletilmez
}

Çünkü new ya işini yapar, ya da hata atmıştır. (Not: new'ün hata atmaması da istenebilir; bkz. std::nothrow)

2. Aldığımız bellekle işimiz bitince geri vermeliyiz.

Bütün kaynaklar için geçerli.

3. Erişeceğimiz dosyanın gerçekte orda olup olmadığına emin olmalıyız.

Bir çok başka şey için geçerli. Örneğin dosyanin_icerigi() diye bir işlev var diyelim:

string dosyanin_icerigi(const string & dosya_ismi)
{
    ifstream dosya(dosya_ismi.c_str());

    if (!dosya) {
        throw DosyaHatasi;
    }

    // ... asil islemler ...
}

Çünkü, dosyanın içeriğini üreten bir işlevin işi, dosyanın içeriğini üretmektir. Açılamazsa hata atmaktan başka bir şey yapamaz.

4. Verinin değişmesine gerek olmayacak alanlarda veriyi sabit (const) olarak nitelendirmeliyiz.

Olabilen her yerde const...

5. İşleve ve sınıfa değer ya da referans geçirirken verinin "işlenebilecek olduğundan" emin olmalıyız.

Tabii ki. Eiffel dilinin icat etmiş olduğu "design by contract" dil olanağı, D'de "contract programming" ismiyle geçer. Bu dillerde işlevlerin giriş ve çıkış koşulları dil tarafından denetlenebilir.

Bu ayrıca işlevin kullanıcıları ile işlev arasındaki sözleşmenin dil düzeyinde ifade edilmesidir.

Bu forumla ilgisi yok ama D'nin bu olanağını şu sayfada anlatmıştım:

http://ddili.org/ders/d/sozlesmeli.html

C++'da ve C'de bu işi elle yapmak zorundayız. Şu anda çalıştığım firmada oldukça çok C kodu var. Her bir işlev, her birisi, ilk iş olarak giriş parametrelerinin denetler.

Yukarıdaki C kodunda eksik bırakmışım... Örneğin şöyle olması gerekir:

int bar(Kaynak ** in_out)
{
    int hata = 0;

    if (!in_out) goto cikis;

    // ...

Yani evet, her işlevin giriş koşulları denetlenmelidir.

6. Bu madde ve sonrası hakkında bir fikrim yine yok

C++'da bir sürü öğüt (guideline) var. Bunları içeren çok sayıda kitap da var. Bir yerden sonra düşünmeden yapılıyor...

*Yaklaşık bir yıldır ceviz forumdaki tüm C/C++ konularını okumama rağmen istisna işlenmesi konusunda bu kadar az soru olmasına şaşırdığımı belirtmeliyim.

Benim bir taktiğim, soruyla ne kadar ilgisiz olsa da gördüğüm eksikleri düzeltmek. Örneğin daha yeni "hiçbir değişkeni ilklemeden kullanmayın"ı ve "evrensel değişken kullanmayın"ı hatırlatan bir şeyler yazdım. Ukalalık riski ile... :/

Ama şöyle bir işlev gördüğümde onun yanlış olduğunu söylemiyorum, çünkü bu çok derin bir konu ve öğrenen arkadaş daha çok başlarda:

void foo()
{
    BirTur * p = new BirTur;
    // ...
    delete p;
}

"Hiçbir kaynağı kod içinde açıkça geri vermeyin"... (Çünkü arada hata atılırsa delete satırı işletilmez.)

Bu arada, ben aynı kodu geçtiğimiz sene içinde mülakata çağırdığımız en az 30 kişiye sormuşumdur. Ancak bir iki tanesi öyle kod yazılmaması gerektiğini söylemiştir. Üstelik bu kişiler ya bu işten para kazanan, ya da Amerika'nın en iyi üniversitelerinden yeni çıkmış insanlar... :/

Ama kimseyi suçlamaya gerek yok. Bu konular yaygın olarak bilinmiyor. Bilgisayar bilimlerine genel olarak bakan bir üniversitenin de dört sene içinde uzman C++'cı yetiştirmesi zaten beklenmemeli.

Ali

[quasimodo]

try {
    int * p = new int;
} catch(...) {
    exit(EXIT_FAILURE);
}

delete p;

Acikcasi buyuk bir firmanin buyuk bir projesinde hic calismadim ama ben usengecligim yuzunden su sekilde yazdigimda oluyor. Bu sekilde yazmakta cok buyuk yanlis mi? Yani eger catch blogu yakalamamissa herhangi bir hata atmadi, demekki allocate islemi basarili ve delete rahatca cagirilabilir. Yaniliyor muyum?

[_Onk@_]

...
Ama kimseyi suçlamaya gerek yok. Bu konular yaygın olarak bilinmiyor. Bilgisayar bilimlerine genel olarak bakan bir üniversitenin de dört sene içinde uzman C++'cı yetiştirmesi zaten beklenmemeli.

Birde ziraat fakültesinin hiç beklenmemeli. Peki son olarak hocam:
1. İleri C++ konuları özellikle Hata Yakalama ve İşleme ile ilgili kaynak olarak neyi tavsiye edersiniz. Baskılı, internet...
2. catch ile hatayı yakaladığımızda yapacağımız işlemler ne olmalıdır?
3. Tüm exceptions'ların listesini nerden bulabilirim ya da hangi işlevin hangi exception'u fırlatacağını nereden öğrenebilirim.

Takip ettiğim/etmeyi düşündüğüm kaynaklar:
MSDN http://msdn.microsoft.com/en-us/libr...8VS.80%29.aspx
C++ Reference http://www.cppreference.com/wiki/exception/start
CPP.com http://www.cplusplus.com/doc/tutorial/exceptions/
GotW
Sefer ALGAN'ın makalesi: http://www.csharpnedir.com/articles/...%20Yakalama%29
Kaan ASLAN : İleri CPP notları

[e_koca]

- işini önce yan tarafta hallet; nesnenin veya programın durumuna ancak o iş doğru çalışmışsa dokun

Ne demek istediginizi anlamadim, biraz daha acarmisiniz?

- hataları hiçbir zaman sonraya bırakma; sınıfları tasarlarken de akılda olsun

Burda hatayi yakalamaktanmi, yoksa islemektenmi bahsettiniz ?

- işlevlere birden fazla görev verme

Mesela siralama islemi yapan bir isleve, tamam sen siralamani yap ayni zamanda en buyuk sayiyida bize dondur dedigimiz zaman.Mantikli bir ornek degil ama ogrenmek acisindan soruyorum, hata yakalama acisindan bunun sakicasi ne ? Siralamayi yapamadigin icinmi bir hata nesnesi firlatildi yoksa en buyugunu donduremedigi icinmi bir hata nesnesi firlatildi ikileminde biraktigi icinmi ?

[e_koca]

try {
    int * p = new int;
} catch(...) {
    exit(EXIT_FAILURE);
}

delete p;

Acikcasi buyuk bir firmanin buyuk bir projesinde hic calismadim ama ben usengecligim yuzunden su sekilde yazdigimda oluyor. Bu sekilde yazmakta cok buyuk yanlis mi? Yani eger catch blogu yakalamamissa herhangi bir hata atmadi, demekki allocate islemi basarili ve delete rahatca cagirilabilir. Yaniliyor muyum?

Bence sorun zaten allocate isleminin basarili oldugu durumlar icin onemli degil bu durumda banada sanki guvenliymis gibi geldi. Fakat kod buyudukce sorun cikarir. Onemli olan nokta kodun tamaminda hata nesnesi firlatildiginda dinamik nesnelere baglanan kaynagin geri idade edilemeyecegi. Mesela

try {
     int *p new int;
     foo();
} 
catch(...) {
     exit(EXIT_FAILURE);
}

////
void foo()
try
{
      //...
     //...
}
catch(...)
{
     exit(EXIT_FAILURE)
}

foo fonksiyonu icerisinden bir hata nesnesi firlatildi, Programin hemen sonlandirilmasi gerekiyor. p pointerina baglanan kaynak geri iade edilmez.

Eger programin kullandigi kaynaklar dinamik sinif nesnelerine baglanmislarsa, bu nesnelerin sonlandirici islevleri cagrilmayacagi icin kaynaklar iade edilmez. Bu yuzden smart pointer kullanilmalidir. Diye not almisim zamaninda...

[acehreli]

try {
    int * p = new int;
} catch(...) {
    exit(EXIT_FAILURE);
}

delete p;

Acikcasi buyuk bir firmanin buyuk bir projesinde hic calismadim ama ben usengecligim yuzunden su sekilde yazdigimda oluyor. Bu sekilde yazmakta cok buyuk yanlis mi?

Benim gösterdiğim küçük işlevde, eğer atılan hata daha üstteki işlevler tarafından zaten yakalanmayacaksa sorun yok. Zaten hata yakalanmadığı zaman program sonlanır.

Yani senin örneğinle benimki arasında bu açıdan bir fark yok.

Benimkindeki olay, eğer bizi çağıran işlev veya daha yukarıdaki bir işlev o hatayı yakalar ve işine bir şekilde devam ederse ortaya çıkıyor.

Yani,

... = new ...
hata_atilabilir();
delete ...

gibi bir koddaki tehlike, ortadaki işlemler sırasında bir hata atılırsa ortaya çıkıyor. Biz, bu işlevde, kendi temizliğimiz yapamamış oluyoruz.

Bu arada, tabii ki hatayı burada yakalamayacağız. Bizim olasılıkla atılabilecek onlarca hatadan haberimiz olmayabilir bile. Çağırdığımız işlevin çağırdığının çağırdığı üç ay sonra hata atmaya başlayabilir. Biz programın her işlevini baştan denetleyip bu hata için try/catch blokları koyamayız. Pratik değil.

new yazdığımız veya başka bir kaynak ayırdığımız her işleve de try/catch blokları yazamayız. Aynı işlevde p gibi 3 tane daha kaynak olsa kod çok daha karışık olur.

Hem hatayı yakalasak ne yapabiliriz? Eğer ne yapabileceğimizi bilmiyorsak zaten yakalamamak en iyisidir. Eğer ne yapılacağını biliyorsa yukarıdaki bir işlev yakalasın.

Yani eger catch blogu yakalamamissa herhangi bir hata atmadi, demekki allocate islemi basarili ve delete rahatca cagirilabilir. Yaniliyor muyum?

Eğer zaten exit() çağrılacaksa yakalamaya hiç gerek yok. Eğer exit() çağrılmayacaksa ve hatayı bekleyen üst işlev için yine de tekrar atacaksak, belki de şöyle olmalı:

try {
    int * p = new int;
} catch(...) {
    // ... yakalayinca ne yapacaksak; o islemler ...

    // unutmadan temizliğimiz
    delete p;

    // belki de yukaridakiler bekliyordur diye tekrar atmaliyiz:
    throw;
}

// bu da hata atilmadigi zamanki temizlik satiri
delete p;

Onun sakıncası, en azından kod tekrarına neden oluyor.

Ali