[C] Come funziona l'Heap?

[ramy89]

Aspettate,scusate se non apro un altro thread,ma visto che siamo in tema:

Originariamente inviato da ramy89
Ma in generale c'è un modo per sapere il compilatore dove mette le variabili?

Ma allora c'è un legame tra la quantità di ram che hai e la dimensione di puntatori?
Io ho 4 gb di ram,ma se sulla mia macchina i puntatori sono di 32 bit come fa un puntatore a tenere traccia di tutta la ram?
Ci vorrebbero puntatori lunghi 8 byte se non sbaglio i conti.

Sapreste rispondere a queste domande?
Se poi mi dite di aprire un altro thread lo faccio,ma mi sembra in tema.

[deleted_29]

Originariamente inviato da ramy89
Comunque a me non ha mai riportato un segmentation fault sull' heap,non ho mai visto la parola heap scritta tra gli errori del debugger.

E' semplice, perchè l'" heap"... non esiste in un computer.
E' solo "un modo di dire": esistono solo gli indirizzi (ormai da un decennio solo virtuali)

Comunque un' altra domanda che avevo: ho fatto un piccolo conto,2^32 è all' incirca lo spazio di indirizzamento che serve a memorizzare puntatori di 32 bit

Non è "all'incirca", è "esattamente"

,e sul mio widnows 7 a 64 bit i puntatori hanno sempre 4 byte cioè 32 bit di dimensione,eppure la mia macchina è a 64 bit.

Assolutamente NO

Ma allora c'è un legame tra la quantità di ram che hai e la dimensione di puntatori?

In realtà... molto più complessa di quella che stai pensando , soprattutto nel mondo segmentato x86

Io ho 4 gb di ram,ma se sulla mia macchina i puntatori sono di 32 bit come fa un puntatore a tenere traccia di tutta la ram?
Ci vorrebbero puntatori lunghi 8 byte se non sbaglio i conti.

Non sbagli affatto.

Ma il discorso è mooolto più complicato, e nel caso di macchine x86 ancora di più, per ragioni "storiche".
Adesso non vorrei spiegare quali sono i modi di indirizzamento 8086, poi quelli 80286, quelli 80386 (rimasti praticamente fino a "ieri") e quelli a 64 bit.

Nè come funzioni windows a 64 bit.
---
Vabbè in versione supermegacompressa (a costo di perdere in precisione, ma pazienza) i puntatori sono "davvero" da 32 bit (4 byte) e consentono di indirizzare "davvero" fino a 4GB di memoria.
Su Windows "normalmente" la dimensione massima del chunk è 2GB per... non lo dico, vabbè cambia poco.

Questo significa che un programma windows a 32 bit può allocare un vettore di fino a 2GB (4GB in certi casi), ma non di 6GB ad esempio, anche se la macchina fisica li ha disponibili (veri o virtuali che siano)
---
Siccome i 64 bit sono "un sovrainsieme compatibile all'indietro" coi 32, quando usi programmi a 32bit sfrutti solo metà della capacità dei registri della CPU (4 byte anzichè 8). Attenzione anche qui ci sarebbero 10000000 cose da dire, che non dico.
---
Per indirizzare PIU' di 2^32 (4GB) in un singolo vettore ti serve un programma a 64 bit, ove i puntatori sono da 64 bit (=8byte) e dove puoi indirizzare (in teoria) 2^64. In teoria perchè... blablabla.

Quindi programma-a-32-bit-su-windows-64-bit==programma-a-32-bit-su-windows-32-bit [per banalizzare]
---
Chi è curioso può facilmente cercare dettagli sul meccanismo "occulto" di segmentazione (e paginazione) dei processori intel, che è davvero complicato in quanto deve rimanere "compatibile" all'indietro con processori di 25 anni fa che potevano indirizzare direttamente 64K di memoria, e con "truccchi vari"... ben 1MB in tutto
Si sono aggiunti "strati su strati", sempre più complessi, per far sì che oggi una macchina a 64bit possa eseguire anche il DOS in modalità reale, partendo da un floppy, come fosse davvero una macchina di 25 anni fa

[deleted_29]

Originariamente inviato da ramy89
Sapreste rispondere a queste domande?
Se poi mi dite di aprire un altro thread lo faccio,ma mi sembra in tema.

bhè sono ottimista, ho scritto compilatori e sistemi operativi per parecchi anni

[alka]

Originariamente inviato da ramy89
Sapreste rispondere a queste domande?
Se poi mi dite di aprire un altro thread lo faccio,ma mi sembra in tema.

