1. Otomatik Form Oluşturmayın: Normalde, projeye eklediğiniz her bir form uygulama tarafından otomatik olarak oluşturulmak üzere ayarlıdır. Bunu dpr dosyasının kaynak kodunda bulunan Application.CreateForm ile görebilrisiniz. Her ne kadar bu size formlara erişirken büyük kolaylık sağlasa da uygulamanın ilk çalışma zamanını önemli derece de yavaşlatmaktadır. Bu yüzden formları otomatik olarak oluşturmayın. Sadece ihtiyacınız olduğunda dinamik olarak oluşturun. Çoğu zaman sadece ana formu otomatik olarak oluşturmanız kafi glecektir.
2. Mümkün Olduğunca Windows API’lerini Tercih Edin: Yapacağınız bir işlem için eğer Windows API’lerinde bu işi göre bir fonksiyon var ise, sakın ayrı bir fonksiyon yazmaya kalkmayın. Windows fonksiyonlarını kullanmak bizim için en hızlı yöntem olacaktır. Bu yüzden bir fonksiyon yazmadan önce Windows API’si içinde bu işi yapan başka bir fonksiyonun olup olmadığından emin olun.
3. Küçük Fonskiyonlar İçin “inline” Direktifini Kullanın: Yeni Delphi sürümleri “inline” direktifini desteklemektedir. “inline” kullanmak exe boyutunu artıracaktır. Fakat hız da artacaktır. Eğer küçük fonskiyonlarınız varsa veya büyük olsa da çok fazla yerde kullanılmayan fonksiyonlarınız varsa, fonksiyon veya prosedür tanımlamasından sonra “inline” direktifini kullanın.
4. Table yerine Query Tarzı Bileşenler Kullanın: TTable gibi bileşenleri mümkün olduğunca kullanmaktan çekinin. Bunun yerine TQuery veya TSqlQuery tarzı bileşenleri tercih edin.
5. FastMM Kullanın: FastMM projesi, normalde Delphi 2005 ile Delphi’ye dahil oldu. Eğer daha düşük versiyon kullanıyorsanız kesinlikle FastMM kullanın. D2005 ve yukarısı için de yeni güncellemeler oldukça faydası olacaktır. Daha fazla bilgi için FastMM’i google’da arattırın.
6. Kodlarınızı Yazarken Disiplinli Olun: Kodlarınızı yazarken değişken, sınıf, fonksiyon isimlendirmelerinde belli bir standarta uyun. Bıraktığınız kod yorumlarını daha sonradan bakacak mışsınız veya başka birisi projeyi devam ettirecekmişcesine yazın. Bu ve bunun gibi kendinize kurallar belirleyerek disiplinli bir şekilde kodlarınızı yazın. Bu size, daha sonradan programınızı bitirdikten sonra kolay bir optimizasyon imkanı sağlayacak. Tekrar kodlara dönüp baktığınızda disiplinli ve düzenli yazılmış bir kod göreceksiniz ve yavaş çalışan veya hatalı çalışan kısımları daha çabuk farkedip, kodunuzu optimize edebileceksiniz.
7. Basm İle Optimizasyona Gidin: Basm yani Delphi içinde assembler kullanarak bazı önemli yerleri optimize edebilirsiniz. Özellikle hızın çok önemli olduğu yerleri bu şekilde optimize edebilirsiniz. Bununla ilgili olarak  daha önceden burada bir şeyler karalamıştık.

Tabi bunlar dışında hızı etkileyen başka faktörlerin de olduğunu unutmayın. Fakat ilk etapta bu adımlara dikkat etmeniz, programlarınızdaki çalışma hızını önemli derece artıracaktır. Buradaki adımların çoğunun tek dez avantajı, exe boyutunun biraz artabilmesi. Fakat bu devirde kimse exe boyutunu çok önemsemiyor.

Benim aklıma 7 adım geldi fakat sizlerin de önerileri olursa lütfen yorum yazarak katkıda bulununuz.

Güncelleme: 07.03.2009: Bu maddelere ek olarak buradaki yorumda bulunan 3 maddeye daha göz atmanızı tavsiye ediyorum. Saadettin beye teşekkürler.

Fatih Tolga Ata © 2009

Bu yazı serisi, önceden yazdığım makaleler gibi tecrübe ve bilgiye dayalı olmayacak. Okuduğum kitap ve makalelerden ve denemelerimden oluşacak. Bu yüzden bu makale serisinin hedeflediği kitle, sadece bu işin meraklılarına hitap ediyor. Derleyici-yorumlayıcı yazmak isteyenlere faydalı bir konu özeti olacağını düşünüyorum. Ayrıca bu işe yeni başlayacak olanlara veya başlamış ama bir sebepten dolayı yarım bırakmış kimselere de bir fihrist, bir yol haritası olacağını düşünüyorum. Tabi bu notları çıkarmakla ben de kendimi bu konuda geliştirmeyi düşünüyorum.

Başlarken..

İlk derleyici yazma merakım, bir işletim sistemi yazma merakım olduğunda başladı Gerçi işletim sistemi olarak sadece disketten boot edilebilir ve dos benzeri bir şeyler yazabildim ancak. Fakat bu gayretim bana çok şeyler kazandırdı. Öncelikle bilgisayar ve işletim sisteminin çalışma mantığını çok iyi bir şekilde sindirdim. Ayrıca assembler ve diğer programlama dilleri noktasında da çok faydası oldu. Ayrıca derleyicilerin işletim sistemleri için ne kadar önemli ve vazgeçilmez bir şey olduğunu da gördüm. Bütün o kodları assembler ile yazmak bir yana, herhangi bir hata olduğunda kafayı yememek bir yana. Bu tabiki ilk başlarda derleyici yazma merakından çok, derleyici yazma ihtiyacını doğurdu.

Tabi bunlar çok öncelerde kaldı. Artık eskisi gibi işletim sistemi yazmak gibi uçuk bir düşüncenin altına girmeyi düşünmüyorum. Fakat derleyici yazmak o kadar da uçuk, ütopik olan bir şey değil. Zira en ünlü programalama dillerine baktığınızda hemen hemen hepsinin ilk başlarda bir veya iki kişi ile yazıldığını görürsünüz. Bu konu ile ilgili araştırma yaptıkça, bu konunun anlaşılmasının çok zor olmadığını fakat teoriden pratiğe, uygulamaya dökmenin zorluğunu gördüm. Son zamanlarda derleyici tasarım teknolojisinin gelişmesiyle beraber uygulamaya dökme işlemi de artık -eskisi gibi- çok zor değil. Zamanı geldiğinde bu teknolojilerden bahsetmeye çalışacağım.

Bu Makale Serisi Kime Hitap Ediyor

İlk başlarda da dediğim gibi öncelikle bu işe meraklı olmalısınız. Bu konu sadece derleyici veya yorumlayıcı yazmaktan ibaret değil tabiki. Eğer yabancı bir dilden (mesala İngilizce’den) Türkçe çeviri yapan veya tam tersi işlemi yapan bir çeviri programı yapmak istiyorsanız, yine bu konu iyi bilmeniz gerekiyor.

Bir derleyici, yorumlayıcı yazabilmek için bir programlama diline iyi hakim olmanız da gerekmektedir. Bu yüzden bu makaleyi okuyabilmeniz için en az bir adet programlama dilini iyi bilmeniz gerekiyor. Üstelik nesne tabanlı programlamayı da bilmeniz işinizi daha da kolaylaştıracaktır.

Ayrıca şunu da belirtmek isterim. Bu konuda Türkçe kaynak yok denecek kadar az. Bu konuda kendinizi geliştirmek istiyorsanız ilk başta İngilizce ile başlasanız fena etmezsiniz.

Kitaplar ve Kaynaklar

Piyasada bu konu ilgili bir çok kitap mevcut. Kimi çok eski ve şu anki teknolojiye hitap etmiyor, kimisi de çok teoride kalıp pratikte hiç bir kullanımından bahsetmiyor. Onca kitap arasından kendimize referans kabul edebileceğimiz kitabı seçmek zor olabiliyor. Ben bunlardan beğendiğim ve gerçekten kaliteli kitapları tavsiye edeceğim. Bu kitaplar genel yorumlarda da iyi gözle bakılan ve günümüz derleyici teknolojilerine de uygun kitaplardır.

Benim tavsiye edebileceğim kitaplar şunlar:

Compilers, Principles, Techniques and Tools; 2nd Edition: Bu kitap, derleyici tasarımının temel ve vazgeçilmez kitabı olarak kabul edilir. Derleyici tasarımcıları arasında ilk baskısının kapağındaki ejder figüründen dolayı “Dragon Book” ismiyle anılmaktadır. Kitabın ilk baskısı yanılmıyorsam 1986 yılında yayınlanmış. Fakat benim tavsiye edeceğim 2. baskısıdır. 2. baskısı 2006′da çıktı ve değişen bir çok derleyici teknolojisini barındırmaktadır. İyi bir başlangıç yapmak isteyen ve yanı başında referans kitap olarak bulundurmak isteyenlere tavsiye ediyorum.

Engineering a Compiler (Cooper, Torczon): Bu kitabı çok aramama rağman ancak ebay üzerinde bulabildim. Sıfır almak isteyenler için amazonda da mevcut. Ebook olarak bulmayı niyetlenenlere söyleyeceğim şey şu ki, bu kitabın internet üzerindeki ebookları eksik. Daha doğrusu draft, yani yazarın kitap çıkmadan çok önceki taslak metinlerinden oluşuyor. Şu ana kadar incelediğim kitaplar arasında işe yarar, teori ve pratik bilgisi iyi olan ve yeni derleyici teknolojilerine hitap eden nadir kitaplardan birisi.

The Definitive ANTLR Reference: İleride bahsedeceğim derleyici derleyicilerinden birisi olan ANTLR ile ilgili yazılmış güzel bir kitap. ANTLR derleyici derleyicisini tasarlayan ve yazan Terence Parr tarafından yazılmış olan kitapta, sadece ANTLR ile ilgili bilgi bulunmamakta. Bu kitapta derleyici tasarımının temel bilgileri yanında gramer oluşturma, lexer, parser çalışma mantıkları ve LL çakışmaları gibi bir çok konuda bilgi de bulunmakta. Önceki iki kitap, her ne kadar pratikte kullanılabilecek bilgiler içerse de genelde teoriyi hedefleyen kitaplardır. Fakat bu kitap, öğrendiğimiz teoriyi uygulumaya nasıl dökebilceğimizi ayrıntısı ile anlatmakta.

Derleyici-yorumlayıcı yazmak isteyen herkese bu üç kitabı şiddetle tavsie ediyorum. Bunlar dışında yardımcı olabilecek şu kitaplara da göz atabilirsiniz. 

Bu kitaplarla beraber bir sorununuz olduğunda, internet üzerinde ANTLR ve Coco/R mail listeleri sizlere yardımcı olacaktır.

Ayrıca sourcefoge.net gibi bir çok sitede bulabileceğiniz açık kaynak kodlu derleyici projeleri bulunmaktadır. Özellikle Tiny C benzeri bir çok açık kaynak kodlu ve küçük (yani incelenebilir) derleyicilere ulaşabilirsiniz. Gcc, freepascal gibi büyük projeleri de inceleyebilirsiniz. Fakat bu projeler çok büyük olduklarından pek öğretme/öğrenme amaçlı değiller. Bunun yerine daha çok küçük ve deneysel projeleri bulup incelemekte yarar var.

Ben yeri geldikçe bu tarz projeleri bulup sizlerle paylaşacağım. Ayrıca yeni çıkmış olan veya benim yeni keşfettiğim güzel kitapları da burada yeri geldikçe tanıtmaya çalışacağım.

Bir sonraki bölümde derleyiciler hakkında temel teorik bilgiler bulacaksınız. Bir sonraki bölümde anlamadığınız yerler olursa burada verdiğim kitap ve kaynaklardan istifade edererek araştırırsınız. Çünkü bunlar temel konulardır ve sonrasında gelecek olan bölümler bu temel bilgiler üzerine inşa edilecektir.

Bölüm 1: Derleyiciler ve Çalışma Mantığı

Derleyici tasarımı, bilgisayar biliminde önemli bir sahayı oluşturmaktadır. En basit olarak bir derleyici, büyük bir bilgisayar programıdır. Bir derleyici, kaynak kodu alır ve belli bir bilgisayar mimarisine uygun çalıştırılabilir bir hedefe çevirir. Bu çevirimin bir parçası da girilen kaynak kodun imla analizini yani syntax analizini yapmaktır. Bu imla analizi sonucunda, kaynak kodlarda hata tespiti yapılır ve kaynak kodun derleyici içindeki karşılıklarına çevrilir. Derleyeci, daha sonra, bu çevrilmiş olan kaynaklara bir mânâ, anlam yükler. Bu anlam yüklemesi sonucunda, derleyici anlam hatalarını araştırır. Bu işlemden sonra da kaynak kodun derleyicide ifade ettiği anlama göre hedeflenen çıktı üretilir. Tabi bu açıklama çok yüzeysel bir açıklama ve adeta bu bölümde göreceklerimizin bir özeti hükmünde oldu.

Derleyici tasarımı, bir mühendislik çalışmasıdır ayrıca. Derleyici yazarı, bu yolda kendisine bol alternatifi olan, masrafı, avantajları ve zorluğu belirgin olan bir tasarım ortamı oluşturmak zorundadır. Her bir karar, oluşturulacak olan derleyiciyi etkileyecektir. Oluşturulacak olan ürünün kalitesi bu alınan kararlara bağlıdır.

Derleyici tasarımı, çok eski olmamasına rağmen, tatmin edici seviyelere kadar gelişmiş bir konudur. Bu konuda bir çok başarılara imza atılmıştır. Piyasada olan bir çok derleyici ve binlerce çeşit programalama dili ile beraber, bu konudaki bilgiler kullanılarak geliştirilmiş bir çok program, bunun ispatıdır. Bir problemi çözmek için bir çok yöntem geliştirilmiştir. Ben burada en güncel ve popüler tekniklerden bahsetmeye çalışacağım. Ama bilinki, bahsedeceğimiz her bir konu ve teknik için alternatifler mevcuttur. Bu alternatifleri araştırmak size kalmış.

Derleme İşlemine Genel Bakış

Bir program çalıştırılabilir olmadan önce, bir çok çevirim işlemlerine tabi tutularak hedef çalıştırılabilir kodlar oluşturulurlar. Bu çevirim işlemini yapan programın özel adına derleyici (compiler) diyoruz. Derleyici, kendisinin anlayacağı bir dilde kaynak kodlarını alır ve çıkışta çalıştırılabilir kodlar üretir. Bu çalıştırılabilir kodlar Windows’da exe, dll, Linux’de elf, so gibi dosyalar olabilceği gibi, .net, java gibi sanal makinalar için çalıştırılabilir kodlar da üretebilir.

Ayrıca çalıştırılabilir kodlar, direk olarak işleme de tabi tutulabilirler. Yani javascript, vbscript gibi direk olarak derleme anında çalışan derleyiciler de mevcuttur. Bu tip derleyicilerin özel adına ise yorumlayıcı (interpreter) denilir. Her ne kadar bazı eski kaynaklarda yorumlayıcılar ve derleyiciler iki farklı şeylermiş gibi gösterilse de çalışma mantıkları aynı olduğu için hepsine genel olarak derleyici demeyi uygun buluyorum. Çünkü derleme işleminde, ileride ayrıntısı ile göreceğimiz gibi, ilk safha yorumlama, ikinci safha ise kod üretmedir. Yorumlayıcıların tek farkı, kod üretme safhası bulunmamasıdır.

Ayrıca yorumlayıcı kodları, çalışabilmek için bir yorumlayıcıya ihtiyaç duyarlar. Mesela php kodları php derleyicisine, basic kodları basic derleyicisine, javascript kodları ecmascript destekli bir browser’a ihtiyaç duyarlar. Bu kodlar, yorumlayıcı olmadan çalıştırılamazlar. Fakat C++, Delphi gibi derleyicilerin ürettiği kodları, direk olarak işletim sistemi üzerinden işlemci çalıştırmaktadır, daha sonradan derleyiciye ihtiyaçları yoktur.

Bir de günümüz teknolojisinde yorumlayıcı olan ama temelde derleyiciler gibi kod üretebilen derleyiciler de mevcuttur. Mesela php derleyicisi, yorumlayıcı gibi ayrı bir dosyaya işletim sistemine uygun bir kod üretmeden, hemen çalışmaya başlar. Fakat yorumlayıcılardan farklı olarak “kod üretir”. Bu kod tabiki ayır bir dosya değil, IIS, Apache gibi server’lara uygun yapıda opcode’lardır.

Günümüzde derleme işlemi yapan bir programı, yorumlayıcı, derleyici olarak kesin bir şekilde ayırmak zorlaşmıştır. Bunun yerine hepsine derleyici demek ve derleme işlemindeki ilk bölüme yorumlayıcı demek daha doğru olacaktır. Ve bu mantığın kavram karmaşasını da önleyeceğini düşünüyorum. Ve herhangi bir yorumlayıcıya derleyici demeyi de yanlış bulmuyorum. (Php yorumlayıcısı yerine, php derleyicisi demek bana daha uygun geliyor…)

Peki, kaynak kodumuz, derleyici ile tanıştıktan sonra hangi aşamalardan ve safhalardan geçiyor? Bu konuyu ayrıntısı ile ilerleyen bölümlerde göreceğiz. Burada özet mahiyetinde şöyle bahsedebiliriz:

Derleyici İşleyiş Diagramı

Genel manada bu şekilde olsa da hem arka planda, hemde görüntüde bir çok safha değişebilmektedir.

Kaynak kod derleyicimize geldiği vakit, ilk olarak, kaynak kodun harfleri teker teker işlenir ve tanımlanarak token dediğimiz nesnelere dönüştürülürler. Bu işlemi gerçekleştiren parçaya Lexer denilir. Lexer’ın görevi, imla (syntax) analizi yapıp sonuç olarak bir token listesi oluşturmaktır. Bu imla analizi sırasında kaynak kodda hatalar da bulunabilir. Bu hatalar Lexer tarafından tespit edilir ve imla hatası (syntax error) olarak bildirilir. Lexer, kaynak kodun ifade ettiği, edeceği anlam ile uğraşmaz. Hangi token’nın hangisinden sonra geldiği ile ilgilenmez.

Mesela aşağıdaki karakter katarına bakalım.

Lexer, bu karakter katarındaki her bir karakteri ayrıştırır. “width” kelimesini bir token, “:=” atama operatörünü bir token, 2 sayısını bir token ve “;” işaretini bir başka token olarak belirler. Eğer gramere göre bu karakter katarında hata mevcut değilse token listesini üretir. Burada ayrıca her bir boşluk da, kimi lexer’lar tarafından, birer token olarak kabul edilmektedir. İleride ayrıntısını göreceğimiz token’ı Delphi’deki bir record veya C++’daki bir struct yapısına benzetebilirsiniz. Bu record ya da struct içinde, token’nın türü, bulunduğu pozisyon gibi değerler bulunur.

Lexer, token listesini oluşturduktan sonra işlemini tamamlamıştır. Artık bu token listesini, Parser dediğimiz başka bir derleyici parçasına iletir.

Parser, bu token listesini alır ve bir ağaç yapısı üretir. Bu oluşturulan ağaca, Parse Ağacı denilir. Token listesinden oluşturulmuş olan parse ağacı, yine tokenlardan oluşmuş bir yapıdır ve derleyicinin tanıdığı gramere göre oluşturulur. Parser eğer ağacı oluştururken gramere uygun olmayan bir token ile karşılaşırsa bunu hata olarak bildirir. Parserın ürettiği bu hataya “Gramer Hatası” yada “Parse Hatası” (Parse Error) denilir.

Parser, token içinde bulunan ve tokenın ifade ettiği text ile uğraşmaz. Tokenın karakter katarında hangi pozisyonda bulunduğu ile ilgilenmez. Ayrıca parser, lexer gibi, tokenın ifade ettiği anlam ile uğraşmaz. Parser sadece token listesinin dizilişine göre gramere uygunluğu kontrol eder. Bunun sonucunda da bu token listesinden oluşan bir parse ağacı üretir.

Misal olarak aşağıdaki karakter katarından, Lexer ve Parser’ın ürettiği çıktılara bakalım:

Lexer ve Parser İşleyişi

Bu ağacın oluşturulmasının amacına daha sonra değineceğiz.

Parse ağacı oluştuktan sonra bu ağaç, Semantik Analiz’e (Semantic Analysis) tabi tutulur. Ağacın her bir yaprağında bulunan tokenlar, bu aşamada derleyici için bir mânâ ifade etmeye başlarlar. Yani artık integer olan bir token, derleyici tarafından integer, değişken olan token ise değişken olarak anlam verilir. Bunun sonucunda ise, anlam olarak belli hatalar oluşabilir. Bu aşamada oluşabilecek hatalara Semantik Hatalar (Semantic Errors) denilir. Mesela integer olan bir değişken, string olan bir değişkene direk olarak eşitlenemez! Tabi bu örnek programlama dillerine göre farklılık da gösterebilir. Fakat genel manada integer bir değeri string bir değere direk olarak eşitleyemezsiniz. Çünkü bunların token tipleri farklıdır. Bu tarzdaki, yani anlam bakımından yanlış olan işlemler semantik hataları oluştururlar.

Semantik analiz sonucunda herhangi bir hata oluşmamış ise parse ağacı yardımı ile intermediate code ya da intermediate representation dediğimiz ara bir kod oluşturulur. Tabi bu safha her derleyicide bulunmayabilir. Bu ara kod oluşturulduktan sonra kodlar optimize edilir ve tekrar son çıktı için kod üretilir. Bazı derleyiciler ara kod oluşturmadan direk olarak kod oluşturabilmektedir.

Bu işlemlerden bizi en çok zorlayan kısım lexer ve parser kısımlarıdır. Çünkü bu parçalar, programlama dilinin gramerini ifade eden, tanımlanmasında hata kabul etmeyen, hamaliyesi çok olan parçalardır. Bu zorluklardan dolayı bir çok “derleyici derleyicisi” denilen yardımcı programlar geliştirilmiştir. Her büyük derleyicide bu derleyici derleyicisi kullanılmaktadır. Bunu daha sonra ayrıntısı ile göreceğiz.

Burada bahsettiğimiz tabirler yabancı gelse de, ileride bunları daha iyi ve ayrıntısı ile bahsedeceğiz. Ama genel olarak “Derleyici Tasarım Notları” başlıklı bu yazı serimiz bunlardan bahsedecektir. Burada bir nevi, anlatacaklarımızı özetlemiş olduk. Fakat ayrıntıda gizli, çok farklı teknikler ve yöntemler mevcut. Bunlara yeri geldikçe bahsedeceğiz.

________________________________

Birinci bölüm henüz bitmiş değil. Devamını bir başka zamana atıyorum. 

Kolay gelsin.

Fatih Tolga Ata © 2009

Bu yazımızda C / C++ ve Delphi gramer bilgisi vermek yerine, daha çok C / C++ kodlarını en doğru şekilde Delphi’ye nasıl adapte edebileceğimizi göreceğiz. Yapacağımız işlem sadece bire bir kod çevirisi olmayacak. Yeri geldiğinde hiç bir kod çevirmeden sadece orjinal kütüphaneyi Delphi programımızın içine gömebileceğiz.

Eğer siz de, ister derlenmiş olsun, ister açık kaynak kodlu olsun, bir C / C++ kütüphanesini Delphi’ye nasıl çevirebileceğimizi merak ediyorsanız buyurun beraber yazımıza giriş yapalım.

Giriş

C / C++ ‘dan Delphi’ye kod çevirme derken ilk akla gelen, binlerce satırlık C kodlarını teker teker uğraşıp Delphi olarak yazmak gelecektir. Halbuki bu en son tercihimiz olması gerekmektedir. İlerleyen bölümlerde de göreceğimiz gibi, Delphi derleyicisinin hünerli parmakları bizi bir çok dertten kurtarmaktadır. Yine de bütün kodları baştan çevirmek gibi bir derdin altına girmek isterseniz bu makale size bir başlangıç noktası olacaktır.

Hemen kodlara dalmak gerçekten gerekli mi? Kesinlikle gerekli değil. Çünkü bizim uğraştığımız şey, önceden birileri tarafından yapılıp internet üzerinde dağıtılıyor olabilir. Bu yüzden ilk yapacağımız işlem bir “Delphi port” bulmamız gerekmetedir.

Mesela şuanda en hızlı ve en stabil xml kütüphanesi kabul edilen libxml2 kütüphanesini kullanmak istediğimizde, hemen kodları çevirmeye kalkmak yerine bir Delphi port bulmamız en akıllıca işlem olacaktır. Ki bu kütüphanenin başlık dosyaları zaten sourceforge üzerinde dağıtılmaktadır.

Bu makalede, C objelerinin kullanımı, C veri tiplerinin Delphi’deki karşılıkları, C başlık (header .h) dosyalarının Delphi’ye çevrilmesi gibi bir çok konu bulacaksınız. Bu bilgiler ile istediğiniz bir C kütüphanesini korkmadan Delphi’ye adapte edebilirsiniz.

Bu makalede çok fazla C / C++ bilgisi gerekli mi? Gerekli olsa bu makaleye ihtiyaç duymazdınız. Fakat çok  az da olsa C / C++ gramerine aşinalığınız olmak zorunda. En basit olarak bir bir fonksiyon nasıl tanımlanır, bir değişken nasıl tanımlanır, bir pointer nasıl atanır, bunları bilmeniz gerekmektedir.

Fonksiyon Çağırım Mekanizmaları

Bir çinli ile anlaşabilmek için bir tercüman tutmanız gerekti. Fakat çok aramanıza rağmen çinli bir tercüman bulamadınız. Bunun yerine bir birine benziyor diye kalkıp, japonca bir tercüman tuttunuz. Çinli olan birisi ile ne kadar anlaşabilirsiniz. Her ne kadar bize “benzer” gibi gözükse de iki dil bir birinden farklı dildir. Bu örneği şimdi göreceğimiz konuya hazırlamak için verdim. Bu misalden hakikate şu şekilde geçebiliriz. Derlenmiş olan her bir kütüphanedeki fonksiyonlar belli bir dili konuşmaktadırlar. Bu konuştukları diller görünüşte bir birlerine benzeseler de, ayrıntıda bir birlerinden farklıdırlar. Bu konuşulan dillere fonksiyon mekanizmaları ya da ingilizce terim olarak “calling conventions” denilmektedir. Eğer kullanacağınız fonksiyon farklı bir dili kullanıyor ve siz de fonksiyonu farklı bir dil ile çağırıyorsanız muhtemel hatalar ile karşılaşacaksınız. Bu yüzden ilk öğreneceğimiz konu bu olmalıdır.

