Il peso dei record

[sanric]

Salve a tutti, è la prima volta che vi chiedo qualcosa ma sono molto "niubbo" e non riesco a venirne fuori da questa semplice cosa. 
Se scrivo il seguente programma...

Codice: [Seleziona]

program unRecord;
uses SysUtils;

type
  iMieiDati = record
    nome:string;   //8 bytes
    cognome:string;   //8 bytes
    dataDiNascita:TDateTime; // 8 bytes
    case vivente:Boolean of //1 byte
      True: (residenza:string[20]);  //20 bytes
      False: (dataDecesso:TDateTime); //8 bytes
  end;

var
  imperatore:iMieiDati;

begin
  with imperatore do
    begin
      nome:='Napoleone';
      cognome:='Bonaparte';
      dataDiNascita:=EncodeDate(1769,8,15);
      vivente:=False;
      dataDecesso:=EncodeDate(1821,5,5);
    end;

  WriteLn('Il record pesa ',sizeof(imperatore),' bytes.');
end.

e lo eseguo, nel mio sistema a 64 bit, risulta che:

Codice: [Seleziona]

Il record pesa 56 bytes.

Ora, accanto ad ogni singola variabile, ho segnato in commento il valore che di essa mi viene fornito tramite il comando sizeof().
Da qui la domanda: perché il valore usato nell'esempio è 56 e non 33?
Non ho usato tutti i campi ma mi pare che vengano allocati lo stesso da FPC: ad esempio la variabile residenza viene allocata lo stesso anche nel caso in cui il case... of si riveli falso.
Se volessi essere sicuro che il compilatore non vada ad usare più memoria del necessario, come posso fare?

Beh, mi sembra che come primo approccio ci sia abbastanza carne al fuoco.
Grazie mille a tutti per le gentili risposte.

PS: ho fatto la stessa domanda sia a Bard che a ChatGPT. Ne è risultato che i limiti di quelle tecnologie sono davvero tanti.
Tanto per dire, Bard è rimandato a settembre in matematica dal momento che è convinto che

Codice: [Seleziona]

Pertanto, la dimensione totale del record è 4 + 4 + 8 + 20 + 8 = 56 byte.

 

[DragoRosso]

Ciao, quello che dici è vero se prima di "record" ci aggiungi la parolina "packed" ...

Tutte le strutture vengono riempite con dei "pad" cioè del byte nulli (a zero) per allineare i dati.
Questo operazione consente di ottimizzare il codice compilato ed è praticamente obbligatorio per avere un codice veloce.

Se è presente "packed" allora il compilatore non inserirà alcun "pad" e il record verrà gestito in maniera integrale.

[OT]
Il modo di riempimento (cioè la posizione dei pad) non può essere previsto in maniera assoluta, anche se ci sono delle regole, e ciò fà si che l'uso dei PUNTATORI E DELLA LORO MATEMATICA per l'accesso generico al record può generare inconvenienti difficili da prevedere e da diagnosticare.

Questo è uno dei motivi per cui "odio" l'uso dei puntatori espliciti con le variabili.

Ciao

[DragoRosso]

Il record pesa 56 bytes.
PS: ho fatto la stessa domanda sia a Bard che a ChatGPT. Ne è risultato che i limiti di quelle tecnologie sono davvero tanti.
Tanto per dire, Bard è rimandato a settembre in matematica dal momento che è convinto che

Codice: [Seleziona]

Pertanto, la dimensione totale del record è 4 + 4 + 8 + 20 + 8 = 56 byte.

 

Bard (ma il suo compare non è da meno) è l'esempio tipico della AI: ciò che riportano magari è anche giusto, ma non si sà il perchè .... 

[sanric]

Ciao, quello che dici è vero se prima di "record" ci aggiungi la parolina "packed" ...

Tutte le strutture vengono riempite con dei "pad" cioè del byte nulli (a zero) per allineare i dati.
[cut]

