Bu sayfadaki yazılar
Sayfanın metni
Sayfa 74
Programların derlenmiş halleri ise "prg" klasörü içerisinde yer almaktadır.
Bu "forumda sorulan bir soru üzerine hazırlanmış doküman"ın burada sonuna geldik. Başka yazılarla sizlerle buluşmak dileğiyle.
Benimle irtibata geçmek isteyenler için e-mail adresim;
skate <at> glance <dot> ws (mailto:skate@glance.ws)
Emir Akaydın
Skate / Glance
Klavyeyle gezinmek için ← ve → tuşları.
Sayfa 75
Intro ya da demo hazırlarken, özellikle ürünün sonlarına doğru programcının uyguladığı genel yordam, bitirmeye çalıştığı partı izlemek, küpler yanlış dönüyorsa kodu değiştirip derleyip bir daha izlemek, renkler olmadı gibiyse kodu değiştirip derleyip bir daha izlemek, gfx partı olması gerekenden daha erken girdiyse kodu değiştirip bir daha derleyip yine izlemektir… Ta ki ürün mükemmelleşene ya da daha büyük bir ihtimalle compo deadline gelene kadar bu böyle devam eder. Buradaki en sorunlu durum tahmin edeceğiniz gibi eliniz kolunuz bağlı beklediğiniz derleme sürecidir. Dergide bir yerlerde olması gereken seri üretim yazısını okuyup oradaki bir kısım yöntemleri uygulayanlar için, ufak değişiklikler sebebiyle tekrar derleme olayı tarihe karışacaktır. Bu yazı “değiştirme-derleme-izleme” sürecini tercih eden diğer okuyucuların hayatını oldukça kolaylaştırmasını umduğum birkaç programlama yönteminden bahsedecek.
Derleme Profili
Hedefimizi derleme süresini düşürmek olarak belirlediğimize göre önce derleme süresine etki eden olayların analizini yapalım. Bu sayede derleme işini en yavaşlatan işi bulup onu hızlandırmak, mümkünse ortadan kaldırmak istiyoruz.
Analize sondan başlayalım. Linking (birleştirme) işlemi okunup derlenmiş kaynak dosyalarınızdan hazırlanan obje dosyalarının (.obj uzantılı) içindeki kodların tüm uygulamayı oluşturacak şekilde tek dosyada toplanmasıdır. Bu işlem büyük çoğunlukla obje kodun assembly koduna birebir çevrilmesinden ibaret olduğu için tüm derleme olayının belki de en hızlı aşamasıdır. Bu yüzden bunu atlıyoruz.
Bir önceki aşama derleyicinizin okuyup belli iç yapılara çevirdiği kaynak dosyasının koda çevrilmesi işlemidir. Ancak bu da C/C++ gibi kısmen alt düzey diller için büyük çoğunlukla birebir çevirmedir. Bu da gerçekten çok hızlı geçen bir aşamadır.
Bir önceki ve ilk aşama ise kaynak dosyanızın içindeki yazıların ayrıştırılması (parse edilmesi) ve obje koduna çevrimin kolaylaşacağı basit yapılara haline getirilmesidir. Bu aşama if, while vs. ile yazdığınız dil yapılarının çözülmesi, girdiğiniz değişken, fonksiyon isimlerinin kontrol edilmesi gibi gerçek hayatta devlet memuru olarak bile yapmak istemeyeceğiniz bir sürü amele iş barındırır. C/C++ dillerinin esnekliği (serbest sayıda boşluk vs.) de göz önünde bulundurulursa, bu aşamada tüm derleme zamanının büyük kısmının harcandığı anlaşılabilir.
Headers are Evil!
Hemen celallenmeyin, bir okuyun :)
Peki, bu süreyi azaltmak için ne yapacağız? Kodlarımızı daha mı kısa tutalım? Gerek yok. Çok kısa değişken ve fonksiyon isimleri mi kullanalım? Asla! Bunlara kesinlikle ne gerek var ne de bunları yapmanız size hız kazandırır. Zaten biraz incelerseniz, kaynak kodunuzun ne kadar uzun olursa olsun bazılarının hep aynı sürede derlendiğini göreceksiniz. Derlerken alt alta sıralanan dosya isimleri, hepsi birer birer geliyor, her birinde yaklaşık 3 saniyelik bir bekleme…
Bu dosyaların tepesine bakın, ne görüyorsunuz? Tabii ki include satırları. Eklenen header (başlık) dosyalarını inceleyin. Onların eklediklerini inceleyin. Aralarında gl.h, windows.h gibi cicantik dosyalar göreceksiniz. İster inanın ister inanmayın ama derleme sürenizin yarısından fazlası bu gibi dosyaların parse edilmesi ile geçiyor. Hem de bunları kullanan her kaynak dosyası için birer kez! Derleyicinizin headerlarının olduğu dizine gidin ve windows.h’a bakın. Belki tüm projenizden çok daha uzun bir kod! Öyle değilse de düzinelerce başka header ekliyor olmalı.