Aykiri durumlar (exceptions) konusuna girmemin nedeni, Euclides'in C++'in C'ye eklenmis bes alti tane olanaktan olustugunu soylemesiydi. Onun ifadesine bakinca; C++'in aslinda daha becerikli C gibi oldugu gibi bir anlam cikartmistim. Bu anlamla alinca; sanki C'den ogrendigimiz gibi yazabilir ve gerektikce de C++'in getirdigi olanaklari kullabilirmisiz gibi dusunuluyor gibi gelmisti.
Bense o bes alti tane olanagin yalnizca "ek olanak" olmadiklarini ve kendi programlarimizda kullanmasak bile yazis tarzimizi tamamen degistirdiklerini gostermek icin, aykiri durumlarla ilgili bir ornek vermistim.
Aslinda asagida soyleyecegim seylerin ozeti su: Salt aykiri durum olanagi bile, C++'in C gibi yazilmasini olanaksiz kilar. C gibi yazilan C++ hatalarla doludur. C programcilari kendi dusunce tarzlariyla baslayarak C++ programlari yazamazlar. Once dusunce tarzlarini degistirmeleri gerekir. (Onceki C bilgisinin C++'ta gucluk cikarttigi gorusunun temeli budur.)
Bunun en guzel orneklerinden birisi, cozumu C++ camiasini bes yil kadar ugrastiran bir iddiadir: Tom Cargill, ortaya aykiri durumlarin sanildigi kadar ise yarar olmadiklari ve yarardan cok zarar getirdikleri yolunda bir iddia atar: (Su anda o makalenin icerigini tam olarak hatirlamiyorum, ama buna benzer bir seydir.)
http://www.awprofessional.com/content/images/020163371x/supplements/Exception_Handling_Article.html
Su iki program bu konunun ozunu bence guzel olarak gosteriyor.
Not: Bununla ilgili daha ayrintili bilgi icin aykiri durumlarin babasi Herb Sutter'i okuyabilirsiniz. Ozellikle su, tam bu konu ile ilgilidir:
http://www.gotw.ca/gotw/008.htm
Elimizde iyi bir C programcisi (ornegin ben :) ) tarafindan C'de yazilmis bir YIgIt (stack) gerceklemesi olsun:
Not: Bu programlar gereginden uzun oldular. Aslinda konunun ozu C programindaki Yigit_cikart ve C++ programindaki Yigit::cikart islevlerinde goruluyor. Acelesi olanlar yalnizca o islevlere bakabilirler :)
#include <stdlib.h>
#include <stdio.h>
#include <assert.h>
typedef struct Yigit
{
int * nesneler;
int buyukluk;
int tepe;
}
Yigit;
void Yigit_kur(Yigit * yigit)
{
yigit->nesneler = 0;
yigit->buyukluk = 0;
yigit->tepe = -1;
}
void Yigit_boz(Yigit * yigit)
{
free(yigit->nesneler);
}
void Yigit_buyult(Yigit * yigit)
{
yigit->buyukluk = ((yigit->buyukluk == 0)
? 2
: yigit->buyukluk* 3 / 2);
yigit->nesneler = realloc(yigit->nesneler,
yigit->buyukluk * sizeof(int));
}
/* push */
void Yigit_ekle(Yigit * yigit, int sayi)
{
++yigit->tepe;
if (yigit->tepe == yigit->buyukluk)
{
Yigit_buyult(yigit);
}
yigit->nesneler[yigit->tepe] = sayi;
}
/* pop */
int Yigit_cikart(Yigit * yigit)
{
assert(yigit->tepe >= 0);
--yigit->tepe;
return yigit->nesneler[yigit->tepe + 1];
}
int main()
{
int i = 0;
int const adet = 3;
Yigit yigit;
Yigit_kur(&yigit);
for (i = 0; i != adet; ++i)
{
printf("Ekliyorum: %d\n", i);
Yigit_ekle(&yigit, i);
}
for (i = 0; i != adet; ++i)
{
printf("Cikarttim: %d\n", Yigit_cikart(&yigit));
}
Yigit_boz(&yigit);
return EXIT_SUCCESS;
}
Kendim yazdigima gore, yukaridaki programin hatasiz oldugunu dusundugume inanabilirsiniz. (valgrind da hatasiz oldugunu ve bellek kayiplari bulunmadigini soyluyor.)
Cok guzel... Simdi bu programcinin ayni isi C++'la yapmak istedigini ve yigitini kullanici turleriyle de kullanabilmek icin C++'in sablon olanagini kullandigini varsayalim. Yani artik yalnizca int yigiti degil, herhangi bir turun yigiti olabilecek. (Burada haksizlik yaptigimi dusunmeyin ama; int yerine 'void *' kullanarak ve biraz daha emek harcayarak C yigitini da herhangi bir turle kullanabilirdik.)
#include <algorithm>
#include <assert.h>
template <class T>
class Yigit
{
T * nesneler_;
int buyukluk_;
int tepe_;
void buyult()
{
int const eski_buyukluk = buyukluk_;
buyukluk_ = ((buyukluk_ == 0)
? 2
: buyukluk_ * 3 / 2);
T * yeni_nesneler = new T[buyukluk_];
std::copy(nesneler_,
nesneler_ + eski_buyukluk,
yeni_nesneler);
delete[] nesneler_;
nesneler_ = yeni_nesneler;
}
public:
Yigit()
:
nesneler_(0),
buyukluk_(0),
tepe_(-1)
{}
~Yigit()
{
delete[] nesneler_;
}
// push
void ekle(T const & nesne)
{
++tepe_;
if (tepe_ == buyukluk_)
{
buyult();
}
nesneler_[tepe_] = nesne;
}
// pop
T cikart()
{
assert(tepe_ >= 0);
--tepe_;
return nesneler_[tepe_ + 1];
}
};
#include <iostream>
using std::cout;
int main()
{
int const adet = 3;
Yigit<int> yigit;
for (int i = 0; i != adet; ++i)
{
cout << "Ekliyorum: " << i << '\n';
yigit.ekle(i);
}
for (int i = 0; i != adet; ++i)
{
cout << "Cikarttim: " << yigit.cikart() << '\n';
}
}
Bu da cok guzel ve yine hem bana hem de valgrind'a gore hatasiz... Ancak bu program, sablonda T ile belirtilen Yigit parametresinin bir kullanici turu oldugunda ve o turun kullanimi (ornegin kopyalanmasi) sirasinda bir aykiri durum atilmasi durumunda hatali olmaya baslayacaktir.
Bunun nedeni, C++ programinin C gibi dusunulerek yazilmis olmasidir. Programci C'den bildigi yontemleri uygulamis ve hatasiz oldugunu sandigi bir C++ programi yazmistir.
Burada C++'ta islemeyen yontem, henuz tepedeki nesnenin cagirana saglikli bir sekilde dondurulecegi kesin olmadan tepe_ ogesinin eksiltiliyor olmasidir. cikart islevi icinde
--tepe_;
dedigimizde, tepedeki nesne artik Yigit'in gozunde yigittan cikartilmistir. Ancak,
return nesneler_[tepe_ + 1];
satirinda donus degeri cagiranin ortamina kopyalanirken bir aykiri durum atilirsa, tepedeki nesne artik kaybedilmis olacaktir.
C++ programcisi, arayuzleri boyle olasiliklari goze alarak yazmak zorundadir. Boyle bir dusunce tarzi C'de yoktur. Bazi ortamlarda sunulan Structured Exception Handling'i (SEH) C'nin yaygin bir olanagi olarak sayamiyorum. SEH'in kullanildigi durumlarda da bunun ozel durumlarla sInIrli oldugunu, ve C programcilarinin alistiklari dusunce tarzlarini biraktiracagini dusunmuyorum. (Cevremde ve nette gordugum C programlarinda onlarin bu sekilde yazildiklarini dusundurecek seyler gormedim.)
C++ programinin dogru yazilabilmesi icin tek cozum, Yigit sinifinin arayuzunun degistirilmesidir. cikart islevi deger donduremeyecegine gore, ekle ve cikart islevlerine ek olarak, tepedeki nesneye erisim saglayan 'tepe' adli bir islevin de yazilmasi gerekir.
Yalnizca degisiklikleri veriyorum:
template <class T>
class Yigit
{
/* ... */
// pop
void cikart()
{
assert(tepe_ >= 0);
--tepe_;
}
T & tepe()
{
return nesneler_[tepe_];
}
// Bu da sabit Yigit nesneleri icin
T const & tepe() const
{
return nesneler_[tepe_];
}
};
/* ... */
int main()
{
/* ... */
int const tepedeki = yigit.tepe();
yigit.cikart();
cout << "Cikarttim: " << tepedeki << '\n';
}
}
Sonucta, aykiri durumlar C'ye eklenen olanaklar degil; C++'ca dusunmeyi C'ce dusunmekten ayiran cok onemli unsurlardir.
Daha once soyledigim birinci/ikinci ornegi de bunun baska bir gostergesidir. Islemler aykiri durum atabilecekleri icin, C++'ta hemen hemen hicbir kod satirinin isleneceginden emin olamayiz. Bu, temizlik isleriyle ilgili olan satirlarda cok buyuk onem tasir.
Onun icin, C++'ta temizlikle ilgili olan isler kod satirlarina yazilmazlar. O isler, cagrilacaklari kesin olarak bilinen bozucu islevler (destructors) icinde yapilmak zorundadirlar. Iste bu da C programcisinin C++'a gectiginde alismak zorunda oldugu buyuk bir degisikliktir.
Kodun icine serpistirilmis fopen/fclose, malloc/free, lock/unlock, vs. gibi kullanimlar geride birakilmalidir.
Cok konustum... Aslinda sonucta soylemek istedigim bu kadar uzun degil: Ek olanaklar yalnizca ek olmayabilirler.
Ali
Ayrica not: Aslinda ek olanaklarin dilin karmasikligini dogrusal olarak arttirmadiklarini da dusunuyorum ama artik onu soylemek istemiyorum ;) Yani bes alti ekin etkisi, karmasikligi karesini almak gibi etkileyebilir. (Bunlari soylemedim :) )