Program Karışıyor.Header ve Source File Dosyaları Olarak Bölme Mantığı Nedir ?

[Kazım]

Arkadaşlar programı tek mainfile içerisine yazmaya başladım ancak yazdığım fonksiyonlar - tanımlalar dosyayı çok büyüttü ve karışmaya başladı.Bende yapısal parçalarına bölmek istiyorum.Örneğin LCD SPI ANALOG vb. kısımlarına header ve source file dosyalarını oluşturup ana mainfile dosyasını toparlamak istiyorum.Bunun mantığı nedir? Örnek soru; Ana dosyada neden bazen Header baen de Source file include edilir ? Hangi kısımlar header dosyasına hangi kısımlar source dosyasına yazılır ? Püf noktaları nelerdir ? Dikkat edilmesi gereken noktalar nelerdir ? gibi sorularım var. Usta ve deneyimli arkadaşların yanıtlarını bekliyorum.

[yamak]

Fonksiyonların prototiplerini header file ın içine yazarsın.Source file'da da implement dersin.Yani asıl kodlar source file dadı bunların tanımlamaları da header file'da.Sonra da header file ı mainfile içinde çağırırak source file içindeki fonksiyonları kullanabilirsin.

[Klein]

https://www.picproje.org/index.php/topic,35794.870.html
59. sayfada ön bilgi mevcut.

[serhat1990]

@ yamak Hoca'nın dediği gibi . Programın daha yapısal daha anlaşılır olması için programı böyle parçalara bölmek iyi olacaktır . En basitinden şöyle birşey yap giriş çıkış ayarların için bir header ve source dosyası oluştur . Bu dosyayı programına include et. Olayın basit ve güzel olduğunu göreceksin ...

Örneğin header içinde şöyle bir tanımlama olsun .

/*
Port ayar header dosyası   port.h
*/

void port_ayar(void);   // portları ayarlayan fonksiyondur..

Source dosyan ...

/*   Kaynak c dosyası port.c 

#include <pic.h>
#include <port.h>

void port_ayar(void)
{
    TRISB=0xFF;
    TRISD=0x00;

}

*/

ana program dosyası

#include <pic.h>
#include <port.h>

__CONFIG ( 0x1234 );

void main()

{
    port_ayar();
   
     while(1)

      {

       PORTD=0xFF;
   
       }

}

bu şekilde yapabilirsin .

[Erdem]

Aslında teknik olarak bir fark yok. Eğer isterseniz derleyici .c uzantılı dosyayı eklemenize ya da .h uzantılı dosyayı derlemenize izin verecektir.

Ama iyi bir programlama alışkanlığı olarak uygulamada bazı farklılıklar var:

* İşlev bildirimleri ('declerations') .h uzantılı dosyaların içine konur.
* İşlev tanımlamaları ('definitions') , yani gerçekleştirme kısmı ise .c uzantılı dosyalara konur.

Örneğin bir işlevin tanımlama, gerçekleme kısmını .h uzantılı dosyaya koyarsam ne olur. O zaman birden fazla .o uzantılı dosya oluşur.

Bu yüzden işlevlerin tanımlama yani gerçekleştirme kısımları .h uzantılı dosyalara konulmaz.

Bir .c dosyasında tanımlı olan bir işlevim olsun.  Eğer bu işlevi diğer .c kaynak dosyalarından kullanmak istiyorsam bu işlevin bildirimi diğer kaynak  dosyalarından erişilebilir olmalıdır. İşlev bildirimlerini ayrı bir başlık dosyasına .h toplamamızın nedeni budur. Böylece #include ekleyip diğer kaynak dosyalarından kullanabiliriz.

Yukarıda Serhat'ın verdiği örnekte olduğu gibi.

Eğer bir .c kaynak dosyasındaki işlevleri diğer kaynak dosyalarından kullanmak istemiyorsak başlık dosyasında tanımlamaya gerek yok.

[Kazım]

Bir .c dosyasında tanımlı olan bir işlevim olsun.  Eğer bu işlevi diğer .c kaynak dosyalarından kullanmak istiyorsam bu işlevin bildirimi diğer kaynak  dosyalarından erişilebilir olmalıdır. İşlev bildirimlerini ayrı bir başlık dosyasına .h toplamamızın nedeni budur. Böylece #include ekleyip diğer kaynak dosyalarından kullanabiliriz

Evet mesajlar ayrı ayrı bütün sorularıma cevap oldu. Yalnız ; Örneğin  işlemlerin tanımlı olduğu bir .c dosyam var ve .h dosyası yok.Diğer kaynak kodda bu dosyayı #include etsem ne olur.Klein 'inverdiği linkteki mesajlarda olduğu gibi çift declaration hatası mı verecek? .2. soru .o dosyasını daha önce duymamıştım bu dosya neye yarar.

Yanıtlarınız ve vakit ayırdığınız için sağolun arkadaşlar ...
mesaj birleştirme:: 06 Ekim 2012, 17:42:20

[Erdem]

Hayır. Başta da belirttiğim gibi isterseniz .c uzantılı dosyaları da #include ile ekleyebilirsiniz. Derleyici açısından teknik bir fark yok. Ama örneğin diğer işlevde de main işlevi ya da başka bir işlevin tanımlanmamış olması gerekir.

.o uzantılı kütükler gcc'nin bağlayıcı için oluşturduğu kütüklerdir. Daha sonra bağlayıcı bunları makine diline çevirir.

$ nm diger.o
         U birSeylerYap
00000000 T digerIsleviKullan
00000014 T main

nm program kodlarının hangi sembolleri kullandığını gösterir. Satır başlarında U, "use"dan geliyor ve diger isimli programın o işlevleri kullandığını söylüyor.

[Kazım]

Pekiyi saol ...

[Kazım]

Gerbay -- 

Detaylı anlatımın için teşekkür ederim ..

[z]

Bende benzer sorunu asm dosyalarda yaşıyorum. C deki gibi header yapısı olmadığından (varsa da ben bilmiyorum) mecburen
ana asm dosyasının içine include direktifi ile diğer dosyaları tarif ederek kodlarımın birleştirilmesini sağlıyor ve tek bir dosyada anlaşılırlığı ve takibi zorlaştıran yapıdan uzaklaşmaya çalışıyorum. Ancak keilde yanlış hatırlamıyorsam 6 adet includedan sonra bir daha include yaparsam keil sapıtıyor ve ilgisiz satırlara hata vermeye başlıyor. Bu durumda en son eklediğim kodun bulunduğu dosyadaki satırları daha önce include ettiğim kodların arasına serpiştiriyorum. Bu durumda hata yok oluyor.

Acaba bunun da bir çözümü varmı? Yada keilin asm için de C deki gibi include haricinde dosya birleştirme/ayırma yöntemleri varmı?

[z]

Şu an üzerinde çalıştığım kodlardaki yapıyı koruyarak basit bir örnek oluşturayım ve buraya yazayım. Dosyalarım birbirini include etmiyor çünkü.