C programmering och header struktur

[lizerdboy]

Tjena
Satt och diskutera header struktur med en polare och har egentligen inte tänkt på vad som är KORREKT struktur.


Jag gör som så att jag skapar en Main.c och har global.h som header till main och alla andra .c filer.
när jag skapar en ny funktions fil .c så gör skapar jag alltid en .h fil med samma namn


i .c och .h filerna så lägger jag,
tex på Eeprom.c

Kod: Markera allt

/* Includes ------------------------------------------------------------------*/
#include "Global.h"
#include "Eeprom.h"

i Eeprom.h

Kod: Markera allt

/* Define to prevent recursive inclusion -------------------------------------*/
#ifndef __Eeprom_H
#define __Eeprom_H

//[b] här lägger jag alla funktions anropp[/b]
unsigned char I2C_Read(void);

#endif /* __Eeprom_H */

Eeprom.c har jag inkluderat i mitt program projekt.
Och när jag ska använda Eeprom funktionerna i någon annan .c fil så inkluderar jag bara Eeprom.h i den filen så funkar det fint.

Nu så försökte polaren och jag att skapa samma struktur på ett program "för ett Pic program" i går.
skillnaden var att man inte kunde inkludera .c filer i projekt som jag är van med, utan bara använder notpad.
Och hur man än la upp det så vart det bara massa fel.


Så nu undrar jag vad som är rätt struktur och anrops standard för .c och .h i en C program miljö?
finns det en sådan standard?

det jag kan läsa mig till när jag gogglar detta så är det samma struktur som jag använder.
alltså att man bara inculderar test1.h filen i övriga .c filer för få tillgång till text1.c funktioner.
Men det känns som det saknas någon länkning till själva .c filen, i detta fall alltså test1.c.

Är jag helt lost eller vad är det jag missar ??

Har använt denna struktur många år utan problem, men jag har dock alltid kört med programmerings projekt med alla .c filer inkluderade i projektet.
så här ser mitt upplägg ut iaf,

[Zeela]

Sättet du gör på är väl mer eller mindre standard i C-världen.

Vad kör din kompis för utvecklingsmiljö?
Vad får ni för fel?

Hade detta varit "vanlig" programmering i C för en PC så hade jag sagt att han måste kompilera alla c-filer till objekt filer och skicka med dessa till länkaren.
Det borde vara samma här. Beroende på om kompilatorn/miljön stödjer multipla källkodsfiler eller ej. (Men det ska väl de flesta miljöer fixa???)

[sodjan]

> skillnaden var att man inte kunde inkludera .c filer i projekt som jag är van med,

Och hur är det ??

> utan bara använder notpad.

Notepad ??

> Och hur man än la upp det så vart det bara massa fel.

Komplett värdelös information utan exempel. "En massa fel" är
det absolut sämta felbeskrivningen man kan tänka sig.

[lizerdboy]

Jag var inte ute efter att få någon lösning på polarens problem, utan kom på mig själv bar att inte vara säker på min sak hur
man strukturerar upp .c och .h och ville läsa på mig men hittar ingen bra info, därefter frågan här.

Sodjan:
>>> skillnaden var att man inte kunde inkludera .c filer i projekt som jag är van med,
det sättet som jag precis förklara hur jag la upp min .c och. h struktur.

>>> utan bara använder notpad.
alltså ingen färdig program miljö utan bara kompilerar via kommando prompten.

>>> Komplett värdelös information utan exempel. "En massa fel" är
>>> det absolut sämta felbeskrivningen man kan tänka sig.
absolut, men det var inte det som jag ville ha svar på så om du trodde det så får jag väll ursäkta för missförståndet

Zeela:

>>>> Vad kör din kompis för utvecklingsmiljö?
>>>>Vad får ni för fel?
Kan kolla upp det , men jag tror kompilatorn är Hi-tech.

>>> Hade detta varit "vanlig" programmering i C för en PC så hade jag sagt att han måste kompilera alla c-filer till objekt filer och skicka med dessa till länkaren.
>>> Det borde vara samma här. Beroende på om kompilatorn/miljön stödjer multipla källkodsfiler eller ej. (Men det ska väl de flesta miljöer fixa???)
Ska kolla upp det. Det låter som det kan vara felet.


Men jag var mer ute efter att kolla om att mitt tanke sätt är mer eller mindre korrekt.
Och frågan om hur .c filen blir länkad då man ara anropar .h för att få tillgång till dess funktioner.

[sodjan]

Bara för att man gör include på en h fil så händer normalt inget mer.
På något sätt måste länkningen "veta" att den även ska länka
in den obj/lib fil som hänger ihop med h-filen. Om inte får man
"undefined symbol" eller "unresolved reference" eller vad nu det
aktuella verktyget kallar det.

I MPLAB så lägger man till de aktuella källkodsfilerna till projektet så bygger
MPLAB en MAKE funktion av det hela som tar med rätt saker.

För HiTech så utgår jag från att dokumentationen har rätt svar på
alla frågor kring HiTech.

> det jag kan läsa mig till när jag gogglar detta så är det samma struktur som jag använder.
> alltså att man bara inculderar test1.h filen i övriga .c filer för få tillgång till text1.c funktioner.

Includen gör att funktionerna *definieras* rent symboliskt. Det har ingenting med
att länkaren sedan även faktiskt *hittar* funktionerna...

[jesse]

Du verkar ju lägga upp det på ett riktigt sätt , men det hjälper ju inte om du bara använder kompilatorn rakt av på en enda textfil. Antagligen är tricket att man skriver en make-fil som förklarar vad som ska göras och vilka filer som ingår i projektet? Men jag vet inte hur det ska se ut.

