Merhaba,

Bu sınıfta gerçekten yetenekli şablonlar var ve elbette, artık yavaş bilgisayarlar ve depolama sıkıntıları yok. Şimdi Ali hocam bu ve benzeri nedenlerden dolayı bu başlığı gereksiz görebilir. Çünkü daha önce bu tür optimizasyonların gereksiz olduğunu konuştuk. Ayrıca Phobos kütüphanesinin, bize getirdiği sağlam güvenlik önlemleri sayesinde daha az yan etkisiz programlar üretebiliriz. Tıpkı printf'in hassasiyeti ve writef'in muazzam esnekliği (ama tam güvenliği) gibi...

Neyse, aradaki farkları göstermek için 3 sürümle derlenebilen (-version=... parametresi kullanılmalı) küçük bir deneme yaptım. Çünkü insan ister istemez soruyor aynı işi yapıyorsa, neden? Elbette cevaplarını önceki paragrafta işaret ettim. Gerçi önceden de basit ekrana yazan uygulamalar için çekirdekteki printf'i kullanılmasını önermiş ve benzer bir analiz yapmıştım...:)

/*
   converter.d (26.07.2012)
*/
version(std_yok) {
   import core.stdc.stdio: printf;

   uint pow10 (uint i) {
       uint p = 1;
       foreach(x; 0..i) p *= 10;
       return p;
   }
   int toNum (string args) {
       int n, magicNum = 48;
       foreach(a, arg; args) {
           n += (cast(int) arg - magicNum) * pow10(args.length - a - 1);
       }
       return n;
   }
}
version(stdio_yok) import std.conv, core.stdc.stdio: printf;
version(std) import std.conv, std.stdio;

void main() {
   string sayı = "123";

   version(std_yok) {                    // Linux32'de 249.306 bayt
       int i = sayı.toNum;
       printf("%d x 3 = %d\n", i, i * 3);
   }
   version(stdio_yok) {                  // Linux32'de 373.641 bayt
       int i = to!int(sayı);
       printf("%d x 3 = %d\n", i, i * 3);
   }
   version(std) {                        // Linux32'de 426.686 bayt
       int i = to!int(sayı);
       writef("%d x 3 = %d\n", i, i * 3);
   }
}

Şahsen std.stdio sınıfını çok şişkin buluyorum. Bunu ikiye bölseler ne güzel olurdu. Ayrıca bu sınıfı kullanmayınca ^^ matematiksel işlemi için std.math'ı import etmem gerektiği uyarısını aldım. O yüzden 'pow10()' diye bir işlev yazdım. Hoş bu sayede %100 C uyumlu hale geldi. Çünkü onda da bu işarete hata vermekteydi. İşin ilginci bu basit denemeyi C'de yazsanız 7-8 KB...:)

Başarılar...

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Ama GC diyenleri duyar gibiyim...:)

Belki derleyicide GC'yi iptal eden bir parametre olsa da EXE boyutları bu kadar olmasaydı. Sanki bir D interpreter'i varmış da kodu onun sonuna ekleyip Perl gibi çalışıyor. GtkD ile uygulama geliştirmeye de gıcık oluyorum! Çünkü küçük bir uygulama için o kadar çok harici dosyaya ihtiyacınız var ki aklınız şaşar...:)

