Newsgroup: it.comp.lang.c++
Titolo: Array di parametri non omogenei

Ho un array di parametri che definiscono le proprieta' di un oggetto.
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)?

 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

 soddisfa le tue necessitï¿œ.
Si, grazie Max.

Guglielmo Calligaro ha scritto:

Non conosco la soluzione, certo più rapida sicura ed 
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

 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.