Newsgroup: it.hobby.elettronica.digitale
Titolo: Suggerimento per "contenitore" dati generico

Ciao,
 
sto rimaneggiando una mia libreria per integrare nei miei progetti la 
gestione di parametri e di valori da scambiare con le applicazioni a 
livello più alto.
 
In estrema sintesi si tratta banalmente di una struttura C che descrive 
il mio elemento e di alcune classi adatte a maneggiarlo.
 
Attualmente ho definito 4 tipi di dati fondamentali:
 
bool (1 bit)
int  (16 bit)
float (32 bit)
string (dimensione massima fissata)
 
con i quali riesco a gestire tutto quel che mi serve - al momento.
Immagino però che ci sia già qualcosa di fatto e fatto meglio di come 
l'ho implementato io :)
 
Stavo valutando l'ipotesi di ridurre i tipi di dati a uno solo: string. 
Poi a seconda dei casi vado a convertirlo come preferisco. Una specie di 
"tipizzazione a posteriori". A costo di un overhead in lettura e 
scrittura posso gestire virtualmente qualsiasi tipo di dato e aggiungere 
facilmente nuove funzionalità.
 
Attualmente utilizzo una union decidendo subito quale dato andrà 
inserito. Questo mi permette di gestire nativamente la variabile ma 
aggiungere un nuovo tipo di dato comporta una revisione profonda di 
tutta la libreria.
 
Commenti?
 
 
Grazie!
Marco
 

 Commenti?
 
Che intendo per parametri da scambiare con le applicazioni a livello più 
alto?

 alto?
 
 
Ad esempio, in un sistema di acquisizione potrei avere una funzione (o 
un processo nel caso di un sistema embedded) che si occupa di ricevere i 
dati al livello fisico (adc, seriale, ingress digitali, ecc...).
 
Poi mi serve il livello di presentazione: display, webserver, altra 
seriale, per mostrare i dati all'utente. Tipicamente si tratta di 
un'altra funzione o di un altro processo.
 
Di solito il primo riempie la struttura dati e il secondo attinge da 
essa. In questo modo posso apportare facilmente modifiche ai vari 
livelli senza dover rimaneggiare l'intero software.
 
Marco
 
 

 
 > Di solito il primo riempie la struttura dati e il secondo attinge da
 
xml
 
Giuia
 

 xml
 
 
Che c'azzecca? :)
L'xml è un modo per memorizzare i dati, e presuppone per lo meno 
l'utilizzo di un file-system.
 
Ciao!
Marco
 
 

 e presuppone per lo meno l'utilizzo di un file-system.
 
Perchè?
 
 

 Perchè?
 
 
Non riesco a immaginare l'utilità di avere in RAM un documento xml e 
neppure vedo come possa risolvere i miei dubbi iniziali. Se Giulia fosse 
un po' meno criptica... :)
 
Infine, sempre relativamente alla mia esperienza un file xml viene letto 
ed eventualmente i dati in esso contenuti vengono utilizzati per 
popolare una struttura in memoria. Quindi torniamo al punto di partenza.
 
Ciao!
Marco
 
 

 popolare una struttura in memoria. Quindi torniamo al punto di partenza.
 
Non so se XML va bene nel tuo caso, anche perchè mi sembra troppo 
complesso in molte architetture embedded.
 
Però l'idea non mi sembra proprio malsana.  La libreria che gestisce XML 
(in creazione e ricezione) la scrivi una volta sola ed automaticamente 
ti genera in RAM, a seconda dell'implementazione, una struttura dati che 
puoi leggere e che rispecchierà i dati che vuoi inviare/ricevere.  Il 
cambio dei parametri (in numero, tipo, ecc) non dovrebbe avvenire a 
livello di libreria.
 
Potrebbero risultarti utili tutti i meccanismi di serializzazione, tra 
cui quello che mi ispira molto fiducia è il Protobuf di Google.