nagy tömb deklarálás

C/C++

A kérdésem az igazán csak elméleti, mert ugyebár allokálni sokkal szebb neki memóriát, de a kérdésem mégis az lenne, mekkora maximális méretű tömb deklarálható?
Vagy milyen fordítási kapcsolóval lehet 64k-nál nagyobb tömböt csinálni?

( Arbiter | 2008. 04. 09., sze – 10:55 )

Szia!

Ha nem kell minden tömbelemnek rögtön értéket adni, érdemes lehet láncolt listával helyettesíteni, így egy csomó memória spórolható.

( popacsek | 2008. 04. 09., sze – 10:59 )

Arra gondolsz, hogy lokálisan a stacken akarsz tömböt deklarálni?
Szerintem nincs 64k-s limit.

( mrev | 2008. 04. 09., sze – 11:07 )

Kipróbál? Símán lehet 64K-nál nagyobb tömböt deklarálni. 


#include <stdio.h>
int main()
{
    char buf[0x100000000];
    buf[0x100000000-1]='x';
    printf("sizeof 0x%lx\n",sizeof(buf));
    return 0;
}

Ez pl. símán lefut. Persze gondja lesz az os-nek, ha a program a tömböt elkezdi igazából használni.
--
CCC3

Egy ilyet raktam gyorsan össze, de ezt nem szereti :(

#include fcntl.h //kacsacsőröket nem tudtam megjeleníteni
#include sys/types.h
#include sys/uio.h
#include unistd.h
#include string.h
#include stdio.h

struct entry{
char name[22];
char value[22];
};

#define MERET_R 1000000

int main(int argc, char *argv[]){

char line[8192];
struct entry roamers[MERET_R];

printf("azdmeg\n");
}

Simán lefordul, de Segmentation fault-al fut

Ilyet nem csinalunk, semmilyen korulmenyek kozott. Ez bad coding, IMO. Miert is nemjo, ha dinamikusan malloc()-olsz, vagy new-elsz neki memoriat?

Bar nyilvan nem szempont, de en Amigan iszonyatos mennyisegut anyaztam ilyesmi miatt, mert portolaskor kulonosen gyakran fut bele az ember a quality FOSS alkalmazasokban ilyen kodba, hogy stackbe foglal nehany 100k-s tempbuffereket (es az meg a jo eset, ha csak annyit), aztan nekiall rekurzivan hivni. Holy shit. Es itt alapbol 4k a stack merete. De 64k-nal tobbet meg a webbongeszo sem hasznal...

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

64-bites Linuxon, gcc 4.1.2-vel fordítottam. Más rendszereken másképp lehet. Annyi mindenesetre látszik, hogy irreálisan nagy (a fizikai memóriánál nagyobb) tömböket is hajlandó létrehozni. Az os memóriakezelése nyilvántartja, hogy a nagy memóriablokk melyik része van benn ténylegesen a fizikai memóriában, melyik része változott, mit kell kirakni a swapra, valahogy így képzelem. Komplikált ügy.
--
CCC3

( tr3w v | 2008. 04. 09., sze – 11:31 )

A 64k-s limit csak dos alatt volt valós módban.
Ilyennel max Turbo C 3.0-ban találkozhatsz. :)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

( asch v | 2008. 04. 09., sze – 13:42 )

Oprendszerfüggő, de az alapelvek kb ezek:

Amit programblokkban deklarálsz, az a stacken jön létre.
Ezt a szálankénti stack mérete korlátozza, ami oprendszer szintű beállítás. Szerintem a stacket nem szokás dinamikusan továbbfoglalni ha elfogy. Pedig elvileg akár lehetne is. Tehát itt egy fix limit van.

Amit a függvények között statatikusan, az már induláskor egy statikus memóriaterületen. Itt szerintem az oprendszer virtuális memóriája és persze a címzési modell a korlát. Egy mai rendszeren itt foglalhatsz 4GB-ig szerintem.

Dinamikus foglalásnál szintén akármennyit foglalhatsz. Sőt az oprendszer akár csinálhat neked olyat is, hogy ha a közepét nem használod a tömbnek, akkor ahhoz nem rendel memórialapot, csak on-demand.

Mit akarsz vele csinálni?