Newsgroup: it.comp.lang.delphi
Titolo: Tipi record

Ciao a tutto il NG,
ho un problema un po particolare.
Per questioni pratiche ho creato un array di record in memoria di questo
tipo:
type
Tmiorec = record
    nome: string;
    anni: smallint;
    note: string;
end;
Tarraymiorec = array of Tmiorec;
La particolarità sta nel definire "nome" e "note" come tipo "string". E'
necessario che io definisca questi tipi come string perchè non posso
conoscere a priori quanto lungo è il nome e soprattutto quanto le "note".
Finchè gestisco tutto in memoria tutto OK ! I problemi nascono quando voglio
scrivere su file questi record.
Utilizzo TFileStream (ho provato anche con ReadFile, WriteFile,...ma sono la
stessa cosa) ma il "sizeof" del TmioRec non corrisponde all'esatta
dimensione.
Se definisco nome come string[40] va tutto bene! ma non è quello che mi
serve.
L'alternativa che ho trovato ora è scrivere gli elementi del record "uno ad
uno" sul file indicando prima la lunghezza !!!
Es.
var
    vString: string;
    vI: integer;
begin
    vI :=  length(nome);
    miofilestream.write(vI, sizeof(vI));
    miofilestream.write(miorec.nome, vI);
Ma la cosa mi piace poco visto che il Tmiorec è VERAMENTE lungo!!!!
Qualcuno ha qualche suggeririmento ?
grazie in anticipo
ciaoooo
Solid Snake IT
"Nemo mortalium omnibus horis sapit" (Plinio il VECCHIO)

conoscere a priori quanto lungo è il nome e soprattutto quanto le "note".
Scusa, ma perche' per le note non usi un TStringList ?
--
CyberWalkie - walkietalkie(at)
libero.it

 Ma la cosa mi piace poco visto che il Tmiorec è VERAMENTE lungo!!!!
e allora ?
Tu aggiungi due variabili al tuo record che indicano la lunghezza del nome e
delle note.
Essendo due Longint molto probabilmente, ti occupano 4 byte in memoria e
quindi su file, in questo modo avrai solo 8 byte in più su ogni record e
riuscirai a risolvere il tuo problema.
Volendo puoi usare anche due variabili tipo Word che ti occupano 4 byte in
totale.
 > Qualcuno ha qualche suggeririmento ?
quello che ti ho dato. Il problema non è tanto scrivere ma leggere.
Se tu scrivi 40 caratteri, come fa il tuo programma a sapere che deve
leggerne 40 se tu non glielo dici ?
Volendo puoi mettere caratteri particolari che separano i vari campi, ma
infine 4 byte non sono la fine del mondo !!
Oppure oppure.......i file di testo a chi li lasci !!
Ci hai pensato ? La strada è più spianata ma qualche carattere speciale lo
devi comunque mettere.
Ok, ora ti saluto.
Ciao ciao....
P.S. Se mi viene in mente un'altra idea ti faccio sapere.
Antonio Tarolla

uno" sul file indicando prima la lunghezza !!!
Usa ShortString, al posto di String.
Quello che io ti consiglio di fare e' di memorizzare in file di
testo esterni le note e collegarle al record mediante il nome del
file.  In pratica, il tuo record diventa :
type TMioRecord = record
                    Nome : ShortString ;
                    Anni : SmallInt ;
                    Note : TFileName ;
                  end ;
Questo metodo, ad esempio, e' usato con Paradox per salvare i
campi Memo (usati proprio per le note).
--
CyberWalkie - walkietalkie(at)
libero.it

 campi Memo (usati proprio per le note).
Si, in questo modo risolve in pieno.
Ma anche se formatta il suo record in una certa maniera,  puň gestire il
tutto in un file di testo unico.
Tanto il fatto che il file principale sia binario a lui non so quanto
importi. Non č certo una segretezza in piů perchč le stringhe vengono
salvate come tali mentre i numeri invece secondo una serie di byte che
dipendono dal tipo usato.
Comunque come decide sceglie bene !!
Ti saluto....ciao ciao !!
Antonio Tarolla

 Qualcuno ha qualche suggeririmento ?
