Dotaz: Maximalna velkost jednorozmerneho pola v C

[Warchangel]

Dobry den,

chcel som sa opytat, ci je velkost jednorozmerneho pola v jazyku C nejak obmedzena. Pretoze potrebujem jednorozmerne pole typu long, ktore bude mat maximalne 1 000 000 prvkov. Ale ked v programe napisem "long pole[1000000]" a dam spustit program, tak mi to hned pri starte vyhodi chybu. Ale ked pouzijem "long pole[500000]", tak vsetko funguje ako ma.

popripade, neviete ako tento problem vyriesit, aby som mohol mat " long pole[1000000]"?

Za odpovede vopred dakujem.

---

---

Odpovědi

[Václav Vanc]

Ta maximální velikost pole bude pravděpodobně záviset na hardwaru a překladači. Pro takto velká pole je vhodné používat dynamicky alokovanou paměť. Tudíž si nastuduj funkce malloc a free.

[Warchangel]

To pole se vam nejspise nevejde na zasobnik. Deklarujte ho jako staticke, pak by to melo fungovat (pokud nemate dementni prekladac).

[mankind_boost]

long je 32bitovej pokud vim, no a pole o rozměru 1 000 000 prvků má velikost 4GB, což může překračovat limit 32bit aplikace.

[tom]

1 000 000 prvků má velikost 4MB

[mankind_boost]

no jó :D

dneska sem se moc vyspal a je to znát :D

[mess]

Tohle mi připomíná, jak se u nás na fakultě vyučující baví tím, že zadávají projekty, do kterých píšou něco v tomto smyslu:

... prvků v této množině může být klidně i 10⁶ ... Napište program, který ji zpracuje."

Každý rok to číslo dávají vyšší. A potom baví okolí tím, že vyprávějí kolik lidí tu paměť ve svém projektu alokuje staticky na zásobníku.

Takže rada na závěr - nastuduj si malloc() a free(). A popřemýšlej, jestli je pole přesně to, co potřebuješ (jestli by se třeba neuplatnil spojový seznam).

[aaaaaaaaaaaaaaa]

Ak sa da nieco implementovat cez pole, pouzil by som pole.

Spojak je pomaly a neefektivny, ci uz berieme zabranu velkost alebo len rychlost priechodu od zaciatku do konca. Pristup cez pointery nieco stoji, nefunguje tu rozumne prednacitanie (ked su data po celej pamati) a pri pridavani kazdeho noveho prvku je treba volat pomerne pomaly malloc.

Keby to nejak zoskupoval a robil by spojak poli, tak by to bolo snad o trochu lepsie. Takto je napriklad na mojom systeme overhead na 1 prvok 8B (4B malloc + 4B pointer na dalsi prvok) pri velkosti prvku 4B (long). To znamena az 3x vacsiu spotrebu pamati.

[Kit]

Základní axiom: Univerzální řešení neexistuje.

Spojový seznam může být za určitých okolností efektivnější a úspornější, než pole. Záleží na typu úlohy, kterou zpracovávám.

[aaaaaaaaaaaaaaa]

Ked potrebujem nieco vkladat inde ako na koniec, pricom nevie, kde presne, tak ano - spojak moze byt rychlejsi ako pole. Aj to by som ale riesil spojakom poli, prave kvoli opisanym dovodom. O uspornosti spojaku oproti polu pochybujem - aky moze byt mensi overhead ako nulovy?

[mess]

Pokud ta položka bude větší (např. nějaká struktura), tak ten poměr spotřeby paměti nebude už tak nevýhodný. Navíc někdo by v některých typech úloh mohl ocenit konstantní časovou složitost operace vložení prvku do seznamu oproti lineární složitosti u pole. Nic není černobílé.

[aaaaaaaaaaaaaaa]

Staci vkladat na koniec pola namiesto na zaciatok a hned mame tiez konstantu.

Viem, ze je niekedy jednoducho treba pouzit spojak, ale v tom pripade si ho reprezentujem (ako som spomenul vyssie) spojakom poli, aby sa zaroven vyuzilo vyhod poli.

Graf (a zlozitejsie struktury) davam tiez najradsej do pola, lebo taketo rozvhnutie lepsie vyuziva pamat a cache (medzi zaznamami nie su "poznamky" od mallocu, takze nastava menej aliasingu pri cache-ovani), zo skusenosti to bezi rychlejsie ako "pointerami implementovany" graf (spojak) a v debug verzii je mozne velmi jednoducho spravit kontrolu, ktora overuje validitu adries (tu ide o indexy do pola) a pritom to upozorni na problemy.