Grazie mille DragoRosso per la gentile risposta.
Quindi non è del tutto vero che le variabili che fanno parte della "variant part" (così vengono definite nell'Object Pascal Language Guide di Borland) non sono allocate preventivamente. O sbaglio?

[DragoRosso]

Le parti "variant" dei record sono allocate preventivamente sulla lunghezza più lunga dei campi interessati, in realtà ci pensa il compilatore.

I record hanno sempre lunghezza fissa, perchè le definizioni che hanno lunghezza variabile (ad esempio una "string") vengono allocate come puntatore. La "lunghezza" di un record non cambia durante la vita dello stesso.

Per inserire i "pad", il compilatore si basa sull'allineamento predefinito (in un 64 bit l'allineamento è a 64 bit, ossia quad word o 8 byte) o l'allineamento in essere in quella parte di codice.

Quindi, supponiamo che l'allineamento predefinito non venga modificato allora qualsiasi variabile (campo) di un record viene allineato a quella lunghezza o suoi multipli inserendo dei byte a zero. Questo in generale. Ogni compilatore può usare una propria tecnica per il riempimento.

Ciao

[sanric]

Approfitto della vostra gentilezza per comprendere qualcosa che davvero mi sfugge e cioè: perché le "variant parts" di una struttura record, pur avendo un'istruzione condizionale al proprio interno, non la rispettano?
Faccio un piccolo esempio qui sotto:

Codice: [Seleziona]

program variantPart;

type
  TPersona = record
    nome:string;
    cognome:string;
    dataDiNascita:TDateTime;
    case vivente:Boolean of
      True: (residenza:string[20]);
      False: (dataDecesso:TDateTime);
  end;

var
  imperatore:TPersona;

begin
  with imperatore do
  begin
    nome:='Napoleone';
    cognome:='Bonaparte';
    vivente:=False;
    residenza:='Parigi';  \\ <----
  end;
  WriteLn(imperatore.nome,' ',imperatore.cognome);
  WriteLn('Residenza: ',imperatore.residenza);
end. 

In teoria, essendo per l'appunto Napoleone morto da un bel pezzo, la variabile residenza non dovrebbe essere contemplata ed il compilatore avrebbe dovuto darmi un bel messaggio d'errore.
Invece tutto fila liscio come l'olio con il seguente output:

Codice: [Seleziona]

Napoleone Bonaparte
Residenza: Parigi

Logicamente mi sembra che la cosa non torni: dove mi sto sbagliando?

[nomorelogic]

ciao sanric

il fatto è che la parti varianti del record, condividono la memoria e questo è il motivo per cui sono stati implementati.
Questo in modo da permettere di vedere quella parte di memoria come un campo unico oppure come più campi.

Sta a chi codifica utilizzare il record variante in modo congruo.
Nel tuo caso tramite una "if" potresti decidere quale variante utilizzare.

Leggi qua per maggiori spiegazioni.
https://wiki.freepascal.org/Record#Variable_structure

[DragoRosso]

Per completare quanto detto da @nomorelogic, la memoria condivisa (che come ti accennavo è lunga quanto la lunghezza massima del campo più lungo + eventuali pad) è diciamo in formato raw. Cosa significa ?

Significa che inserendo una stringa nel campo residenza o un data nel campo datadecesso ciò che "leggerai" usando entrambe le variabili sarà congruo solo ed esclusivamente se leggerai il campo corretto.

Se inserisci una data (il cui formato interno è un double) tale valore potrà essere riletto correttamente solo se accederai al dato "datadecesso", idem per la residenza. E fai attenzione che leggendo ad esempio la "datadecesso" avendo inserito come ultimo dato una stringa in "residenza" potrebbe provocare una eccezione (perchè un double ha una rappresentazione ben precisa e quindi potrebbe essere generato un NAN ... "not a number").

Nel tuo esempio hai inserito il valore "Parigi" come residenza, prova e leggere il campo "datadecesso" e vedi cosa ti riporta ...

Ciao

[sanric]

Nel tuo esempio hai inserito il valore "Parigi" come residenza, prova e leggere il campo "datadecesso" e vedi cosa ti riporta ...

