Inkludera c på samma sätt som assembler?

[BJ]

När man programmerar Pic-processorer
i assembler så kan man lägga en valfri del
av programmet i en egen fil, för att få
filerna mindre, och inkludera den där den
ska vara.
Går det att göra likadant i c, eller är man
tvungen att göra en funktion av det man
vill flytta ut?
Och hur skulle det gå med rader som:

#pragma config CP0 = OFF // Code protection off.

[Findecanor]

Du kan include:era en .c - fil precis som en .h - fil, om det var det du undrade.

[Klas-Kenny]

och inkludera den där den
ska vara.

Du vill alltså mitt i löpande kod, inkludera en annan fil som har bara ett stycke kod, rakt upp och ner?

Det är fullt möjligt att det går med vanlig #include, vet faktiskt inte då jag inte provat. Men herrejösses vad oläslig koden skulle bli om man gör på detta vis.
Dela upp koden i lämpliga funktioner så blir allt utmärkt. Sen inkluderar du alla filer överst i koden.

[BJ]

Jag menade så som Klas-Kenny skrev.

Kanske blir det bra att ha delarna i funktioner.
För att skilja huvudprogrammet från alla
#pragma config ...
så skulle huvudprogrammet hamna i en
egen funktion. Men då använder man ju
en stack-nivå bara för det...

[Klas-Kenny]

Pragma är inga problem att lägga i en egen h-fil typ config.h, sen inkludera överst i main.c med #include "config.h"

[Findecanor]

(flyttat från inlägg jag först redigerat ovan):

En #include fungerar precis som om man raderade raden och klistrade in innehållet från den andra filen på den platsen. Det finns ingen "magi" - det är bara rå text-data.

Att include:era maskinkod i C vore lite bökigare. Man får nog kompilera till assembler, och sedan ha ett script som formatterar om assembler-koden till C-satser med inline-assembler.

Det går inte att använda länkaren för att inkludera kod inuti kod, utan de olika sektionerna från de olika objektfilerna läggs bredvid varandra. C-program länkas ihop med namnen på funktioner och variabler, som översätts till pekare som skrivs ner i platser i alla platser i programmet där de ska användas. (grovt förenklat)

[BJ]

En #include fungerar precis som om man raderade
raden och klistrade in innehållet från den andra filen
på den platsen. Det finns ingen "magi" - det är bara
rå text-data.

Okej.

Pragma är inga problem att lägga i en egen h-fil
typ config.h, sen inkludera överst i main.c med
#include "config.h"

Okej. Jag provade nu, och det verkade fungera
utan problem.

Tack.

[sodjan]

Om du ändå ser ett behov av att dela upp koden i flera källkodsfiler
av praktiska orsaker, så är det nog lika bra att även göra det till olika
separat kompilerade moduler. T.ex. så går en "build" snabbare eftersom
enbart de filer som kräver det kompileras om.

En annan sak är att list filen blir mer svårläst (om du inkluderar C-kod),
eftersom den inte kommer att motsvara källkoden rakt av. Eller så får
man slå på någon option som inkluderar #incude filerna i list filen, men
då får du massor med headers där också...

Jag hade gjort de delar av koden som redan är testad och "godkänd"
till separata filer/moduler, så slipper du att tänka på det.

> så skulle huvudprogrammet hamna i en egen funktion.

Alltså main()? Låter opraktiskt. Låt initiering, dina config och huvudelen
av main() rutinen ligga i din huvudfil och gör resten till funktioner.

[anders_bzn]

Alltså,

Man inkluderar inte en C-fil i en annan C-fil. Det blir oläsbart. Det är ett dåligt sätt att lösa problemet med stora filer. Man bryter ut saker för att det ska bli lättare, lägger saker med liknade funktionalitet och ser till att ha ett vettigt api till den funktionaliteten som man ser till att beskriva i header-filen.

Inkluderar man en c-fil från två andra filer så kan man få massor med konstiga problem förutom kod-duplicering. Om det ens går att kompilera. Det beror lite på vad man gjort. Att inkludera en headerfil från två andra filer är inte ett problem, det är tänkt att man ska göra så.

Om du tänker inkludera en c-fil så tänk om. Jag kommer inte på någon fördel med detta. Tänk om och gör rätt.

[TomasL]

C-filerna (och H-filerna) lägger du till i projektet, H-filerna inkluderar du vid behov i de c-filer som behöver dem.

[BJ]

Okej.

Det jag gjorde nu, till att börja med,
var att lägga pragma-raderna i en h-fil
som jag inkluderade upptill i huvud-filen,
och det verkade fungera.

[Findecanor]

Jag håller faktiskt också på med ett projekt hemma just nu där jag ska inkludera en .c-fil i en annan, men det är ett specialfall och jag rekommenderar inte att man gör så här om man kan undvika det.
I mitt fall behöver jag samma ganska komplicerade C-deklarationer och definitioner flera gånger med olika parametrar. Jag snackar inte olika anrop här utan const static-datastrukturer som ska ligga i flash.

Nej, det är inte alls särskilt läsligt, men jag prioriterar andra saker än läslighet i just det här fallet. Mikrokontrollern är 8-bittars AVR, inuti bl.a. existerande hårdvara. Det är väldigt begränsat med RAM och andra resurser så det måste ligga färdigt i flash och kan inte skapas programmatiskt under körning.
Mjukvaran är också ett slags ramverk för andra (räknar med mindre erfarna) programmerare och det är inte meningen att de ska vara inne och rota i de komplicerade delarna. Istället prioriterar jag enkelhet i hur man sätter parametrarna som avgör instansieringen.
Alternativet hade varit att skriva ett script som genererar datastrukturerna och det tycker jag faktiskt skulle blivit ännu mer komplicerat för mig att skriva, parametrarna skulle behövt ligga i flera filer (skrivna i C och i något annat), och sen skulle användaren förstås ha behövt installera scriptspråket också.

[Icecap]

Jag brukar inkludera C-filer ganska frisk t <projektet> men inte i C-filer.

Jag kan tänka mig att man kan ha canska tunga definitioner som enklast beskrivs i en egen fil - men den fil är dock en .H-fil.

[Nerre]

Men då använder man ju en stack-nivå bara för det... :humm:

Tankevurpa. Dagens kompilatorer är tillräckligt smarta för att optimera bort detta.

Jag tycker det är lite läskigt att se hur kompilatorer optimerar, jag har kompilerat väldigt enkelt "blinka LED-program" i C för AVR för att försöka få det att likna mitt "blinka LED-program" i assembler. Utan optimering gick det att få koden från gcc att se ut ungefär som min assemblerkod. Med maximal optimering förstod jag knappt hur den resulterande assemblerkoden fungerade :)

Att lägga funktioner inline för att ta bort onödiga call/return är en väldigt grundläggande optimering.

[sodjan]

> Alltså,
> Man inkluderar inte en C-fil i en annan C-fil.

Nej, man "gör" inte så. (*)
Men ja, det går rent tekniskt.

Det är inte vanligt/normalt att man gör det i C, men i andra
språk så är det en mer naturlig del av språket, som COPY
kommandot i Cobol (fungerar som #include i C).

(*) Skulle kunna finnas specialfall där man vill ha det inline
av prestandaskäl, men det finns väl en "inline" option för
funktioner för att tvinga fram det? Sen så är det ju även en
optimering, som Nerre säger, men utan egen direkt kontroll.