Jesses följetång om AVR programmering i C...

[speakman]

Kommer inte ihåg vad av allt, men jag misstänker c-eldoc.el.

[bearing]

h-filerna används varje gång. Det är C-filerna som kan kompileras separat. Väl?

Du är nästan unik i världen att stava programmering "progrannering", enligt google

[sodjan]

> h-filerna används varje gång. Det är C-filerna som kan kompileras separat. Väl?

Lite oklart vad du menar. Vad menar du med "varje gång" ?
H-filerna inkluderas normalt från C filen vid kompileringen.
Efter det så används de inte mer. Så i princip är det ingen
skillnad på hur C eller H filerna "används"...

[bearing]

Jag menar att om man i ett projekt använder förkompilerade C-filer, så inkluderar man ju ändå H-filerna. Så om man kompilerar en main.c som inkluderar några H-filer, vilka alla inkluderar en specifik H-fil som innehåller en rad som ger varning, kommer den varningen synas för varje fil som inkluderar H-filen med raden som ger varning.

[Nerre]

H-filerna inkluderar man för att kompilatorn vid kompileringen av en C-fil skall veta vilka funktioner som finns i en annan C-fil.

Utan H-filerna skulle kompilatorn inte kunna varna för om du t.ex. använder en funktion eller dess returvärde på fel sätt. En C-fil kan ju bara använda de funktioner som finns definierade i den filen (inklusive alla includes).

H-filerna används ju egentligen inte av kompilatorn utan av preprovessorn. Kompilatorn tar över filen efter att alla includes och sånt är utfört av preprocessorn.

Anledningen till att man använder H-filerna är just att slippa kopiera samma sak till 4711 olika C-filer. Man behöver inte använda H-filer, men det blir väldigt bökigt att göra ändringar om man inte gör det. Och med förkompilerade libbar så är det ju inte säkert man har tillgång till C-filerna ens utan måste ha H-filer för att veta hur funktionerna ser ut.


Det enklaste sättet att fatta hur det fungerar är ju att helt enkelt köra kompileringen, inklusive preprocessorn, manuellt.

Kör man GCC så finns ju GPP att köra separat.

[sodjan]

> Jag menar att om man i ett projekt använder förkompilerade C-filer, så inkluderar man ju ändå H-filerna.

Ja, om det som ingår i H filerna *behövs* i den egna koden. Det är inte säkert och ofta
används en speciell H fil som enbart innehåller "extern" direktiv och där annat som användes
vid kompileringen är borttaget. D.v.s enbart det som utgör "interfacet" mellan ditt program
och den förkompilerade filen. Du behöver ju inte alla definitioner som den där andra
C filen använder sig av.

Det finns absolut ingen regel som säger att *alla* H filer måste inkluderas bara för att
de har används vid kompileringen av en OBJ fil som länkas in.

Får man varningar (eller felmeddelanden) så är något fel (eller i alla fall inte helt OK), men
det har inget direkt med separatkompilering att göra.

[bearing]

Så du menar att man vid kompileringstillfället av en C-fil använder en annan H-fil än vad som senare inkluderas i andra filer?
Det har jag aldrig sett.

För att minska eventuellt förvirring; mitt inlägg längst upp på den här sidan var ett svar på ett inlägg som togs bort just innan jag skickade mitt inlägg. Inlägget handlade om att samma varning dök upp flera gånger under kompilering/länkning.

[sodjan]

> Så du menar att man vid kompileringstillfället av en C-fil använder en annan H-fil än vad som senare inkluderas i andra filer?

Självklart! Det är det normala sättet att hantera det.

Låt oss ta ett enkelt exempel...

Säg att du skriver en lite C-snutt som gör en utskrift. Låt oss kalla denna för "my_print.c".
Denna behöver då sannolikt "stdio.h" och kanske andra h-filer för olika lib'ar.

Denna C-fil har en funktion som heter "my_print_func()" och som du anropar från ditt "egna" program.
Det som ditt egna program då behöver är en fil som heter t.ex "my_print.h" och som enbart har en
deklaration av "my_print_func()". Om du inte gör några andra utskrifter så behöver du sannolikt
inte "stdio.h" (eller några andra h-filer till lib'ar). Du behöver naturligstvis inte inkludera h-filer
till lib'ar som *enbart* används i OBJ filerna !

Ny kanske inte just "stdio.h" var det bästa exemplet därför att just den används nästan
alltid, men du förstår säkert principen...

[speakman]

Ett praktiskt exempel:

myfunction.c:

Kod: Markera allt

#include <stdio.h>

void myveryspecialputs(char *msg)
{
        puts(msg);
}

myfunction.h:

Kod: Markera allt

#ifndef _MYFUNCTION_H
#define _MYFUNCTION_H

void myveryspecialprint(char *msg);

#endif

myprogram.c:

Kod: Markera allt

include <stdio.h>
include "myfunction.h"

int main(void)
{
        puts("Normal output\n");
        myveryspecialputs("Special output\n");
}

Verkningslöst program, men här inkluderar "myfunction.c" inte "myfunction.h" alls. Däremot använder myprogram.c den filen för att veta vilka funktioner som finns att tillgå (deklarationer).

edit: #ifdef-satsen i .h-filen gör man för att den bara ska inkluderas EN gång vid en och samma kompilering. Annars finns risk att den börjar klaga. Dock inte i just det här specifika fallet, så de delarna kan helt förbises.

[sodjan]

Om du hade plockat bort "puts" från myprogram.c (och även "include <stdio.h>")
så hade det tydligare visat att man inte måste inkludera samma filer i myprogram
som i den inlänkade OBJ filen, vilket ju var det som diskuterades. Alltså :

myfunction.c:

Kod: Markera allt

#include <stdio.h>

void myveryspecialputs(char *msg)
{
        puts(msg);
}

myfunction.h:

Kod: Markera allt

void myveryspecialprint(char *msg);

myprogram.c:

Kod: Markera allt

include "myfunction.h"

int main(void)
{
        myveryspecialputs("Special output\n");
}

[jesse]

Ursäkta, det var jag som drog igång det här... Gjorde ett inlägg om filen <util/dealy.h> varför den utfördes en massa gånger fast den började med #ifndef DELAY_H #define DELAY_H... men sen förstod jag ju svaret själv... Det jobbiga var att jag fick varningen: "koden ej optimerad, därför fungerar delay.h ej som tänkt"... 6 gånger! Lite irriterande med en hel djungel av varningar!

[bearing]

Jag minns inte riktigt vad du skrivit, och den här förklaringen förstod jag inte. Vad var det som var fel, och vad berodde det på?

[jesse]

Jo... en .h-fil brukar innehålla raderna

Kod: Markera allt

#ifndef FILNAMN_H
"define FILNAMN_H
     ... kod ...
#endif

Detta borde göra att t.ex. en varning inne i filen bara borde skrivas ut en gång när man kompilerar. Men jag fick sex varningar - alla från samma rad i filen util/delay.h. Det berodde på att jag hade flera källfiler i projektet, och för varje ny källfil så nollställdes alla definitioner igen.

[bearing]

Jag förstår... tror jag.
Hade du ändrat i alla källfiler innan kompilering/länkning?
För det är väl meningen att filerna bara ska kompileras ifall de ändrats.

[speakman]

Har man en gemensam .h-fil som inkluderas i alla C-filer så kommer den kompilera om rubbet när man ändrar i den .h-filen.