Jump to page: 1 2
Thread overview
kutuphane dosyası oluşturmak ve programa eklemek
May 26, 2020
cos00kun
May 26, 2020
cos00kun
May 27, 2020
cos00kun
May 28, 2020
cos00kun
May 29, 2020
fugur
May 29, 2020
cos00kun
May 29, 2020
cos00kun
May 26, 2020

Kütüphaneler ve derleme seçenekleri üzerinde basit denemeler yapıyorum.
D_program klasörümün içinde '"main.d"' dosyası, '"kutuphane"' klasörü var ve kutuphane klasörünün içinde de '"foo.d"' dosyam var. dosyalarım şöyle;

****main.d ****

module main;
import std.stdio;
import foo;

void main() {
   int sayi;
   writeln("Bir Sayı gir..= ");
   readf(" %s", &sayi);
   writeln();
   writeln("İki Katı..= ", ikiKat(sayi));
   writeln("Karesi..= ", kareKok(sayi));
}

foo.d

module foo;

int ikiKat(int i) {
 return i * 2;
}

int kareKok(int i) {
 return i*i;
}

elbette '"D_Program"' klaörümün içinden '"dmd -m64 main.d kutuphane/foo.d"' şeklinde derleyince sorun yok ancak benim amacım bu değil! ben '"kutuphane"' klasörümde bulunan '"foo.d"' yi bir kütüphane dosyası haline getirmek ve ardından main.d dosyasındanda bu kütüphane dosyamı kullanmak istiyorum..

'"kutuphane"' klasörüne terminal açarak ;

"dmd -lib -m64 foo.d"

bar.a adında bir kütüphane dosyası oluşturdum.

Şimdi sorularım şunlar;

  1. şimdi ben main'den '"foo.d"' yerine bu yeni oluşan '"foo.a"' kütüphanesini nasıl kullanacağım yine import ederek mi ? çünkü denediğimde sonuç vermedi '"dmd -m64 main.d -Lfoo" "dmd -m64 main.d -Lfoo.a" ' falan denedim ama olmadı.

  2. nedense '"dmd -share -m64 foo.d"' komutunu kullanarak dinamik kütüphane yaratamadım acep ne ola ki ?

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

May 26, 2020

Hay kafam.. Modüller bölümünde yine en alt bölümleri görmemişim orada dediğiniz gibi zaten yazmışsınız herşeyi! teşekkürler şimdi her şey yolunda.

Alıntı (acehreli):

>

İkinci soruda umarım '-share' değil de '-shared' yazmışsındır. :)

Evet aynen öyle yapmadım! :-D :-D şimdi düzeldi :blush:

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

May 26, 2020

Aşağıda söylediklerime rağmen D dünyasında kütüphane kullanımı yaygın değil.

Ek olarak, import etmek yalnızca derleme aşamasını geçmeye yarar. foo.d'nin (veya kütüphanesinin) derleme satırında ek olarak bildirilmesinin nedeni, bağlayıcının derlenmiş olan işlev tanımlarını bulup programı oluşturmasıdır.

Daha da ek olarak, dmd'nin görece yeni bir seçeneği var: Komut satırına '-i' ekleyince "dmd'ciğim, beni komut satırında uğraştırma lütfen, hangi modüller gerekiyorsa sen onları bağlayıcıya geçirirsin" denmiş oluyor.

Kütüphane konusunda şurası yararlı olabilir:

http://ddili.org/ders/d/moduller.html#ix_moduller.k%C3%BCt%C3%BCphane

Eğer foo.d kutuphane klasörü içindeyse, foo.d'nin başına modül adı olarak 'module kutuphane.foo;' koymalısın. (Bazı durumlarda yalnızca foo da işe yarıyor ama doğrusu kutuphane.foo.)