Derivare MioRec da TPersistent fa orrore? (si avrebbe lo streaming 'a
gratis').
In alternativa, includi nel record un header che contenga la posizione
del record successivo (e/o precedente). Naturalmente se carichi ed editi
il primo record devi riscrivere tutto il file o marcare il record come
non valido e riscriverlo alla fine o qualcosa di simile. Ancora: usa un
db con campi memo e carica / scarica su quello.
Saluti
Paolo Arosio

In genere, nessuno a monte è in grado di sapere quanto un utente
scrive in un campo di un db.
Ricordo un vecchio prg che aveva il campo ragione sociale di 40
caratteri e chi lo usava bestemmiava xche era troppo corto.
A parte le note x le quali la tstringlist è il TOP, devi darti dei
presupposti su cui costruire la logica della tua applicazione.
Se nome e cognome sono veramente nome e cognome, credo che
difficilmente possano esistere nomi + lunghi di 40 caratteri e 
cognomi + lunghi di 60 caratteri, o no?
-- 
Posted from 
ammi.mclink.it
 [195.110.128.1] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ha scritto nel messaggio
news:9id220$smv$1...@lacerta.tiscalinet.it...


dipendono dal tipo usato.
Non credo sia questione di segretezza, quanto di natura dei
campi contenuti nel record.  Non tutti, difatti, potrebbero
essere rappresentati in forma testuale.
--
CyberWalkie - walkietalkie(at)
libero.it

grande!).
Ma a questo punto che motivo c'e' di inglobare tutto in un
unico file ? E' tanto + avvalorata la mia idea che sarebbe
meglio porre un puntatore (nome del file) ai dati contenuti
in un file esterno.
--
CyberWalkie - walkietalkie(at)
libero.it

La tua idea non è affatto male ma avrei un proliferare di file notevole.


 essere rappresentati in forma testuale.
invece mesà che sono entrambi i casi.
Ora mi sorge il dubbio: quali sono i dati che non posso essere rappresentati
in forma testuale ?


in forma testuale ?
Per es. le immagini o, comunque, il tipico contenuto dei
campi BLOB di un database.
--
CyberWalkie - walkietalkie(at)
libero.it

 campi BLOB di un database.
intendi dati in forma binaria !! Ma sei proprio sicuro ?
PGP ad esempio riesce a salvare dati generici in forma testuale. ( immagini,
file eseguili ecc ecc.....)
Ci hai pensato ?


Ciao,
vi consiglio di leggere il mio penultimo post (10/07/2000 - 10.02)
Cmq visto che avevo anche degli elementi tipizzati alla fine ho optato
scrivendo un elemento del record alla volta.
grazie
ciao


Potresti dare un'occhiata a XML. Un database può essere salvato facilmente 
in XML (che poi è un file di testo) in questo modo:
<clienti>
 <cliente>
   <id_cli>1001</id_cli>
   <nome>Mario</nome>
   <cognome>Rossi</cognome>
   <note>blablablablablablabla.....</note>
 </cliente>
 <cliente>
  ..
 </cliente>
  .
  .
</clienti>
Tieni conto che il salvataggio in XML ti apre la strada a infinite altre 
possibilità: visualizzare i dati all'interno di una pagina html con vari 
formati (griglia, lista), estrazione di dati/campi particolari, generazione 
di report in pdf/doc/xls, etc, etc, il tutto senza toccare il tuo file dei 
dati ma semplicemente lavorando con i file di schema.
Spero di aver capito il tuo problema
HTH
Mr Coke -- D&D Provider
-------------------------------
Message Posted by  <dedGateway>
http://www.dedonline.com/forump

 scrivendo un elemento del record alla volta.
insomma hai usato i file binari da come ho capito.
Non eri proprio obbligato.
L'idea di Mr Coke credo sia la migliore fra tutte anche se dipende da ciò
che veramente vuoi fare, ma visto che mi pare di aver letto che questo tuo
progetto evolve nel tempo, meglio fare delle solide basi invece di cambiar
lo standard tra poco tempo con tutti i problemi del caso.
Il file XML è comunque un file di testo che rispetta uno standard fisso.
Eventuali immagini o dati binari, ricorda che sono comunque memorizzabili in
un file di testo aperto in modalità TEXTFILE o con un TStringList, TMemo ecc
ecc...
Hai parlato di cifratura. Non hai però specificato dettagli aggiuntivi. E'
una cifratura fatta su due piedi oppure qualcosa di veramente sicuro al
giorno d'oggi ?
Riguardo il tuo esempio di memorizzare una unit in un file, questo è
possibile grazie ai file di testo. L'unit è comunque un file di testo. Non è
che Delphi ha nel suo codice sorgente un record dove rappresenta ogni
elemento dell'unit con il problema di saper quanto è lungo o meno.
Se poi ad esempio pensi a Word o lo stesso OutLook, questi mica allocano una
quantità fissa di memoria per contenere un documento o un messaggio perchè
non sanno quanto potrà essere lungo. Allora secondo questo ragionamento,
tutti i documenti avrebbero la stessa lunghezza in byte, cioè la massima
prevista da Word o OutLook !!
Invece usano un formato proprietario per rappresentare tutti i dati
contenuti nel documento o nel messaggio senza problemi di staticità.
In fin dei conti formattando il file di testo in una certa maniera, puoi
fare quello che ti pare e piace. L' XML, HTML ecc ecc.... in un file di
testo, sono una formattazione particolare ( secondo uno standard ) del testo
stesso.
Ok, ora ti saluto. Prima di iniziare ad usare a pieno ritmo il tuo
programma, pensa bene alle conseguenze di ogni scelta fatta visto che il
progetto evolve nel tempo !!
Ciao ciao...
Antonio Tarolla

 Qualcuno ha qualche suggeririmento ?