Direk olarak çağırım mekanizmalarının delphi karşılıklarını vermek yerine az da olsa bir kaç özelliklerinden bahsetmek istiyorum. Çünkü hangi çağırımı nerede ne için kullanacağımızı bilmemiz şarttır.

Şu an literatürde en çok kullanılan 4 çeşit fonksiyon çağırım mekanizması vardır. Bunların ne olduğunu ayrıntısı ile anlatan buradaki makalemize göz atabilirsiniz. Hatta okumadı iseniz bir göz gezdirmenizi şiddetle tavsiye ediyorum. Biz burada bu mekanizmaların çalışma şekillerinden çok işimize yarayan kısmını anlatmaya çalışacağız. Ama linkini verdiğim makalede bunların çalışma şekillerini ayrıntılı bir şekilde bulabilirsiniz.

Birinci olarak göreceğimiz çağırım mekanizması register çağırımıdır. Delphi varsayalın olarak bütün fonksiyon ve metodlarda bu çağırımı kullanmaktadır. Normalde Dehlpi’de “register” ayrılmış kelimesini fonksiyon ya da metodun sonuna eklemekle, fonksiyon ya da metodu bu çağırım için ayarlamış oluruz. Fakat varsayılan olarak kullanıldığı için bunu yazmanıza gerek yoktur:

procedure RegisterCagirimliProcedure; register;

Fonksiyon çağırım mekanizmaları ile ilgili yazıyı okuduysanız en verimli ve performanslı çağırımın bu olduğunu biliyorsunuzdur. Bu mekanizma ilk olarak Borland tarafından geliştirilip C++ Builder ve Delphi derleyicilerinde kullanıldı. Şu anda bildiğim bütün C / C++ derleyicileri bu çağırımı desteklemektedir. C / C++ derleyicilerinde bu çağırım __fastcall olarak isimlendirilmektedir.

Her ne kadar en hızlı çağırım __fastcall yani register olsa da ve çoğu derleyici tarafından desteklense de, belki de alışkanlıklardan dolayı, C / C++’da pek kullanılmamaktadır. Genelde Linux ve Windows’da ileride gelecek olan başka çağırımlar kullanılmaktadır.

__fastcall yani register çağırımları, Microsoft’uın derleyicilerinde __msfastcall olarak başka bir biçimi de almıştır. Fakat şu anda Delphi bu çağırımı desteklememektedir. Umarım ilerideki Delphi derleyicilerinde bunu görebiliriz. Fakat bu çağırım __fastcall kadar bile yaygın ve fazla kullanılmadığı için şu anda anlattığımız çevirim işlemi için çok da önemli değil. Hatta, eğer bir kütüphane bir çok dili desteklemek gibi bir gayesi varsa __fastcall çağırımını da desteklememektedir.

Kısacası bu çağırımı delphi’ye aktarmak için hiç bir şey yapmamız gerekmiyor. Çünkü delphi bunu varsayılan olarak kullanıyor. Mesela aşağıdaki C fonksiyonunu delphi’ye çevirelim:

__fastcall int birFonksiyon(int i);

function BirFonksiyon(i: Integer): Integer;

İkinci çağırım mekanizmamız __pascal yada delphi’de pascal çağırımıdır. Ki bu çağırım Win 3.1 zamanından kalma eski bir çağırımdır. Bu yüzden eğer karşılaşırsanız yapmanız gereken __pascal yerine pascal yazmalısınız.

Üçüncü çağırım mekanizmamız __stdcall ya da delphi’de stdcall çağırımıdır. Bu çağırım, Windows işletim sisteminin varsayılan çağırım mekanizmasıdır. Eğer windows’a ait bir DLL’i kullanacaksak, bilinki %99 stdcall olarak tanımlanmıştır. __stdacall çağırımı derleyicilerde çeşitli takma adlar ile kullanılmaktadır. Genelde “WINAPI” kelimesi __stdcall için kullanılmaktadır. Mesela aşağıdaki Windows API’sinden bulunan fonksiyonu şöyle çevireceğiz:

WINAPI BOOL ReleaseCapture(VOID);

function ReleaseCapture: Boolean; stdcall;

Yardım dosyalarında bu fonksiyonun başında WINAPI ya da __stdcall ifadesini görmesek de, biliyoruz ki bu bir Windows fonksiyonudur. Öyleyse bu fonksiyon stdcall çağırımıdır. Bu çıkarım ile hem delphi hem de C kodunda bu çağırımı belli ettim.

Dördüncü ve son çağırımımız ise __cdecl ya da delphi’de cdecl çağırımıdır. Bu çağırım C / C++ derleyicilerinin varsayılan çağırımıdır. Eğer C dosyalarında hernangi bir çağırım belirtilmemiş ise, bu fonksiyon cdecl olarak çağırılacaktır. Yani aşağıdaki fonksiyonlar aynı şeyi ifade edip her iksinin de çevirimi aşağıda gösterilmektedir.

void bir_proc();
__cdecl void ikinici_proc();

procedure bir_proc; cdecl;
procedure ikinci_proc; cdecl;

İleride makroları göreceğiz. Aşağıdaki makro tanımlamaları da geçerlidir ve kullanılmaktadır.

__stdcall = _stdcal = CALLBACK = WINAPI = APIENTRY = PASCAL = APIPRIVATE

__cdecl = _cdecl = WINAPIV

__fastcall = _fastcall

Yukarıda eşitliklik ile ifade edilenleri birbirlerinin aynısı olarak kabul edebilirsiniz.

DLL Kullanımı ve Çağırımlar

Normalde bir DLL’den bir fonksiyonu kullanmak için fonksiyonu nasıl tanımlayacağımızı bir hatırlayalım:

const
  DLLDosyasi = 'birkutuphane.dll';
procedure bir_proc(); cdecl; external DLLDosyasi;

Kendi DLL’imizi kullandığımızda fonksiyonu nasıl tanımlayacağımızı biliyoruz. Peki DLL’i biz yazmamış isek ne yapacağız?

Bu durumda, eğer herkes tarafından kullanılabilir bir DLL dosyası ise, DLL sağlayan firma, ekip, yazılımcı, vs. DLL dosyası ile beraber bir “header” dosyası sağlayacaktır.

Delphi’de, bildiğiniz gibi, unit iki bloktan oluşur. Birinci blok yani interface bloğu, unit tarafından “unit dışında” kullanılacak olan sınıf, değişken, fonksiyon, vs. ‘den oluşur. İkinci blok yani implementation bloğu ise, interface bloğunda tanımlanmış olan fonksiyon ve sınıfların esas kodlarından oluşur. Yani esas çalıştırılan kodlar implementation kısmında bulunur. Ayrıca implementation’da tanımlı herhangi bir değişken, fonksiyon, vs. eğer interface’de tanımlı değilse diğer unitlerde görünmezler ve kullanılamazlar.

C / C++ dosyaları da Delphi’nin unit dosya mantığının aynısıdır. Fakat Delphi’nin aksine C / C++ dosyaları tek parça halinde değil iki parça halinde tutulurlar. Delphi’de interface olarak ifade ettiğimiz blok C ‘de “header” olarak ifade edilir ve “.h” uzantısına sahiptir. Nadir de olsa C++’da header dosyaları “.hpp” uzantısı alabilirler. Delphi’de implementation olarak ifade edilen esas çalışan kodlar ise C’de “.c” ve C++’da ise “.cpp” uzantısı ile ifade edilen dosyalardadır.

Header dosyaları, şart olmasa da, genelde kütüphanenin “include” adlı klasöründe barındırılmaktadır. Kullanacağınız DLL’in header dosyası da bu veya bunun benzeri bir klasörde bulunacaktır. Header dosyası olmadan Delphi çevirimi yapmamız çok zor olacaktır. Hatta üst düzey assembler bilginiz olması gerekebilir. Bu yüzden DLL ile beraber en az bir adet header dosyasına sahip olduğunuzu varsayıyorum.

Bu başlık altında esas olarak anlatmak istediğim mevzuya şimdi geliyoruz.

DLL’e ait header dosyasına baktığımızda fonksiyonların hangi çağırım mekanizmalarını kullandıklarını görebiliyor ve anlayabiliyoruz. Fakat derlenmiş olan DLL dosyalarında bu çağırım mekanizmalarını belirten hernhangi bir işaret var mı?

Bunun için yardımcı bir araca ihtiyaç duyacağız. Aslında TDump isimli ve delphi ile beraber gelen bir konsol uygulaması bulunmakta. Ancak konsol uygulaması yerine göresel bir aracı tercih ederim. Ama illaki tdump kullanmak isteyen olursa “-b” parametresi ile beraber kullanabilirsiniz. Her neyse, ihtiyacımız olan program “Dependency Walker” . Bu program ile DLL’de bulunan tüm fonksiyonları isimleri ile beraber görebiliriz.

Peki header dosyasında fonksiyonlar ayrıntılı bir şekilde olmasına rağmen neden ekstra bir araca ihtiyaç duyuyoruz. Aslında ekstra bir programa ihtiyacımız yok. Header dosyaları fazlasıyla yeterlidir. Fakat bazen DLL’ler varsayılan ayarlarla derlenmemektedir. Bu da bize sorun çıkarabilmektedir.

DLL’ler derlenirken fonksiyon isimleri çeşitli ekler alırlar. Bu ekler, fonksiyonun hangi çağırımı kullandığını belirler. Ama bazen bu varsayılan isimlendirmenin dışına çıkan kütüphane yazılımcıları, bütün ekleri kaldırabiliyorlar. Mesela cdecl fonksiyonları önlerinde “_”  işaretini barındırırlar. Veya stdcall fonksiyonları fonksiyon isiminden sonra “@” işareti ve parametrelerin boyutlarını içeren bir dizi ekten ibarettirler. Dependency Walker gibi programlar, bize fonksiyonların hangi isimlerden oluştuğunu gösterecektir. Eğer header dosyasını Delphi’ye hatasız aktardık fakat halen fonksiyonun bulunmadığına dair hata alıyorsak demek ki isimlendirmeler yanlış demektir. Bunun için aşağıdaki yöntemi kullanmalıyız:

procedure BirProc; cdecl; external DLLDosyasi name '_bir_proc';

Gördüğünüz gibi “external” direktifinin hemen sonuna bir boşluk ile beraber bir name direktifi ekledik. Bu “name” direktifi ile DLL’deki fonksiyona direk olarak işaret etmiş oluyoruz. Bu tekniği sadece ihtiyaç dahilinde kullanabilirsiniz. Veya C / C++ ismi size hoş gelmedi ise fonksiyonun ismini Delphi’de kullanım adını değiştirmek için kullanabilirsiniz.

Not

Bir tecrübemi aktarmak istiyorum. Eğer C / C++’a fazla hakim değilseniz, muhtemelen header dosyalarını çeviriken bir çok hata yapacaksınız. Bu durumda DLL’i statik olarak kullandığınızdan dolayı, delphi programı derleyecek ama çalıştıramayacktır. Ve program donacaktır. Çünkü istediği DLL içinde sizin tanımladığınız gibi bir fonksiyon bulamamıştır. Bunun yerine ilk başlarda, header dosyasının çevirimi doğru bir şekilde çevrilene kadar, DLL dosyasını dinamik olarak yükleyin. Bu şekilde çıkan hataları, hangi fonksiyon tanımlamasından kaynaklandığını belirleyebilirsiniz. Dinamik DLL yüklemesinin nasıl yapıldığını internetten araştırarak bulabilirsiniz.

Not

Header dosyalarını çevirmek için aslında JEDI kütüphanesine ait bir araç bulunmaktadır. Fakat bu araç da tam olarak header dosyalarını çevirememektedir. Daha doğrusu yine burada anlattığımız bilgilere ihtiyaç duyacaksınız. Bu araç sadece çok büyük dosyalarda yazım kolaylığı sağlamak açısından bir kolaylık getirmektedir. Ayrıca ileride anlatacğımız konular için bu araç yetersiz kalmaktadır. Bu araca Dr. Bob’un sitesinden ya da JEDI kütüphanesinden erişebilirsiniz. (Header Conversation Tool)

Çağırım mekanizmalarına hakim olmak Delphi çevirimi noktasında size büyük kolaylık sağlayacaktır. Bu yüzden bu konuyu ilk sıraya aldım ve biraz da uzun tuttum.

Veri Tipleri

C / C++ kodları, çok fazla pointer ile ilgili işlemleri barındırmaktadır. Basit bir tip tanımlamasında bile pointerlara ihtiyaç duyarsınız. Fakat C / C++’da bulunan bu pointer kullanımı Delphi’ye geçtiğinde illaki pointer kalacak diye bir şart yoktur. Kullanımda bu olay farklılık göstermektedir.

İlk önce basit veri tiplerinden başlayalım. Aşağıdaki fonksiyona bir göz atalım:

char* birfonksiyon(void);

Burada “char*” olarak çıktı veren bir fonksiyonuz mevcut. C’de “*” işareti pointer tanımlamak ve çarpım işlemlerini yapmak için kullanılır. Eğer char, int gibi bir tip ile birlikte kullanılıyorsa bu, pointer operatörüdür. Bu örnekte “char*” ifadesi bir char işaretçisini ifade eder. Bu Delphi’de PAnsiChar ile ifade edilir. PChar demiyorum çünkü Delphi 2009 ile beraber artık PChar unicode oldu. Fakat buradaki “char” ansi olan bir char tipidir. Bunun Delphi karşılığı:

function birfonksiyon: PAnsiChar; cdecl;

olacaktır. Burada kullanılan C / C++ pointer’ı aynı şekilde Delphi’de de pointer olarak geçmiştir. Fakat bazen C’de pointer’lar hem pointer tanımlamak için, hem dizi tanımlamak için hem de parametrelerde çıkış için kullanılabiliyor. Bunların ayırımını zamanla ve tecrübeyle kazanacaksınız. Aşağıda referans olarak kullanabileceğiniz bir tablo gözükmektedir. Bu tabloyu kullandıkça artık aşina olup tekrar dönüp bakmayacağınızı da zannediyorum. Ama şimdi her birine birer birer göz atmanızda yarar var.

Tabloyu incelerseniz çoğu tipin birbirinin aynısı olduğunu anlarsınız. Bu yüzden tablo biraz uzunca oldu. Bunun nedeni C / C++’da bolca makro denilen yapıların kullanılmasıdır. Makrolar ile ilgili işlemleri ileride anlatacağımızdan şimdilik burada kısa kesiyoruz.

Gördüğünüz gibi string yerine PChar yada PAnsiChar kullanılmakta. Tabloda ayrıca Delphi 2009 ve yukarısında kullanılmak üzere verdiğim alternetifler de mevcut.

#define UINT unsigned int

Veri tipleri ile ilgili zamanı geldikçe yine değineceğiz. Ama giriş için bu kadarlık bilgi yeterli.

Makrolar

Diyeceksiniz ki, ne oluyor C dersine mi başladık? Eğer bir dilden diğer dile çevirim yapmak istiyorsanız her iki dilin de incelikleri bilmeniz gerekmektedir. Tabi biz burada bir C kitabı yazacak değiliz. Bunun yerine mümkün olduğunca kısa tutup püf noktalarını vermeye çalışıyorum. Fakat, yeri gelecek bir C kitabını karıştırmanız gerekebilecek veya C ile ilgili bir siteyi…

Makrolar C / C++ derleyicilerine, derlemeden hemen önce yapılacak olan işlemleri bildirir. Bir nevi Delphi’deki {$ ..} derleyici direktiflerine benzeselerde bunlar daha karmaşıklardır. Önemli nokta, makroların derlemeden hemen önce çalıştırılmasıdır ve derlemeye dahil olmamasıdır. Bu yüzden C / C++ derleyicileri precompile denilen bir işleme tabi tutulurlar. Bu da C / C++ derleyicilerinin neden bu kadar yavaş derlediklerinin bir sebebidir. Eğer C / C++ ile büyük bir programı derlememiş iseniz hala, Delphi gibi 1-2 sn içinde derlediğini zannedersiniz. Halbuki C/C++’da ömrünüz yarısı derlemekle geçer

Aşağıda tanımlı basit bir makro görüyorusunuz:

#define BIRMAKRO MakronunDegeri

Makro burada gördüğünüz gibi #define ile tanımlanıyor. Delphide olduğu gibi #ifdef, #ifndef, #endif gibi ifadelerle bu makronun tanımlı olup olmadığı kontrol edilebilir.

Peki bu makro delphi’ye geçirilecek mi? Belki evet belki hayır. Eğer makro bir fonksiyonu tanımlıyorsa bu durumda makroyu delphide tanımlamalısınız. Aksi taktirde makronun değeri sizin için yeterlidir. Makroyu geçrimenize gerek yok.

Eğer önceki konudaki tüyoyu okudu iseniz makroların gerçek değerlerine nasıl ulaşacağımızı biliyoruz. Mesela aşağıdaki makroyu birebir delphi’ye geçirmeye luzum yoktur:

C:

#define size_t unsigned int
__stdcall size_t getSize();

Delphi:

function getSize: Cardinal; stdcall;

Ama isterseniz size_t makrosunu bir tip olarak tanımlayabilirsiniz de:

size_t = Cardinal;

Ama lüzum yok. Peki hangi makroları delphi’ye çevirmemiz gerekli? Şimdiye kadarki tecrübeme göre genelde fonksiyon makrolarını geçrimek yeterli. Aşağıda örnek bir fonksyion makrosu mevcut ve devamında delphi kodlarını bulabilirsiniz:

#define Fonksiyon(Msg) MessageBox(NULL, Msg, NULL, NULL)

procedure Fonksiyon(Msg: PChar); inline;
begin
  MessageBox(0, Msg, '', 0);
end;

Gördüğünüz gibi sadece “inline;” olarak tanımlamamız aynı etkiyi yapacaktır. Çünkü “inline” direktifi de makro gibi fonksiyonun çağrıldığı yerde çalıştırılır. Inline ve makro fonksiyonlar için internette bir çok makale bulabilirsiniz.

Bunun dışında makrolar ile iligli olarak şunu söylemek istiyorum. Önceden de dediğim gibi her makronun bire bir Delphi’ye çevrilmesine gerek yoktur. Makro fonksiyonların haricinde bir de bazen makro sabitler de tanımlanabilir. Mesela:

#define ei_NONE 0
#define ei_WRITE 1
#define ei_READ 2
#define ei_CREATE 3

Bu tanımlamaları ister const ile tek tek eşitleyerek yaparsınız isterseniz enumerator tanımlarsınız. Biz ikisini de görelim:

//const ile
const
  ei_NONE = 0;
  ei_WRITE = 1;
  ei_READ = 2;
  ei_CREATE = 3;
//enumerator ile
type
  Tei = (ei_NONE = 0, ei_WRITE = 1, ei_READ = 2, ei_CREATE = 3);

Tercih size kalmış…

Çok karmaşık makrolar geldiğinde internetten veya bir c kitabından yardım alabilirsiniz. Fakat bu kadarlık bilgi sizi fazlasıyla idare edecektir.

Gelecek Makalede

Daha yapacağımız çok işler olacak. Şimdilik bu verdiğimiz bilgiler ile kendiniz çevirimler deneyebilirsiniz. Fakat, daha görememiz gereken çok önemli konular mevcut. Özellikle fonksiyon parametreleri başlı başına bir konu başlığı.

Bununla beraber bu makale serisinde sadece DLL kullanımını görmeyeceğiz. Gelecek makalelerde DLL kullanmadan C obje dosyalarını direk olarak delphi’ye gömeceğiz. Böylece programınızın yanında ek bir DLL verme zorunluluğunuzda kalkacak. Tabi bu konu başlı başına bir makale bölümü olacaktır.

Yine gelecek makalelerde hedear dosyaları haricindeki, implementation olarak ifade ettiğimiz kısımları da sıfırdan Delphi’ye nasıl çevrileceğinden bahsedeceğiz. Daha doğrusu yine bazı püf noktalara değineceğiz. Yoksa tüm gramerin nasıl çevrileceğini anlatmak biraz uzun ve sıkıcı olabilir.

Bu bölümlük bu kadar.

Fikir, eleştiri ve önerilerinizi bekliyorum.

Fatih Tolga Ata – 2009

Hafıza Bölgesinde Stream Kullanımı

Takdir edersiniz ki en hızlı stream verisi hafızada bulunan stream verisidir. Yani bir hafıza stream nesnesi her halukarda okuma-yazma işlemleri dosya ve veritabanından hızlı çalışacaktır. Bu durumda eğer bir stream ile çok fazla okuma-yazma işlemleri gerçekleştiriliyorsa, ilk başta bir hafıza streami kullanılmalı ve stream ile işimiz bitip son durumu kaydetmek istediğimizde bu hafıza streaminden başka bir stream nesnesine aktarım yapılması en doğru işlem olacaktır. Aynı şekilde stream verisi üzerinde çok miktarda Seek işlemi yani stream işaretçisinin pozisyonunu değiştirme işlemi gerçekleştiriyorsanız, bu durumda yine stream verisinin tamamını bir hafıza bölgesine aktarmalısınız.

Aşağıdaki örneğe göz atalım:

procedure TForm1.Button1Click(Sender: TObject);
var
  Mem: TMemoryStream;
  writebuffer, readbuffer: AnsiString;
begin
  Mem := TMemoryStream.Create;
  try
    writebuffer := 'Diyezon';
    Mem.WriteBuffer(writebuffer[1], Length(writebuffer));
    Mem.Position := 0;
    SetLength(readbuffer, Length(writebuffer));
    Mem.ReadBuffer(readbuffer[1], Length(readbuffer));
    ShowMessage(readbuffer);
  finally
    Mem.Free;
  end;
end;

Gördüğünüz gibi TMemoryStream’in Create oluşturucusu hiç bir parametre almıyor. Burada ekstradan yazma işleminden sonra Position := 0 ile stream işaretçisini başa getiriyoruz. Çünkü yazma işleminin sonunda işaretçi pozisyonu kayacaktır. Okuma işlemini yapabilmemiz için yine işaretçiyi başa getirip okutuyoruz. Aynı işlemi Seek metodu ile de yapabiliriz. Ek bir not olarak, Seek metodu Position’dan daha hızlı çalışmaktadır.

Hafıza streami kullanmak, oluşturulması esnasında hiç bir parametre gerektirmediğinden, diğerlerine nazaran daha kolay ve pratiktir. Bu yüzden yapacağımız yüksek yoğunluktaki stream işlemlerini TMemoryStream ile yapmamız bizim yararımıza olacaktır. Özellikle Seek işlemlerinde yani pozisyon değiştirme işlemlerinde hafızadan faydalanmak önemli bir performans artışına sebep olacaktır.

Stream’lerin Aktarımı ve Kopyalanması

Stream verileri ile okuma-yazma işlemlerinden sonra yapılan en önemli işlem de bir stream’in başka bir stream verisi üzerine aktarılmasıdır. Mesela bir dosyayı hafızaya almak isteyebilirsiniz. Veya hafızadaki bir veriyi veritabanına aktarmak isteyebilirsiniz. Bu durumda her stream fonksiyonunda bulunan CopyFrom metodu kullanılır.

Aktarım işleminde basit bir metodu kullanmaktan öte, bir noktaya dikkat edilmesi şarttır. CopyFrom metodu ve bunun gibi bir çok metod, stream işaretçisinin bulunduğu pozisyondan itibaren işlemeye başlarlar. Aşağıdaki örneğe bir göz atalım:

procedure TForm1.Button1Click(Sender: TObject);
var
  Mem: TMemoryStream;
  F: TFileStream;
  //Mem, F: TStream; şeklinden de yazılabilirdi...
  buffer: AnsiString;