Kütüphane dosyasının adının libfoo.a olduğunu varsayarsak, onu bağlayıcıya bildirmenin bir çok yolu var:

  • Derleme satırına doğrudan libfoo.a yazmak.

  • Derleme satırına '-L-lfoo' yazmak. Bu durumda, -L, "bundan sonra yazacağım şey bağlayıcıya gitsin" anlamına geliyor. Bağlayıcıya '-lfoo' verildiğinde "foo kütüphanesini kullanmak istiyorum" denmiş oluyor. Bağlayıcı foo kütüphanesinin adının örneğin libfoo.a veya libfoo.so olduğunu bildiğinden kütüphane klasörlerinde o dosyaları otomatik olarak arar. Eğer kütüphanen burada olduğu gibi sistem klasörlerinde değilse, bağlayıcıya '-L' seçeneği ile başka hangi klasörlerde aramasını istediğini söylersin. Ancak, şimdi bağlayıcının '-L' seçeneğinden bahsediyoruz, dmd'ninkinden değil. O yüzden şöyle yazılır: '-L-Lkutuphane_klasorum -L-lfoo'.

İkinci soruda umarım '-share' değil de '-shared' yazmışsındır. :)

Ali

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

May 27, 2020

Ali hocam yukarıdaki konuya ek şunu sormak istiyorum; dediklerinizi yapınca sorun yok gibi görünüyor ancak bu durumda elimizde foo.d olmayacağına göre (foo.a oluştuğu için farzedelim foo.d dosyasını artık sildim ve bu foo.a kütüphanesini main.d nin yanına koydum) main.d dosyasında bulunan

module main;
import std.stdio;
import foo; // Burası!!

'import foo' burda bulunmaya devam etmeli mi ve aynı söz dizimiyle mi bulunmalıdır ? eğer ben bu satıra dokunmazsam '"dmd -m64 main.d foo.a"' yi çalıştırdığım vakit bana haklı olarak

'main.d(4): Error: module foo is in file 'foo.d' which cannot be read
import path[0] = /usr/include/dmd/phobos
import path[1] = /usr/include/dmd/druntime/import'

hatasını veriyor. Eğer 'import foo' satırını silerek '"dmd -m64 main.d foo.a"' çalıştırırsam bu sefer de yine haklı olarak;

'main.d(11): Error: undefined identifier ikiKat
main.d(12): Error: undefined identifier kareKok'

hatasını veriyor. Nasrettin hocaya hak verdim herkese haklısın demekte haklıymış :-p
burada nerde hata yapıyorum ? İnşallah saçma sapan bir hata yapıyor değilimde hakettiğim fırçayı yemem :-D

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

May 28, 2020

Ali Hocam sanırım konu yavaş yavaş kafama oturmaya başladı. Benim bir hatam D dilini biraz da C veya C++ gibi düşünmem!. Kaldı ki genel olarak C/C++ gibi diller aslında bildirimlerini *.h uzantılı dosyalarda tanımlayarak Kütüphane oluşturabiliyor ve bunu kullanıyorken, D dilinde yukarıda belirttiğiniz sebeplerden ötürü zaten ihtiyaç duyulmuyor. Elbette bu mümkün ama anlamı yok. Ama yine de benim oluşturduğum kütüphane dosyası D dilinde yazılmışken en azından derleyicinin ve belki de bağlayıcının D dili yüzü suyu hürmetine bunu anlamasını ve otomatikman .a ve.sa kütüphanelerini herhangi bir .di ve .d dosyasına gerek olmadan eklemesini beklerdim. Sonuçta ben son kullanıcıyım bu beklentiye kimse kızamaz :-p
(Elbette ben derleyiciyi ve bağlayıcıyı D dilinin parçası olarak görüyorum ve ona göre yorum yapıyorum.. Konuyla ilgili bilgim yeterli olmayabilir.)

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

May 28, 2020

Sembolleri kullanabilmek için iki farklı bilgiye ihtiyaç var:

  • Bildirim (declaration): Bu, kodun derlenebilmesi için gerekli. Örneğin, 'int foo(int);' diye bildirilmişse, derleyici foo'nun int alan ve int döndüren bir işlev olduğunu bilir ve foo'nun kodda doğru olarak kullanılıp kullanılmadığını denetler.

  • Tanım (definition): Bu, kodun kendisidir. 'int i;' gibi basit de olabilir, örneğin bir işlevin içeriği gibi karmaşık da olabilir.

Tanım derlenir ve bağlayıcı tarafından bağlanır.

