För bästa minneshantering - Deklarera utanför funktion, eller innanför?

datatyp funktion(argument){
     const datatyp[rad][kolumn] = {{x,y,z}, {x,y,z}, {....}};
}

const datatyp[rad][kolumn] = {{x,y,z}, {x,y,z}, {....}};

datatyp funktion(argument){
     
}

Förutsatt att datatypen inte är gigantisk (flertalet megabyte eller större) så går det snabbare att generera upp den på nytt än att läsa in den från minne. Nyttja alltid stacken i första hand - den är snabbare än andra minnen.

Skickades från m.sweclockers.com

Kort sagt så, ja. Får arrayen inte plats i stacken får du skapa upp den i heapen med malloc och sen köra free innan funktionsslut.

Skickades från m.sweclockers.com

Jag tolkar frågan som att eftersom du pratade om att det är en väldigt stor mängd data som ska vara i arrayen, ska du skriva in allt för hand? Eller är det inte så mycket som ska vara i?

Strunta i tidigare inlägg i tråden. De har inte koll på vad de uttalar sig om.

Så länge din array är const spelar det ingen roll om den definieras i globalt scope eller inom funktions-scope. Oavsett var du lägger den kommer den att hamna i kod-minnet (varken på stack eller heap) och accessas på samma sätt. Eftersom den inte kan ändras kan kompilatorn lägga datat "bredvid" programkoden.

Stora mängder const-data lägger man oftast globalt, men om du bara skall använda det i en funktion kan du lägga det i funktionen också. Det spelar ingen roll. Det kommer ta lika mycket plats och accessas på samma sätt. Attributet static styr bara om symbolen skall synas utanför filen eller inte. Med static kommer du bara åt din array i samma fil. Utan static kan du ha en extern-deklaration i en headerfil och komma åt den från andra filer.

@heretic16: Uppenbarligen är vi flera som inte vet vad vi pratar om. Jag var lite trött i går kväll.

För en funktionslokal array (låt oss kalla den A) skall det allokeras utrymme på stacken. Är den initierad måste dessutom kompilatorn se till att dessa värden hamnar i A. Detta sker oftast genom att kompilatorn har lagt ut data (A') som A skall initeras med och kopierar A' till A. Är det är liten array kan kompilatorn även lägga ut kod som initierar den element för element.

Om, som i ditt fall, A är const skulle kompilatorn kunna strunta i att allokera den på stacken och läsa direkt från A'. Jag trodde det var en optimering som alla kompilatorer gjorde, men så är icke fallet. Om du vill vara säker på att slippa denna kopiering måste du deklarera din funktionslokala array static.

Att skriva till ett const-objekt är undefined behavior och GCC utnyttjar det flitigt i andra sammanhang så jag är lite förvånad över att de inte gör det här också. Att skriva till en const array kan jämföras med att skriva till en sträng-literal (const char * som pekar till kodminnet) och man kopierar inte strängarna till skrivbart minne utifall någon skulle får för sig att skriva till dem. (Ja, det finns en option som gör det för legacy-kod.)

Mitt tips är att du lär dig mäta tid i C och sen gör du några testrundor med stora mängder data. Då får du fakta istället för debatt, samt att du lär sig ett verktyg som är ovärderligt om du kodar saker som behöver optimeras.

Från geeksforgeeks.org:

#include <time.h>

clock_t start, end;
double cpu_time_used;

start = clock();
... /* Do the work. */
end = clock();
cpu_time_used = ((double) (end - start)) / CLOCKS_PER_SEC;

Kritiska här är att separera deklaration/alias från definition. I C/C++ kan man tyvärr inte göra några extra vettiga optimeringar bara för att en man har en const-pekare till något.

Orsaken är att det är helt tillåtet att skapa en const-pekare till en minnesarea som i sig inte är konstant. Alias-reglerna i C/C++ är ur den aspekten en käpp i hjulet för att kunna ge extra optimeringar.

void foo(int n);
void bar();

void baz(const int *p) {
    foo(*p); // <- första läsning via pekare p
    bar(); // <- är fullt möjligt att bar() ändrar på det p pekar på :(
    foo(*p); // <- måste läsa om värdet från p
}

Om däremot definitionen är konstant säger standarden detta:

"J.2 Undefined behavior
...
- An attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type (6.7.3)
..."

Detta är något i alla fall moderna versioner av GCC/LLVM utnyttjar. Om kompilatorn "ser" att deklarationen av data man jobbar med är konstant så läses normalt inte samma data in igen bara för att två referenser är separerade av funktionsanrop vars implementation kompilatorn inte "ser" (adress till anrop hanteras i länksteget).

Vad det gäller TS fråga kvarstår fråga: vilken typ av system handlar det om?
Är det en mikrokontroller eller på något sätt ett system mer realtidskrav allokeras data lämpligen statiskt/permanent (d.v.s. vid kompileringssteget) eller om man inte kan avgöra storleken vid det tillfället allokeras allt (och släpps aldrig) vid start så snart man vet storlek.

I fall där man av något skäl måste dynamiskt allokera och släppa minne där storleken på minnesarean varierar och är rätt hopplös att förutse så är C/C++ fel språk. Detta är ett av de fall GC med indirekt minnesreferens (t.ex. JVM och .NET/CLR) passar långt bättre då dessa är immuna mot fragmentering p.g.a. att minnet helt enkelt kan komprimeras vid behov (indirekt minnesreferens gör detta möjligt utan att "pekare" pekar fel, i C/C++ kallas dessa pekare typiskt för "handtag").

Lite knee jerk av mig, men beroende på platform behöver man nog inte oroa sig över fragmentering i första laget. Att slänga ut manuel minneshantering pga sporadisk, dynamisk allokering känns därför lite i överkant i många fall.

Helt samt, var därför jag ställde frågan kring vilket typ av system det handlar om här. Finns flera anledningar att undvika GC, men finns betydligt fler saker än att hantera eventuellt fragmentering som talar för GC.

Dels kan extern fragmentering (att man hackar upp minnet i mindre bitar) delvis undvikas genom ökad intern fragmentering (man hanterar minne i relativt få minnesblockstorlekar och avrundar storleken uppåt till närmast tillgängliga blockstorlek). Har skrivit ett par TCP/IP-stackar genom åren, där kan massor med buffertar allokeras/frias på kort tid och olika cache:ar med block i en viss storlek används både för att minimera extern fragmentering samt som prestandaoptimering.

Omvänt har GC en rad fördelar om man har flera trådar i sitt program som delvis jobbar mot delad data. Tekniker som persistent data structures kan vara väldigt effektiva här förutsatt att man har en GC och kan undvika lås samt något som kallas ABA-problemet.

Har fuskat lite inom detta, bl.a. tagit fram denna (patenterade) teknik.

Var just av sådant du nämner här jag skrev

"vilken typ av system handlar det om? Är det en mikrokontroller eller på något sätt ett system mer realtidskrav allokeras data lämpligen statiskt/permanent"

GC och hårda realtidskrav är i praktiken helt inkompatibla, däremot kan program med mjuka realtidskrav fungera med vissa typer av GC. Ett sådant exempel är GC i språket Go, där har vissa egenskaper som "compacting GC" (vilket är det som kan eliminera fragmentering helt) offrats just för att man ansåg GC vara ett krav men man kunde inte heller tulla allt för mycket på jitter.