Newsgroup: it.comp.lang.c
Titolo: Strutture: 3 + 4 = 8 ????

Salve a tutti!
Ho un grosso problema con le strutture che mi sta facendo letteralmente
impazzire.
Come è possibile che creando una struttura composta da 3 variabili char e 2
short int, andando a calcolarne la lunghezza in byte con sizeof mi dia 8 ??
Non dovrebbe essere 7 ?
Il problema mi si presenta sempre con le strutture che contengono tipi
differenti di variabili e non quando sono tutte uguali.
Grazie a che vorra aiutarmi.
Saluti, Lorenzo
gu...@ba.dada.it
\\ Se hai 1 minuto visita il mio sito!
http://www.geocities.com/TimesSquare/Hangar/1638/

...


In genere i compilatori per cpu x86 portano la lunghezza totale ad un
multiplo di 2 o addirittura portano la lunghezza di ogni singolo membro ad
un multiplo di 2 perche' l'accesso e' piu' veloce. C'e' uno switch dei
compilatori che permette di eliminare questo comportamento (/Zp mi sembra
sul compilatore Microsoft).
Antonio Donatiello
Ruggiero&Lorenzo Guida ha scritto nel messaggio


Non dovrebbe essere 7 ?
No, non dovrebbe necessariamente essere 7; il compilatore puo`
scegliere quale "padding" (letteralmente, "imbottitura") usare per
garantire un buon compromesso fra risparmio di memoria e
velocita` di accesso.
Su molte CPU, ad esempio, uno short int *deve* risiedere ad un
indirizzo PARI.  Immaginati dunque un array di strutture come
quelle che hai descritto: poiche` il sizeof di un array di N di esse
DEVE, per legge del linguaggio, essere N*sizeof di 1 di esse,
se una struct avesse un sizeof dispari, allora sarebbe del tutto
impossibile tenerle tutte "ben allineate", cosi` che gli short siano
tutti ad indirizzi pari.
Su altre CPU, come tutte le moderne Intel e compatibili, PUOI, se
vuoi, accedere a dati "disallineati" -- ma un simile accesso e`
capacissimo di costarti rallentamenti del 100% o anche di piu`!
Quindi, anche in questi casi, l'approccio normale per il tuo
compilatore sara` quello di includere un po' di imbottitura.
Se non ti importa niente di rallentare come una lumaca, ma e`
invece cruciale risparmiare ogni bit, molti compilatori ti offrono
il modo (non-portabile) di dirglielo: ad esempio, #pragma pack
nei compilatori Microsoft.
Se vuoi un modo portabile, devi invece farti tu stesso la
dovuta aritmetica di indirizzi e accedere ai dati sempre
tramite memcpy e simili funzioni di bassissimo livello; e`
infatti questo (usare la memoria come "stringa di byte")
l'unico modo garantito (a prezzo di feroci penalita` di tempo
d'accesso, naturalmente) di avere il pieno controllo sul
layout delle tue strutture in memoria.
Alex

 
http://www.geocities.com/TimesSquare/Hangar/1638/
La ragione e' spiegata chiaramente nel Kernighem & Ritchie Ed.2 inglese p.138
: "Don't assume that the size of a structure is the sum of the size of its
member. Because of alignment requirememnts for different objects, there may
be unnamed "holes" in a structure". Cio' significa che un oggetto di un
particolare tipo e' allocato con un indirizzo in memoria (il suo puntatore)
che e' multiplo di un certo numero. In una implementazione con sizeof(char) =
1 (sempre), sizeof(short)=2, sizeof(long)=4. I puntatori di solito saranno
rispettivamente multipli di 1, 2, 4. Una struttura, di solito, avra' le
richieste di allineamento dettate dai suoi membri. Cioe' se una struttura ha
un char e un long e' probabile che abbisogni 8 byte per allocare entrambi con
l'allineamento appropriato. Tutto cio' e' fortemente dipendente
dall'implementazione e nessun programa che richieda un minimo di portabilita'
puo' dipendere dalle richieste di allineamento. Anche per una data
implementazione, a meno che una precisa descrizione non sia disponibile nella
documentazione, e' rischioso fare assunzioni su cio' basate sul buon senso.
Ciao Paolo
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/
       Search, Read, Discuss, or Start Your Own    

...