Jag har dålig koll på hur det här verkligen fungerar så det kunde vara intressant att få nån förklaring i vilken ordning saker sker när man klickar på "build". I en färdig IDE så skapas ju en (obegriplig) makefil automatiskt.

[BJ]

Får jag passa på och fråga en sak.
Varför har man h-filer till c-program, när man ändå ska ta med c-filerna i projektet?
Funktionerna finns ju i c- eller cpp-filerna. Kompilatorn eller länkaren måste ju gå in i
c-filerna för att hitta hela funktionerna. Är det för att det ska gå fortare att kompilera?
Jag förstår att man kanske vill ha med konstanter och definierade värden,
men annars?

[Zeela]

Men jag var mer ute efter att kolla om att mitt tanke sätt är mer eller mindre korrekt.
Och frågan om hur .c filen blir länkad då man ara anropar .h för att få tillgång till dess funktioner.

Det är rätt tänkt att dela upp relaterade funktioner i egna .c-filer och i en .h-fil definiera de funktioner som ska kunna användas i andra .c-filer.
Det är ett snyggt och enkelt sätt att paketera sin c-kod i olika "moduler".

Men som sodjan skrev har det inget att göra med hur länkaren hittar funktionerna. Det är enbart till för att kompilatorn ska känna till att funktionerna finns och kunna göra syntax kontroller samt lägga in anrop till dem i den objektkod som trillar ut ur kompileringssteget.

Länkaren försöker sen koppla ihop de olika funktionerna i objektfilerna med varandra. (Här får gissningsvis din kompis fel om han inte anger alla objektfiler som ska länkas.)

[sodjan]

> Kompilatorn eller länkaren måste ju gå in i
> c-filerna för att hitta hela funktionerna.

Blande inte ihop det ! Kompilering resp länkning är två olika processer.

*Kompilatorn* använder h-filerna för att generera rätt kod för själva funktionsanropet.
*Länkaren* använder sedan obj/lib filerna för att just länka ihop anropet med rätt funktion.

Men visst, du kan skriva dina "prototypes" direkt i din/dina c fil/filer också, men
det blir jobbigare att underhålla än att använda h-filer.

> Är det för att det ska gå fortare att kompilera?

Nej, för att det ska gå att kompilera över huvudtaget...

[BJ]

Ok.

[pbgp]

Får jag passa på och fråga en sak.
Varför har man h-filer till c-program, när man ändå ska ta med c-filerna i projektet?
Funktionerna finns ju i c- eller cpp-filerna. Kompilatorn eller länkaren måste ju gå in i
c-filerna för att hitta hela funktionerna. Är det för att det ska gå fortare att kompilera?
Jag förstår att man kanske vill ha med konstanter och definierade värden,
men annars?

Det finns ett skojigt språk som heter D, som inte gör som C

Där inkluderar man objektfilerna i sina .d-filer. Inga headers alltså. Nackdelen är att man måste ha en kompilerad objektfil för att kunna kompilera sina .d-filer. Men det vill man nog ha för det mesta i alla fall.

[sodjan]

> Nackdelen är att man måste ha en kompilerad objektfil för att kunna kompilera sina .d-filer.

OK, när det gäller D alltså.

> Men det vill man nog ha för det mesta i alla fall.

Menar du generellt ? Förrutom just D ?
I så fall finns det ju inget som helst anledning till det.
Det räcker att allt är kompilerat och klart inför länkningen.
Ingen kompilering förutsättar att någon annan modul redan
är kompilerad.

[pbgp]

Ja, jag menar generellt.

Fast vad jag egentligen menar är att man ändå har allt kompilerat och klart vid länkningstillfället, så ordningen borde inte spela någon roll. Vad metodiken i D medför, är att kompileringen görs i en viss ordning. Den ordningen för nog mest med sig fördelar. Jag kan inte komma på någon nackdel på rak arm, men jag skulle gärna bli upplyst.

[sodjan]

Varken för- eller nackdelar igentligen. Bara allt är kompilerat vid länkningen.
Sen är det en helt annan sak vad som är normalt eller vanligt, men
det har inget att göra med vad som krävs.

Nackdelen skulle väl kunna vara just att utvecklingen styrs upp på ett visst sätt.
Om det t.ex är olika personer som utvecklar de olika delarna så måste var
och ens arbete synkroniseras/serialiseras vilket totalt kan ta längre tid. D.v.s
att alla funktioner/subrutiner måste vara klara innan första testkompileringen
av huvudapplikationen.

Från http://en.wikipedia.org/wiki/D_%28progr ... anguage%29

"Most current D implementations compile directly into machine code for efficient execution."

vilket ju förklarar att alla anropade rutiner/libbar måste vara kompilerade när
huvudprogrammet kompileras. Det är inte rellevant för C hur som helst...

[swesysmgr]

Nu så försökte polaren och jag att skapa samma struktur på ett program "för ett Pic program" i går. skillnaden var att man inte kunde inkludera .c filer i projekt som jag är van med, utan bara använder notpad. Och hur man än la upp det så vart det bara massa fel.

Man kan göra så men det är väldigt mycket jobbigare och ger egentlgen ingenting jämfört med att använda en utvecklingsmiljö.

Om han kollar kompilatorflaggorna för Hi-Tech C så ser han att -Ic:\includefiler måste användas för att kompilatorn skall hitta det som skall inkluderas.

Enklaste sättet att få till det rätt är att använda MPLAB som sodjan skrev om, det är en rätt risig miljö för C-utveckling men den går att använda. Hi-Tech C fungerar som en helt integrerad plugin i MPLAB och programmet är gratis.

Prövar att kompilera ett program där och titta sedan i kompilatoroutputten så ser han hur de vanligaste flaggorna för Hi-Tech ser ut.