Ho fatto la prova: FPC mi ha restituito il valore "30/12/99", quasi fosse una sorta di valore di default.
Mah, forse chi ha costruito FPC ha ascoltato molto Prince! 

[DragoRosso]

Ho fatto la prova: FPC mi ha restituito il valore "30/12/99", quasi fosse una sorta di valore di default.
Mah, forse chi ha costruito FPC ha ascoltato molto Prince! 

  In realtà quella è la rappresentazione in formato datetime della stringa che hai inserito (non ho notizia che 30/12/99 sia un qualche default).

Giusto per dire che con le parti variant dei dati occorre fare molta attenzione. Io in genere preferisco inserire un campo che definisce il tipo di dato rappresentato in un altro campo (anche variant, anche se non mi piace molto) in modo che sia inequivocabile la cosa, e con l'accesso protetto sia in lettura che in scrittura tale per cui l'errore è pressochè impossibile.

Ti posto appena possibile un esempio di codice.

Ciao

[sanric]

Ti posto appena possibile un esempio di codice.

Grazie mille, sono in debito!

[nomorelogic]

Ho fatto la prova: FPC mi ha restituito il valore "30/12/99", quasi fosse una sorta di valore di default.
Mah, forse chi ha costruito FPC ha ascoltato molto Prince! 

  In realtà quella è la rappresentazione in formato datetime della stringa che hai inserito (non ho notizia che 30/12/99 sia un qualche default).

30/12/99 in effetti suona strano
me se fosse 30/12/1899 (e probabilmente lo è) allora sarebbe un valore per rappresentare una data zero
potrebbe essere che, non essendo presente nell'area di memoria, una data valida, venga restituito 30/12/1899


Edit:
potresti verificare la data esatta formattando tipo "yyyy-mm-dd"?

[sanric]

potresti verificare la data esatta formattando tipo "yyyy-mm-dd"?

Ok, ho fatto la prova usando questo codice (più che altro un recap se qualche niubbo come me si fosse perso nel frattempo):

Codice: [Seleziona]

program variantPart;

uses
  SysUtils, DateUtils;

type
  TPersona = record
    nome:string;
    cognome:string;
    dataDiNascita:TDateTime;
    case vivente:Boolean of
      True: (residenza:string[20]);
      False: (dataDecesso:TDateTime);
  end;

var
  imperatore:TPersona;

begin
  with imperatore do
  begin
    nome:='Napoleone';
    cognome:='Bonaparte';
    vivente:=False;
    residenza:='Parigi';  // <----
    WriteLn(nome,' ',cognome);
    WriteLn('Residenza: ',residenza);
    WriteLn(FormatDateTime('yyyy-mm-dd',dataDecesso));
  end;
end. 

Il risultato è codesto (e avevi ragione tu):

Codice: [Seleziona]

Napoleone Bonaparte
Residenza: Parigi
1899-12-30

Come sospettato, sembra essere un valore di default per indicare una data "0", in modo da non incappare nel rischio ipotizzato da DragoRosso di un NaN.
Se così fosse mi sembrerebbe una mossa intelligente.

[nomorelogic]

essendo così, quella data del 1899 la puoi usare come costante per verificare se è presente un valore oppure no

[sanric]

Certo, sapendolo posso gestire la cosa abbastanza comodamente con un ciclo if.. then.

Tuttavia, anche se ho compreso le spiegazioni fornite, trovo il fatto di allocare lo stesso la memoria per le variabili comprese in una variant-part un po' fuorviante.
Se non fossero allocate sarebbe più logico e semplice poter effettuare un controllo in fase di parsing del codice, evitando errori.
Inoltre, se il padding è il vero problema, non comprendo perché non poter utilizzare anche nelle variant-part dei puntatori "mascherati" (ad es. string al posto di string[xxx]).

Vabbé, mi fermo qui altrimenti la cosa diventa pesante e non so quanto interessante per gli altri utenti del forum.