C ve C++'ta modül olmadığından, bir kütüphanenin olanaklarının bildirimleri .h dosyasına, tanımları da örneğin .c dosyasına yazılır.

D gibi modül kullanan dillerde bu iki kavram normalde aynı dosyadadır. Buna rağmen, modül dosyasının bu iki sorumluluğu değişmez: Derlenmiş olan tanımlar kütüphane içine gömülü olsa bile, modül dosyası bildirimler için yine de gereklidir.

Aşağıdaki nedenlerden ötürü D'de bildirim ve tanımı ayrı yerlerde yapmıyoruz:

  • Kod zaten hızlı derleniyor

  • Çoğu durumda kütüphaneyi verdiğimiz kimselerden kodu gizlemeye gerek duymuyoruz. (Özellikle açık kodda.)

  • C++'ta da olduğu gibi, şablonlarda bildirimi tanımdan ayırmak olanaksız.

  • Dönüş türü 'auto' olan işlevlerde bildirimi tanımdan ayırmak olanaksız çünkü dönüş türü derleyici tarafından işlevin içeriğinden belirlenir.

Her ne kadar birbirinden ayırmasak da D'de de bildirim dosyası oluşturmak mümkün:
'dmd -H foo.d'
İsmi .di ile biten bir dosya oluşturulur. İçine baktığınızda bazı tanımların bulunmadığını ama örneğin şablon tanımlarının yine de içerildiğini göreceksiniz.

İşte, kod kütüphane olarak sunulduğunda yanında ilgili .di dosyaları da verilir ve böylece kullanıcılar 'import foo;' derler ve o .di eklenir.

Ali

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

May 29, 2020

Alıntı (acehreli):

>

Alıntı (cos00kun):

>

derleyicinin ve belki de bağlayıcının D dili yüzü suyu hürmetine bunu anlamasını ve otomatikman .a ve.sa kütüphanelerini herhangi bir .di ve .d dosyasına gerek olmadan eklemesini beklerdim.

Derlenmiş olan kodun kaynak kodla ilgisi yoktur. Oysa, derleyicinin örneğin foo.bar() dediğimizde kaynak kodu görmesi ve foo'nun bir değişken olduğunu ve bar()'ın belki de onun bir üye işlevi olduğunu bilmesi gerekir. Bunun için kaynak kod gerekiyor.

Alıntı:

>

Sonuçta ben son kullanıcıyım bu beklentiye kimse kızamaz :-p

Son derece makul bir istek ama bazı teknolojiler önceden kurulmuş düzene uymak zorunda kalabiliyorlar.

Alıntı:

>

(Elbette ben derleyiciyi ve bağlayıcıyı D dilinin parçası olarak görüyorum

Derleyici öyle ama bağlayıcı (ve onun kuzeni 'loader') işletim sisteminin parçası olarak görülmelidir. C, C++, D, vs. gibi dillerin kaynak kodları aynı kütüphaneye girebilirler ve o kütüphaneyi kullanan bambaşka dillerden (örneğin Python) çağrılabilirler. Bunun olabilmesi, bağlayıcının dilden bağımsız olması nedeniyledir.

C++ dünyasında da keşke bağlayıcı C++ dilini anlasa, ne güzel şeyler olabilirdi diye hayıflanılır ama olamaz. :)

Ali

/*--Konu dışı--

Bu gibi problemlere çözüm MS'in COM mimarisi ve CLR. CLR kodu bir çeşit makine kodu fakat yerel makinenin kodu değil. COM bazı durumlarda sıkıntılı bir mimari olmasına rağmen, hey senelerdir bununla yaşıyoruz çoğumuz.

https://en.wikipedia.org/wiki/Component_Object_Model

Net bilgim olmamasıyla birlikte COM'un JAVA'daki karşılığı JavaBeans herhalde.
--Konu dışı--*/

Belki kütüphane derlerken önişlemci gibi bir yapının çözümleyip arayüzü algılayabileceği bir üstveri (metadata) object koduna eklenebilir yorum olarak (hata ayıklama bilgisi gibi). Bu bilgiyi de proje yönetim uygulaması, proje oluşturma aşamasında kullanır. Sistem dilleri kullanıcıları tarafından rağbet görmemiş olacak ki yapılmamış.