Piuttosto che chiedere queste cose a ruota libera sul forum, non sarebbe meglio farsi una ricerca o comprarsi un libro e leggersele?

Siamo off topic già dall'inizio, non andiamoci ancora di più...

[ramy89]

Bhe ma non c'è l' occasione di sentirsi spiegare tutto in un modo così riassuntivo da uno così:

Originariamente inviato da franzauker
bhè sono ottimista, ho scritto compilatori e sistemi operativi per parecchi anni

Comunque adesso ho risolto,scusate il disturbo

[Paulin]

Originariamente inviato da Laikius91 ... se una funzione mi deve ritornare una stringa creata all'interno della funzione, questa non può essere stata allocata normalmente, con
char stringa [10];
ma occorre averla allocata ad esempio con:
char* stringa;
stringa = (char*) malloc (sizeof (char) * 10);
A livello pratico/teorico come si spiega questa cosa?

A leggere così sembra che la risposta che cerchi non sia tanto come funziona l'heap, ma il perché una variabile debba essere allocata sull'heap.

In realtà la stringa char* stringa;
allocata come stringa = (char*) malloc (sizeof (char) * 10);
potrebbe benissimo essere allocata come char stringa [10];
Nel primo caso andrà a finire nel Private Heap del processo, nel secondo caso andrà a finire comunemente nel data segment, ma nulla cambia (a parte il fatto che l'accesso all'heap è leggermente più lento) dal momento che tu hai specificato il numero di caratteri a compile time e verrà comunque riservando uno spazio di 10 bytes.

Il motivo per cui si ricorre all'allocazione sull'heap è che l'heap è "growable", ovvero può accrescere a seconda della necessità del processo. Così una allocazione del tipo:

stringa = (char*) malloc (sizeof (char) * numOfChars);

potrà richiedere al sistema uno spazio di memoria extra (rispetto ai segmenti di dimensione fissa dell'immaggine dell'applicativo in memoria) che sarà determinato soltanto quando l'applicativo sarà in esecuzione, ovvero quando la variabile numOfChars riceverà il suo valore. Per questo motivo la memoria allocata dinamicamente non è detto che sia sistemata su uno spazio contiguo, è verosimilmente più facile che sia distribuita in diversi frammenti. Quando il processo avrà liberato la memoria richiesta con free(stringa) questa quantità di memoria ritornerà al sistema. Per questo è importante ricordarsi di liberare prima di perdere il puntatore.

[Laikius91]

Originariamente inviato da Paulin
A leggere così sembra che la risposta che cerchi non sia tanto come funziona l'heap, ma il perché una variabile debba essere allocata sull'heap.

In realtà la stringa char* stringa;
allocata come stringa = (char*) malloc (sizeof (char) * 10);
potrebbe benissimo essere allocata come char stringa [10];
Nel primo caso andrà a finire nel Private Heap del processo, nel secondo caso andrà a finire comunemente nel data segment, ma nulla cambia (a parte il fatto che l'accesso all'heap è leggermente più lento) dal momento che tu hai specificato il numero di caratteri a compile time e verrà comunque riservando uno spazio di 10 bytes.

Il motivo per cui si ricorre all'allocazione sull'heap è che l'heap è "growable", ovvero può accrescere a seconda della necessità del processo. Così una allocazione del tipo:

stringa = (char*) malloc (sizeof (char) * numOfChars);

potrà richiedere al sistema uno spazio di memoria extra (rispetto ai segmenti di dimensione fissa dell'immaggine dell'applicativo in memoria) che sarà determinato soltanto quando l'applicativo sarà in esecuzione, ovvero quando la variabile numOfChars riceverà il suo valore. Per questo motivo la memoria allocata dinamicamente non è detto che sia sistemata su uno spazio contiguo, è verosimilmente più facile che sia distribuita in diversi frammenti. Quando il processo avrà liberato la memoria richiesta con free(stringa) questa quantità di memoria ritornerà al sistema. Per questo è importante ricordarsi di liberare prima di perdere il puntatore.

Tutto chiaro grazie mille davvero!
Quello che comunque non avevo subito capito era perchè una stringa allocata normalmente avevo tempo di vita pari a quello della sua funzione e quindi non poteva essere ritornata (poichè variabile locale!), mentre una stringa allocata "pseudo-dinamicamente" (passami il termine) aveva tempo di vita indipendente dalla funzione che la creava e pertanto poteva essere il valore di ritorno della funzione stessa.
Ora ho chiarito davvero tutto, grazie ancora!