begin
  Mem := TMemoryStream.Create;
  F := TFileStream.Create('c:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    buffer := 'Diyezon';
    Mem.WriteBuffer(buffer[1], Length(buffer));
    //karakter katarımızı hafızaya aldık.

    Mem.Position := 0; //Önemli!!!!

    F.CopyFrom(Mem, Mem.Size);
  finally
    Mem.Free;
    F.Free;
  end;
end;

İlk yaptığımız işlem bir karakter dizisini hafızaya almak oldu. Ardında bu hafıza streamini dosya üzerine kopyaladık. Burada dikkat edilmesi gereken nokta Position := 0 kısmıdır. Hafızaya karakter dizisinin yazılmasından sonra stream işaretçisi sona kayar. Böylece sonrasında gelen CopyFrom gibi metodlar bu pozisyondan itibaren işlem yapmaya başlarlar. İşaretçi sonda olduğu için CopyFrom kopyalayamaz ve bir istisna hatası çıkarır. İşte bunu önlemek için işaretçiyi başa alıyoruz ve hafıza streaminin tamamını dosya üzerine aktarıyoruz.

Kısacası CopyFrom metodu, kopyalanacak olan streamin işaretçi pozisyonundan itibaren, sizin belirlediğiniz uzunluk kadar stream’den okur ve diğer streame aktarır. Tek dikkat etmemiz gereken nokta kopyalayacağımız kaynak stream’in mevcut işaretçi poziyonudur. Eğer işaretçi poziyonu sonda ise CopyFrom kaynak stream’den veri okuyamayacak ve hata meydana gelecektir.

Nesneler ve Bileşenleri Okuyup Yazmak

Nesneleri, stream üzerine yazmak denildiğinde ilk akla gelen record verileri gibi okuyup yazmaktır. Halbuki nesneler, her ne kadar benzese de, record verilerinden çok farklıdır ve karışıktır. Bu yüzden direk olarak bir sınıf ya da nesne stream üzerine aktarılamaz. Ancak sizin belirlediğiniz kısımları ayrı ayrı, önceden öğrendiğimiz okuma-yazma işlemleri ile halledebilirsiniz.

Fakat bileşenlerde durum biraz farklıdır. Daha doğrusu TPersistent sınıfından türeyen bütün sınıflarda durum biraz farklıdır. TStream sınıfında, bileşenlerin özelliklerini stream üzerine alabilmek için ReadComponent ve WriteComponent metodları mevcuttur. Bu metodlar sayesinde bileşenler stream verileri üzerine aktarılabilirler. Ki, Delphi IDE’si bunu bol bol kullanmaktadır. Eğer bileşen yazımı ile ilgili 3 bölümlük makaleyi okumuş iseniz bileşenlerde bir özelliğe kaydedebilme özelliği kazandırmıştık. Yani özelliğin kaydedebilme özelliği yoksa stream üzerine aktarılamazlar. Özelliklerin kaydedilebilme işlemine burada değinmeyeceğiz. Ama isterseniz, bileşen yazımı ile ilgili makaledeki kolleksiyon ve binary özellikler kısmına göz atabilirsiniz.

Bileşenlere bu özelliği kazandıran TPersistent sınıfıdır. TPersistent sınıfı ile ilgili daha fazla bilgi alabilmek için yardım dosyalarına göz atabilirsiniz.

Yeni bir form açalım ve bir button ekleyelim. Buttonun OnClick olayına aşağıdaki kodları yerleştirelim:

procedure TForm1.Button1Click(Sender: TObject);
var
  Mem: TMemoryStream;
  F: TFileStream;
begin
  Mem := TMemoryStream.Create;
  F := TFileStream.Create('c:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    Mem.WriteComponent(Button1);

    Mem.Position := 0; //Önemli!!!!

    F.CopyFrom(Mem, Mem.Size);
  finally
    Mem.Free;
    F.Free;
  end;
end;

Bu programı çalıştırıp button’a basarsanız, C: bölümde deneme.txt isimli bir dosya göreceksiniz. Bu dosyayı bir hex editor ile açıp kontrol edebilirsiniz. Ama dosyaya baktığınızda TButton’a ait tüm özelliklerin olmadığını göreceksiniz. Çünkü burada sadece bileşenin değişmiş olan özellikleri kaydedilir. Her özellik bir default değere sahiptir. Ve bu değer değişmiş ise, WriteComponent metodu bunu stream üzerine yazacaktır.

Şimdi bu dosyadaki Button1 bileşenini okutalım ve form üzerinde oluşturalım. Bunun için yeni bir uygulama açalım ve içinde Button1 isimli bir button olmamasına özen gösterelim. Çünkü birazdan bu bileşeni dosyadan biz oluşturacağız.

Form üzerine bir button ekleyelim ve ismine Button2 diyelim ve Caption olarak "bileşeni dosyadan oku" gibi bir şey yazalım. Ardından buttonun OnClick olayına aşağıdaki kodları yerleştirilem:

procedure TForm1.Button2Click(Sender: TObject);
var
  F: TFileStream;
  Button1: TButton;
begin
  F := TFileStream.Create('c:\deneme.txt', fmOpenRead or fmShareDenyNone);
  try
    Button1 := TButton.Create(Self);
    Button1.Parent := Self;
    F.ReadComponent(Button1);
  finally
    F.Free;
  end;
end;

Programı çalıştırıp Button2′ye tıklarsanız form üzerinde önceden kaydettiğimiz Button1 bileşenini göreceksiniz.

Önceden de dediğimiz gibi TPersistent olmayan nesneleri direk olarak stream olarak yazmak ve okumak mümkün değildir. Fakat kendinizin tanımlayacağı formatta, stream’den okuma ve stream’e yazma gibi fonksiyonlar ile nesnelerinize bu özelliği kazandırabilirsiniz. Zaten TPersistent sınıfının da yaptığı işlem budur. TPersistent sınıfına fazla girmek istemiyorum, fakat merakı olanlar TPersistent ile beraber TFiler, TReader gibi sınıflara yardımdan göz atabilirler.

Ek olarak bu konuda söyleyebileceğim bir tecrübem de şudur. İster VCL içinde olsun, ister başka bir yerden bulacağınız bir bileşen veya bir sınıf olsun, eğer stream ile çalışıyorlarsa şu 4 metod bunlarda bulunacaktır. LoadFromStream, LoadFromFile, SaveToStream, SaveToFile.

Buna tecrübe dedim çünkü literatürde bu metodlar aynı isim ve parametrelerle bulunacak diye bir şart yoktur. Fakat VCL’de bulunan bileşenlerde bolca kullanılan bu metodlar, diğer 3. parti bileşen ve sınıflarda da kolaylık ve alışkanlık olması açısından isimlerini ve yapılarını korumuştur. Eğer bir sınıf stream ile işlem yapıyorsa bilinki bu sınıfta, yukarıda bahsettiğimiz 4 metod bulunacaktır.

Sizler de yazacağınız sınıflarda bu metodları aynı isim ve yapıda kullanırsanız, sınıfınızı ya da bileşeninizi kullanacak olan kişiler zorlanmayacaktır. Bu metodların tanımlamasını VCL’de herhangi bir sınıf ya da bileşenin tanımlamasından kopyala yapıştır ile alabilirsiniz. Sadece burada değişecek olan kısım LoadFromStream ve SaveToStream metodlarıdır. Bu metodların içeriğini kendinize göre yeniden oluşturmalısınız.

Resource Verilerini Okuyup Yazmak

Resoruce verileri, kısaca açıklamak gerekirse, exe ya da dll dosyanız içine gömülen verilerdir. Bu veriler resim, yazı, icon, form olabileceği gibi herhangibir formatta stream verisi de olabilir.

Resource dosyaları ".RC" uzantılı bir dosyadan herhangi bir resource compiler ile derlenir. Bu derleme sonucunda ".RES" uzantılı bir dosya oluşacaktır. RES dosyalarını istediğiniz bir resource derleyicisi ile oluşturabilirsiniz. Çünkü bu res dosyaları derleyiciden bağımsızdır. Fakat RC dosyasının grameri değişiklik gösterebilmektedir. Biz bu makalede resource verilerini derlemek için delphi ile beraber gelen brcc32 derleyicisini kullanacağız. İsterseniz Visual Studio veya benzeri bir başka resource manager ile RES dosyaları oluşturabilirsiniz. Eğer Delphi 2009′a sahip iseniz, yeni "Resource Manager" ile daha rahat resource dosyaları oluşturabilirsiniz.

Delphi 2009′da menüden Project/Resources… altından ulaşabilrsiniz.

Biz elimizde Delphi’den başka bir şey olmadığını düşünerek işe koyulalım ve resource dosyamızı oluşturalım.

Notepad ile yeni bir yazı dosyası oluşturalım ve içine bir yerlerden uzun bir paragraf bulup yapıştırılım. Bunu yazi.txt ismi ile kaydelim. Aynı klasöre başka bir yazı dosyası daha oluşturalım ve içine aşağıdakileri yazalım:

yazi RCDATA yazi.txt 

Daha sonra bu dosyayı "yazi.rc" ismi ile aynı klasöre kaydedelim.

Burada ilk yazdığımız kelime resource’a verdiğmiz isimdir. İleride bu isme göre resource verimizi kullanacağız. İkinci kısımda RCDATA ile verimizin tipini belirledik. Burada RCDATA’nın dışında BITMAP, CURSOR ve ICON gibi ayrı ayrı tipler kullanılabilir. Bunların tam listesi için internette araştırma yapabilirsiniz. (http://msdn.microsoft.com/en-us/library/aa381043(VS.85).aspx). En sondaki kısım ise resource olarak kullanacağımız verimizin dosyasını giriyoruz.

Başlat/Çalıştır ile cmd yazıp entere basıp komut satırına geçelim. Buradan dosyaları kaydettiğimiz klasöre geçelim(msdos biliyorsunuzdur herhalde ). Ardından aşağıdaki komutu yazıp entere basalım.

brcc32 yazi.rc

Bir problem oluşmadı ise aynı klasörede yazi.res isimli bir dosya göreceğiz.

Bu işlemlerden sonra Delphi’ye geçip yeni bir uygulama açalım. Yeni uygulamamızı .res dosyalarını oluşturduğumuz klasöre kaydedelim. Şimdi az önce oluşturduğumuz res dosyasını programımız içine gömmek için gerekli işlemleri yapalım.

Unit1′in kodlarını açalım ve uygun bir boşluğa aşağıdaki derleyici direktifini girelim:

{$R yazi.res}

Programızı derlediğimizde bu res dosyasında buluna bütün veriler, resource verisi olarak programımıza gömülecektir. İsterseniz bunu ResHack gibi herhangi bir resource yöneticisi ile kontrol edebilirsiniz.

Şimdi bu gömülmüş olan veriyi okumamız gerekiyor diyelim. Mesela az önce programımız içine gömdüğümüz yazi.txt dosyasını bir memo içine alalım ve gösterelim.

Form üzerine bir adet memo bileşeni ve bir adet button ekleyelim. Button’unun OnClick olayına şunları yazalım:

var
  Res: TResourceStream;
begin
  Res := TResourceStream.Create(hInstance, 'yazi', RT_RCDATA);
  Memo1.Lines.LoadFromStream(Res);
end;

Programı çalıştırıp button’a basalım. Bir sorun çıkmadı ise memo bileşeninde yazi.txt dosyasındaki yazılı olan paragrafı göreceğiz.

Bu yaptığımız örnek ile görüyoruz ki; bir TResourceStream nesnesi, herhangi bir exe veya dll içindeki resource verilerine erişebiliyor. Create oluşturucusunda gördüğümüz ilk parametre resource verisini nereden çekeceğimizi belirliyor. Buna daha sonra değineceğiz. İkinci parametre olarak erişeceğimiz resource verisinin ismidir. Bunu RC dosyasını hazırlarken görmüştük. Aynı şekilde son parametre de RC dosyasında belirlenmişti. Bu son parametre ile resource verisinin tipini belirliyoruz. Tek fark olarak baş tarafına RT_ ön ekini getiriyoruz.

Sonraki işlem ise memo bileşenin Lines özelliğine streamdeki veriyi aktarıyoruz.

Bu mantığı kullanarak istediğiniz türde veriyi resource olarak gömebilir ve program çalışması anında kullanabilirsiniz. Bu yaptığımız örnek sadece mevcut programdan verileri çekebilir. Fakat başka bir dll ya da exe’den veri çekmemiz gerektiğinde ne yapacağız?

İşte bu durumda hInstance olarak girdiğimiz parametre değişecektir. Çünkü burada girdiğimiz parametre veriyi nereden çekeceğimizi daha doğrusu resource verisinini nerede olduğunu belirler.

Her program(exe, dll, ocx, ..) çalıştırıldığında windows tarafından bir handle numarası ile ilişkilendirilir. Delphi’de bu handle numarasına erişebilmek için hInstance isimli global bir değişkeni kullanıyoruz. Bu yüzden Create oluşturucusunda mevcut çalışan programımızın handle numarasını buraya birinci parametre olarak girdik.

Peki başka bir exe veya bir dll’in handle numarasını nasıl alırız?

Bunun için cevabımız LoadLibrary fonksiyonudur. Bu fonksiyon ile çağırdığımız herhangi bir program geçici olarak hafızaya yüklenir ve windows tarafından bir handle atanır. Bu handle numarası ise çıkış olarak döner. Eğer yükleme işlemi başarısız ise handle numarası 0 olarak dönecektir. Mesela yukarıda yaptığımız işlemleri bir dll içinden almaya kalkarsak nasıl yapacaktık?

var
  Res: TResourceStream;
  DLLHandle: THandle;
begin
  DLLHandle := LoadLibrary('resource.dll');
  if DLLHandle <> 0 then
  begin
    Res := TResourceStream.Create(DLLHandle, 'yazi', RT_RCDATA);
    Memo1.Lines.LoadFromStream(Res);
  end;
end;

Aynı işlemi exe, ocx gibi diğer çalıştırılabilir formatlar içinde yapabilirsiniz.

Artık herhangi bir veriyi exe içine gömüp okumayı öğrendik. Şimdi de bu işlemin bir benzerini veritabanlarında yapalım.

Veritabanında Stream Kullanımı

Artık buraya kadar öğrendiklerimizle herhangi bir stream verisini okuyup yazabiliriz. Burada yapacağımız işlem de pek farklı olmayacak. Bu yüzden hemen konuya girelim ve kısaca veritabanlarında nasıl stream kullanıldığını görelim.

Veritabanlarında bulunan tablolarda stream verilerini saklamak için alanımız BLOB tipinde olmalıdır. BLOB tipindeki alanlar binary veriler tutabilir. Fakat indeksli ve üzerinde çok arama tarama işlemleri yapılan bir tablomuz var ise bu BLOB alanlar veritabanı işlemlerini yavaşlatacaktır. Bu yüzden bu BLOB alanları başka bir tablo üzerine taşımak performansı artıracaktır.

Tabloda bulunan bir BLOB alana veri yazmak ve bu alandan veri okumak için TBlobStream nesneleri kullanılır. Kullanımı aşağıdaki gibidir:

var
  blob: TBlobStream;
begin
  blob := tblBirTablo.CreateBlobStream(tblBirTablo.FieldByName('BlobAlan'), bmReadWrite);
  try
    blob.Position := 0;
    blob.ReadBuffer(...);
    blob.WriteBuffer(...);
    ......
  finally
    blob.Free;
  end;
end;

Genel manada kullanım bu şekildedir fakat daha başka yöntemler ile de blob stream oluşturulabilir. Bu örnekte BlobAlan isimli bir alan hem okuma hem de yazma işlemleri için stream olarak bizim blob stream nesnemize atanmıştır. Burada sadece okuma işlemleri yapacaksak bmRead, sadece yazma işlemi yapacaksak bmWrite parametrelerini kullanmalıyız.

TStream’i .NET ve Delphi 2009′da Kullanmak

TStream sınıfı Delphi’nin bileşen mantığının temelini oluşturmaktadır. Delphi, .NET ortamına taşınırıken haliyle TStream sınıfı da ufak farklılıklar ile .NET ortamına taşınmıştır. Benim burada bahsedeceğim konu sadece bu küçük farklılıklar olacaktır. Geri kalan işlemlerde buraya kadar öğrendiğiniz bilgiler fazlasıyla yetecektir.

.NET ortamında Pointer işlemleri kullanılmadığından TStream sınıfı ve alt sınıfları için bir değişikliğe gidilmesi şarttı. Bu yüzden, TStream sınıfı .NET ortamına taşındığında Pointer işlemleri yerine, bu işlemlerin yerini tutan belirgin ve basit tipler için ayrı ayrı metodlar hazırlandı.

Mesela hatırlarsanız normalde TStream sınıfında bulunan ReadBuffer ile bir srting veri yazdığımızda string’i pointer olarak type cast yapıp parametre olarak giriyorduk. .NET’de pointer kullanmadığımız için ReadBuffer yerine artık aynı isimli ve sadece özel tipler için özdeşleştirilmiş bir metodumuz var. Bu metodu kullanarak rahat bir şekilde pointer kullanmadan işlemlerimizi aynı şekilde yapabiliriz. Tabi bu daha önce yaptığımız Win32 TStream sınıfına göre çok rahatlık getirmektedir. Bu da hiç şüphesiz .Net’in getiridiği rahatlıklardan birisi.

ReadBuffer ver WriteBuffer metodlarından bir kaçındaki değişlikliklere göz atalım:

    //TBytes
    procedure ReadBuffer(Buffer: TBytes; Count: Longint); overload;
    procedure WriteBuffer(const Buffer: TBytes; Count: Longint); overload;

    //Boolean
    procedure ReadBuffer(var Buffer: Boolean); overload;
    procedure WriteBuffer(const Buffer: Boolean); overload;

    //Integer
    procedure ReadBuffer(var Buffer: Integer); overload;
    procedure WriteBuffer(const Buffer: Integer); overload;
    procedure WriteBuffer(const Buffer: Integer; Count: Longint); overload; platform;

    //Char
    procedure ReadBuffer(var Buffer: Char); overload;
    procedure ReadBuffer(var Buffer: Char; Count: Longint); overload; platform;
    procedure WriteBuffer(const Buffer: Char); overload;
    procedure WriteBuffer(const Buffer: Char; Count: Longint); overload; platform;

    // AnsiChar
    procedure ReadBuffer(var Buffer: AnsiChar); overload;
    procedure ReadBuffer(var Buffer: AnsiChar; Count: Longint); overload; platform;
    procedure WriteBuffer(const Buffer: AnsiChar); overload;
    procedure WriteBuffer(const Buffer: AnsiChar; Count: Longint); overload; platform;

Tam liste için lütfen Borland.Vcl.Classes unitinde bulunan TStream sınıfına ya da yardıma göz atınız.

Gördüğünüz gibi aynı ReadBuffer metodu, overload yöntemi ile bir çok kez tanımlanmış. Biz bunlardan ihtiyacımız olanı seçip kullanacağız. Boolean ve Integer yazımı için tek bir adet parametre gerektirdiğine dikkat ediniz.

Diyelimki stream üzerine yazdıracağımız veya okuyacağımız veri çeşidine uygun bir metod bulunmamakta. Bu durumda verimizi bir byte dizisi gibi düşünüp ona göre davranacağız. Bu durumda verimizi TBytes’a yani "array of Byte" tipinieçevirmemiz gerekmektedir. Bunun için herhangi bir for döngüsü tanımlayarak bu işlememizi yapabiliriz.

Integter ile ilgili metodlara bakarsanız, en sonda fazladan Count parametresi alan bir metod yerleştirdim. Bütün metod çeşitlerinde alternatif olarak bu ikininci parametreye sahip olan metodlar mevcuttur. Bu parametreyi mesela Integer için normalde 4 byte ayrılmasına rağmen siz 10 byte yer ayırmak istediğinizde kullanablirsiniz.

Bu metodlara baktığınızda string ile ilgili bir özel metodun olmadığını farkedeceksiniz. Peki string veriyi nasıl yazacağız?

Bu durumda veriyi hangi encode’da yazacağımız veya okuyacağımız önemli. Veriyi istersek UTF8 formatında istersek UTF16 veya ANSI olarak okuyabilir ve yazabiliriz. Bu durumda string verimizi byte dizisine çeviren veya byte dizisini string verisine çeviren bir yönteme ihtiyacımız var. Aşağıdaki örneğe göz atalım:

var
  Mem: TMemoryStream;
  s: string;
  bytes: TBytes;
begin
  Mem := TMemoryStream.Create;
  try
    s := 'diyezon';
    bytes := Encoding.UTF8.GetBytes(s); //uses'a System.Text eklenmeli
    Mem.WriteBuffer(bytes, Length(bytes));
    Mem.Position := 0;
    Memo1.Lines.LoadFromStream(Mem);
  finally
    Mem.Free; //Yapmanıza gerek yok.
  end;
end;

Gördüğünüz gibi string verimizi utf-8 olarak stream üzerine attık ardından memo1 ile ekranda gösterdik. Bu işlemi yapabilmek için string verisini uygun bir byte dizisine çevirmemiz gerkiyordu. Bunun için System.Text alanında bulunan Encoding sınıfını kullanıyoruz. Bu sınıfı kullanabilmek için uses’a System.Text’i eklemelisiniz.

İsterseniz bu yazma işlemini Encoding.Unicode ile utf-16 ya da diğer adıyla unicode olarak, isterseniz Encoding.Default ile işletim sisteminin varsayılan ansi karakterleri olarak yazıp okuyabiliriz. Önemli olan string bir şekilde byte dizisine çevrilmiş olması gerekmektedir. Ayrıca yazma ve okuma işlemlerinde aynı tip encode formatını kullandığınızdan emin olun. Yani ya her ikisinde de Unicode ya da her ikisinde de UTF8 kullanın.

Eğer TBytes’dan stringe çevirim yapmamız gerekirse bu durumda aşağıdaki metodu kullanıyoruz:

s := Encoding.UTF8.GetString(bytes)

Gördüğünüz gibi .net ile bu işlemleri yapmak çok basit. Ayrıca en sonda stream’i free yapmasanız da Garbage Collector sizin için bunu yapacaktır. Fakat TFileStream kullanıyor ve dosyaya fmShareExclusive gibi kilitleyici bir parametre ile ulaşıyorsanız, stream nesnesini öldürmeden veya program kapanmadan, başka bir program dosyaya ulaşamaz, dosya kilitli kalır.

Bu bölümde bahsetmek istediğim başka bir konu da bu işlemleri Delphi 2009 ve üstünde yapmak. Burada bahsediyorum, çünkü bahsedeceğimiz bu konu .net ile de ilgili bir konu.

Aslında daha önceden gördük ki; bir stringi stream’e yazmak için stream’in kaç karakter olduğundan çok ,boyutunu bilmemiz gerekiyor. Bu yüzden ansi ya da ascii stringlerde boyut olarak her zaman Length(string) şeklinde aldık. Çünkü ansi stringlerde boyut = karakter sayısıdır. Fakat unicode olan stringlerde bu durum biraz farklıdır. Unicode olan stringler 1 byte değil, 2 byte yer kaplarlar. Bu yüzden WideString gibi unicode stringler ile uğraştığımızda artık boyutumuz Length*2 olmaktadır. Bildiğiniz gibi Delphi.Net ve Delphi 2009 ve yukarısı derleyicilerde "string" ve "Char" tipi unicode formatındadır. Bu derleyicilerde ansi olarak veri tanımlamamız gerektiğinde AnsiString, AnsiChar, PAnsiChar gibi tipleri kullanmalıyız. Aksi durumda bu derleyicilerde bir Char tipi 2 byte yer kaplar. Bu konu ile ilgili daha önceden örnek verdiğimizden bu konuyu burada bitiriyorum.

.NET Stream Nesnesinin Kullanımı

TStream’e ek olarak, .net’de aynı mekanizma bulunmaktadır. Neden bilmiyorum ama .net’de bulununa bir çok teknoloji Delphi ile benzerlik göstermektedir. Belki de c# ve .net’in fikir babası olan Anders Hejlsberg’in delphi’nin ilk temellerini atmasından kaynaklanıyor olabilir. Her neyse biz konumuza dönelim.

Aslında bu konu çok uzun anlatılabilecek bir konu ve burada bahsetmemiz makaleyi bir üçüncü bölüme bile taşıyabilir. Ki bence buna gerek yok. Ben sadece TStream ile arasındaki benzerlikleri gösterip, nasıl kullanıldığına dair bir örnek vermek istiyorum.

Bu bölümü VCL.Net kullanmak istemeyip saf .net kodu oluşturmak isteyenler veya Delphi Prism kullananlar için yazmak istedim. Aksi takdirde TStream sınıfı çoğu kez işimizi rahat bir şekilde görmektedir. Fakat bazen kullandığımız .net sınıfları .net’in stream sınıflarına ihtiyaç duyabilmektedir.

VCL’de bulunan bazı stream sınıfları yerine .net’de bulunan karşılıklarını şöyle sıralayabilriiz:

TFileStream => FileStream
TMemoryStream => MemoryStream
TIdTCPClient => NetwrokStream

vs..

Tabi bu stream sınıflarının metodları benzerlik gösterse de kullanımları farklıdır. Bu stream sınıflarını kullanabilemek için uses’a System.IO alanını eklemelisiniz. Biz buradan MemoryStream ile ilgili bir örnek verelim:

var
  Mem: MemoryStream;
  s: string;
  bytes: array of Byte;
begin
  Mem := MemoryStream.Create;
  s := 'diyezon';
  bytes := Encoding.UTF8.GetBytes(s);
  Mem.Write(bytes, 0, Length(bytes));

Gördüğünüz gibi kullanım olarak TStream’den farklı değil. Fakat Write metodunu TStream’de olduğu gibi bir çok çeşidi olduğunu zannetmeyin sakın. Çünkü MemoryStream sınıfında Write metodunun sadece iki adet varyasyonu mevcut. Bu metodda ilk parametre byte dizisi, ikinci parametre nereden itibaren yazılacağı yani ofset ve üçüncü parametre olarak yazdırılacak verinin uzunluğu giriliyor.

Bunun dışında bu string ve binary değerleri rahat bir şekilde okuyup yazabilmek için çeşitli ek sınıflar kullanılmaktadır. Mesela BinaryWriter ile binary değerleri stream üzerine yazabiliriz veya StreamReader ile streamden karakter verilerini okuyabiliriz. Aşağıdaki örneğe göz atalım:

var
  Mem: MemoryStream;
  textW: StreamWriter;
  s: string;
  bytes: array of Byte;
begin
  Mem := MemoryStream.Create;
  textW := StreamWriter.Create(Mem);
  s := 'diyezon';
  textW.Write(s);

Yukarıda yaptığımız işlemin aynısını burada StreamWriter sınıfı ile gerçekleştirdik. İşte burada StreamWriter sınıfının Write metodunda bir çok varyasyon mevcuttur. Bu varyasyonlara yardım dosyalarından ulaşabilirsiniz. Mesela bir Integer değer yazmak için yine StreamWriter’a ait Write metodunu kullanmamız kafidir.

Bunun dışında bir de kullanabileceğimiz BinaryWriter ve BinaryRead sınıfları mevcuttur. Bu sınıflar ise binary verileri okuyup yazmak için kullanılırlar. Ama kullanım aynı olduğu için bu konuya da girmeyeceğim.

Burada en son olarak BufferedStream sınıfından bahsetmek istiyorum. Bu stream ile okuma ve yazma işlemlerini başka bir stream üzerinde buffer’layarak daha hızlı işlemler yaptırabilirsiniz. Hatırlarsanız TMemoryStream sınıfından bahsederken, bu sınıfı diğer stream sınıflardaki okuma yazma işlemleri yerine kullanılabileceğinden ve bunun performansı artırdığından bahsetmiştik. İşte burada TMemoryStream bir buffer vazifesi görmektedir.

Mesela bir dosyaya bir çok veri yazılacak, ve bu veriler parça parça yazılacak. Ayrıca bu dosya stream’i üzerinde bir çok seek işlemi yani ileri geri alma işlemleri yapılacak. İşte bu durumda direk olarak TFileStream gibi bir dosya stream nesnesi ile uğraşmak yerine hafıza stream’leri ile uğraşmamız işlemlerimizin performansını önemli derecede artıracaktır. Yapacağımız stream işlemlerini bir hafıza stream’i üzerinde gerçekleştirip, en son işlemimiz bittiğinde hafıza stream’ini ilgili stream nesnesine aktarmak en akıllıca yöntemdir. İşte bu yönteme buffering ya da tamponlama tekniği denir.

İşte bu anlattığımız tekniği BufferedStream nesnesi gerçekleştirmektedir. Aynı işlemi ekstra bir memory stream tanımlayarak siz de oluşturabilirisiniz, hatta bu makalede buna benzer örnekleri çok gördük.

BufferedStream sınıfını kullanmak isteyenler, yardım dosyalarında ve msdn’de tanımlamasına bakabilirler. Artık stream mantığını kafanızda yerleştirdiğinize göre burada kullanımını vermek artık sıkacaktır.

Sonuç

Bir makalenin daha sonuna geldik. Bu makale serisinde VCL ve .net’de kullanılan stream sınıflarına değinmeye çalıştık ve bu sınıfların kullanımına dair çeşitli örnekler vermeye çalıştık.

Tabi ki burada verdiklerimiz stream için en temel konulardır. Bu makaleyi okuduktan sonra artık kafanızda stream’e ait somut düşüncelerin oluştuğunu zannediyorum. Ve bundan sonra önünüze gelecek olan bir çok stream işlemini rahat bir şekilde halledebileceğinizi umut ediyorum.

Fikir, eleştiri ve yorumlarınızı bekliyorum. Ayrıca makaledeki hataları bildirirseniz sevinirim.

Hayırlı çalışmalar.

Fatih Tolga ATA, Şubat 2009

Stream’ler hakkında bir makale yazmak, yapacaklarım arasındaydı. En son gelen bir istek üzerine stream konusuna el atalım istedim. Bu makale serimizde hem VCL’de bulunan TStream, hem de .NET’de bulunan Stream sınıfları ve kullanımlarından bahsetmeye çalışacağım.

Özellikle TStream üzerinde stringlerle uğraşmak gibi bir çok konu programcıların kafasını karıştırabilmektedir. Bu ve bunun gibi sorunların çözümlerine de çareler bulmaya çalışacağız.

Stream Nedir?

Bilgisayar ortamında yazma-okuma işlemlerinden bahsettiğimizde aklımıza bir çok şey gelir. Mesela disk üzerinde bir dosyaya erişip üzerinde yazma ve okuma işlemleri yapabiliriz. Veya bir hafıza bölgesinde yazma-okuma işlemleri yapabileceğimiz gibi bir veritabanındaki bir tablo alanında veya daha başka çeşit çeşit ortamlar üzerinde yazma-okuma işlemleri yapabiliriz. Bu bütün yazma-okuma işlemleri aslında her zaman yöntemi, işleyişi aynı olan bir fonksiyonlar dizisidir. Sadece alt planda yazma-okuma işleminin yapılacağı yüzeyde(disk, hafıza…) farklılıklar oluşmaktadır.

İşte bu işlemleri kolay bir şekilde, ortak bir sınıf üzerinden yapmak istediğimiz zaman ortaya Stream gibi bir yapı çıkıyor. Stream nesnelerini kullanarak, bir dosyayı yazıp okuyabilir, aynı fonksiyonları kullanarak bir hafıza bölgesine ulaşılabilir veya yine aynı fonksiyonlar ile bir veritabanı tablosunun alanına ulaşılabilir.

Stream, burada anlatılan basit özelliklerin yanında, stream verileri üzerinde bir çok işlemi yapabilmemize imkan sağlamaktadır. Bu makalemizde bunları ayrıntısı ile görmeye çalışacağız.

Stream Verileri

Stream nesneleri, stream verilerini kullanmamızı sağlamaktadır. Stream verileri, üzerinde çalışılan yere göre çeşitli veriler içermektedir. Bu bir resim dosyası olabileceği gibi kendimize özel çok farklı bir format da olabilir.

Buradan da anlaşılacağı gibi, stream verileri bir nevi bir byte dizisidir. Yani aynı veriyi "array of byte" şeklinde kullanarak da oluşturabilir ve üzerinde işlem yapabiliriz. Fakat bu, bize ek masraftan başka bir şeye yaramayacaktır. Üstelik yazacağımız fonksiyon ya da sınıf stream nesneleri gib esnek ve hızlı olmayacaktır.

Stream Ne Zaman Kullanılmalı?

Yapacağımız işlemerde stream mi, array mi kullanılmalı noktasında karar vermek istediğimizde bir kaç hususu göz önünde bulundurmamız gerekecektir.

İlk olarak bilmemiz gereken stream verileri array’de olduğu gibi indeksli değildir. Eğer kullanacağımız veriler, sabit veri tipi ise ve bir for döngüsüne girmek üzere oluşturulacak ise kullanacağımız nesne array olacaktır. Stream’de de istediğiniz veriye array’de olduğu gibi ulaşabilirsiniz. Fakat bu ileride de göreceğimiz gibi array indekslerinden farklı olarak çalışmaktadır.

Eğer bu veri dizimiz bir disk veya bir hafıza bölgesi üzerine yazılacaksa ve burada işlem yapılacaksa, bu durumda array yerine stream kullanılması bize bir çok kolaylık sunacaktır.

Aynı şekilde veri dizimiz sabit veri tipleri içermiyorsa yani sadece array of string veya sadece array of Integer değilse bu durumda yine stream kullanmalıyız. Mesela veri dizimizin birinci elemanı 4 karakterlik bir string, ikinci elmanı bir Integer, üçüncü elemanı bir Boolean, vs… gibi. Bu şekilde kendi dosya formatımızı oluşturabileceğimiz gibi, doc, exe, zip gibi bir çok binary dosyasının yapısını bildiğimizde bu dosyaların verilerine de ulaşabiliriz.

VCL’ de Stream Kullanımı

İlk başta VCL ile stream kullanımına değinelim. Ardında .Net üzerinde stream kullanımını göreceğiz.

VCL ile stream işlemleri yapabilmek için TStream sınıfından türeyen bir çok sınıf mevcuttur. TStream sınıfı abstract olarak tanımlanmış bir sınıftır ve direk olarak kullanılamaz. Abstract olarak oluşturulmuş olan bir sınıftan nesne oluşturulamaz. Ancak bu abstract sınıftan türemiş olan abstract olmayan sınıflardan nesne oluşturulabilir. Bu şekilde bir yapı olması, tüm stream sınıflarının aynı olan bir çok metod ve özelliğe sahip olmasını sağlar. Abstract sınıfların avantajları burada anlatılacak kadar kısa değil. Bu yüzden şimdilik bu kadar bilmemiz yeterli.

Help dosyasına göz attığımızda TStream sınıfından türemiş bir çok stream sınıfını görüyoruz.

TFileStream: Disk yani dosya sistemi üzerinde bulunan dosyalarla işlem yapmamızı sağlar.

TMemoryStream: Dosyalar üzerinde yapılan aynı işlemleri bir hafıza bölgesi üzerinde yapmamızı sağlar.

TBlobStream: Veritabanında bulunan bir tablodaki BLOB yani binary veri olarak tanımlanmış alanlar üzerinde okuma-yazma işlemleri yapmamızı sağlar.

TResourceStream: Resource dediğimiz, exe, dll gibi çalıştırılabilir dosyalar içine gömülü olan resim, yazı, dialog kutuları, versiyon bilgisi gibi çok çeşitli verileri okuyup yazmamıza imkan sağlamaktadır.

TStringStream: Aynı işlemleri bir string verisi üzerinde işlem yapabilmemizi sağlar. Böylece, sınırsız uzunlukta bir string üzerinde stream ile yapılabilecek her türlü işlemler yapılabilir.

Bunlar, temelde kullanılan stream çeşitleridir. Bunun gibi özel olarak tasarlanmış bir çok stream sınıfı da olabilir. Fakat hepsi TStream sınıfından türediği için, kullanımları da aynı olacaktır.

Dosyalar Üzerinde Stream İşlemleri

Dosyalar ile uğraşırken TFileStream kullanıldığını söylemiştik. TStream sınıflarının nasıl kullanıldığını, sonucu kolay görme açısından ilk başta dosyalar üzerinde görelim. İleride diğer stream çeşitlerine de değineceğiz.

var
  AFile: TFileStream;
  Buffer: String;
begin
  AFile := TFileStream.Create('C:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    Buffer := 'Deneme';
    AFile.WriteBuffer(Pointer(Buffer)^, Length(Buffer));
  finally
    AFile.Free;
  end;

Bu kodları bir button’nun OnClick olayına yerleştirip deneyelim. Kodlar çalıştırıldığında, C: üzerinde eğer bir erişim ihlali yoksa deneme.txt isminde bir dosya göreceğiz.

İlk bakışta bu kodlar ürkütücü gelebilir. Fakat konular ilerledikçe stream kullanmanın ne kadar rahat olduğunu göreceğiz.

AFile‘ın oluşturulduğu satıra bakalım. Bir TFileStream nesnesi oluşturabilmeniz için iki adet parametreye ihtiyacınız var. Birincisi dosyanın yolu, ki bizim örneğimizde "deneme.txt" olarak verilmiş. İkinci parametremiz ise bu dosya üzerinde yapacağımız işlem kipini ve paylaşım kipini belirler. İşlem ve paylaşım kipleri "or" kelimesi ile birleştirilerek kullanılır. Şimdi bu kiplerin ne olduğuna bakalım:

İşlem Kipleri:

fmCreate: Verilen dosya yolunda eğer dosya yoksa oluşturur. Eğer dosya var ise üzerine yazar.

fmOpenRead: Dosyayı sadece okuma amaçlı açar.

fmOpenWrite: Dosyayı sadece yazma amaçlı açar.

fmOpenReadWrite: Dosyayı hem okuma hem de yazma için açar.

Paylaşım Kipleri:

fmShareExclusive: Diğer uygulamaların, bizim üzerinde çalıştığımız dosya üzerinde hem okuma hem de yazma işlemlerini yasaklar.

fmShareDenyWrite: Diğer uygulamalar dosyayı okuyabilir fakat üzerinde yazma işlemi yapamazlar.

fmShareDenyRead: Diğer uygulamaların, dosya üzerinde okuma işlemi yapmasını yasaklar.

fmShareDenyNone: Ne okuma ne de yazma yasağı koyar. Yani diğer uygulamalar, dosya üzerinde yazma ve okuma yapabilirler.

fmShareCompat: Eskiden dos zamanlarında kullanılan FCB(File Control Block) ile uyumluluğu sağlamak için kullanılır. Windows üzerinde fmShareExclusive, Linux üzerinde ise fmShareDenyNone ile aynıdır. Bu yüzden bunu es geçebilirsiniz.

Yukarıda verdiğimiz örnekte olduğu gibi işlem kipleri ve paylaşım kipleri "or" kelimesi ile birleştirilerek kullanılır. Örneğimizde dosya fmCreate ile eğer yoksa oluşturulacak ve eğer varsa üzerine yazılacaktır. Ve dosya fmShareDenyNone kipinde olduğu için üzerinde herhangi bir okuma yazma yasağı bulumamaktadır.

Ardından try..finally buloğunda, stream üzerine yazma işlemleri yapılmaktadır. Şimdilik bu kısmı anlatmayacağız. Çünkü okuma ve yazma işlemleri için ayrı bir konu başlığımız bulunmaktadır.

finally bloğunda gördüğümüz Free metodu dosyalar üzerinde fazladan bir önem arz etmektedir. Çünkü bir kez TFileStream ile bir dosyaya erişildiğinde, bu stream nesnesi Free oluncaya yani yok edilinceye kadar, dosyanın handle’ı işletim sistemi tarafından tutulur. Dosya handle’ı aktif olduğu sürece dosyanın silinmesi taşınması işletim sistemi tarafından engellenir. Ve genelde herkesin karşılaştığı "Bu dosya bir uygulama tarafından kullanıyor." gibi bir mesaj alırız. Bunun için unlocker, process explorer gibi harici programlar ile aktif kalan bu handle’lar kapatılarak dosyalar silinebilir. Bu yüzden okuma yazma işlemlerimiz biter bitmez stream nesnemizi Free yapmalıyız.

Kısaca bir stream nesnesini oluşturmak için aşağıdaki şablonu kullanmalıyız:

var
  AStream: TBirStreamSınıfı;
begin
  AStream := TBirStreamSınıfı.Create({Stream sınıfına ait parametreler...});
  try
    //Stream üzerinde okuma yazma işlemleri
  finally
    AStream.Free;
  end;
end;

Stream Üzerinde Okuma-Yazma İşlemleri

Stream’ler üzerinde yazma işlemleri için başlıca Write ve WriteBuffer metodları ve okuma işlemleri için de Read ve ReadBuffer metodları tanımlanmıştır. Şimdi göreceğimiz işlemler Win32‘ye göre anlatılacaktır. İleride ayrı bir başlık halinde TStream sınıfının .NET üzerinde nasıl yazma okuma yapabileceğiniz de göreceğiz. Ayrıca .NET içinde bulunan Stream sınıflarına değineceğiz.

Stream üzerinde yapılan okuma yazma işlemleri bir işaretçi vasıtası ile yapılır. Bu işaretçi hangi pozisyonda ise o pozisyonda okuma ve yazma işlemi yapılır. İlk stream nesnesi oluşturulduğunda işaretçinin pozisyonu sıfırdır. Bu metodlar çağrıldığı vakit, yani her okuma ve yazma işleminin sonunda stream işaretçisi bir sonraki pozisyona kayar. Stream işaretçisi, stream verisinin sonuna gelip gelmediğini test etmek için Eof metodu kullanılır.Bu paragraf streamlerin çalışma mantığının anlaşılması için önemlidir. Bu yüzden dönüp ikinci bir defa okumanızda fayda var.

Sonunda Buffer yazan metodların yazmayanlardan farkından söz etmek istiyorum. Tek fark, "istisna" (Exception) yakalama özelliğidir. Yani mesela ReadBuffer metodu yine alt planda Read metodunu çalıştırır. Fakat Read metodu bir sorunla karşılaşır ve okuyamaz ise, ReadBuffer metodu, EReadError istisnasını yollar. Aynı şekilde WriteBuffer da sorun yaşadığında EWriteError istisnasını yollar. Böylece okuma ve yazma işlemlerinde herhangi bir hata olup olmadığının tespiti için ReadBuffer ve WriteBuffer ile beraber istisnaların yaklanması kafidir.

Okuma ve yazma metodları, işlemlerini bir buffer aracılığı ile gerçekleştirir. Bu buffer bir string olabilceği gibi bir Integer, bir record dahi olabilir. Bu yüzden her veri tipi için okuma ve yazma işlemlerinin nasıl olduğunu ayrı ayrı incelemeye çalışalım.

Sayısal Değelerin Okunması ve Yazılması

Integer, Byte, Double gibi sayısal verileri okuyup yazmak diğerlerine nazaran en basit işlemdir. Ekstra bir çevirim yapmamıza gerek kalmamaktadır.

Bunu bir örnek üzerinde görelim. İki adet button yerleştirelim. Birinin Caption özelliği "Yaz", diğerinin Caption özelliği de "Oku" olsun. "Yaz" butonuna çift tıklayalım ve şunları yazalım:

procedure TForm1.btnYazClick(Sender: TObject);
var
  BirStream: TFileStream;
  BirInteger: Integer;
  BirDouble: Double;
  BirReal: Real;
  BirByte: Byte;
begin
  BirStream := TFileStream.Create('c:\deneme.bin', fmCreate or fmShareDenyNone);
  try
    BirInteger := 15000;
    BirDouble := 1.3;
    BirReal := 123.123123123;
    BirByte := 65;
    BirStream.WriteBuffer(BirInteger, SizeOf(Integer));
    BirStream.WriteBuffer(BirDouble, SizeOf(Double));
    BirStream.WriteBuffer(BirReal, SizeOf(Real));
    BirStream.WriteBuffer(BirByte, SizeOf(Byte));
  finally
    BirStream.Free;
  end;
end;

Gördüğünüz gibi bir TFileStream nesnesi oluşturduk ve bu stream nesnesini kullanarak dosyaya bir takım sayısal değerler yazdırdık. Mesela ilk yazdırma örneğimizde buffer, Integer tipinde bir değişkendir. Bu Integer değeri yazdırırken ne kadar yazdırılması gerektiğini WriteBuffer metodunun ikinci parametresi olarak giriyoruz. Yani yazdıracağımız bu buffer kaç byte yer tutacak, onu ikinci parametre olarak giriyoruz. Örneğimizde, bu parametre olarak Integer‘ın boyutunu giriyoruz. Bunun için SizeOf fonksiyonundan faydalanıyoruz. Help dosyasına baktığımızda, Integer‘ın 4 byte yer kapladığını görürüz. Burada yaptığımız işlem dosyada 4 byte’lık bir alana Integer değeri yazdırmaktan ibarettir.

Ardından gelen yazma işlemleri de aynı mantık ile yapılmaktadır. Burada dikkat etmemiz gereken nokta ikinci parametredir. Çünkü bu parametre yanlış girilirse hem yazmada hem de okumada eksik ve yanlış verilerle karşılaşırız. Bu örnekten de anladığımız gibi sayısal veriler ile uğraşırken SizeOf(DeğişkeTipi) şeklinde ikinci parametreyi belirlememiz yeterlidir.

Şimdi bu programı çalıştırıp Yaz butonuna basalım. Diskin C: bölümünde deneme.bin isimli bir dosya oluşmuş olmalı. Herhangi bir hex editor ile (HxD) bu dosyayı açıp inceleyebilirsiniz. Eğer ayrıntısına girmek isterseniz Integer ve diğer sayısal değerlerin nasıl yazıldığını inceleyebilirsiniz. Mesela demiştik ki dosyamızın ilk 4 byte’ında bir Integer bulunmaktadır. Dosyamızı bir hex editör ile açtığımızda ilk 4 byte’ında 98 3A 00 00 yazdığını görürüz. IBM (x86) tabanlı makinelerde bu veriler tersten yazılırlar. Bu yüzden bu ifadeyi 00 00 3A 98 olarak düşüneceğiz. Hesap makinesini açıp 16′lık Hex moda geçelim. Tabi bunu yapabilmek için bilimsel moda geçmeniz gerekmektedir. Hex modu seçili iken 3A98‘i yazalım. Ardından Dec yani ondalık olarak her zaman kullandığınız sayı formatına çevirelim. Ve karşımızda 15000 sayısını göreceğiz ki bu değer örneğimizde Integer olarak dosyanın baş tarafına yazdırılmıştı. Diğer veri tiplerinin nasıl kaydedildiğini bu şekilde inceleyerek bulabilirsiniz.

Şimdi gelelim bu değerleri okumaya… Oku butonumuza çift tıklayıp şu kodları girelim:

procedure TForm1.btnOkuClick(Sender: TObject);
var
  DosyaOku: TFileStream;
  BirInteger: Integer;
  BirDouble: Double;
  BirReal: Real;
  BirByte: Byte;
begin
  DosyaOku := TFileStream.Create('c:\deneme.bin', fmOpenRead or fmShareDenyNone);
  try
    DosyaOku.ReadBuffer(BirInteger, SizeOf(Integer));
    DosyaOku.ReadBuffer(BirDouble, SizeOf(Double));
    DosyaOku.ReadBuffer(BirReal, SizeOf(Real));
    DosyaOku.ReadBuffer(BirByte, SizeOf(Byte));
    ShowMessage('Integer: ' + IntToStr(BirInteger) + #13 +
      'Double: ' + FloatToStr(BirDouble) + #13 +
      'Real: ' + FloatToStr(BirReal) + #13 +
      'Byte: ' + IntToStr(BirByte)
    );
  finally
    DosyaOku.Free;
  end;
end;

Şimdi bu programı çalıştıralım ve bu sefer oku butonuna basalım. Ve karşımızda dosyaya yazdırdığımız değerler…

Gördüğünüz gibi okuma işlemi yazma işleminden farklı değil. İhtiyacımız olan tek şey bir buffer ve bu buffer’ın tipinin boyutu. Eğer değişken tipinin boyutunu yanlış girersek veya okuma sırasını yer değiştirirsek, istediğimiz sonucu alamayız. Çünkü stream üzerine yazarken, bu sırada ve bu değişken tipleri ile yazılmıştır. Okurken de aynı sıra ve uzunlukta okunmalıdır. Bu yüzden, bu şekilde kendi dosya formatlarımızı oluştururken, bir plan üzerinde dosya formatında hangi pozisyonda hangi veri bulunacağı ve boyutu belirlenmelidir.

Gördüğünüz gibi sayısal verileri okumak ve yazmak hiç de zor değil. Şimdi dilerseniz karakter dizilerini nasıl okuyup yazacağımızı görelim.

Karakter Dizilerinin Okunup Yazılması

Karakter dizisi dediğimizde aklımıza gelen ilk değişken tipleri string ve PChar‘dır. Eğer Delphi 2009′dan önceki bir sürüm kullanıyorsanız bu değişken tipleri ANSI‘dir. Yani her bir karakter bir byte yer kaplar. D2009 ve sonrası için her bir karakter Unicode olduğu için 2 byte yer kaplarlar.

İlk önce PChar verilerini nasıl yazıyoruz ve okuyoruz onu görelim:

procedure TForm1.btnYazClick(Sender: TObject);
var
  DosyaYaz: TFileStream;
  Karakterler: PChar;
begin
  DosyaYaz := TFileStream.Create('c:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    Karakterler := 'http://www.diyezon.com';
    DosyaYaz.WriteBuffer(Karakterler^, Length(Karakterler));
  finally
    DosyaYaz.Free;
  end;
end;

Karakter verililerini yazdırırken ve okurken dikkat etmemiz gereken nokta yine verinin kapladığı alandır. Karakter dizisinin kapladığı alanı hesaplayabilmek için bir karakterin ne kadar yer kapladığını bilmemiz gereklidir. Önceden de dediğim gibi, eğer karakterleriniz ANSI ise yani Unicode değilse, her bir karakter 1 byte yer kaplar. Bu yüzden bu örneğimizde yazılacak uzunluk olarak karakter sayısını verdik. Çünkü ANSI karakter katarlarında karakter sayısı, karakter dizisinin boyutuna eşittir. Fakat PChar yerine PWideChar kullansa idik ya da bu kodları D2009 ve üzeri bir sürümde çalıştırsa idik her bir karakteri 2 byte olarak alacaktık. Bu durumda karakter sayısı karakter dizisinin boyutuna eşit değil, boyutun yarısı kadarı olacaktı. Yani Yukarıdaki kodda PChar‘ı PWideChar yaparsak WriteBuffer metodunun ikinci paramteresine Length(Karakterler) * 2 yazmamız gerekiyordu. Bu bahsettiğimizi örneğimizde değiştirip deneyin ve bir hex editör ile her bir karakterin 2 byte yer kapladığına şahid olun. Ama daha sonra tekrar PChar olarak değiştirip dosyayı tekrar yazın. Çünkü birazdan yapacağımız okuma işleminde PChar olarak okutacağız.

Okuma işlemine geçmeden önce WriteBuffer metodunda ilk parametreye bir göz atalım. Burada gördüğünüz gibi Karakterler değişkeninin sonuna ^ operatörünü ekledik. Bu operatör, işaretçilerle (pointer) birlikte kullanılan özel bir operatördür. Bir işaretçinin işaret ettiği esas değere erişmek için bu operatörü kullanıyoruz. Örneğimizde ise PChar tipindeki değişkenimizin işaret ettiği gerçek değeri buffer parametresi olarak girdik. Çünkü PChar da bir çeşit işaretçidir. Ve Karakterler^ yazmak ile bu işaretçinin hafızada işaret ettiği gerçek karakter verisini buffer olarak girdik.

Şimdi yazdırdığımız bu stream verilerini okuyalım:

procedure TForm1.btnOkuClick(Sender: TObject);
var
  DosyaOku: TFileStream;
  Karakterler: PChar;
begin
  DosyaOku := TFileStream.Create('c:\deneme.txt', fmOpenRead or fmShareDenyNone);
  try
    Karakterler := AllocMem(22);
    DosyaOku.ReadBuffer(Karakterler^, 22);
    ShowMessage(Karakterler);
  finally
    DosyaOku.Free;
  end;
end;

İlk yaptığımız işlem Karakterler değişkeni için hafızadan yer ayırmaktır. Bunun için AllocMem fonksiyonu kullanılır. Tabi bunun için okuyacağımız verinin ne kadar uzunlukta olduğunu bilmemiz gerekiyor. Eğer okuyacağımız karakter verilerinin uzunluğu belli değilse ya da duruma göre boyut değişebiliyorsa bu durumda daha başka bir şeyler yapmamız gerekecek. Bununla ilgili ayrıntılı bilgiyi ilerleyen konularda bulacağız. Ama şimdilik veri uzunluğumuzu sabit kabul ederek işlemlerimizi yapalım.

AllocMem ile hafızadan yer ayırdıktan sonra bu hafıza bölgesine stream verilerini yerleştirebiliriz. Bunun için yine ReadBuffer ile stream’den veri okuyoruz ve buffer’a atıyoruz. Yine buffer olarak işaretçinin gerçek değerini ifade eden ^ operatörünü kullanıyoruz. İkinci parametrede de ne kadar uzunlukta okuyacağımızı belirliyoruz.

PChar ile veri okuma ve yazma bu şekilde olmakta. Peki string bir değişkeni nasıl yazıp okuyacağız? Aslında PChar‘da kullandığımız yöntemden farklı değil. Çünkü string ile PChar arasında çok büyük bir fark bulunmamakta. Zaten çalışma anında bu iki tip arasında dönüşümler rahatlıkla yapılabilmektedir. Yazma için yazdığımız kodları aşağıdaki gibi değiştirelim:

procedure TForm1.btnYazClick(Sender: TObject);
var
  DosyaYaz: TFileStream;
  Karakterler: string;
begin
  DosyaYaz := TFileStream.Create('c:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    Karakterler := 'http://www.diyezon.com';
    DosyaYaz.WriteBuffer(Pointer(Karakterler)^, Length(Karakterler));
  finally
    DosyaYaz.Free;
  end;
end;

Önceki yazma işleminde çok farklı olmadığını burada görüyoruz. Tek yaptığımız işlem derleyiciye, string değişkene bir işaretçi gibi davranmasını söylüyoruz. Bu şekilde derleyici, string olan Karakterler değişkenini bir işaretçi gibi düşünecek ve ^ operatörü ile esas hafıza bölgesindeki veriyi buffer olarak kullanacak. Burada Pointer yerine PChar yazarak da type casting yapabilirsiniz.

Okuma kodları PChar‘a göre fazla ya da eksik değil. Önceki okuma fonksiyonumuzu aşağıdaki gibi değiştirelim.

procedure TForm1.btnOkuClick(Sender: TObject);
var
  DosyaOku: TFileStream;
  Karakterler: string;
begin
  DosyaOku := TFileStream.Create('c:\deneme.txt', fmOpenRead or fmShareDenyNone);
  try
    SetLength(Karakterler, 22);
    DosyaOku.ReadBuffer(Pointer(Karakterler)^, 22);
    ShowMessage(Karakterler);
  finally
    DosyaOku.Free;
  end;
end;

AllocMem yerine string için SetLength fonksiyonunu kullanıyoruz. Böylece string olan değişkenimizin boyutunu belirliyoruz. ReadBuffer‘da yapılanlar önceden anlatılmıştı.

String için yaptığımız bu işlemler biraz pointer yani işaretçi bilgisi gerektiren işlerdi. Halbuki bu pointer işlerine girmeden de string verileri yazıp okuyabiliriz. Ama ilk önce bu şekilde vermemin sebebi, esasında işin arkaplanda çalışma şeklini göstermekti.

Aslında diziler ve işaretçi olan PChar gibi karakter katarları hafızada bulunan esas verilerdeki ilk elemana işaret ederler. Derleyici bu değişken tipleri ile uğraşırken bunların uzunluğundan haberdardır ve ilk pozisyondan itibaren hafızada bu değişkenler üzerinde işlem yapabilir. Esasında PChar ve string‘de ortak olarak yapılan işlem, karakter dizisinin ilk elemanını buffer olarak girmektir. Her iki durumda da ^ operatörü dizinin hafızadaki ilk karakterine işaret eder. Geri kalanında Write ya da Read metodları verilen uzunluk kadar bu ilk karakterden itibaren okumaya ya da yazmaya başlar. Yukarıda string için yazdığımız kodları şu şekilde daha kolay ve sade bir şekilde de yazabiliriz:

procedure TForm1.btnOkuClick(Sender: TObject);
var
  DosyaOku: TFileStream;
  Karakterler: string;
begin
  DosyaOku := TFileStream.Create('c:\deneme.txt', fmOpenRead or fmShareDenyNone);
  try
    SetLength(Karakterler, 22);
    DosyaOku.ReadBuffer(Karakterler[1], 22);
    ShowMessage(Karakterler);
  finally
    DosyaOku.Free;
  end;
end;

procedure TForm1.btnYazClick(Sender: TObject);
var
  DosyaYaz: TFileStream;
  Karakterler: string;
begin
  DosyaYaz := TFileStream.Create('c:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    Karakterler := 'http://www.diyezon.com';
    DosyaYaz.WriteBuffer(Karakterler[1], Length(Karakterler));
  finally
    DosyaYaz.Free;
  end;
end;

Gördüğünüz gibi pointer’lardan kurtulup, bize yakın olan kodları kullandık ve aynı sonucu aldık. Ama arka planda derleyici bizim ilk yazdığımız ve işaretçileri kullandığımız kısımdaki gibi çalışır.

Burada tek yaptığımız işlem buffer olarak string değişkeninin ilk karakterini girmek. Tabi okuma işleminde yine SetLength‘i unutmuyoruz. Çünkü okuma işleminden önce hafızada yeterince yer ayrılması şarttır.

Önceden de dediğim gibi uzunluğu sabit uzunlukta olmayan karakter dizileri için ayrı bir konu başlığı ayırdık. O zamana kadar karakter dizimizin boyutunu sabit kabul edeceğiz.

Record’ların Stream Verileri Olarak Kullanılması

Genelde stream ile yapılmak istenen bir gurup veriyi yazmak ve okumaktır. Bu gurup verileri ise genelde record‘lar ile tutarız. Mesela aşağıda bulunan record içinde bir çok değişik değişken tipi bulunmaktadır.

TDosyaBasligi = record
  Imza: string[3];
  Versiyon: Double;
  IcerikBoyutu: Integer;
end;

Record’ları streamler ile beraber kullanırken şuna dikkat etmemiz gerekiyor. Bir record verisini stream ile okuyup yazabilmek için, record içeriğinin sabit uzunluklu verilerden oluşuyor olmasıdır. Aksi halde bu record, özel işlemler yapılmadığı taktirde, streamlerde kullanılmak için elverişli değildir. Bu yüzden yukarıda string değişkenini 3 karakter ile sınırlandırdık.

Okuma esnasında da aynı record verisini kullanarak rahat bir şekilde okuma işlemini yapabilriiz. Peki ama bu bize ne avantaj sağlayacak?

Önceki örneklerde gördüğümüz gibi, herbir string, Integer, Double gibi değişkenler için ayrı ayrı Read ve Write metodları kullandık. Halbuki bu değişkenler eğer sabit bir formda ise bunları bir paket halinde okuyup yazabilmeliyiz. İşte bu paket halinde okuyup yazma işlemi için recordları kullanıyoruz. Yani yukarıda verdiğimiz TDosyaBasligi isimli recordu yazabilmek için tek tek içinde bulunan 3 değişkeni yazdırmamız gerekmiyor. Sadece TDosyaBasligi isimli recordu yazdırmamız kafidir.

Şimdi yukarıda verdiğmiz recordu interface kısmında, TForm tanımlamasının yukarısında ama type‘ın altında yazalım. Ve Yaz butonunun OnClick olayına şunları yazalım:

procedure TForm1.btnYazClick(Sender: TObject);
var
  DosyaYaz: TFileStream;
  Paket: TDosyaBasligi;
begin
  DosyaYaz := TFileStream.Create('c:\deneme.txt', fmCreate or fmShareDenyNone);
  try
    Paket.Imza := 'DYZ';
    Paket.Versiyon := 1.2;
    Paket.IcerikBoyutu := 1500;
    DosyaYaz.WriteBuffer(Paket, SizeOf(TDosyaBasligi));
  finally
    DosyaYaz.Free;
  end;
end;

Gördüğünüz gibi herhangi bir ekstra işlem yapmadım. Sanki basit bir sayısal veriyi yazdırır gibi recordumuzu yazdırdık. Aynı şekilde okumasını da gerçekleştirelim:

procedure TForm1.btnOkuClick(Sender: TObject);
var
  DosyaOku: TFileStream;
  Paket: TDosyaBasligi;
begin
  DosyaOku := TFileStream.Create('c:\deneme.txt', fmOpenRead or fmShareDenyNone);
  try
    DosyaOku.ReadBuffer(Paket, SizeOf(TDosyaBasligi));
    ShowMessage(Paket.Imza + #13 + FloatToStr(Paket.Versiyon) + #13 +
      IntToStr(Paket.IcerikBoyutu));
  finally
    DosyaOku.Free;
  end;
end;

Bu programı çalıştıralım ve ilk önce Yaz sonra da Oku buttonlarına tıklayalım. Böylece bir recordu yazıp okuyabildik. Fakat disk üzerine yazılan dosyayı bir hex editör yardımı ile incelersek göreceğiz ki ilk kısımda bulunan 3 karakterlik stringten önce 1 byte’lık bir veri bulunmaktadır. Önceki string yazma işlemlerinden farklı olarak burada record içindeki stringlerin sadece verisi yazdırılmaz. String değişkeninin tamamı record ile beraber yazdırılır. String değişkenin tamamından kastımız stringi oluşturan parçalardır. Bir string, PChar gibi karakter dizilerinden farklı olarak ilk 0. baytında stringin veri uzunluğunu tutar. Bu örneğimizde 3 karakter uzunluğunda olduğu için hex editörde ilk göreceğimiz değer 03 değeridir. Tabi bu tek bytelık alanda en fazla 255 değeri yani FF değerini tutlabilir. Bu yüzden sınırlı bir string(literal string) kullanabilmek için en fazla 255 karakter kullanabiliriz. Aksi halde daha başka yollara başvurmalıyız. Başta bulunan 03 ifadesini kaldırıp sadece string verisini yazdırmak istersek array kullanmamız gerekmektedir. Array kullanımını bir sonraki konuda göreceğiz.

Sabit uzunluklu recordları kaydederken gördüğünüz gibi hiç zorlanmıyoruz. Eğer record içeriği burada olduğu gibi sabit uzunluklu değilse yani record içine PChar ya da limitsiz string girersek ne yapacağız. Bu durumda eğer yapabiliyorsak değişken uzunluklu olanları recorddan çıkartıp işlemlerimizi o şekilde yapmalıyız. Değişken uzunluklu verileri recorddan ayrı olarak okuyup yazmamız gerekmektedir. İleriki konularımızda değişken uzunluklu veriler ile nasıl çalışacağımızı da göreceğiz.

Dizileri Stream Verisi Olarak Kullanmak

Aslında dizileri stream üzerine yazmak için, buraya kadar öğrendiğimiz bilgiler yeterli. String’leri nasıl yazdırır ve okutuyorsak, aynı şekilde array’leri de yazdırıp okutabiliyoruz.

//Yazdırmak için
var
  FS: TFileStream;
  BirDizi: array[0..5] of Integer;
begin
  FS := TFileStream.Create('c:\deneme.bin', fmCreate or fmShareDenyNone);
  try
    BirDizi[0] := 153;
    BirDizi[1] := 1;
    BirDizi[2] := 3442;
    BirDizi[3] := 902;
    BirDizi[4] := 455;
    FS.WriteBuffer(BirDizi[0], SizeOf(BirDizi));
  finally
    FS.Free;
  end;
end;

//Okutmak için
var
  FS: TFileStream;
  BirDizi: array[0..5] of Integer;
begin
  FS := TFileStream.Create('c:\deneme.bin', fmOpenRead or fmShareDenyNone);
  try
    FS.ReadBuffer(BirDizi[0], SizeOf(BirDizi));
    ShowMessage(IntToStr(BirDizi[0]) + #13 +
      IntToStr(BirDizi[1]) + #13 +
      IntToStr(BirDizi[2]) + #13 +
      IntToStr(BirDizi[3]) + #13 +
      IntToStr(BirDizi[4]) + #13);
  finally
    FS.Free;
  end;
end;

Gördüğünüz gibi ilk elemanını buffer olarak giriyoruz ve ikinci parametre olarak da dizinin boyutunu parametre olarak giriyoruz.

Eğer dinamik array kullanıyorsak okuma işlemini gerçekleştiren ReadBuffer metodundan önce mutlaka SetLength ile dizinin boyutunu belirlemiş olmalıyız. Ayrıca dizinin kapladığı alanı bulabilmek için dinamik dizinin eleman sayısı ile elaman tipinin boyutunu çarpmalıyız. Yani yukarıdaki örnekte dinamik dizi kullanmış olsa idik Length(BirDizi) * SizeOf(Integer) kazacaktık.

İki ve daha fazla boyuttaki diziler için ise, iç içe bir for döngüsü kurularak bir okuma ve yazma algoritması geliştirilebilir.

Bu kısım diziler için kolay kısımdı. Çünkü bunlar önceki öğrendiklermizden farksızdır. Fakat eğer ActiveX ile uğraşıyorsanız, Word, Excel gibi programların otomosyonu ile uğraşıyorsanız variant array‘ler ile uğraşmışsınızdır. İşte bu durumda variant olan array’leri stream’e kaydetmek ve stream’den okutmak bu kadar kolay değildir. Ama zor da değildir. Eğer ActiveX ile uğraşmıyorsanız diğer başlığa atlayabilirsiniz, ya da nasıl yapıldığı hakkında fikir sahibi olmak için kalıp okuyabilirsiniz.

Bu örneğimizde otomosyon ya da ActiveX nesnelerine girmeyeceğim. Bir şekilde bu nesnelerden variant array verilerini aldığınızı düşünerek haraket edeceğim.

var
  VariantArray: Variant;
  VArraySize: Integer;
  PArray: Pointer;
  FS: TFileStream;
begin
  VariantArray := ActiveXNesnesi.ArrayDonderenMetod; //Bu kısım size ait...
  VArraySize := VarArrayHighBound(VariantArray, 1) - VarArrayLowBound(VariantArray, 1) + 1;
  PArray := VarArrayLock(VaraintArray);
  FS := TFileStream.Create;
  try
    FS.WriteBuffer(PArray^, VArraySize);
  finally
    FS.Free;
  free;
  VarArrayUnlock(VaraintArray);

Karışık gibi görünse de eğer ActiveX ile uğraşıyorsanız bu kısım size zor gelmeyecektir. İlk başta bir nesneden variant array değerini aldık. Bu değeri siz delphi içinde de oluşturabilirsiniz. Ardından bu array’in boyutunu hesapladık ve VArraySize isimli değişkene attık. Burada dikkat etmeniz gereken nokta, bu örneğimizde diziyi byte, char gibi her elemanı 1 byte olan bir diziye göre hesapladık. Eğer array’deki elemanların boyutu 1 byte’dan fazla ise bu durumda:

VArraySize := (VarArrayHighBound(VariantArray, 1) -
  VarArrayLowBound(VariantArray, 1) + 1) * TVarData(VariantArray).VArray^.ElementSize;

gibi bir şeyler yazmamız gerekiyordu. Yani eleman sayısı ile bir elemanın boyutunu çarpıyoruz. Daha sonraki gelen işlemlerde, variant array’in ilk elemanının işaretçisini alıyoruz. Bunun için VarArrayLock fonksiyonundan faydalanıyoruz. Bu işaretçiyi daha sonra buffer olarak WriteBuffer‘da kullanıyoruz. Bu işaretçi ile işimiz bitince VarArrayUnlock yapmayı unutmuyoruz.

Variant dizisini stream’den okurken de VarArrayCreate fonksiyonunu kullanıyoruz ve yeni bir dizi oluşturuyoruz. Ardından aynı VarArrayLock ve VarArrayUnlock işlemleri arasında dizimizi stream’den okuyoruz. Bu kısmı size bırakıyorum…

Değişken Uzunluktaki Verileri Okuyup Yazmak

Buraya kadar öğrendiğimiz işlemlerde hep varsayılan bir uzunluktan bahsettik. Fakat her zaman durum bu şekilde olmuyor.

Mesela, kullanıcının bir TMemo bileşenini doldurduğu bir form var. Biz bu TMemo‘da bulunan yazıyı ve başka verileri kendi dosya formatımızda saklamak istiyoruz. Ya da veritabanına kendi formatımızda kaydetmek istiyoruz. Bu durumda string’in ne uzunlukta olduğunu yazarken bilebiliriz fakat okurken bilemeyiz. Çünkü dosya’da ya da herhangi bir stream’de kayıtlı bulunan o string’e ait uzunluk, artık bizim bilgimizin dışına çıkmıştır. Buraya kadar yaptığımız örneklerde hep yazma ve okuma işlemlerini aynı programa koyduk ve aynı çalışma zamanında işlettirdik. Bu yüzden okuduğumuz verilerin boyutunu her zaman biliyorduk. Halbuki okuma fonksiyonu ayrı bir işlemde ise ya da programı açıp kapadığımızda da okuma işleminin çalışmasını istiyorsak bu durumda kaydedeceğimiz veriyi özel bir biçimde kaydetmeliyiz.

Bu ve bunun gibi durumlarda yapacağımız işlem çok basit ve her türlü değişken uzunluklu veri tipi için geçerlidir. Yapacağımız tek şey değişken uzunluklu olan verinin boyutunu sabit bir pozisyona yazmaktır. Ardından okuma esnasında bu sabit pozisyondaki değeri okutarak değişken olan verinin boyutu hakkında bilgi sahibi olabiliriz.

Mesela stream formatımız şu şekilde olsun:

Tabi bu çok basit bir format şekli. Normalde bir çok sabit içerikle beraber bir çok değişken içeriği iç içe kullanmamız gerekebiliyor.

Formatımıza göre ilk 3 byte’da dosya imzası bulunacak. Ardından gelen 8 byte dosyanın versiyonunu tutacak. Ve sonrasında gelen 4 byte’lık Integer değer ise bizim üzerinde uğraştığımız esas konudur. Çünkü bu Integer değer sonrasında gelen string içeriğin boyutunu tutmaktadır. Böylece okuma esnasında string verimizi ne kadar okuyacağımızı belirleyebiliyoruz.

En sonda ise 4 byte’lık bir Integer daha ekledim. Bu değer aslında bu örneğimizi için gerekli değil. Fakat burada bir noktaya dikkatinizi çekmek istediğimden bu değeri de dosya formatına ekledim.

Değişken uzunlukta olan string, array ya da herhangi bir değişkeni kaydederken normalde ilk akla gelen stream’in sonuna kadar okumak olacaktır. Ya da stream’in uzunluğundan diğer verilerin boytunu çıkarmak olacaktır. Halbuki işin içine iki veya daha fazla değişken uzunlukta veri girdiğinde ve buradaki örnekte olduğu gibi değişken uzunluktan sonra da bir başka veri geldiğinde bu mantık bizi idare etmeyecektir. Aynı şekilde dosya formatımızı sürekli olarak güncellenebilen bir format ise bu mantık yine çökecektir.

Bu durumda en mantıklı işlem, değişken verilerin başında bu verinin uzunluğunu saklamak olacaktır. Böylece sonrasında gelen değişken uzunluktaki veri rahatlıkla okunabilir.

Şimdi bu anlattıklarımızı pratiğe dökelim ve yukarıdaki stream formatımızı yine bir dosya üzerinde yazıp okuyalım. Bunun için yeni bir uygulama açın ve form üzerine bir adet button ve bir adet memo yerleştirin.

Unit’in interface kısmında TForm1 tanımlamasının hemen üstünde(type bloğu içinde) şunları yazalım:

type
  TDosyaBasligi = record
    Imza: array[0..2] of Char;
    Versiyon: Double;
    IcerikBoyutu: Integer;
  end;

Buttonnun OnClick olayına aşağıdakileri yazalım.

var
  FS: TFileStream;
  Baslik: TDosyaBasligi;
  Icerik: string;
  Rastgele: Integer;
begin
  FS := TFileStream.Create('c:\deneme.dyz', fmCreate or fmShareDenyNone);
  try
    Icerik := Memo1.Lines.Text;
    //Başlık bilgilerinin yazımı
    Baslik.Imza := 'DYZ';
    Baslik.Versiyon := 1.2;
    Baslik.IcerikBoyutu := Length(Icerik);
    FS.WriteBuffer(Baslik, SizeOf(TDosyaBasligi));

    //Değişken boyutlu içeriğin yazımı
    FS.WriteBuffer(Icerik[1], Length(Icerik)); //Unicode olduğunda Length * 2

    Randomize;
    Rastgele := Random(100);
    FS.WriteBuffer(Rastgele, SizeOf(Integer));
  finally
    FS.Free;
  end;

Burada aslında yeni bir şeyler görmedik. Sadece öğrendiklerimizi bir problemin çözümünde kullandık.

Baslik yazdırılmadan önce, değişken uzunluktaki içeriğimiz olan memo’nun Text bilgisinin uzunluğunu, Baslik record verisi içine alıyoruz. Ardından bu recordu stream’e yazdıktan sonra, değişken içeriğin uzunluğu da yazılmış oldu. Ardından normal bir stringi yazdırır gibi bütün karakterlerini stream üzerine yazdırdık. Ardından da rastgele bir sayıyı bu değişken uzunluktaki veriden sonra yazdırdık. Artık programı çalıştırıp Memo içine bir şeyler yazalım ve button’a basıp verileri stream üzerine kaydedilim.

Şimdi gelelim bu stream formatının okunmasına… Bunun için ayrı yeni bir uygulama açalım ve bir button ekleyelim. Ve bu buttonun OnClick olayına geçip şunları yazalım:

var
  FS: TFileStream;
  Baslik: TDosyaBasligi;
  Icerik: string;
  Rastgele: Integer;
begin
  FS := TFileStream.Create('c:\deneme.dyz', fmOpenRead or fmShareDenyNone);
  try
    //Başlık bilgilerinin okunması
    FS.ReadBuffer(Baslik, SizeOf(TDosyaBasligi));

    if Baslik.Imza <> 'DYZ' then
    begin
      ShowMessage('Desteklenmeyen format');
      Exit;
    end;

    if Baslik.Versiyon > 1.2 then
    begin
      ShowMessage('Bu format ancak üst versiyonlarda açılabilir.');
      Exit;
    end;

    //Değişken boyutlu içeriğin okunması
    SetLength(Icerik, Baslik.IcerikBoyutu);
    FS.ReadBuffer(Icerik[1], Baslik.IcerikBoyutu);
    FS.ReadBuffer(Rastgele, SizeOf(Integer));

    ShowMessage(Icerik + #13 + IntToStr(Rastgele));
  finally
    FS.Free;
  end;
end;

Burada yaptığımız işlem sadece verilerin okunmasından ibaret. Sadece dikkat etmemiz gereken kısım, ReadBuffer‘ dan önce SetLength ile değişken uzunlukta olan verinin uzunluğunu belirlememiz gerekiyor.

Değişken uzunluktaki stringler bu şekilde okutulabilir.

Bir küçük tüyo olarak, verileri yazdırdığımız kısımdaki şu kodlara bir daha göz atmanızı isteyeceğim:

  Icerik := Memo1.Lines.Text;
  ......
  ......
  Baslik.IcerikBoyutu := Length(Icerik);

Bu kodlar Baslik recordunun yazılmasından evvel doldurulmaktadır. Bazen öyle durumlar oluyorki, veri uzunluğunu verinin stream’e tamamen yazdırılmasına kadar bilemiyoruz. Mesela değişken uzunlukta bu stringimiz, stream’e yazdırılma esnasında belli bir algoritma ile dinamik olarak oluşturuluyor olabilir. Bu durumda string verisi tamamen stream üzerine yazdırılmadan, uzunluğunu bilemeyiz. Bu durumda TStream‘e ait Seek metodunu kullanacağız. Bu metod stream üzerinde belli bir pozisyona atlamamızı sağlamaktadır. Bu durumda kodumuz şöyle bir şey olacaktı:

  //Şimdilik yer ayırmak için 0 yazdırıyoruz.
  Baslik.IcerikBoyutu := 0;
  FS.WriteBuffer(Baslik, SizeOf(TDosyaBasligi));

  .....
  .....
  //Stream üzerine verilerin yazdırılması ve boyutunun hesaplanması...
  //Burada değişken uzunluktaki veri yazdırılmakla birlikte boyutu da hesaplanıyor.
  .....
  .....

  FS.Seek(15, soFromBeginning);
  FS.WriteBuffer(IcerikBoyutu, SizeOf(Integer));

Aynı şeyi Baslik recordunu en sonda yazdırmakla da yapabilrdik. Veya daha başka yollar ile de bu dediklerimiz yapılabilir. Burada bilmemiz gereken Seek metodunun kullanımıdır. Seek metodunda ilk parametre olarak 15 girdik. Çünkü örneğimizdeki stream format tablomuza baktığımızda 15. byte pozisyonunda içerik boyutu bulunmaktadır. Seek ile stream’in yazma işaretçisini buraya taşıdık ve bu pozisyondan sonra 4 byte’lık bir Integer değer yazdırdık. Seek metodunda kullanılan ikinci parametre için help dosyalarını gezebilirsiniz.

Değişken uzunlukta olan diziler için, yani dinamik diziler için de aynı mantığı kullanmamız gerekmektedir. Değişken olan dizinin boyutunu da stream üzerine yazdırmamız ve okuma anında bu değeri okuyup diziyi SetLength ile tekrar oluşturmamız gerekmektedir. Yapacağımız işlemler aynı olacağı için bu kısmı size bırakıyorum.

Bu bölümde bu kadar bilgi yeterli. Gelecek bölümde stream verilerinin başka streamler üzerine aktarılması ve kopyalanması, streamler ile nesne ve bileşen kullanımı, hafıza, resource, veritabanı gibi ortamlarla stream kullanımı ve son olarak .NET ortamında stream kullanımından bahsedeceğiz. İkinci bölüme geçmeden burada anlatılanları iyi bir şekilde kavrayıp, kendi denemelerinizi yapmanız gerekmektedir.

Eleştiri ve yorumlarınızı bekliyorum…

Fatih Tolga Ata – 2008

Aslında bu bölüm gerçekten uzun oldu. Normalde VCL kullanımını üçüncü bir bölüme taşımayı düşünüyordum. Ama bu konuda istekler olunca birleştrip yayınlamayı düşüdüm. İçeride sizi iki sayfalık bir makale bekliyor. Bu yüzden sayfa sonunda bitti zannedip kapatmayın!

Hazırsanız başlayalım.

Kanallar’ı Eş Zamanlı Olarak Çalıştırmak

Kanallar ile uğraşırken karşılaşılan en büyük sorunlardan bir tanesi de şüphesiz kanalları ortak bir şekilde sorunsuz olarak çalıştırmaktır. Eminim kanallar ile uğraşan birisi bütün kanallar tarafından ortak olarak kullanılan bir kaynağa erişmede problemlerle karşı karşıya gelmiştir ve kanalları bir köşeye itmesine sebep olmuştur.

Mesela şu veritabanı problemi size tanıdık gelecektir. Diyelim ki, iki adet kanalımız var ve bunlardan birincisi veritabanındaki bir kaydı açıp değişiklik yapmaya başladı. Sonra ikinci kanal aynı kaydın belli bölümlerinde düzenlemeler yaptıktan sonra veriyi kaydetti. Ardından birinci kanal, aynı verilerdeki değişikliğini bitirdi ve kaydetti. Birinci kanal, ikinci kanal’ın değişikliklerinden habersiz olduğundan ikinci kanalın yaptığı düzenlemeler de uçtu gitti.

Burada okuduğunuz problem, normalde kanallar ve veritabanı ile uğraşan bir çok programcının başına gelmiş bir problemdir. Bununla birlikte sadece veritabanında değil bir çok noktada özellikle bir dosyayı, bir portu, bir DLL’i veya başka bir şeyi, kanalların ortak kullanmasında hep benzer sıkıntılarla karşılaşılmıştır. Bu gibi sıkıntıların ve problemlerin çözümü kanalları eş zamanlı kullanım için kritik bölgeler tanımlamak ya da muteksleri kullanmaktır. Bu iki yöntem de makalemizin konuları arasındadır.

Kritik Bölgeler(Critical Sections)

Kritik Bölgeler -ya da başka yerlerde görebileceğiniz gibi kritik kesimler, bölümler, vs..- yukarıda anlatığımız problemdeki, birinci kanalın kaynağı kullanması esnasında ikinci kanalın bu kaynağa erişmesini englelemek için kullanılır. Birinci kanal işini yapıyorken, ikinci kanal’a çalışması için bir zaman dili ayrılmaz. Böylece birinci kanal işini bitirene kadar ikinci kanal çalıştırılmaz.

Bunun için örnek bir uygulamada yukarıdaki anlattığımız senaryolara benzer bir problem oluşturalım ve çözümünü aramaya çalışalım.

Diyelim ki, iki adet kanalımız var ve bu kanallar bir döngünün her adımında bir dizi işlem gerçekleştiriyor. Ve bu gerçekleştirdikleri işlemler için ortak kullandıkları global olarak tanımlanmış bir değişken olsun. Meseleyi anlatabilmek için iki kanalında yaptığı işlemlerin sonucunun aynı olmasını sağlamak istiyorum. Böylece problem daha iyi anlaşılabilecek.

Birinci kanal bir döngünün her adımında global değişkenimize teker teker harfler ekliyor ve sonuçta değişkenimizde bir yazı oluşuyor. Aynı işlemi ikinci kanalımız da yapıyor ve sonuç olarak birinci kanal ile aynı yazıyı üretiyorlar. Yanlız ikinci kanal harfleri teker teker eklemek yerine ikişer ikişer ekliyor. Ekleme işlemi çok hızlı olduğundan problemin oluşması için aralara Sleep rutinini ekleyerek işlemi birazcık yavaşlatıyoruz. Şimdi bu mantığımızı koda dökmeye başlayalım.

Yeni bir VCL uygulaması açalım ve bir adet button ekleyelim. Aşağıdaki gibi unitin var bloğunda global bir değişken tanımlayalım:

var
  Form1: TForm1;
  SonucYazi: string; //Global değişkenimiz

Ardından buttonun OnClick olayını aşağıdaki gibi değiştirelim.

procedure TForm1.Button1Click(Sender: TObject);
var
  Kanal1ID, Kanal2ID: DWORD;
begin
  CreateThread(nil, 0, @Kanal1, nil, 0, Kanal1ID);
  CreateThread(nil, 0, @Kanal2, nil, 0, Kanal2ID);
end;

Bu iki adet kanalımıza ait kanal fonksiyonlarını da aşağıdaki gibi oluşturalım:

procedure Kanal1;
procedure Kanal2;

...

implementation

...

procedure Kanal1;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    SonucYazi := SonucYazi + 'd';
    Sleep(10);
    SonucYazi := SonucYazi + 'i';
    SonucYazi := SonucYazi + 'y';
    SonucYazi := SonucYazi + 'e';
    Sleep(10);
    SonucYazi := SonucYazi + 'z';
    SonucYazi := SonucYazi + 'o';
    SonucYazi := SonucYazi + 'n ';
    Sleep(10);
  end;
end;

procedure Kanal2;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    SonucYazi := SonucYazi + 'di';
    Sleep(10);
    SonucYazi := SonucYazi + 'ye';
    SonucYazi := SonucYazi + 'zo';
    Sleep(10);
    SonucYazi := SonucYazi + 'n ';
  end;
end;

Gördüğünüz gibi iki kanal fonksiyonu da aynı sonucu üretiyor. Ama sonucu üretme yolları farklı. Ayrıca iki kanal da peş peşe oluşturulup çalıştırılıyor. Forma bir adet daha button ekleyelim ve bize sonucu göstersin. Bunun için ikinci butonumuzun OnClick olayını aşağıdaki gibi düzenleyelim:

procedure TForm1.Button2Click(Sender: TObject);
begin
  ShowMessage(SonucYazi);
end;

Bu programı çalıştırdıktan sonra ve kanalları birinci düğme ile çalıştırdıktan sonra sonuç yazının "diyezon diyezon diyezon …" gibi bir şey olmasını isteriz. Yani bir for döngüsünün bir adımı tamamlanmadan SonucYazi isimli global değişkene müdahale olmasını istemeyiz. Halbuki programı çalıştırdığınızda sonucun hiç de böyle olmadığını göreceğiz. Kanal1 işini bitirip "diyezon " yazmadan Kanal2 işe karışmış ve aralarda kendi harflerini eklemiştir. Hakeza bu, Kanal2 için de geçerlidir. Yani Kanal2, döngünün bir adımını bitirip istenilen sonucu veremeden Kanal1 global değişkenimize müdahale etmiştir.

Burada verdiğimiz örnek biraz soyut kaçabilir. Çünkü yaptığımız işlemden sonuç olarak elimize bir şey geçmiyor. Ama karşılaşacağınız sorunlar hep bu tarzda sorunlardır. Karşılaştığınız sorunları verdiğimiz bu örnek ile kıyaslama yapabilirsiniz. Mesela biz bu örneğimizde işlem adımlarını yavaşlatmak için Sleep rutinini kullandık. Normal hayatta kanallar ile uğraşırken zaten yaptığımız işlemlerin adımları Sleep rutinini aratmamaktadır. Mesela bir veritabanı tablosunda Edit ve Post gibi metodları kullandığımızda belli bir miktar işlemin tamamlanmasını bekleriz. Bir de eğer sizde sonuç düzgün çıkıyorsa yine söylüyorum işlemciniz, bu makaleyi yazdığım sıralardaki işlemcimden hızlı demektir. Bu durumda Sleep rutinine verdiğimiz değerleri çok az miktarlarda artırmayı deneyin.

Sadede gelelim ve problemi anladı isek şöyle bir soruyu kafamıza getirelim: Bir kanal belli bir işini bitirmeden önce diğer kanalların müdahalesini nasıl engelleyebiliriz?

Cevabı zaten bu bölümün başında verdik. Bunun için belli yerleri kritik bölge ilan edeceğiz. Bir kanalda kritik bölge ilan ettiğimiz yerdeki kodlar çalışmaya başladığı sırada, diğer kanallardaki aynı kritik bölgedeki kodlar işletilmez ve bekler. Yani aynı kritik bölgeye sahip kanallardan aynı anda sadece bir bölgedeki kodlar çalıştırılabilir. Böylece diğer kanalların istenilmeyen müdahalesi engellenmiş olur.

Bir Kritik bölge tanımlamak için bilmemiz gereken üç dört adet Windows apisi vardır.

InitializeCriticalSection: Bu fonksiyon kritik bölge’yi temsil eden recordun ilk değerlerini atamakla sorumludur. Yani kritik bölgeyi kullanıma hazırlamaktadır. Genelde formun OnCreate olayında kullanılır.

DeleteCriticalSection: Yukarıdaki fonksiyonun tam tersi olarak, bu fonksiyon da kritik bölgeyi ortadan kaldırır. Genelde formun OnDestroy olayına yerleştirilir.

EnterCriticalSection: Bu fonksiyonu çalıştırdığınız satırdan itibaren kritik bölgenin başlangıcını belirtirsiniz. Yani Delphi’deki "begin" kelimesi gibi düşünebilirsiniz.

LeaveCriticalSection: Bu fonksiyon ise, çalıştırıldığı satırla kritik bölgeyi sınırlandırır. Yine Delphi’deki "end" ifadesine benzetebiliriz.

Kritik bölgeyi temsil eden record ise TRTLCriticalSection tipindedir. Normalde Windows SDK yardım dosyalarında LPCRITICAL_SECTION şeklinde tanımlanmıştır. Ama Delphi ekibi bir çok windows yapısını tanımlarken bunlara "T" ile başlayan daha iyi okunur alias isimler vermişler. Her neyse…

Kritik bölgenin tanımlanması gayet basittir. Bir kritik bölgeyi işletim sistemine tanıtmak için InitializeCriticalSection fonksiyonunu kullanıyoruz. Kritik bölge ile işimiz bittiğinde de DeleteCriticalSection fonksiyonunu çağırmayı unutmuyoruz. Ardından kanal fonksiyonlarımızda kritik bölgeleri belirleyip başına EnterCriticalSection ve sonuna LeaveCriticalSection sonksiyonlarını koyuyoruz.

Örneğimize dönelim ve kritik bölgeleri eklemeye başlayalım. Bizim müdahale istemediğimiz bölge, kanal fonksiyonlarındaki döngülerin her bir adımıdır. Yani teker teker veya ikişer ikişer ekleme yapılan kısımlarda bir adım işini bitirmeden başka bir kanalın global değişkenimize müdahalesini engellemek istiyoruz. Kısacası kritik bölgemiz bu örnekte, döngünün her bir adımı olmalıdır.

İlk başta global olarak bir değişken daha tanımlayalım. Bu değişken bizim kritik bölgemizi temsil eden record olsun.

var
  Form1: TForm1;
  SonucYazi: string;
  BirinciKritikBolge: TRTLCriticalSection; //kritik bölgemizi temsil ediyor.

Ardından formun OnCreate ve OnDestroy olaylarını aşağıdaki gibi değiştirelim.

procedure TForm1.FormCreate(Sender: TObject);
begin
  InitializeCriticalSection(BirinciKritikBolge);
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  DeleteCriticalSection(BirinciKritikBolge);
end;

Eğer başka kritik bölgeler de tanımlamış iseniz bunları da InitializeCriticalSection ve DeleteCriticalSection fonksiyonlarını kullanarak oluşturmalı ve silme işlemlerini gerçekleştirmelisiniz. Bizim örneğimizde bir adet kritik bölge yeterlidir.

Şimidi kanal fonksiyonlarında bahsettiğimiz yerleri kritik bölge olarak ilan edelim.

procedure Kanal1;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    EnterCriticalSection(BirinciKritikBolge); //BirinciKritikBolge başlangıcı
    SonucYazi := SonucYazi + 'd';
    Sleep(10);
    SonucYazi := SonucYazi + 'i';
    SonucYazi := SonucYazi + 'y';
    SonucYazi := SonucYazi + 'e';
    Sleep(10);
    SonucYazi := SonucYazi + 'z';
    SonucYazi := SonucYazi + 'o';
    SonucYazi := SonucYazi + 'n ';
    Sleep(10);
    LeaveCriticalSection(BirinciKritikBolge); //BirinciKritikBolge bitişi
  end;
end;

procedure Kanal2;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    EnterCriticalSection(BirinciKritikBolge); //BirinciKritikBolge başlangıcı
    SonucYazi := SonucYazi + 'di';
    Sleep(10);
    SonucYazi := SonucYazi + 'ye';
    SonucYazi := SonucYazi + 'zo';
    Sleep(10);
    SonucYazi := SonucYazi + 'n ';
    LeaveCriticalSection(BirinciKritikBolge); //BirinciKritikBolge bitişi
  end;
end;

Yapacağımız başka bir işlem kalmadı. Programı çalıştırıp deneybiliriz. Sonucun "diyezon diyezon diyezon …" gibi düzgün olduğunu göreceğiz. Çünkü Kritik bölge tanımlayarak sadece bir kanalın kritik bölgesini çalıştırmış olduk. Böylece bir kanal global SonucYazi değişkeni ile uğraşırken diğer kanal buna müdahale edemeyecektir.

Burada bir adet kritik bölge tanımladık. Sizler ihtiyaca göre projelerinizde bir çok kritik bölge tanımlayabilirsiniz. Ayrıca kritik bölgelerin birbirinden bağımsız hareket ettiğini de aklınızdan çıkarmayın. Bazen karıştırılan nokta bu kısım olabiliyor. Mesela bu örneğimizde bir adet kritik bölge mevcut ama iki farklı yapılan iş var.

Gördüğünüz gibi kanalları eş zamanlı olarak çalıştırmak o kadar da zor değilmiş. Tek yaptığımız bell bölgeleri kritik bölge olarak ilan etmek. Şimdi yeni bir kavramla daha tanışalım.

Muteksler(Mutex)

İngilizce’ de, mutual ve exclusive kelimelerinin birleşiminden meydana gelmiştir. Dilimizde ise müşterek ve seçkin kelimeleri bu kelimeleri karşılamaktadır. Programlama terminolojisinde ise, sadece tek işlemdeki değil birden fazla işlemdeki kanalları eş zamanlı olarak kullanılmasını sağlayan bir tekniktir.

Bir mutekse aynı anda sadece bir tek kanal sahip olabilir. Literatürde, bu mutekse, bir kanal sahip olduğunda, muteksin kanal tarafından "tetiklendiği" ya da "tutulduğu" söylenir. Aynı şekilde eğer kanal bu mutekse sahip deiğilse muteks "serbestir" ya da "tetiklenmemiştir" tabirleri kullanılır.

Şu an kafanızda mutekslerin ne olduğuna dair somut bir düşünce oluşmamış olabilir. Ama bölümün sonuna kadar okuduğunuzda neyin ne olduğuna dair bir fikir oluşacağına eminim.

Bir muteks, CreateMutex fonksiyonu ile oluşturulur. Bu fonksiyonun tanımlanması ve açıklaması aşağıdadır.

function CreateMutex(lpMutexAttributes: PSecurityAttributes;
  bInitialOwner: BOOL;
  lpName: PChar): THandle;

lpMutexAttributes: Muteksin güvenliği ile ilgli parametredir. Bu parametreye nil girerek varsayılan güvenlik özelliklerini ayarlamış oluyoruz.

bInitialOwner: Kanalın bu mutekse sahip olup olmadığını ya da yukarıda bahsettiğimiz gibi muteksin tetiklenip tetiklenmeyeceğini belirler. True ya da False giriyoruz. Genelde muteksi programın ana kanalında oluşturduğumuzdan, ana kanalın mutekse sahip olmasını istemeyiz. Bu yüzden genelde bu parametreye False gireriz.

lpName: Eğer farklı işlemler bu mutekse erişecekse bu muteksimize bir isim vermemiz gerekmektedir. Buraya nil de girebilirisiniz. Bu durumda isimsiz bir muteksimiz olur.

Bu fonksiyon eğer muteksi oluşturabilirse çıktı olarak muteksin handle numarasını dönderir. Eğer muteks oluşmamış ise 0 değerini çıktı olarak verir.

Muteksleri, kritik bölgeler gibi düşünebilirsiniz. Kritik bölge oluşturmak için kullandığımız InitializeCriticalSection fonksiyonu yerine CreateMutex fonksiyonunu, kritik bölgenin başlangıcını belirten EnterCriticalSection yerine WaitForSingleObject fonksiyonunu, kritik bölgenin bitişini bildiren LeaveCriticalSection fonksiyonu yerine de ReleaseMutex fonksiyonunu kullanıyoruz. CloseHandle ile de CreateMutex ile oluşan muteksin handle’ını kapatmayı da unutmuyoruz.

İlk önce bir muteks oluşturalım.

birmuteks := CreateMutex(nil, False, 'ornekmuteks');

Ardından kritik bölgeyi oluşturduğumuz yerlerdeki fonksiyonları muteksin fonksiyonları ile yer değiştiriyoruz. Şimdilik sadece Kanal1 için örnek verelim.

procedure Kanal1;
var
  i: Integer;
begin
  for i := 0 to 10 do
  begin
    WaitForSingleObject(birmuteks, INFINITE); //Muteksin tetiklenmesini bekle
    SonucYazi := SonucYazi + 'd';
    Sleep(10);
    SonucYazi := SonucYazi + 'i';
    SonucYazi := SonucYazi + 'y';
    SonucYazi := SonucYazi + 'e';
    Sleep(10);
    SonucYazi := SonucYazi + 'z';
    SonucYazi := SonucYazi + 'o';
    SonucYazi := SonucYazi + 'n ';
    Sleep(10);
    ReleaseMutex(birmuteks); //Muteksi serbest bırak.
  end;
end;

Şimdi muteksin ne olduğuna dair kafanızda bir şeyler şekillenmeye başlmamıştır. Çünkü kodlara baktığımızda WaitForSingleObject fonksiyonu bir şeyleri bekliyor ve ReleaseMutex ise bir şeyi serbest bırakıyor. WaitForSingleObject, "tek bir nesne için bekle" gibi bir manası var. Esas yaptığı görev, birinci parametresinde verilen handle numarasına göre bir muteksi beklemektir. İkinci parametresinde ise ne kadar bekleyeceğini belirliyoruz. Bu örneğimizde INFINITE (sonsuz) girmekle, bir muteks tetiklenene kadar bekleyeceğini belirttik. Bu parametreye, en fazla ne kadar bekleneceğini milisaniye şeklinde girebilirsiniz.

Muteksi anlamada genelde verilen örnek ve bence en iyi örnek bayrak yarışıdır. Bayrak yarışlarında bir şeritte ancak bir koşucu koşabilir. Bayrağı alan koşmaya başlar. Bir şeritte, bayrağa sahip olmayan, koşabilmek için bayrağı beklemesi gerekmektedir. Böyelece her bir şeritte sadece bir yarışçı koşabilir.

Aynen bunun gibi, kanallar çalışabilmek için mutekse sahip olmaları gerekmektedir. Mutekse sahip olan koşmaya yani çalışmaya başlar. Mutekse sahip olmayan, muteksin kendisine gelmesini bekler. Bir hatırlatma olarak, önceki paragraflarda sahip olmanın tetiklemek olduğundan bahsetmiştik.

İşte WaitForSingleObject ile muteksin bu kanalımıza gelmesini beklemiş oluyoruz. Ve bunu örneğimizde, INFINTE yani sonsuz süre kadar bekliyoruz. Ve muteksle işimiz bittiğinde diğer kanalların kullanabilmesi için muteksi ReleaseMutex ile serbest bırakıyoruz. Ve yine tekrar ediyorum "Bir mutekse aynı anda sadece bir tek kanal sahip olabilir."

CreateMutex ile oluşturduğumuz muteksin handle’nı formun OnDestroy olayında CloseHandle ile kapatmayı da unutmuyoruz. Yani kritik bölgelerde yaptığımız DeleteCriticalSection yerine

CloseHandle(birmuteks);

gibi bir şey yazmalıyız.

Bu örneği, makaleyi fazla uzatmasın diye, burada tüm kodlarını yazmayacağım. Muteks örnek projesini buradan indirebilirsiniz.

Eğer tek bir muteks değil de bir den fazla muteksi tetiklemesini bekelemek istersek ne olacak? Bu durumda WaiıtForMultipleObjects fonksiyonunu kullanacağız. WaitForSingleObject tek bir muteksi beklerken WaitForMultipleObject fonksiyonu birden fazla muteksi beklemektedir. Kullanım aynı olduğu için bununla ilgili bir örnek yapmayacağım. Bu fonksiyon ile iligli tek söyleyebileceğim şey ikinci parametrede beklediğiniz mutekslerin handle’larını dizi şeklinde girmeniz olacaktır.

Başka İşlemlerden Mutekslere Sahip Olma

Dediğimiz gibi, mantık olarak mutekslerin kritik bölgelerden tek farkı, başka program ve işlemlerdeki kanallar ile ortak ve eş zamanlı çalışmaya izin vermesidir. Bunun için muteksimize bir isim vermemiz gerektiğini söylemiştik. İşte bu ismi kullanarak başka bir işlem muteksin handle numarasını alabilir. Gerisinde de WaitForSingleObject ve ReleaseMutex fonksiyonlarında bu handle numarasını kullanabiliriz. Yani mevcut bir muteksin handle numarasını alabilmek için:

birmuteks := OpenMutex(0, False, 'ornekmuteks');

dememiz yeterli. Bunu yukarıdaki örneğimizde CreateMutex yerine kullanabilirsiniz. Ama unutmamanınız gereken nokta bunun ile mevcut bir muteksin handle numarasını alırız. Eğer muteks CreateMutex ile hiç oluşturulmamış ise bu fonksiyon 0 değerini dönderir.

OpenMutex fonksiyonunun parametreleri CreateMutex ile aynı olduğundan burada fazladan bir açıklama yapmayacağım.

Bu konuda bir örnek yapmak isterseniz yukarıda verdiğimiz örneği iki uygulamaya bölebilirsiniz. Kanal1‘i birinci uygulamada, Kanal2‘yi de ikinci uygulamada oluşturursunuz. Ve ikisinde de OnCreate olayında şöyle bir şey girersiniz:

var
  BirMuteks: THandle;
.....
procedure TForm1.OnCreate(....);
begin
  BirMuteks := OpenMutex(0, False, 'ornekmuteks');
  if BirMuteks = 0 then
    BirMuteks := CreateMutex(nil, False, 'ornekmuteks');

Kısaca burada yaptığımız işlem eğer "ornekmuteks" isminde bir mutex henüz oluşturulmamış ise oluşturuyoruz.

Bu şekilde iki veya daha fazla sayıda işlem tek bir muteks üzerinde kanallarını eş zamanlı olarak çalıştırabilirler. Bu örneği kendiniz yapmaya çalışın. Gerçi burada yapılmışı var . Ama lütfen indirip incelemeden önce kendiniz yapmayı deneyin.

—

İşte size iki adet yöntem. Ve ikisi de windows programlamada çok sık kullanılmaktadır. Kanalları beraber çalıştırmak istediğinizde, istrer muteks kullanın isterseniz kritik bölge tanımlayın. Her ikisinin de tanımlanması ve kullanılması çok kolay. Kafanızdaki "kanal kullanmak çok zordur" düşüncesini birinci bölümde aştığınızı düşünüyorum. Buraya kadar olan kısım ile de "kanalları eş zamanlı çalıştırmak zordur" düşüncesini yendiğinizi zannediyorum.

Peki muteks ve kritik bölge arasında tercih yapmak gerekirse hangisini tercih etmeliyiz. Bence performans açısından pek fark olmaz. Seçim noktanız şu olmalı. Eğer, tek bir işlemden değil de bir çok işlemden yani bir çok programdan oluşan bir gurubun kanalları ortak ve eş zamanlı kullanmasını düşünüyorsak kesinlikle muteks kullanmalıyız. Aksi durumda yani eş zamanlı çalışacak olan kanallar sadece tek bir işlemde bulunuyorlarsa o zaman seçim size kalmış. Hangisi rahatınıza gidiyorsa onu kullanabilirsiniz.

Şimdi farklı bir konuya geçiş yapalım. Hazırsanız ikinci sayfadan devem edelim.

Bu makale, ileri seviye Windows programcılığına geçiş kapısıdır. Bu makeledeki konuları öğrendikten sonra Win32 programcılığının en güçlü özelliklerini öğrenmiş olacaksınız.

Yanlız "ileri seviye" tabiri gözünüzü korkutmasın. Çünkü makeleyi bitirdiğinizde thread kullanımının aslında ne kadar kolay olduğunu göreceksiniz. Bununla birlikte bu makalede bu konu ile ilgili her ayrıntıyı anlatabilmemiz için yüzlerce sayfalık kitap yazmamız gereklidir. Bu yüzden burada işin mantığını kapıp, ihtiyacınız oldukça yardım dosyalarına müracaat etmeniz gerekebilir.

Kanallar hakkında hiç bir bilginiz olmayabilir. Bu makalede işin temelinden alacağız ve makaleyi bitirdiğinizde kendi programlarınıza kanal ekleyebilecek duruma geleceğinize inanıyorum.

Bu makale serisinde kanallar temelden anlatılmakla beraber, ileri seviye kanal kullanımı, VCL bileşenlerinde kanal kullanımı ve Muteksler de ana konularımız arasına girecektir.

Giriş

İlk başta bir kaç teorik bilgi ile başlamak istiyorum. Bu bilgilieri olabildiğince sıkmadan, kısa tutmaya çalışacağım.

Disk üzerindeki her bir dosya çalıştırıldığında artık windows için birer işlem(process) olurlar. Bir işlem Windows için fazla bir şey ifade etmez. Çünkü işlemler sadece hafızada belli bir bölgede var olmaktan sorumludur. Esas işlemi yapan kısım kanallardır(thread). Bir işlem en az bir adet kanala sahiptir. Win 3.1 gibi işletim sistemleri sadece bir adet kanala sahiptir. Ama Windows 95 ve üstü, Unix, OSX gibi işletim sistemleri birden fazla kanala sahip olabilirler.

İşletim sistemi bir programı ya da bir DLL’i ilk başta işlem olarak hafızaya taşır. Bu esnada işlem eylemsiz olarak durur. Bu işleme ait kanallar ise bizim belirlediğimiz ölçüde programın kodlarını çalıştırmaya başlar.

Her kanal, çalışma esnasında kendi eax, ebx, edx gibi register verilerini tutan bir yapıya sahiptir. Bu yapıya context(içerik) adı verilmektedir. Bu yapının Delphi’deki karşılığı TContext olup, Windows unitindedir. Bu record tipini incelediğinizde bir çok register’ı barındırdığını göreceksiniz. Eğer buradaki Delphi ve Assembler ile ilgili makaleyi ve buradaki fonksiyon çağırım makenizmalarını okudu iseniz şimdi anlatacaklarımız size tanıdık gelecektir. Çünkü kanalların işleyiş mantığı fonksiyon çağırımlarına benzemektedir. Ama devam edebilmek için bunları okumak zorunda değilsiniz.

Her bir kanal sahip olduğu önceliğe göre işletim sistemi tarafından işleme alınacaktır. Bu işleme alış esnasında sahip olduğu context‘deki register değerleri yüklenir. Esp, Ebp, Eip gibi registerlar da yüklendiğinden, kanal önceden kaldığı yerden önceki stack değerlerine göre işlemine devam edecektir. Ve yine önceliğine göre belli bir süre sonunda işletim sistemi bu kanalı durdurup register değerlerini context yapısında saklar. Daha sonra diğer bir kanalın context verisini yükleyerek başka bir kanalı işlemeye geçer. Ve hakeza bu işlem tüm kanallar için devam edip gider. İşletilme ve geçiş süreleri çok kısa olduğundan, biz sanki aynı anda tüm kanallar işletiliyormuş gibi zannederiz. Halbuki bütün kanallar belli bir sıra ile çok kısa sürelerde işletilip diğer bir kanala geçilmektedir. Yani her kanal aynı anda çalışmaz, biz öyle zannederiz. Tabi bu anlattıklarımız tek işlemci ve tek çekirdek için geçerlidir. Kanalların işletilme sürelerini ise kanalların önceliği belirlemektedir. Hangi kanal daha yüksek öncelikli ise o kanal daha fazla işletilme süresine sahip olur. Eğer kanal arkaplanda çalışma üzere ayarlanmış ise, diğer kanallar işlemlerini tamamladıktan sonra ancak bu kanala sıra gelecektir. Eğer kanal çok yüksek önceliğe sahip ise uzun bir süre bu kanal işleme devam edecek ve diğer kanallara sıra gelmeyecektir.

Demek ki, aynı anda bir kaç işlem yapmak istiyorsak kafa patlatıp, parmak yormamıza gerek yokmuş. Çünkü işletim sistemi zaten sizin için bu sistemi kurmuştur. Sadece biraz vaktiniz ayırmanız ve kanallar nasıl oluşturuluyor öğrenmeniz yeterlidir.

Kanal Oluşturma Yöntemleri

Aslında böyle bir başlıkla konuya giriş yapmak istemezdim. Ama kanal oluşturmayı öğrenmeden önce bir kaç şeyi açığa kavuşturmak istiyorum. Gerek forumlardan gerekse haber guruplarından kanallarla ilgili gelen sorulardan bir çoğu kanalların yanlış oluşturulması üzerine kaynaklanan yanlışlıklardan gelmektedir.

Normalde bir kanal windows ortamında CreateThread Windows API’si ile oluşturulur. Fakat VCL bize TThread isminde bir sınıf da sunmuştur. Kullanım açısından ayırt edebileceğiniz temel nokta şudur. Eğer kanalda yapacağınız işlemler VCL sınıflarını etkilemesi gerekiyorsa TThread sınıfını kanal oluşturmak için kullanıyoruz. Yok eğer VCL sınıflarını ilgilendiren bir işlem söz konusu değilse CreateThread API’sini kullanıyoruz. Bunun neden böyle olduğunu ileride VCL ve Kanal kullanımı ile alakalı başlıkda vereceğim. Muhtemelen Bölüm 2′de göreceksiniz. Bu yüzden biraz sabır.

Başlarken bu şekilde bir giriş yapmamın sebibi buradan kaynaklanıyor. Bir çok kişi belki de Windows API’lerine karşı bir soğukluktan dolayı CreateThread ile uğraşmak istemiyor ve CreateThread ile ilgili kısımları gözü kapalı atlayabiliyor. Bu yüzden eksik kanal bilgisi ile ileride bir çok sorunla karşılaşabiliyor. Ama şimdi göreceğimiz gibi kanal oluşturma işlemi sanıldığı kadar zor ve karmaşık bir işlem değil.

Bir Kanal Oluşturalım

Kanal oluşturma ile sorumlu Windows fonksiyonu CreateThread fonksiyonudur ve aşağıdaki gibi tanımlanmıştır:

function CreateThread(lpThreadAttributes: Pointer;
  dwStackSize: DWORD; lpStartAddress: TFNThreadStartRoutine;
  lpParameter: Pointer; dwCreationFlags: DWORD; var lpThreadId: DWORD): THandle; stdcall;

Bu fonksiyonun parametrelerinin kısaca açıklamasını verelim.

lpThreadAttributes: Kanalımıza atanacak olan bir çok güvenlik özelliğini belirtmemize yarar. Eğer nil girerseniz varsayılan güvenlik özellikleri kullanılacaktır. Win9x ve WinMe için bu değer nil olmalıdır. Bu konu ile alakalı daha fazla bilgi almak için sdk yardım dosyalarından SECURITY_ATTRIBUTES başlığına müracaat edebilirsiniz.

dwStackSize: Eğer kanal için özel bir stack büyüklüğü belirlemeyecekseniz bu değeri 0 olarak girmelisiniz. Böylelikle kanalın stack büyüklüğü program ile aynı olacaktır. Gerektiğinde stack boyutu otomatik olarak genişletilebilir.

lpStartAddress: Bu parametre esas işi gören parametredir. Çünkü kanal çalışmaya bu parametredeki fonksiyon işaretçisi ile beraber başlar. Burada tek yapmamız gereken fonksiyonun isminin önüne @ işareti vererek girmektir.

lpParameter: Bir önceki parametrede girdiğimiz kanal fonksiyonuna parametre yollamak istiyorsanız, bu parametrelerin içinde bulunduğu bir record’un adresini buraya girmelisiniz. Ayrıca record haricinde karakter veya sayı değelerini de parametre olarak yollayabiliriz.

dwCreationFlags: Bu parametre ile kanalın oluşturulur oluşturulmaz çalışıp çalışmayacağını belirliyoruz. Eğer bu parametreye CREATE_SUSPENDED girerseniz, kanal oluşturulur fakat kendisine çalışmaya başlaması için izin verilmez. Bu durumda siz ResumeThread fonksiyonu ile bu kanala çalışma talimatı vermedikçe kanal o şekilde çalışmadan duracaktır. Bir kez ResumeThread ile çalışmaya başladıktan sonra SuspendThread ile tekrar kanalı durdurabilirsiniz. Eğer bu parametreye 0 girerseniz, kanal oluşturulur oluşturulmaz çalışmak için sıraya girecektir.

lpThreadId: Bu parametreye kanal kimlik ID’si atanır. Buraya değeri olmayan bir Dword değişken giriyoruz. Değişken gireceğiz çünkü "var" olarak tanımlanmış. Çünkü kanal oluşturulduktan sonra Windows NT,2000 ve üstü işletim sistemlerinde kanalın ID’si bu değişkene yüklenir. Windows 9x/Me işletim sistemlerinde bu değer daima 0′dır.

Şimdi gelin bu fonksiyonu kullanarak bir kanal oluşturalım.

var
  KanalID: DWORD;
begin
  CreateThread(nil, 0, @KanalFonksiyonu, nil, 0, KanalID);

İşte hepsi bu! Tek yaptığımız sadece gerekli parametreleri kullanmak, gerisini duruma göre nil veya 0 yapmak. Bu fonskiyon çağrıldığında KanalFonksiyonu isimli fonksiyonumuz kanal içinde çalışmaya başlayacaktır.

Dilerseniz KanalFonksiyonu isimli fonksiyonumuzun tanımlamasını şimdi yapacağımız örnek içinde verelim.

Basit Bir Örnek

Şimdi oluşturduğumuz bu kanalın nasıl çalıştığını basit bir örnek ile görmeye çalışalım. Yeni bir uygulama oluşturalım ve Form üzerine bir adet button ve bir adet label koyalım. Button’nun Caption özelliğini "Oluştur ve Çalıştır" olarak değiştirelim. Ve Button’nun OnClick olayına kanalımızı oluşturan şu kodları girelim:

procedure TForm1.Button1Click(Sender: TObject);
var
  KimlikID: DWORD;
begin
  CreateThread(nil, 0, @KanalFonksiyonu, nil, 0, KimlikID);
end;

Şimdi de kanalımızda esas işi yapan KanalFonksiyonu isimli fonksiyonumuzun tanımlamasını girelim:

function KanalFonksiyonu(P: Pointer): Longint; stdcall;

...

implementation

...

function KanalFonksiyonu(P: Pointer): Longint; stdcall;
var
  i: Integer;
  Toplam: Int64;
begin
  Toplam := 0;
  for i := 0 to 1000000000 do
  begin
    Toplam := Toplam + i;
    Toplam := Toplam shl 4;
  end;
  Form1.Label1.Caption := 'Kanal işlemini tamamladı. Sonuç:' + IntToStr(Toplam);
end;

Bu fonksiyonda ekstra bir şey yapmıyoruz. Sadece bir for döngüsü var ve matematiksel bir işlem yapılıyor. For döngüsü bittiğinde ise formdaki label’a bir sonuç yazdırıyoruz.

Bu for döngüsünü, ayrı bir kanalda değil de programın ana kanalında çalıştırmaya kalksaydık muhtemelen Application.ProcessMessages ve TTimer gibi çözümlere gidecektik. Bu durum da çok fazla miktarda performans düşüklüğüne sebep olacaktı. Ayrıca işlemlerimiz genelde buradaki gibi basit matematiksel işlemler olmadığından, programda çökmelere ve donmalara sebep olacaktık.

Bu programı çalıştıralım ama button’a basmayalım. Eğer açık değilse View menüsünden "Thread Status" penceresini ve "Event Log" penceresini açalım ve görebileceğimiz bir köşeye yerleştirelim. Eğer BDS 2005 ve üstü kullanıyorsanız bu pencereler debug esnasında altta görünür biçimde hazır olacaklardır.

Ardından buttona bir kez basalım ve "Thread Status" penceresine yeni bir eleman eklendiğine dikkat edelim. Eğer buradaki eleman çok çabuk bir şekilde görünüp kayboldu ise işlemciniz benimkinden hızlı demektir . Bu yüzden for döngüsündeki limit değeri biraz artırıp tekrar çalıştıralım.

Button’a her tıkladığınızda "Thread Status" pencersinden de takip edebileceğiniz gibi yeni bir kanal eklenecek. Tabi butona basma işini o kadar çok abartmayın. Her kanal oluşturulduğunda kendisine bir ID atanacak. Örneğimizde bu değer KimlikID değişkeninde tutuluyor. "Thread Status" pencersinde ise ThreadID sütununda bu değeri görebiliriz. Her kanal işlemini bitirdiğinde "Thread Status" pencersinden kaybolduğunu göreceksiniz. Aynı şekilde "Event Log" pencersinde de kanal’ın ID’sine göre başlama ve bitişi ile ilgili mesajları görebilirsiniz.

Kanal çalışırken program üzerinde istediğiniz işleme devam edebilirsiniz. Formu taşıyabilir, boyutlandırabilir, başka bileşen ve nesneler var ise onları kullanabilirsiniz. Ve bunu yaparken bir yandan kanal(lar) da çalışmaktadır. Aynı kanal fonksiyonunu doğrudan çağırmaya kalktığımızda formumuza döngü bitene kadar müdahale edemeyecektik.

Gördüğünüz gibi bir kaç satır kod ile kanal oluşturuveriyoruz. Tek bilmemiz gereken kısım CreateThread fonksiyonunun parametreleri. Bunların çoğunu da kullanmadık. Ama makalenin ilerleyen kısımlarında bunları da yavaş yavaş kullanıma dahil edeceğiz. İşte bir tanesi geliyor.

Kanal Fonksiyonlarına Parametre Gönderimi

CreateThread fonksiyonunun parametrelerini açıklarken lpParameter‘den söz etmiştik ve bu parametre ile kanal fonksiyonuna istediğimiz parametreyi gönderebileceğimizi belirtmiştik. Şimdi bunu nasıl yapacağımızı görelim.

Bunun için yukarıda yaptğımız örnekten faydalanacağız. İlk başta type bloğunda aşağıdaki record tanımlamasını yapalım.

  PKanalParametresi = ^TKanalParametresi;
  TKanalParametresi = record
    BirParametre: string;
  end;

Ardından kanal fonksiyonumuzu aşağıdaki gibi değiştirelim.

function KanalFonksiyonu(P: Pointer): Longint; stdcall;
var
  Parametreler: PKanalParametresi;
begin
  Parametreler := PKanalParametresi(P); //Parametremizi alalım.
  while True do
  begin
    Form1.Label1.Caption := Form1.Label1.Caption + Parametreler^.BirParametre;
    Sleep(1000); //İşlemcinin %99 çalışmasını istemiyiz değil mi....
  end;
  Dispose(Parametreler);
end;

En son olarak button’nun OnClick olayını da aşağıdaki gibi olacak şekilde değiştirelim.

procedure TForm1.Button1Click(Sender: TObject);
var
  KimlikID: DWORD;
  Parametreler: PKanalParametresi;
begin
  New(Parametreler);
  Parametreler^.BirParametre := 'a';
  CreateThread(nil, 0, @KanalFonksiyonu, Parametreler, 0, KimlikID);
end;

Aslında çok fazla bir şey yapmadık(en azından siz kopyala yapıştır yaptınız:) ). Burada basit bir işaretçi kullanımını görüyoruz. Ve parametre olarak bir record’u kullandık. Record yerine başka veri tiplerini de kullanabilirdik. Ama genelde karşılaşılan sorunlar recordları parametre olarak yollamaktan gelmektedir.

En başta verdiğimiz record tanımlamasına bakarsanız, PKanalParametresi isminde bu recordumuza işaretçi olan bir tip göreceksiniz. Parametremizi işaretçi olarak kullanacağımızdan bu tipe ihtiyacımız olacak. Ardından Button’nun OnClick olayına bakalım. Burada önceki örneğe göre fazladan 2 satır ekledik. İlk başta var bloğunda Parametreler isminde bir record işaretçisi tanımladık. Ardından işaretçi hiç bir şey ifade etmediğinden, işaretçiye ait bir recordun hafızada oluşturulması için New rutinini kullandık. Devamında bu record’un değişkenlerinden birine bir string değer atadık. CreateThread fonksiyonu parametreyi işaretçi olarak istediğinden buraya direk olarak Parametreler değişkenimizi girebiliriz. Çünkü bu değişken bir record işaretçsidir.

En son olarak yeni kanal fonksiyonumuza baktığımızda, işaretçi olarak gelen parametremizin nasıl kullanıldığını görüyoruz. Burada bizim için önemli olan kısım Dispose kısmıdır. Çünkü burada New ile oluşturduğumuz ve işaretçiye ait olan recordu hafızadan siliyoruz.

Record işaretçisi yerine normal record kullansa idik ve sonra da bunu parametre olarak geçirirken pointer olarak geçirse idik olmazmıydı. Olurdu… Üstelik New ve Dispose rutinlerini de kullanmak zorunda kalmazdık. Ama, bu durumda boş yere hafızda yer işgal edecektik. Çünkü parametre recordu sadece bir kerelik işimize yarayacak. Bu yüzden işimiz bitince Dispose ile hafızdan siliyoruz.

Bu örneğimizi de çalıştırıp deneyebilirsiniz. Ayrıca Görev Yöneticisi ile işlemciyi yüzde kaç kullandığını da görebilirsiniz. Tabi burada Sleep rutinini kullanmak yerine daha başka yapılabilecek şeyler var ama şimdilik kafa karıştırmamak için bunları sonraya bırakıyorum.

Sonuç

Bu bölümü burada noktalayalım. Gelecek bölümde kanalların nasıl birbirleri ile birlikte çalışabileceğini göreceğiz. Ayrıca Mutex’ler ve VCL ile kanal kullanımı da gelecek bölümde göreceğimiz konular arasında olacak. Böylece kanallar konusunda hiç bir şüpheniz, korkunuz kalmayacağı gibi programlarınıza da profesyonellik katacaksınız.

Gelecek bölümde buluşmak ümidi ile… Yorumlarınızı ve eleştirilerinizi bekliyorum. Yine her zaman ki gibi sorularınızı buradan yada Delphi Türkiye forumlarından iletebilirsiniz

Fatih Tolga Ata © 2007

Kaynaklar

• Windows SDK Yardım Dosyası
• Delphi 4 Unleashed, Charlie Calvert, Sams Pub., 1999

Bu bölümde Sınırlandırıcıları(Constraints) göstermeye çalışacağız. Hazırsanız buyrun.

Sınırlandırıcılar(Kısıtlamalar, Constraints)

Öyle olurki bazen, tip argümanlarınızın belli metodları ve özellikleri içermesini isteyebilrsiniz. Mesela çizim yapma özelliği olan sınıfların kolleksiyonunu tutan bir generic sınıf düşünün. İsmi de TCizebilenKolleksiyon gibi bir şey olsun. Bu generic kolleksiyona atayacağınız her elemanın bir çizim gerçekleştiren “Ciz” gibi bir metodunun olmasını isteyebilirsiniz. Bu durumda, tip parametresini belli arayüzler ile sınırlandırmanız gerekmektedir. Bu örneğimizi koda dökecek olursak, arayüzümüz şöyle bir şey olacak:

ICizebilen = interface
public
  procedure Ciz;
end;

Bu arayüz ile sınırlandırılmış olan kolleksiyon sınıfımız da şöyle bir şey olabilir:

TCizebilenKolleksiyon<T: ICizebilen> = class
...
end;

Bu durumda T parametresine atayacağımız her argümanın ICizebilen arayüzünün sahip olduğu özellik ve metodlara sahip olacağını garantilemiş oluyoruz.

.Net ortamında kullanabilceğiniz bir çok arayüz bulunmaktadır. Bu arayüzler genelde “able” son eki ile biterler. “able” ekinin Türkçe karşılığı “-ebilen”, “-abilen” olarak düşünebilirsiniz.. ISerializable, IComparable, ICloneable, vs…

Tip parametreleri birden fazla arayüz sınırlandırıcısı alabilir. Bu durumda tip parametreleri virgül yerine aynen prosedür ve fonksiyonların parametrelerinde olduğu gibi “;” noktalı virgül ile ayrılırlar. Mesela:

TSinif<T: ISerializable; U: IColoneable> = class

gibi… Bu örneğe göre T parametresi ISerializable arayüzünü, U parametresi de IColoneable arayüzünü desteklemesi şarttır.

Ayrıca, birden fazla sınırlandırıcı, tek bir tip parametresine atanabilir. Bu durumda bunlar, “AND” lojik mantığına göre tip parametresini sınırlandırırlar.

TSinif<T: ISerializable, IColoneable> = class

gibi… Bu örnekte T parametresi hem ISerializable, hem de IColoneable arayüzlerini desteklemek zorundadır. Aynı şekilde prosedür ve fonksiyon parametrelerinde olduğu gibi aynı sınırlandırmaya sahip iki tip parametresini virgül ile ayrırak beraber yazabilirsiniz:

TSinif<T, U: ISerializable> = class

gibi… Bu örneğe sınırlandırıcıya sahip olmayan bir parametre daha ekleseydik noktalı virgül ile ayırmamız gerekecekti:

TSinif<T, U: ISerializable; Z> = class

gibi…

Bunlar grammer ile ilgili kısımlardı. Peki derleyicinin davranışı nasıl olacak? Aşağıdaki örneğe bakalım:

TPrintableCollect<T: IPrintable> = class ...
...
TDeneme = class(IPrintable)
  procedure Print;
end;

THata = class
end;
...
var
  Calisan: TPrintableCollect<TDeneme>;
  Hatali: TPrintableCollect<THata>; //Syntax hatası: THata sınıfı IPrintable arayüzünü desteklemiyor.

Gördüğünüzü gibi THata sınıfı IPrintable arayüzüne yabancı olduğu için tip argümanı olarak atadığımızda syntax hatası alıyoruz.

Bununla beraber aynı mantık ile arayüz yerine bir sınıfı sınırlandırıcı olarak kullanabilirsiniz. Bu durumda generic sınıfımız ancak ve ancak sınırlayıcı olarak verdiğimiz sınıf ve alt sınıflarından tipleri alabilir. Mesela:

TBirSinif = class...
TBirAltSinif = class(TBirSinif)...
TBirKolleksiyon<T: TBirSinif> = class...

Bu örneğimizde T tip parametresine ancak ve ancak TBirSinif ve ondan türeyen sınıflar argüman olarak atanabilir.

Sınırlandırıcılarda Belirsizlik

İki adet sınırlandırıcı, bir tip parametresine atandığını düşünelim. Mesela:

TTest<T: ISerializable, ICloneable> = class
  BirNesne: T;
  procedure Klonla;
end;

procedure TTest<T>.Klonla;
begin
  BirNesne.Clone;
end;

Derleyici “BirNesne” değişkeninin ISerializable ve ICloneable arayüzlerini desteklediğini biliyor. Ayrıca IClonable arayüzünde de Clone isminde bir metod olduğunu da biliyor. Bu yüzden Klonla metodunda Clone metodunu çağırırken herhangi bir çevirim işlemi yapmadık. Çünkü derleyici, Clone metodunun hangi arayüze ait olduğunu biliyor.

Farz edelim ki Clone metodu, hem ISerializable hem de ICloneable arayüzlerinde bulunuyor olsun. Bu durumda Clone metodunu yukarıdaki gibi çağırdığımızda ne olacak? Derleyici bu durumda belirsizilik olduğuna dair bir hata mesajı gösterecektir. Bu belirsizliği ortadan kaldırmak için harici çevirim(explicit casting) yapmalıyız. Yani:

procedure TTest<T>.Klonla;
begin
  ISerializable(BirNesne).Clone;
  ICloneable(BirNesne).Clone;
end;

Bu durumda, ilk Clone çağırımı ISerializable arayüzü üzerinden, ikincisi ise ICloneable arayüzü üzerinden gerçekleşecektir.

Sınırlandırıcı Olarak constructor, class ve record Kullanmak

Eğer sınırlandırıcı olarak record gibi referansız tipler kullanacaksak bu durumda “record” ayrılmış kelimesini kullanıyoruz. Ama dikkat etmemiz gereken konu kullanacağımız tip argümanı nullable yani null değer alabilen bir tipten olmamalı. Mesela string nullable’dır ama Integer değildir.

Aynı şekilde eğer sınırlandırıcımız sadece referanslı tipler olacaksa bu sefer de “class” ayrılmış kelimesini kullanmaktayız. Ayrıca kullanacağımız tip nullable olabilmeli. Yani tip argümanı olarak sınıfların yaninda string gibi nullable tipleri de kullanabiliriz. Bunları şu şekilde örneklendirelim:

TReferansiz<T: record> = class...
TReferansli<T: class> = class...
TBirRecord = record
end;

var
  Hatali1: TReferansiz<string>; //Hatalı, çünkü string nullable,
  Hatali2: TReferansli<Integer>; //Hatalı, Integer referanslı bir tip değil
  Uygun1: TReferansiz<TBirRecord>;
  Uygun2: TReferansiz<Integer>;
  Uygun3: TReferansli<string>; //string nullable bu yüzden uygun.

gibi…

Constructor kelimse ise, sınırlandırıcıda kullanılan sınıfın mutlaka parametresiz bir constructor’a sahip olmasını şart koşmaktadır. Mesela:

TBirSinif = class
  constructor Create;
end;

TBirBaskaSinif = class

end;

TBirKolleksiyon<T: constructor> = class...
...

var
  Uygun: TBirKolleksiyon<TBirSinif>;
  Hatali: TBirKolleksiyon<TBirBaskaSinif>;

Bu örnekte Uygun nesnesinde tip argümanı olarak TBirSinif tipini girdik. Ve derleyici bunu kabul etti. Çünkü TBirSinif parametresiz bir constructor’a sahip ve sınırlandırıcımız için uygun. Fakat Hatali nesnesinde tip argümanımıza girilen TBirBaskaSinif tipi parametresiz bir constructor’a sahip değil. Bu yüzden derleyici burada hata gösterecektir.

Sonuç

Normalde Delphi.NET derleyicisi, generics ve .net 2.0′a tam destek vermekle beraber, bir çok bug da içeriyor. Gerçi bu cümleleri yazdığım sıralarda, RAD Studio 2007 daha 1 haftadır piyasada. Şu an bildiğim kadarı ile Rad Studio 2007′in çıkacak olan update’inde büyük çoğunlukla derleyici ve asp.net’deki düzeltmeler bulunacak. Derleyici düzeltmelerinde de pastanın büyük payını generics ile ilgili hatalar alacak. Bu yüzden generics ile uğraşırken “Internal Error XXXX” gibi hatalar ile karşılaşırsanız kafanızı duvarlara vurmayın. Çünkü internal error’lerin hepsi bug olarak kabul edilir. Böyle bir durumla karşılaştığınızda eğer yoksa QC’ye rapor edebilirsiniz.

Fatih Tolga Ata © 2007

Kaynaklar:

• CodeGear’ın Delphi Parametrize Tipler ile İlgili Taslak Metinleri
• .NET 2.0 SDK Yardım Dosyası
• Microsoft Visual C# 2005 Step by Step, John SHARP, 2005 Edition

]]> http://www.diyezon.com/2007/09/23/enine-boyuna-generics-bolum-2/feed/ 1 http://www.diyezon.com/2007/09/18/enine-boyuna-generics-bolum-1/ http://www.diyezon.com/2007/09/18/enine-boyuna-generics-bolum-1/#comments Tue, 18 Sep 2007 03:58:02 +0000 Fatih Tolga Ata http://www.diyezon.com/?p=54 Bir iki önceki makalemizde, Delphi gramerine katılan generics ve parametrize tipleri yüzeysel olarak tanıtmıştık. Generics, RAD Studio 2007′ nin çıkması ile artık sadece beta tester’larını değil, tüm Delphi programcılarını ilgilendiren bir konu olmuştur. Gerçi şu an için sadece .NET ortamında kullanabildiğimiz bu özellik bir sonraki sürümde Win32 için de kullanılabilir bir gramer olacaktır. Başlangıç için önceki makalemizi okuyabilir ya da direk buradan başlayabilirsiniz. Zira bu bölümde Generics ile ilgili temel bilgiler vereceğiz.

Giriş

Generics’i doğru bir şekilde anlayabilmek için, hangi problemleri çözmek için dizayn edildiğini anlamakta yarar var. Bunun için ilk başta temel bir konudan ve bununla ilgili bir problemden bahsedelim.

.Net ortamı için object tipini herhangi bir değer ya da değişken için referans olarak kullanabilirsiniz. Çünkü her bir referans tipi otomatik olarak System.Object sınıfından türetiilir. Delphi’nin özel tipleri bile .net ortamına geçtiğinde artık birer object olacaktır. Fakat bazı durumlarda explicit casting yapmadan object sınıfına atama yapmak derleyicinin hata üretmesine neden olabilir (Explicit ve Implicit terimlerine yabancı iseniz buradaki makalede ilgili başlığı bulabilirsiniz.). Bunun için AUTOBOX direktifini kullanmamız gerekebilir. Yani aşağıdaki gibi, Delphi’ye ait özel bir tipi, .NET’in object tipine implicit olarak atama yaptığımızda derleyici hata üretecektir.

var
  i: Integer;
  o: &Object;
begin
  o := i;

Derleyicinin hata üretmemesi için ya AUTOBOX kullanacağız ya da explicit casting uygulayacağız:

var
  i: Integer;
  o: &Object;
begin
  o := &Object(i); //Explicit casting
  {$AUTOBOX ON}
  o := i;

Buradan çıkardığımız sonuç, her halükarda eğer .Net ortamından söz ediyorsak, ister Delphi tipi olsun ister olmasın, herşey &Object (System.Object) sınıfından türemiştir. Ve bir şekilde tüm tipler, object nesnesine atanabiliyor.

Biz bu bilgiliyi kullanarak sınıflarımızı ve metodlarımızı bir çok noktada genelleştirebiliriz. Mesela VCL’den hatırlayacağınız TList sınıfına benzer bir liste sınıfı hazırlayabilir ve object‘in yukarıdaki anlattığımız özelliği sayesinde içinde istediğimiz tipte nesneler barındırabiliriz. System.Collections alanında bulunan Queue(kuyruk) sınıfı da bu tarz bir yapıya sahiptir(Kuyruğa ilk giren ilk çıkar.). Mesela aşağıdaki örnekte iki farklı tipi Queue nesnesinin bir elemanı yapıyoruz.

uses
  System.Collections, System.Xml;
  ...

{$AUTOBOX ON}
var
  b: TButton;
  s: XmlDocument;
  q: Queue;
begin
  q := Queue.Create();
  b := TButton.Create(nil);
  x := XmlDocument;
  q.Enqueue(b);
  q.Enqueue(x);

Queue sınıfının Enqueue metodu, kuyruğa yeni bir object eklemeye yarar. Enqueue metodu object tipinde parametre aldığından her çeşit nesne bu metod ile kuyruğumuza eklenebilir. Bu örneğimizde TButton ve XmlDocument tipinde iki farklı nesneyi kuyruğa ekledik. Kuyruktan bir eleman çıkarmak için ise Dequeue metodunu kullanmamız gerekecektir. Dequeue metodu da aynen Enqueue metodu gibi object nesneleri ile çalışır. Yani Dequeue metodunun çıktısı bir object olacaktır. İşte bu noktada, object sınıfının özelliğinden dolayı Queue sınıfı ve bu iki metodu genel çapta kullanılabilir bir yapıdadır.

Yukarıdaki kodlara şunları ekleyip derlemeye çalışalım:

var
  ...
  ...
  cikanB: TButton;
  cikanX: XmlDocument;
begin
  ....
  ....
  cikanB := q.Dequeue; //ilk button girmişti, ilk de o çıkacak.
  cikanX := q.Dequeue;

Bu kodu derlemeye kalkdığınızda “Incompatible types…” hatasını alacaksınız. Halbuki yukarıda AUTOBOX ile implicit çevirimi aktifleştirmiştik. Peki bu hatayı neden aldık?

Birincisi, AUTOBOX sadece object nesnelerine atama yapılacağında işe yarıyor, object nesneleri başka bir nesneye atama yapılacağında değil. Object sınıfndan türemiş olan bir sınıfın nesnesi object‘e atama yapacağınızda, derleyici bunu otomatik çevirebilir. Ama aksi durumda, object nesnesinin hangi sınıftaki bir nesneye dönüşeceğini kestiremez. Bu durumda explicit çevirim yapmak zorundayız. Bunun için sondaki iki satırı şu şekilde değiştirmeliyiz:

  ...
  cikanB := TButton(q.Dequeue);
  cikanX := XmlDocument(q.Dequeue);
  ShowMessage(cikanX.Name); //"#document"

Peki kuyruktan çıkış sırasını yanlışlıkla değiştirseydik ne olurdu? Biliyoruz ki, kuyruk’ta ilk giren ilk çıkar. Yani örneğimize göre ilk olarak button girmişti ve ilk olarak da o çıkacaktır. Bu durumda sıralarını değiştirelim deneyelim:

  ...
  cikanX := XmlDocument(q.Dequeue);
  cikanB := TButton(q.Dequeue);
  ShowMessage(cikanX.Name);

Bu kod derlenir fakat çalışma anında yanlış yaptığımızı gösteren bir hata alırız. Bu durumda object sınıfının bu genelleştirme özelliğini, bunun gibi yerlerde kullanmak, bir çok yanlışı ve dikkatsizliği de beraberinde getiriyor.

Genelleştirilmiş sınıf ve metodlar oluşturmak için kullanılan bu object yaklaşımının diğer bir dezavantajı ise, object sınıfının diğer bir nesneye çevirim yapılması(unbox işlemi ya da unboxing de denilir) yada başka bir sınıfın object sınıfına çevirim yapılması(box ya da boxing yapılması) esnasında gereken ek hafıza ve işlemci zamanıdır. Yani her defasında Enqueue yapıldığında bir nesne object tipine dönüştürülecek ve her Dequeue yapıldığında ise object nesnesinin tipi başka bir nesneye dönüştürülecektir. Bu da ek işlem gücü ve hafızayı gerektirir.

Sınıfları ve metodları genelleştirmede object yaklaşımının belki başka dezavantajlarda sayılabilir ama, bizim işimiz burada generics ve parametrize tipler. Object yaklaşımı kafamızın bir köşesinde yer etmişken, dilerseniz generics yaklaşımına bir göz atalım.

Generics ve Parametrize Tipler(Parameterized Types)

Aslında Delphi programcıları bunu çok uzun süreden beri bekliyorlardı. Belki de .NET 2.0′a böyle bir özellik gelmeseydi, uzun bir süre daha Delphi böyle bir özellikten yoksun kalacaktı. Borland ya da CodeGear’ın .NET ortamına yaptığı yatırımları eleştirenler olmuştur. Fakat bu yatırımlar sayesinde hem Win32 hem de .NET üzerinde Delphi bir çok yeniliğe gitmiştir. Buradaki makaleden bu yeni özellikleri kısaca tanıyabilirsiniz.

Gramere ve kullanışına geçmeden önce bir kaç terim üzerinde duralım. Terimler ilk başta kafa karıştırıcı gibi gelse de bu terimleri kullandıkça alışacağınıza inanıyorum. Bu terimleri önce veriyorum çünkü makale içerisinde bu terimler kullanılacak.

Terminoloji

Parametrize Tip (Parameterized Type:): Tip Paremetresine ihtiyaç duyan bir çeşit tiptir. Generic tip, parametrize tipin daha çok bilinen ismidir. Ama literatürde ikisi de kullanılmaktadır. Aşağıdaki kodda “Liste<eleman>” sınıfı, bir parametrize tiptir.

type
  Liste<eleman> = class
    ...
  end;

Tip Parametresi (Type Parameter): Bir parametrize tip veya metod başlık tanımlamasında, parametrize tipin veya metodun kodlarında kullanılacak olan bir tipi ifade eden bir parametredir. Daha sonra bu parametreye bir tip argümanı bağlanacaktır. Aşağıdaki kodda “eleman” bir tip parametresidir ve sınıfın kodlarında kullanılacak olan bir tipi ifade eder.

type
  Liste<eleman> = class
    ...
  end;

Oluşturulmuş Tip (Instantiated Type, Constructed type): Parametre kümesi tanımlanmış olan bir parametrize tiptir. Liste<Integer> gibi…

Tip Argümanı (Type Argument): “Oluşturulmuş” bir tip yapmak için gereken bir çeşit tiptir. Mesela Liste<Integer> bir oluşturulmuş parametrize tip ise, Integer bunun tip argümanıdır.

Kapalı Oluşturulmuş Tip (Closed Constructed Type): Bir parametrize tipin tüm parametreleri, gerçek tip olan argümanlar ile çözümlenmiş ise bu tipe, Kapalı Oluşturulmuş Tip denir. Liste<Integer> kapalıdır, çünkü Integer tip argümanı gerçek bir tiptir.

Açık Oluşturulmuş Tip (Open Constructed Type): Eğer bir parametrize tipin en az bir parametresi bir tip parametresi ise, bu tip bir açık oluşturulmuş parametrize tiptir. Ayrıca eğer Liste<T> parametrize tipinde T parametresi bir sınıfı içeren parametre ise Liste<T> açık oluşturulmuş bir tiptir. İleride örnekler yaptığımızda bu daha da pekişecektir.

Oluşturma İşlemi (Instantiation): Derleyici, parametrize tiplerde tanımlı metodlar için gerçek işlem kodunu oluşturur ve kapalı tipler için gerçek virtual metod tablosunu oluşturur. Bu işlem ön derleme esnasında gerçekleşir. Bu işlem Win32′de *.dcu ve *.obj dosyalarını çıkarırken gereklidir. Fakat .Net ortamında gerekli değildir. Çünkü .Net oluşturulmuş tipler için gerekli tanımlamalara sahiptir. Bu yüzdendir ki, C++’da template oluşturduğunuzda, derleyici ilk başta template’li tipleri ayrı ayrı oluşturmak için ön derleme işlemine girişir. Anlaşılan o ki, Delphi’nin bir sonraki versiyonunda da Win32′de generics desteği verebilmek için buna benzer bir yönteme gidilecek. Her neyse…

Bunlar dışında bir kaç terim daha var. Fakat daha fazla kafa karıştırmamak için, o terimleri ayrı başlıklar halinde ileride görelim. Dilerseniz önceden object yaklaşımı ile yaptığımız işlemleri şimdi de generics ile yapmaya çalışalım.

Kullanımı

Kuyruk örneğimizi hatırlayacak olursanız, ekstradan tip çevirim işlemleri yapmıştık. Ayrıca tip güvenliğinin gerekli olduğundan ve bir dikkatsizlikte belli sorunların oluşabileceğinden bahsettik. Ayrıca fazladan gerçekleştirilen object’den bir başka tipe ve daha sonra da o tipden tekrar object’e çevirim yapılmasından dolayı(box / unbox), ekstra hafıza ve işlem gücü gerektiğinden bahsetmiştik.

Bütün bunlara gerek duymadan, genelleştirilmiş sınıflar oluşturabilmek için parametrize tipleri ve generic yapısını kullanabiliriz. Generic sınıflar, tip parametresine sahip olduğundan dolayı, sadece object gibi bir tipe bağlı kalmaz. Böylece yukarıda bahsettiğimiz sıkıntıları da bertaraf etmiş oluruz.

.Net 2.0 ile birlikte System.Collections.Generic alan adının altında bir çok yararlı generic sınıf tanımlanmıştır. Aşağıdaki kod parçasında parametrize Queue sınıf ile oluşturulmuş bir Integer kuyruğu ve bir string kuyruğu görmekteyiz.

uses
  System.Collections.Generic;

  ...
  ...

var
  SayiKuyruk: Queue<Integer>;
  YaziKuyruk: Queue<string>;
  Sayi: Integer;
  Yazi: string;
begin
  SayiKuyruk := Queue<Integer>.Create;
  YaziKuyruk := Queue<string>.Create;
  Sayi := 123;
  Yazi := 'Deneme';
  SayiKuyruk.Enqueue(Sayi);
  YaziKuyruk.Enqueue(Yazi);
  ...

Gördüğünüz gibi, ne bir çevirim işlemi var ne de tipler uyuşuyor mu diye bir endişe… “SayiKuyruk” ve “YaziKuyruk” nesnelerinin ikisi de Queue<T> gibi bir parametrize tip’den oluşturulmuş tipten oluşturulmuştur . Terimlerimizde hatırlarsanız “Kapalı oluşturulmuş tip“ten bahsetmiştik. Derleyici bu örneğimizde Queue<T> tipinden iki adet yeni tip oluşturmuştur. Bunlardan birisi Queue<Integer> ve diğeri ise Queue<string> tipidir. Ve ikisi de kapalı oluşturulmuş bir tiptir. Ayrıca iki tip tamamen bir birinden bağımsız iki farklı tiptir!

Bu örnekten ne öğrendik? Özet olarak, bir generic sınıfa atadığımız tip argümanlarına göre(Integer, string, vs..) yeni bağımsız bir tip oluşturuyoruz. Ve bu oluşturulan tip, parametre olarak verdiğimiz argümanlara göre işlem yapıyor.

Önceki Queue sınıfı, sadece object tipinde nesneler ile çalşıyordu. Bu sınıftan sadece bir adet vardı ve oluşturduğumuz nesneler hep aynı sınıftan oluşturuluyordu. Ama generic Queue sınıfında ise iş biraz değişiyor. Artık tanımladığımız farklı tip için ayrı bir sınıf oluşturuluyor. Bu yüzden örneğimizdeki SayiKuyruk ve YaziKuyruk nesnelerinin sınıfları aynı değildir! Derleyici her iki tip argümanı için de ayrı ayrı sınıflar oluşturmuştur. Tip argümanları gerçek tipler olduğu için de oluşturulan bu iki sınıf da kapalı oluşturulmuş tip olmuştur.

Tanımlanması

Generic tiplerin tanımlanması kullanımı kadar kolaydır. Delphi’de sınıflar, interface’ler ve record’lar tip parametreleri ile birlikte tanımlanabilirler. Ayrıca metodlar ve prosedürel tipler de parametrize yapılabilir. Aşağıdaki sınıf tanımlamasına göz önüne alalım:

type
  TBirSinif = class
  public
    procedure BirSeylerYap(Parametre: string); overload;
    procedure BirSeylerYap(Parametre: Integer); overload;
    procedure BirSeylerYap(Parametre: Boolean); overload;
  end;

Sadece bu sınıf ve metodları düşündüğümüzde aynı iş için üç farklı metod tanımlaması yapıyoruz. Ne için? Sadece bir tipin değişmesi yüzünden. Bir de ikinci bir parametre aldığını düşünün. Veya üç, dört… Ne yapacağız? 4′ün 3′lü kombinasyonunu alıp o kadar farklı metod tanımlaması mı yapacağız?

Bunun yerine bu işi derleyiciye bırakıp, biz sadece tipler ile uğraşıyoruz. Yukarıdaki sınıfımızı parametrize olarak yeniden tanımlayalım:

type
  TBirSinif<T, K, L> = class
  private
    FBirOzellik: K;
  protected
    procedure SetBirOzellik(const Value: K);
  public
    procedure BirSeylerYap(Parametre: T);
    property BirOzellik: K read FBirOzellik write SetBirOzellik;
  end;

Gördüğünüz gibi, Integer string gibi değişkenler yerine sınıfa eklediğim tip parametrelerini kullanıyorum. Bu parametrize tipimizde 3 adet tip parametresi mevuct. Gerçi bu örnekte sadece ilk ikisini kullanıyoruz.

Bir genel kültür bilgisi mahiyetinde, ek olarak, bu sınıf derlendikten sonra TBirGenericSinif`3 gibi bir şekle girecektir. Eğer tip parametre sayısı 4 olsaydı, son kısım “`4” olacaktı. Bu yüzden derlenmiş assembly’nizi ya da programınızı reflect ettiğinizde bu tarz şeyler görürseniz şaşırmayın. Her neyse…

Önceden de bahsettiğimiz gibi yukarıdaki TBirSinif sınıfı ile TBirSinif<T, K, L> generic sınıfı birbirinden çok farklı şeylerdir. İsimleri aynı olabilir ama kesinlikle aralarında bir bağlantı yoktur. Aynı şekilde TBirSinif<Integer, string, Boolean> gibi bir kapalı oluşturulmuş sınıf, TBirSinif<string, string, Integer> gibi başka bir kapalı sınıftan çok çok farklıdır ve bağlantıları yoktur. Çünkü derleyici, tip argümanlarına göre tipleri tekrar tekrar tanımlamaktadır.

Generic Metodlar

Sınıflar gibi metodlar ve prosedürel tipler de parametrize olarak tanımlanabilir. Mesela:

type
  TBirProsedur2<T> = procedure(Param1, Param2: T) of object;
  TNormalBirSinif = class
    procedure BirProsedur<X>(Param1, Param2: X);
  end;

procedure TNormalBirSinif.BirProsedur<X>(Param1, Param2: X);
begin

end;

Görüldüğü gibi parametrize olmayan bir tip içinde(TNormalSinif) parametrize bir metod tanımladık. Bunu yaparken aynen sınıflarda olduğu gibi metod isminden sonra tip parametrelerini giriyoruz. Aynı şeyi parametrize olan bir tip içinde de yapabilirdik. Ama burada karar size ait. Eğer generic bir sınıf içinde farklı parametrelerle tanımlamamız gereken metodlar olursa, bu şekilde parametrize edebiliriz. Yani:

type
  TBirSinif<T> = class
    ...
    procedure BirProc<X>(Param1: X; Param2: T);
  end;

Görüldüğü gibi sınıf tanımlamasında X parametresi tanımlı olmadığı halde, metod tanımlamamızda kullanabiliyoruz. Peki bu gibi bir şeyi nasıl kullanacağız?

Farkında iseniz bir kaç paragraf yukarıda verdiğimiz bir örneğin tam bir çözümlemesini yapmadık. Yani:

type
  TBirSinif = class
  public
    procedure BirSeylerYap(Parametre: string); overload;
    procedure BirSeylerYap(Parametre: Integer); overload;
    procedure BirSeylerYap(Parametre: Boolean); overload;
  end;

Bu sınıfta “BirSeylerYap” metodu overload edilmiştir. Bu sınıfı generic yaparken şu şekilde bir tanımlama yapmıştık:

type
  TBirSinif<T> = class
  public
    procedure BirSeylerYap(Parametre: T);
  end;

Burada her bir kapalı tip için sadece bir adet metodumuz olabiliyor. Yani mesela TBirSinif<Integer> gibi kapalı bir sınıf içinde sadece bir adet “BirSeylerYap” metodu vardır ve sadece Integer tipinde bir parametre almaktadır. Halbuki bizim esas yapmak istediğimiz her bir kapalı sınıf içinde overload yaptığımız tiplerin sınırlandırmasını kaldırmak. Sadece bir çeşit metod yerine birden fazla çeşitte parametre alan metodlarımız olması gerekiyor. Bu yüzden metodumuzu genelleştirmek için onu da parametrize ediyoruz:

type
  TBirSinif<T> = class
  public
    procedure BirSeylerYap<X>(Parametre: X);
  end;

gibi… Bu şekilde bir metodun, istediğimiz kadar çeşidini overload yapmadan oluşturabiliriz. Mesela:

var
  BirNesne: TBirSinif<Integer>;
begin
  BirNesne := TBirSinif<Integer>.Create;
  BirNesne.BirSeylerYap<string>('Deneme bir string');
  BirNesne.BirSeylerYap<Integer>(123);
  BirNesne.BirSeylerYap<Boolean>(True);
  BirNesne.BirSeylerYap<TForm>(Form1);
  BirNesne.BirSeylerYap<TButton>(Button1);

gibi…

Gördüğünüz gibi overload ile kısıtlı sayıda yaptığımız metod tanımlamalarını bu şekilde artırabiliriz. Bu da aynen sınıflarda olduğu gibi, metodlarımızı da genelleştirmemize imkan sağlıyor.

Gelecek Bölümde

Gelecek bölümde Sınırlandırıcıları ya da başka yerlede göreceğiniz tabir ile Kısıtlamalar ya da Constraints tabirlerini göreceğiz. Diğer bölüme geçmek için buraya tıklayabilirsiniz.

Her zamanki gibi yorum ve eleştirilerinizi bekliyorum.

Fatih Tolga Ata

Kaynaklar:

• CodeGear’ın Delphi Parametrize Tipler ile İlgili Taslak Metinleri
• .NET 2.0 SDK Yardım Dosyası
• Microsoft Visual C# 2005 Step by Step, John SHARP, 2005 Edition

Bu makalemizde bu yeniliklere değinmeye çalışacağız. Bunlardan bir kısmını önceki makalelerimizde ayrıntılı olarak işlemiştik. Burada sadece bu sitede bahsetmediğimiz kısımlar bahsedilecek ve önceden bahsettiklerimize linkler içerecektir.

Operator Overloading:

Buradaki makalede ayrıntılı olarak işlenmiştir: http://www.diyezon.com/?p=52

Inline Belirleyicisi:

Derleyiciye tavsiye niteliğinde olan bu belirleyici (ya da direktif), fonksiyon ya da prosedürün kod çıktısında, çağrıldığı yere gömülmesini sağlar. Tavsiye niteliğinde diyorum çünkü, eğer prosedür ya da fonksiyon inline yapılmaya müsait değilse derleyici bu direktifi es geçecektir.

Inline yapılmış prosedür ya da fonksiyon, "call", "ret" gibi assembler komutlarına ihtiyacı olmadığı gibi, stack’ın push ve pop ile yedeğinin de alınmasına ihtiyaç yoktur. Çünkü inline yapılan fonksiyon, direk olarak çağrıldığı kısma yerleşecektir. Halbuki normal fonksiyonlarda call komutu ile hafızada başka bir kod kısmına dallanmaktadır. Ve burada stack’ın yedeği alınıp, fonksiyon sonunda yedek tekrar yüklenmektedir. Daha fazla bilgi için (Delphi ve C++ Builder ile Assembler ve Fonksiyon Çağırım Mekanizmaları).

Inline prosedür ve fonksiyonda bu gibi işlemler yapılmadığından kod daha hızlı çalışacaktır. Ama her fonksiyon çağırımında fonksiyon kodları direk olarak çağrıldığı yere yerleşeceğinden, programınızın boyutu biraz büyüyecektir. Tanımlaması normal fonksiyon ve prosedür gibi olup sadece son tarafa inline belirleyicisi eklenir:

procedure MyProc(x:Integer); inline;
begin
    // ...
end;

Strict Private

Sınıf kavramına katılan bu alan tipi, normal private alan gibidir. Tek fark bu alan daha da gizlidir Bu dediğimizin anlaşılabilmesi için private alanın ne olduğu bilinmesi gerek. Tabi ondan önce sınıfların ne olduğunu biliyorsunuzdur umarım(Bileşen Yazım Klavuzunun ilk bölümleri sınıfları anlatmaktadır).

Private sınıflar normalde, aynı unit içindeki başka sınıflar içinden erişilebilir. Strict Private ise gerçekten gizler. Yani aynı unit içinde bile olsa başka bir sınıf strict private alana erişemez.

Strict Protected

Private için geçerli olan durumun aynısı protected için de geçerlidir. Strict Protected ise sadece aynı sınıf ve sınıfın çocukları tarafından görülebilirler. Aynı unit bile olsa başka bir sınıf bu alanı göremez.

Metodlu Record’lar

Artık Recordlar için private, public gibi alanlar tanımlayıp procedure, function, constructor gibi metodlar tanımlayabiliyoruz. Ayrıca property’ler de tanımlanabiliyor. Yani aynı sınıflar gibi…

type
  TMyRecord = record
    type
      TBirTip = Integer; //tip tanımlaması
    var
      BirAlanDegiskeni: TColor;
    class var
      StatikDegisken: Integer;
    procedure BirProsedur();
    constructor Create;
    property Color: TColor read BirAlanDegiskeni write BirAlanDegiskeni;
    class property StatikOzellik: TBirTip read StatikDegisken write StatikDegisken;
  end;

constructor TMyRecord.Create;
begin

end;

procedure TMyRecord.BirProsedur;
begin
  ShowMessage(IntToStr(Color));
end;

Abstract ve Sealed Sınıflar

Önceden abstract sınıf tanımlanamıyordu. Bunun yerine interface’ler kullanılıyordu. Ama bu her zaman işe yaramayabiliyor. Yabancı olanlar için kısaca abstract, kendisinde herhangi bir tanımlama ve kod bulunayan, kod kısmı, sınıflar için çocuk sınıflarda, metodlar için ise mirasçı metodlarda tanımlı olan bir yapıdır.

type
  TAbstractClass = class abstract
    procedure SomeProcedure;
end;

Bu sınıfın kod tanımlaması TAbstractClass sınıfından türeyecek olan sınıflarda yapılacaktır.

Sealed sınıflar ise, kısır sınıflardır. Yani artık sınıf hiyerarşisinde en sonda bulunan ve kendisinden herhangi bir türetme yapılamayacak olan sınıflardır.

type
  TSealedClass = class sealed
    procedure SomeProcedure;
end;

Bu sınıftan başka bir sınıf türetilemez.

Class Helper’lar

Buradaki makalede ayrıntılı olarak işlenmiştir: http://www.diyezon.com/?p=50

Class Statik Tipler, Değişkenler, Özellikler, Sabitler, Metodlar

Bazen olurki nesneyi tanımlamadan, sınıf içinde bulunan bazı değerlere erişilmesini istersiniz. Bu durumda erişilmesini istediğiniz şeyi, statik olarak tanımlamalısınız. Mesela aşağıdaki örneğe bakalım:

type
  TAClass = class
    strict private
      class var
        StatikDegisken: Integer;
    strict protected
      class function GetStatikOzellik: Integer; static;
      class procedure SetStatikOzellik(val: Integer); static;
    public
      class property StatikOzellik: Integer read GetStatikOzellik write SetStatikOzellik;
  end;

TAClass.StatikOzellik := 879;

Burada gördüğünüz gibi TAClass sınıfından bir nesne oluşturmadan içindeki bir özelliğie eriştik. Class Static tekniğini kullanırken dikkat etmeniz gerken bir kaç önemli nokta şudur:

• Statik metod’lar içinde artık Self değişkenini kullanamazsınız. Çünkü sınıfa referans içeren bir nesne yoktur.
• Statik metodlar ve özelliklerde ancak ve ancak statik olan değişken ve metodları kullanabilirsiniz.
• Statik metodları virtual ya da dynamic olarak tanımlayamazsınız.

Bunun dışında bir sınıf içinde statik sabitler ve statik tipler de oluşturulabilir:

type
  TBirClass = class
  private
    type
      TBirStatikRecord = record
        BirAlan: string;
      end;
  public
    class var
      BirStatikRecord: TBirStatikRecord;
    const StatikSabit = 'Burada class kelimesini kullanmanıza gerek yok!!';
  end;

....
ShowMessage(TBirClass.StatikSabit);

gibi…

İç içe Geçmiş Sınıflar – Nested Classes

Artık bir sınıf tanımlamasının içinde başka bir sınıf tanımlanabiliyor:

type
  TDistakiSinif = class
  public
    type
      TIctekiSinif = class
      public
        procedure IctekiMetod;
      end;
      procedure DistakiMetod;
  end;

procedure TDistakiSinif.TIctekiSinif.IctekiMetod;
begin
  ...
end;

Final Metodlar

Sealed sınıflar gibi final metodlar da bir sınıfın çocuk sınıflarında, final olarak tanımlanmış olan virtual metodun miras alınamadığını ifade eder. Mesela:

TSonMetodluSinif = class(TBirAtaSinif)
public
  procedure SonMetod; override; final;
end;

Bu tanımlamadan sonra artık SonMetod isimli metod, "TSonMetodluSinif" isimli sınıfın çocuk sınıfları tarafından override yapılamayacaktır. Final metodların sadece virtual metodlarda işe yaradığına dikkat edin.

For-In Döngüsü

Artık bir dizi veya kolleksiyon içinde for-in döngüsü ile iterasyon yapılabilmekte:

for DiziElemani in BirDizi do
begin
  ....
end;

for BirKarakter in BirString do
begin
  ...
end;

for BirKumeElemani in BirKume do
begin
  ...
end;

for BirKolleksiyonElemani in BirKolleksiyon do
begin
  ...
end;

Sonuç

Yeni gelen özelliklerin unutmamış isem tamamına değinmeye çalıştım. Bunlara ek olarak Highlander çıktığında generic yani parametrize tiplere de ayrı olarak değineceğiz. Generics’in nasıl bir şey olduğunu merak edenler buraya tıklayarak meraklarını giderebilirler.

Bunlarla ilgili uygulama yapıp geliştirmek sizlere kalmış. Buradaki bilgiler önfikir mahiyetindedir. Derleyici bazındaki yenilikler bunlar olmakla birlikte, VCL ve diğer alanlarda da bir çok yeniliğe gidilmiştir. Yeri geldikçe bunlardan da bahsedebiliriz.

Yorumlarınız önemlidir, bekliyorum.