malloc eller lokala variabler?

[Swech]

En plattform som skall köra program som inte är känt från början trivs ju bäst med Malloc.
Ett inbyggt system som t.ex. skall kontrollera ett antal elmotorer och givare har ju ett
klart definierat program redan från start. Om minnet inte räcker till så är man ute
på tunn is... Det är iallafall mycket tveksamt om 8 bitars system har några fördelar med malloc.

Swech

[lillahuset]

Sedan har vi ju problemet med fragmentering av heapen.

[jesse]

Ett problem kan ju vara ifall du har behov av en lokal/temporär array i flera olika funktioner. Om varje rutin då gör sin egen malloc/free så kolliderar det aldrig, men å andra sidan så blir minnesbehovet svårare att beräkna i förväg.

I det här fallet var det ett antal funktioner som skulle ha en "slaskbuffert". Det är ett exempelprogram jag laddat ner. Jag tänker dock inte använda det, utan göra liknande kod. Eftersom funktionerna aldrig kommer att exekveras samtidigt så går det utmärkt att skapa en global array som kan användas hur som helst inne i respektive funktion. Väldigt onödigt att hålla på med malloc()..free() då.

pbgp: Ofta finns ingen begränsning alls för stacken, den kan växa obehindrat genom hela RAM-minnet och i vissa µ-controllers (som t.ex. ATMega) även börja skriva över register till perifera enheter....

[lillahuset]

Jag har sett flera fall (och gjort det själv en gång) när man har deklarerat en stor array i main() i Windows och programmet har kraschat.

Edit: Altså utan static.

[jesse]

varför har det kraschat?

[lillahuset]

Antagligen för liten stack.

[Icecap]

Hade ett program som jag kompilerade. Jag hade definierat en const uppslagstabell som var rimligt stor - och fick heap-varning.

Flyttade den ut från rutinen och allt var OK. Men heap är ju RAM och en const är ju i programminnet så jag funderar en del över detta, jag har dock inte haft tid att fixa något med det.

Jag använder inte malloc() alls i min programmering till µC, då mest för att jag inte har okända storlekar. Det händer dock att jag behöver en arbetsbuffer och vill återanvända minnet, då deklarerar jag den som en union eller liknande eller cast'ar pekare till den.

Och att använda malloc() i en 8-bitars AVR känns ju helt fel! De resurser finns inte så att det behövs.

[TomasL]

Inte ovanligt att ROM-Konstanter kopieras till RAM vid Boot, detta för att RAM i regel är betydligt snabbare och lättare att komma åt. Du får sätta kompilatordirektiv för att förhindra detta.

[lillahuset]

Deklarerade du den i en funktion? Då behöver du deklarera den "const static" om jag minns rätt.

Edit: Fast att du fick varning om heapen verkar skumt.

[TomasL]

Nja, om kompilatorn försöker kopiera dem till HEAPen, så kan det ju bli så.

[Icecap]

Jup, den skulle deklareras som "static const..."
Och enl. MAP-filen sparas den som ROM-data på det vis.

[Nerre]

Var det C så har ju den en uppstartskod som snurrar innan main() börjar exekveras, jag vill minnas att en av grejerna där är just att kopiera konstanter från programminne till arbetsminne.

[lillahuset]

Det varierar tydligen. I mina ARM-projekt med GCC lägger jag alltid större konstanttabeller i Flash. Funkar fint.

Edit: Brukar bero på hur man deklarerar konstanterna.

[kodar-holger]

Jag har inte tidigare tänkt på att lokala variabler (eller arrayer) måste ha bestämd storlek från början, men det måste de ju förstås.

I varje fall i C och C++. Och om jag inte minns fel klarar modernare versioner av C++ standarden "dynamisk deklaration" eller vad det nu skall kallas. Ada kunde redan 1983 deklarera en lokal variabel med dimensioner från en annan.

I slutänden är det den specifika kompilatorn för en vissa plattform som bestämmer. Bör stå i dokumentationen för kompilatorn om det finns vettig sådan.

Och att lokala variabler hamnar på stacken är väl bara en konvention vi vant oss vid. Jag kan inte tänka mig att standarden för något språk över huvud taget specificerar detta. På inbäddade system kan det spela roll trots att man programmerare i högnivåspråk men då får man väl kalla det för högnivåassembler.

Lokala variabler, ju mer lokala dess bättre, är alltid att föredra före dynamisk allokering med malloc (eller new) om det är möjligt. Då glömmer man inte free.

[ie]

Jag håller på att koda ett system med ett antal olika noder. Dessa kommer att ha olika kombinationer av programmoduler. Dessa moduler är helt skilda från varandra och kan bara kommunicera genom att skicka meddelanden. Dessa meddelande kan skilja i storlek på många sätt, typ olika långa adresser och data.

Jag använder väldigt mycket malloc/free i denna kod, för att optimera minnet genom att endast allokera så mycket som behövs vid varje tillfälle och för varje datamängd. (Mycket av datat är okänt vid kompileringen, t ex antal tempgivare.)

Sen har jag koll på minnesåtgången så att jag kan se om det finns minnesläckor och att minnet räcker för en specifik nod.

Alla noder snurrar med en ATmega328, utom en som kör i princip samma kod på en RPI.

Så visst finns det tillfällen när malloc både är lämpligt och funkar bra på en 8-bitare.