Najprv vyvediem z omylu tých, ktorí si mysleli že chcem rovnakej adrese v pamäti pridelovať viacero mien - nie, nie je to tak, takže pointery asi nebudú riešenie.

Môj problém je v tom, že by som chcel v cykle deklarovať premenné vždy s iným názvom. Napr. v cykle for chcem v každej iteracii definovať premennú s názvom zvyšujúcim sa o 1. Otázka je - je to možné? prípadne, ako? (pre tých ktorí čítali moju predchádzajúcu otázku o c++ - viem, že provokujem, ale nedá mi to nevedieť)

ukážka zdrojového kódu -
for (a=0;a<10;a++)
{
int [premenlivý názov, ideálne by mal hodnotu a+1] = 0;
cout << "Názov premennej je" << [názov premennej definovanej o jeden riadok vyššie] << " a jej hodnota je "<< [opäť názov premennej];
}

Ďakujem.

Riesil by som to poliami.
Napr takto: polia su na toto prave stvorene

O poliach viem, mne ale ide o konkretný príklad s premennými

je to zložitejšie než sa na prvý pohľad zdá. Nechce sa mi to to rozpisovať, radšej si to prečítaj z "prvej ruky" tu: http://en.allexperts.com/q/C-1040/Dynam ... -Names.htm

Neviem, co Ta nuti to robit cez premenne. Polia su stvorene prave na tento ucel, a ak sa nemylim, zaberaju menej pamate.

menej možno hej, ale súvislý blok. Ak tých hodnôt bude veľmi veľa, tak ti také veľké pole nedovolí vytvoriť, kým samostatné premenné to zvládnu (potom ale väčšinou potrebujeme nejak tie premenne evidovať aby sme ich mohli na konci zrušiť, preto sa využívajú vektory, listy a pod.)

Audiotrack: Ďakujem za link, hneď ho idem navštíviť.
Spoteny programator: Ako som hovoril, ide mi prevažne o princíp, presne ako pri mojom predchádzajúcom threade o c++ - t.j pýtam sa či to ide, nie že by som to musel potom zákonite využívať. Ale aj tak, príklad využitia: úloha bola vytvoriť 25 premenných s hodnotou faktoriálu neustále zvyšujúceho sa cisla, pričom program ktorý tieto premenné kontroloval je naschvál skonštruovaný tak, aby akceptoval len premenné vo formáte v1,v2, atď - tot k vyuzitiu.

audiotrack napísal:menej možno hej, ale súvislý blok. Ak tých hodnôt bude veľmi veľa, tak ti také veľké pole nedovolí vytvoriť, kým samostatné premenné to zvládnu (potom ale väčšinou potrebujeme nejak tie premenne evidovať aby sme ich mohli na konci zrušiť, preto sa využívajú vektory, listy a pod.)

audiotrack:
Viem ,ze to bude asi zaviste od mlion veci, ale ako velke suvisle bloky pamete je uz nebezpecne alokovat ?

Skyer:
Najednoduchsie reiesneje je asi pouzit iba mapu:
a popridavas prvky aj z nazvamy a mozes ich cez iterator vypisat, audiotrack-ove riesenie je tiez dobre

nie že nebezpečné, ale nemožné. A veľkosť závisí (v tomto prípade hlavne) od veľkosti stránky v RAM. Ak si ju predelíš veľkosťou dátového typu ktorý do toho poľa dávaš, tak zistíš maximálny počet prvkov ktoré môžeš v poli mať.

ale program samotny predsa so strankami nepracuje nie? operacny system priraduje programu pamat po strankach ale ta je z pohladu programu celistva a ak si program vypyta viac pamate OS mu priradi dalsiu stranku, ak teda ma nejaku volnu v tom pripade by som mal byt schopny vytvorit suvisle pole velkosti kolko potrebujem pripadne teda kolko pamate mam volnej. v realite v RAM to teda suvisle ulozene nebude ale to nemusi byt nikdy ani ked ma pole dva prvky- to si spravuje uz hardware. ale z pohladu programu pole suvisle bude nie? aspon teda tak nejak mi to bolo vysvetlene v skole a zda sa mi to ako celkom realne.

nie, nebude. Program keď chce pristúpiť napríklad k 5. prvku poľa kde máš ukladané int, tak sa pozre na nultý prvok ktorého adresu má, a pripočíta k adrese 5 * sizeof(int) aby našiel tvoj prvok. Práve preto musí byť tento blok fyzicky súvislí. Toto čo hovoríš platí pri dynamických poliach, vektoroch, mapách, listoch a iných neštruktúrovaných dátových typoch, kedy sú to samostatné premenné (porozhadzované po pamäti) a jedna má smerník na druhú aby boli "poprepájané" do štruktúri pripomínajúcej pole. Zaobalené do templatu ti potom poskytujú rovnaké metody aby si si myslel že je to rovnaké súvislé pole. Klasické pole ale potrebuje súvislý blok pamäte, a ak ho nemá, tak sa nemôže vytvoriť

inač, ten tvoj zidealizovaný model, ktorý prideluje pamäte "koľko máš volnej" tiež nie pravda ani pri tých iných dátových typoch, lebo je plno iných obmedzení. Napríklad pri 32 bitovej architektúre nemôžeš procesu prideliť viac ako 2G pamäte...

k tomu zidealizovaniu... to samozrejme viem- hovoril som v teoretickej rovine bez tych inych obmedzeni pretoze neboli dolezite v kontexte.

k tomu polu- adresovu aritmetiku viem nemaj ma za debila prosim, islo mi len o to ze podla toho co viem je RAM virtualizovana operacnym systemom- ma vlastne adresy odlisne od fyzickych, a on tu pamat prideluje dalej programom, ktore ich podla toho co viem dalej virtualizuju a maju zas svoje adresy. teda ak ma RAM nejaky svoj ramec nejakej velkosti a OS ma stranku rovnakej velkosti pricom prideli programu dve stranky ktore niesu vedla seba program by to videl ako jeden suvisly blok pamate velkosti dvoch stranok a teda by mohol vytvorit pole vacsie ako stranka pretoze on by na svoju adresovu aritmetiku pouzil svoje adresy pamate ktore su vedla seba.
takto som to videl ze by to mohlo byt ale nebol som si isty preto som sa spytal. podla toho co hovoris tam teda ta dalsia vrstva virtualizacie pamati- OS-> program nieje a teda program pracuje dalej s adresami OS. v tom pripade s tebou suhlasim. len som si chcel overit moju predstavu pripadne ju opravit.

Funguje to tak, že OS naozaj procesu pridelí pamäť, ktorá sa tvári ako súvislá (aj keď tie sektory fyzicky súvislé nie sú). Problém ale spôsobuje fragmentácia pamäte procesu a teda sa naozaj môže stať, že proces nebude mať dosť veľký súvislý blok pamäte, aj keď voľnej pamäte bude mať ešte dosť veľa.

dakujem za objasnenie, som rad ze si z minuleho semestru este nieco pamatam po prazdninach