Array di parametri non omogenei
Guglielmo Calligaro
Un parametro puo' essere di tipo long, double o std::wstring, ma non
escludo che in futuro possa crescere.
Pensavo di definire questi parametri tramite una classe template tipo:
template <class T> class CParameterT
{
// Unique parameter's code
long m_lcode;
// Parameter's data
T m_data;
public:
CParameterT(long lcode , T val) : m_lcode(lcode) , m_data(val) {};
virtual ~CParameterT(void) {};
T GetValue(void) { return m_data ;}
};
Ma come lo organizzo un array di queste classi?
Esiste una soluzione riconducibile a qualcosa tipo
std::vector<CParameterT> (che ovviamente non funziona)?
Max M.
> Ma come lo organizzo un array di queste classi?
> Esiste una soluzione riconducibile a qualcosa tipo
> std::vector<CParameterT> (che ovviamente non funziona)?
Prima di reinventare la ruota, ti consiglierei di valutare se Boost.Any
soddisfa le tue necessit�.
http://www.boost.org/doc/libs/1_40_0/doc/html/any.html
Max
Guglielmo Calligaro
Si, grazie Max.
Soviet_Mario
elegante suggerita da Max Edgar.
Due aspetti del problema sarebbero da chiarire meglio
1) se defi conoscere a RUN time il tipo (suppongo di si)
2) se puoi permetterti una protezione soft sugli oggetti, ad
esempio con la constness dei puntatori, o se richiedi la
copia fisica hardware dei dati passati.
In questo secondo caso, temo che la sola soluzione,
ingombrante, sia quella della union (unita ad un type-field
...). O, più elegantemente, dalla creazione di una classe
che erediti da tutti i tipi necessari, e sia virtuale (il
che equivale al type field ma il tutto è delegato al
compilatore, quindi più sicuro e più efficiente).
Nel mio piccolo questioni non molto diverse le affrontai,
non sempre in modo soddisfacente, tramite arrays di
puntatori, quindi gli oggetti non erano mai allocati per
eccesso, e negli argomenti di chiamata compilavo un arrai di
soli puntatori. Poi vabbè, io sono patologico e gestivo a
mano i type fields (in effetti era una classe d'appoggio
contenente un puntatore ed un type field).
E' vero che l'array di per sé stesso spreca spazio (ma
consente di allocare i singoli oggetti sparsi e ciascuno
della taglia minima del suo contenuto effettivo) -> tutto
ciò è catastrofico se non riconosci correttamente l'oggetto
ovviamente. L'array di unions invece alloca tutto per
eccesso, ma non richiede un array di puntatori addizionali.
Ha senso se gli oggetti sono di dimensioni non tanto diverse
tra loro. Il primo caso ha senso se esistono alcune classi
di oggetti molto ingombranti, e la union farebbe sprecare
molto (anche tempo di ricopiatura)
ciao
Soviet
Guglielmo Calligaro
> piￜ sicuro e piￜ efficiente).
Effettivamente io ero proprio partito ragionando come te e avevo messo
su una cosa di questo tipo :
class CParameter
{
// Union for parameter's data
typedef union _tdata
{
long l;
double d;
std::wstring *c;
_tdata(void) { d = 0 ;}
} tdata;
// Unique parameter's code
long m_lcode;
// Enum for data type
enum _ttype {
paramlong,
paramdouble,
paramstring
} m_etype;
// Internal data
tdata m_udata;
public:
CParameter(long lcode, long lval);
CParameter(long lcode, double dval);
CParameter(long lcode, const wchar_t *cval);
virtual ~CParameter(void);
const tdata * GetValue( void );
etc...
};
Ho cominciato a pensare ai template quando ho voluto implementare tutti
gli operatori che sicuramente mi sarebbero potuti servire ( = > < != .
Un conto e' scrivere Param1.GetValue()->d > Param2.GetValue()->d mentre
Param1 > Param2 sarebbe meglio.
Devo ancora riflettere su questa problematica e sulla serializzazione
(rigorosamente ASCII, non binaria) per valutare quale strada segeuire.