[C] sizeof, size di variabili e struct

[LordSaga640]

Salve,

sto facendo un progettino per un esame all'università.

Ho la necessità di creare strutture compatte contenente alcuni dati. Ho lo spazio molto limitato quindi sono costretto a risparmiare di molto. Anche un byte è significativo.

mi spiegate perchè sizeof(long)=4 sizeof(short)=2 sizeof(__int16)=2 sizeof(int)=4
ma:
struct FDATA { // 12 byte
long GAMEID; // 4 byte
short BLOCCOID; //2bute
unsigned int DATA_CREAZIONE; // 4byte
unsigned __int16 DIM; // 2 byte
};

sizeof(struct FDATA)=16?

Ho la necessità che la struttura non superi i 14byte!
Grazie in anticipo

[oregon]

Il compilatore, per questione di efficienza, non allinea le strutture al byte per default e quindi aggiunge byte 'dummy' per tale motivo ...

Questo comportamento puo' essere modificato ... quale compilatore usi?

[LordSaga640]

Originariamente inviato da oregon
Il compilatore, per questione di efficienza, non allinea le strutture al byte per default e quindi aggiunge byte 'dummy' per tale motivo ...

Questo comportamento puo' essere modificato ... quale compilatore usi?

Ciao!
Grazie mille per la risposta!

Uso dev cpp 4.9.9.2 su vista a 64 bit.

[oregon]

Prima di dichiarare la struttura scrivi

#pragma pack(1)

[LordSaga640]

Ciao, scusa la cuoriosità, ma cosa significa?
Sai, qualche volta il prof mi chiedesse cosa significa.

Cmq provo a cercare un su google, anche se non ho mai visto nulla del genere (forse non me lo ricordo).
Grazie mille, ora provo^^

EDIT:
Funziona :°°°D, grazie mille.

Ho trovato anche tutte le spiegazioni di pragma! Yo!

[XWolverineX]

puoi passare il link anche a me?

[ntd]

Originariamente inviato da LordSaga640
Salve,

sto facendo un progettino per un esame all'università.

Ho la necessità di creare strutture compatte contenente alcuni dati. Ho lo spazio molto limitato quindi sono costretto a risparmiare di molto. Anche un byte è significativo.

mi spiegate perchè sizeof(long)=4 sizeof(short)=2 sizeof(__int16)=2 sizeof(int)=4
ma:
struct FDATA { // 12 byte
long GAMEID; // 4 byte
short BLOCCOID; //2bute
unsigned int DATA_CREAZIONE; // 4byte
unsigned __int16 DIM; // 2 byte
};

sizeof(struct FDATA)=16?

Ho la necessità che la struttura non superi i 14byte!
Grazie in anticipo

Per risolvere il tuo problema era sufficiente cambiare d'ordine i termini della struttura.

struct FDATA {
       long GAMEID;
       unsigned int DATA_CREAZIONE; // 4byte
       short BLOCCOID;
       unsigned __int16 DIM;
};

PS: il codice che hai postato creerà non pochi problemi su architetture a 64bit. Se vuoi evitare futuri mal di testa definisci esplicitamente tutte le dimensioni dei campi della struttura. La seguente struttura è compatibile con la tua ma funziona anche a se compilata a 64 bit:

struct FDATA
{
  int32_t GAMEID;
  uint32_t DATA_CREAZIONE;
  int16_t BLOCCOID;
  uint16_t DIM;
};

[oregon]

Originariamente inviato da ntd
Per risolvere il tuo problema era sufficiente cambiare d'ordine i termini della struttura.

Concordo ma non sempre e' possibile operare in questo modo e la cosa migliore e' sapere perche' il fatto si verifica e qual e' la soluzione "generale" ...

PS: il codice che hai postato creerà non pochi problemi su architetture a 64bit.

Anche in questo concordo, a patto pero' che il progetto avra' una possibilita' di essere "portato" a 64 bit ...

[LordSaga640]

la pagine è questa
http://docs.hp.com/en/8/pragmas.htm

Sfortunatamente i tipo non li ho scelti io.
http://margot.di.unipi.it/mediawiki/...S07-1-base.pdf

Sul portatile ho vista 32bit e il tipo long è 6byte. Su vista64, stesso compilatore (!!) è diventato magicamente 4 byte.

Per il progetto ho usato 4 pagine da 512 per inserire tutte le informazioni per gestire il file system. Il resto li uso per i dati dei giochi.
Non so il prof con che sistema farà girare il programma, speriamo bene.

Grazie mille ancora.

ps: cambio l'ordine^^

[oregon]

Originariamente inviato da LordSaga640
Sul portatile ho vista 32bit e il tipo long è 6 byte.

Che ???

Ti stai sbagliando ...

ps: cambio l'ordine^^

Fai attenzione ... eventuali modifiche potrebbero riportare il problema ... con il pragma non succede ...