[Makale] C’nin Standart Dosya Fonksiyonlarının Uyguladığı Tamponlama Mekanizması
Standart C fonksiyonlarını kullanmadan bir dosyanın her byte’ı üzerinde sırasıyla işlem yapmak isteyelim. Herhalde ilk akla gelecek yöntem doğrudan işletim sisteminin sistem fonksiyonlarını çağırmak olacaktır. Örneğin UNIX/Linux sistemlerinde dosyayı read fonksiyonuyla (Windows sistemlerinde ReadFile fonksiyonuyla) byte byte aşağıdaki gibi okuyabiliriz:
int fd;
ssize_t result;
unsigned char ch;
if ((fd = open("test", O_RDONLY)) < 0) {
perror("open");
exit(EXIT_FAILURE);
}
while ((result = read(fd, &ch, 1)) > 0) {
/* Okunan byte işleniyor */
}
if (result < 0) {
perror("read");
exit(EXIT_FAILURE);
}
close(fd);
[Makale] Programların Komut Satırı Argümanları
İşletim sistemi tarafından prosese geçirilen komut satırı argümanları program içerisinden çeşitli biçimlerde elde edilebilmektedir. En yaygın yöntem komut satırı argümanlarının programın başlangıç fonksiyonunun parametrelerinden elde edilmesidir. Örneğin, C ve C++’ta komut satırı argümanları main fonksiyonuna parametre olarak geçirilirler. Bu dillerin standartlarına göre programın başlangıç noktasını (entry point) belirten main fonksiyonunun parametrik yapısı ve geri dönüş değeri aşağıdaki iki durumdan biri biçiminde olmalıdır:
int main(void) { /* ... */ }
int main(int argc, char *argv[]) { /* ... */ }
[Makale] UNIX/Linux ve Windows Sistemlerinde Stdin, Stdout ve Stderr Dosyaları
Yalnızca UNIX/Linux sistemlerinde değil modern işletim sistemlerinin çoğunda aygıtlar birer dosyaymış gibi ele alınmaktadır. Örneğin klavye ve ekran -aslında birer dosya olmadığı halde- işletim sistemi tarafından sanki birer dosyaymış gibi işleme sokulurlar. Aygıtlara ilişkin bu tür dosyalar için de birer dosya betimleyicisi ve dosya nesnesi vardır. Bu betimleyicilerle işlem yapıldığında işletim sisteminin dosya alt sistemi aslında bu dosyaların birer aygıta ilişkin olduğunu anlar ve okuma/yazma amacıyla o aygıtlara yönelir. UNIX türevi sistemlerdeki çokbiçimliliği (polymophism) andıran bu tasarıma Sanal Dosya Sistemi (Virtual File System) denilmektedir.
[Blog] C#'taki Yapı ve Sınıf Nesneleri Nerede Yaratılıyor?
Pek çok C# programcısının sınıf ve yapı kavramlarıyla stack ve heap kavramlarını yanlış bir biçimde ilişkilendirdiğini görüyorum. Örneğin, “yapı nesneleri stack’te sınıf nesneleri heap’te tutulur” biçiminde yanlış anlaşılmaya yol açacak bilgiler veren yerli ve yabancı çok sayıda yazı ve makaleyle karşılaştım. Konuya biraz açıklık getirmek istiyorum.
[Makale] UNIX/Linux Sistemlerinde Dosya Betimleyicilerinin Anlamı
UNIX/Linux sistemlerinde her prosesin proses tablosu yoluyla erişilen bir dosya betimleyici tablosu (file descriptor table) vardır. Dosya betimleyici tablosu bir gösterici dizisi biçimindedir. Betimleyci tablo içersindeki her gösterici açılmış bir dosyanın bilgilerinin tutulduğu ve ismine dosya nesnesi (file object) denilen bir veri yapısını gösterir. open fonksiyonundan elde edilen dosya betimleyicisi (file descriptor) prosesin dosya betimleyici tablosunda bir indeks belirtmektedir.
[Makale] Proseslerin Çevre Değişkenleri
Modern işletim sistemlerinde her prosesin bir çevre değişken bloğu vardır. Prosesin çevre değişken bloğu çevre değişkenlerinden ve onların değerlerinden oluşmaktadır. Örneğin, MESAJ bir çevre değişkeninin ismi olabilir, “Merhaba Dunya” ise onun değeri olabilir. Çevre değişkenleri pek çok işletim sisteminde proses yaratılırken belirlenebilmekte ya da üst prosesten (parent process) aktarılabilmektedir. Çevre değişkenlerinin üst prosesten aktarılması en çok karşılaşılan tipik durumdur.
Yanlış İsimlendirmeler
Yıllar önceydi. Bir arkadaşımın kodunu inceliyordum. Kodunda max ismini verdiği bir değişken vardı. Ben de doğal olarak bu değişkenin en büyük değeri tuttuğunu sanarak kodu anlamlandırmaya çalıştım. Ancak birşeyler tam yerine oturmuyordu bir türlü. Meğerse arkadaşım başlangıçta en büyük değeri bulup kullanırken sonra en küçük değerin bulunup kullanılması gerektiğini düşünerek algoritmasını değiştirmiş. Fakat değişkenin ismini değiştirmemiş. Düşünebiliyor musunuz, bir değişken var, ismi max fakat bu aslında en küçük değeri tutuyor :-).
Brian Kernighan “The Practice Of Programming” isimli kitabında değişken isimlerinin kısa (concise), akılda kalıcı (memorable), bilgi verici (informative) ve telaffuz edilebilir (pronounceable) olması gerektiğini söyler. Fakat belli ki yerli ve yabancı programcıların çoğu bu tavsiyeye yeterince kulak asmıyorlar. Halbuki değişkenlerin kullanım amacına uygun bir biçimde isimlendirilmesi önemli. Çünkü bir değişkene uygunsuz bir isim verildiğinde o değişkenin kullanıldığı kod parçası da tamamen yanlış anlaşılabiliyor.
Geçen gün C# dersinde dosya işlemleri konusunda Stream sınıfının Read ve Write metotlarını anlatırken aynı zamanda MSDN’den metotların parametrik yapılarını öğrencilere gösteriyordum. Fakat metotların ikinci parametrelerini anlatırken zorluk çektiğimi farkettim:
public abstract int Read(byte[] buffer, int offset, int count)
public abstract void Write(byte[] buffer, int offset, int count)
Read metodu üçüncü parametresiyle belirtilen miktarda byte değeri birinci parametresiyle belirtilen diziye aktarır. Write metodu da bunun tersini yapar. Peki buradaki offset parametresinin anlamı nedir? Bu parametre aktarımın dizinin kaçıncı indeksinden itibaren yapılacağını belirtiyor. Fakat parametre değişkeni için offset ismi yerine index ismi daha açıklayıcı olmaz mıydı? Her ne kadar offset sözcüğü göreli uzaklık anlamında diziler için de kullanılıyor olsa da bu bağlamda dosya offset’i ile karışması mümkün. Bu parametre değişkenine offset yerine index ismi verilseydi yanlış çağrışımlar engellenebilirdi. Sanırım Microsoft programcıları dizinin bir byte dizisi olmasından dolayı offset sözcüğünü tercih etmiş. Yoksa kütüphanede benzer metotlarda diziler için hep index isminin tercih edildiğini görüyoruz.
Yanlış verilmiş isimlerle her yerde karşılaşmak olası. Fakat Microsoft sistemlerinde çalışıyorsanız sanki daha bir olası :-). Bu sistemlerde o kadar çok yanlış verilmiş isimlerle karşılaştım ki... Örneğin, GetDlgItem isimli bir API fonksiyonu vardır. İsmine bakarsanız bunun diyalog pencerelerine ilişkin bir fonksiyon olduğunu sanırsınız. Fakat aslında bu fonksiyon üst pencerenin handle değerini ve alt pencerenin id değerini alarak alt pencerenin handle değerini verir. Yani aslında çok genel bir fonksiyondur. Buradaki Dlg de Item da yanlış çağrışımlar yapıyor. Fonksiyonun GetChildWnd gibi bir isme sahip olması daha uygun olmaz mıydı? Peki, IsBackground gibi bir property ismi sizde ne çağrışım uyandırıyor? İsim soru eki içerdiğine göre bunun read only bir property olması gerektiğini düşünürsünüz değil mi? Yok işte, .NET’te Thread sınıfının bu property’si thread’i arka plan thread yapmak için kullanılabilen read/write bir property’dir:
thread.IsBackGround = true;
ExecuteNonQuery isimli veritabanı metodunun ne yaptığını sanırsınız? İsmine bakılırsa sorgulamaya yol açmayan işlemleri yapıyor olmalı. Metodu yazanın sorgulama (query) kavramı konusunda kafası biraz karışmış galiba. Aslında veritabanı kayıtları üzerinde yapılan her türlü işleme sorgulama deniyor. Bir SQL komutunun sorgulama olması için bize kayıt döndürmesi gerekmiyor. Burada ismi veren kişi muhtemelen işlemin sorgulama olması için kayıt geri döndürmesi gerektiğini sanmış...
Yanlış isimlendirmelerle yalnızca Microsoft dünyasında karşılaşmış değilim. Aslında kafamda burada yazdıklarımın dışında daha pek çok yanlış isimlendirme örnekleri var. Siz de karşılaşmış olduğunuz yanlış isimlendirme örneklerini bana e-posta yoluyla bildirirseniz sevinirim. Bunların geniş bir listesini çıkartmak istiyorum...
Blog Kaydını PDF Olarak İndir