Örneğin Zafer, Divid Projesi (https://github.com/zafer06/Divid) ile güzel bir başlangıç yaptı. Bu uygulama henüz çok basit ve an itibariyle derlenmiş boyutu 2,0 MB (2065948 bayt) civarında. Ancak bu tek başına çalışmıyor bir bu kadar daha yer kaplayan boyutta iki tane eklenti kütüphanesine (libgtksourceview-2.0-0.dll, libxml2.dll) ihtiyaç duyuyor. Etti 4 MB. ama yeter mi, yetmez bir de aşağıda 22 adet standart kütüphaneler de gerekli. Toplamda (yukarıdakiler ile beraber) 18 MB.'ye aşkın kullanıcının ihtiyaç duyduğu dosyalar bunlar...

Alıntı:

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (acehreli):

Hocam peki tekrar kodlamalar dönersek; bir sınıf içindeki işlevi o sınıfın tamamını miras almadan başka bir sınıfı kopyalamak (sanırım derleyici dilinde link atmak olsa gerek?) mümkün mü? Çünkü programlarımızda olabildiğince tekrarlardan kaçınmak için miras almayı kullanıyoruz. Ancak sadece bir işlev için koca bir sınıf miras alınıyorsa bu mantıklı mıdır?

Teşekkürler...

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı:

evet bu konuda gerçekten haklısınız

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Bu düşünceler beni UML(Unified Modeling Language)'e yönlendirdi. Bu bir programlama dilinden çok programlama dilleri ile birlikte (elbette nesneye dayalı olanlarla) kullanabileceğimiz bir modelleme dili. Sanırım 9 diagramdan (Object, State, Sequence...) oluşuyormuş başlangıçta yapılan bir planlama/standartan ibaret. Böylece yazılımlar şiştikçe içinden çıkılmaz bir hale dönüşmüyor. Farklı metodolojilere sahip insanların bir araya gelip katkı sağladığı bu dil hakkında şurada bilgiler var: http://www.omg.org/spec/

Ayrıca bakınız: C Language Mapping Specification (http://www.omg.org/cgi-bin/doc?formal/99-07-35.pdf)...

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Karşılaştırma için teşekkürler. :)

Alıntı (Salih Dinçer):

Bunlar hep çok zevkli, ve yeri geldiğinde çok yararlı. Ama programa en ufak bir ağ üzerinde bekleme veya disk üzerinde işlem gibi bir olay girdiği an bu tür eniyileştirmelerin hiç önemi kalmıyor.

Hem bu eniyileştirmeler eklemediğimiz modüller ve yararlanmadığımız işlevler gerçekten de gerekmediği zaman anlamlıdır. Örneğin başka bir amaçla eklediğim bir modül, kendisi std.conv'u eklese bu çabaların anlamı kalmaz.

Ama kodun büyümesinin gerçek zararları da var: CPU'nun ara belleğine sığmamaya yol açabildiği için yavaşlığa neden oluyor.

Alıntı:

Evet, program büyüklüğü konusunda asıl çözüm o. Aynı sorunlar C++'ta da olduğu için o forumlarda da çok konuşulurdu. En uç çözüm, tek standart kütüphane dosyası yerine işlevlerin teker teker içerildikleri küçük .o dosyaları sunmaktır. Ama bu sefer program oluşturulurken onların teker teker eklenmeleri gerekir (şu anda otomatik olarak yalnızca libphobos.a (ve herhalde D runtime ama adını bilmiyorum)).

Alıntı:

O garipmiş. Bir dil işlecinin bir modülü gerektirmesi saçma.

Alıntı:

C, 70'lerde yazılmış olan küçücük bir dil. İçinde çok az yetenek var. O zamanlardaki sistemlerde çalışabilmesi için küçük olması da gerekiyordu. D'de ise çöp toplayıcının görevlerini de halleden kapsamlı bir çalışma ortamı var.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (Salih Dinçer):

Ama gidiyor işte. :) Bu konular gerçekten sorun oluştursalar bu durumda olunmazdı. Doğal bir gelişim. Belki de sıkıntının etkisi gittikçe artacak ve çözümler uygulanacak.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (Salih Dinçer):

Hayır.

Alıntı:

Bunu çok yaygın olarak duyuyoruz ama bir çok nedenden dolayı doğru değil.

Alıntı:

Mantıklı değil ve zaten öyle yapılmaz.

Bir işlev bir sınıfın içindeyse o sınıfın üyelerine çok yakından bağlı demektir. Eğer sınıfın üyelerine bağlı değilse neden sınıfın içinde tanımlanmıştır? Buna bakarak bile işlevlerin öncelikle serbest işlevler olmaları gerektiği ortaya çıkıyor.

Ek olarak, kod tekrarını azaltmak için gerçekten başka bir tür kullanılacaksa miras alma değil, içerme kullanılır. Bunun çok bilinen örneğin araba ve motor ilişkisidir. Araba motor türünü kullanmak için ondan türetmez, onu içerir.

Benim ilkelerim şunlar:

• Öncelikle serbest işlevler düşünüyorum. Yapılar ve sınıflar ancak o işlevlerin işlemeleri için gereken belirli süre yaşatılmaları gereken veriler (durum - state) içindir.

• Kalıtım hemen her zaman için bir arayüzü gerçekleştirmek için uygulanır.

• Gerçekleme türetmesi (implementation inheritance) gerektiği zaman bu gerçekleştirme kalıtımda araya sıkıştırılabilir ama o katman zaten yalnızca kendi işiyle ilgili üyeleri içerdiği için o üyelere de ihtiyacımız vardır.

'

Hayvan
|
UçanHayvan <- Belki yalnızca kanat içerir (?)
/
Kuş Yarasa'

İçimden bir ses bu konuda da sana aslında katılacağımı ve belki de seni yanlış anladığımı söylüyor. :)

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]