PHP tarafında composer var, Visual Studio'da nuget var, Python'da pip var, Java'da maven var.

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

May 29, 2020

Alıntı (acehreli):

>

Alıntı (cos00kun):

>

derleyicinin ve belki de bağlayıcının D dili yüzü suyu hürmetine bunu anlamasını ve otomatikman .a ve.sa kütüphanelerini herhangi bir .di ve .d dosyasına gerek olmadan eklemesini beklerdim.

Derlenmiş olan kodun kaynak kodla ilgisi yoktur. Oysa, derleyicinin örneğin foo.bar() dediğimizde kaynak kodu görmesi ve foo'nun bir değişken olduğunu ve bar()'ın belki de onun bir üye işlevi olduğunu bilmesi gerekir. Bunun için kaynak kod gerekiyor.

Peki o halde nasıl oluyor da atıyorum gtkd kütüphanesi gibi kütüphaneleri kurduğumuzda ve programımıza dahil ettiğimizde bunlar direk olarak çalışıyorlar? Acaba bunların klasörlerinde .d dosyaları da mı vardı yoksa :scared: bilemedim :huh: Eve gidince bir bakayım bakalım bu konuya tekrardan

Bir diğer konuda o halde madem .d dosyalarını yada .di dosyalarına da ihtiyaç duyacaksak benim için bir kütüphane dosyası yapmanın bir anlamı yok. Kodlarınızın değiştirilmemesi dışında en azından benim kıt bilgilerime göre bana büyük bir faydası yok gibi görünüyor gider d modüllerini kullanırım olur biter. (Şimdilik)

Bu hafta sonu bu işe biraz daha kafa yorayım.. D öğrenmeye devam.. Sınıflara tekrardan başladım bakalım..

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

May 29, 2020

Tamamdır.. ufak tefek konucuklar dışında sanırım kafama oturttum.. Bu D dilini iyice öğrendikten sonra ortadan kalkacak diye zaman zaman düşünmüyo değil değilim :-) Ayrıca Foruma bakınca da sanki ıssız bir adaya düşmüş iki kişiden biri gibi hissediyorum kendimi :-D :-D
Ama garip bir şekilde burayı çok seviyorum hiç bir zamanda kopacağımı sanmıyorum. Elbette sizin etkiniz çok büyük Ali bey ;-) Kalın sağlıcakla

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

May 29, 2020

Alıntı (cos00kun):

>

derleyicinin ve belki de bağlayıcının D dili yüzü suyu hürmetine bunu anlamasını ve otomatikman .a ve.sa kütüphanelerini herhangi bir .di ve .d dosyasına gerek olmadan eklemesini beklerdim.

Derlenmiş olan kodun kaynak kodla ilgisi yoktur. Oysa, derleyicinin örneğin foo.bar() dediğimizde kaynak kodu görmesi ve foo'nun bir değişken olduğunu ve bar()'ın belki de onun bir üye işlevi olduğunu bilmesi gerekir. Bunun için kaynak kod gerekiyor.

Alıntı:

>

Sonuçta ben son kullanıcıyım bu beklentiye kimse kızamaz :-p

Son derece makul bir istek ama bazı teknolojiler önceden kurulmuş düzene uymak zorunda kalabiliyorlar.

Alıntı:

>

(Elbette ben derleyiciyi ve bağlayıcıyı D dilinin parçası olarak görüyorum

Derleyici öyle ama bağlayıcı (ve onun kuzeni 'loader') işletim sisteminin parçası olarak görülmelidir. C, C++, D, vs. gibi dillerin kaynak kodları aynı kütüphaneye girebilirler ve o kütüphaneyi kullanan bambaşka dillerden (örneğin Python) çağrılabilirler. Bunun olabilmesi, bağlayıcının dilden bağımsız olması nedeniyledir.

C++ dünyasında da keşke bağlayıcı C++ dilini anlasa, ne güzel şeyler olabilirdi diye hayıflanılır ama olamaz. :)

Ali

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

« First   ‹ Prev
1 2