Potresti, usare una struttura di file tipo quella degli INI: in questo
modo ti eviti il problema di andare a marcare i record modificati come
non validi e riscriverli alla fine.
Se poi riesci a fare tutto su un file mappato in memoria (questa
potrebbe essere una bella FAQ, se c'e' qualcuno che vuole scriverla) e
limiti l'accesso a disco al caricamento iniziale e allo scaricamento
finale e' fatta.
Infine, se ti interessa limitare lo spazio su disco e non vuoi che le
info siano leggibili puoi semplicemente streamare su disco una versione
zippata.
Saluti
Paolo Arosio

 
http://www.dedonline.com/forump
Ma guarda chi si vede!!!! :=)
Ma i ragazzi di D&D vogliono colonizzare questo NG? ehehehehheheheheeh
Andrea Raimondi

Ci hai pensato ?
Anche la codifica che viene adottata dai mailer fa cosi', ma
l'occupazione di spazio del testo ottenuto e' maggiore
rispetto al formato "puro".
--
CyberWalkie - walkietalkie(at)
libero.it

 rispetto al formato "puro".
si, questo infatti č verissimo. Ho fatto una stupida prova con l'algoritmo
Base64 ed il risultato su un file ZIP di 21 Kb, ha riportato 6 Kb in piů sul
corrispondente file testuale. Bč...circa il 30% oltre le dimensioni
originali. Non proprio male.....peccato che se lo ricomprimo ristň come
prima !! eheheh
Ti saluto....ciao ciao
Antonio Tarolla

perfettamente che volendo si puņ.
Non capisco dove vuoi arrivare.
Tu dici :
"Ora mi sorge il dubbio: quali sono i dati che non posso
essere rappresentati in forma testuale ?"
Io ti rispondo :
"Per es. le immagini o, comunque, il tipico contenuto dei
campi BLOB di un database."
Tu dici :
"intendi dati in forma binaria !! Ma sei proprio sicuro ?"
Io ti rispondo :
"Certo" 
e tu mi dici che sotto sotto so che si puo' fare ma non lo
ammetto (ho capito bene ?).
E' chiaro che rappresentare dati in forma testuale si puo'
fare, qualsiasi tipo di dato si puo' rappresentare in modo
testuale.
Devi tener presente, tuttavia, che la forma testuale e' una
rappresentazione di una rappresentazione, in molti casi,
(vedi i numeri floating-point) ed aumenta l'imprecisione
della rappresentazione.
Quando dico che quei dati non "possono" essere rappresentati
in forma testuale, intendo che non e' corretto che siano
rappersentati in quel modo.
--
CyberWalkie - walkietalkie(at)
libero.it

 della rappresentazione.
quì non ho capito cosa vuoi dire.
Se io ad esempio converto un file binario ( contenente numeri floating-point
rappresentati uno ad uno con una sequenza di 4 byte ) in un file di testo
tramite l'algoritmo BASE 64, è ovvio ( spero che lo sia !! hehe ) che
l'operazione inversa mi restituisce lo stesso file binario di partenza.
Se non è così i floating point non centrano nulla, in fin dei conti a
livello binario sono solo byte e se l'algoritmo è fasullo lo è per ogni file
binario, altrimenti il risultante sarebbe semplicemente corrotto.
Tu infatti non vuoi dir questo, quindi chiedo spiegazioni !!
Ok, ti saluto.
Ciao ciao....
Antonio Tarolla