Storing a generic value and its type in C++: merge type+value in one class or separating them?

If have a union that currently foresees some simple data types:

union Value
   {
   const char *str;
   double d;
   long l;
   short s;
   bool b;
   void *reference;
   };

The union also allows more complex data types to be stored (like enumerations, references to instances, ...), but all data is stored in one of the members of the Value union.

Because the data types can be complex, the Type is curently stored in a separate structure, which looks like this:

struct Type
   {
   short BaseType;            // one of TYPE_STRING, TYPE_LONG, TYPE_DOUBLE, ...
   char *referenceName;       // only used if BaseType==TYPE_REFERENCE
   Enumeration *enumeration;  // only used if BaseType==TYPE_ENUMERATION
   };

While restructing the application, I was thinking about integrating both structs into one class. Value would then become a pure interface IValue, and there would be subclasses/implementations for each of the different types.

The disadvantage of integrating the Value and Type is that Value cannot be simply copied anymore, but it always needs to be cloned. The advantage is that you are guaranteed never to lose the type of a value anymore.

If I keep Value and Type as separate classes, I would still change Type from one structure to a hierarchy. IType would be the interface, and for every type there would be a subclass/implementation, e.g. StringType, DoubleType, LongType, ... and eveny MyEnumType, MyOtherEnumType, ... The implementations of IType can then decide which value to use in the Value union.

Although copying types still requires a clone, I can at least copy the values without a clone. And in most cases, the values are copied much more than the types.

When keeping Value and Type separate, the whole concept is that you can copy the Value around as many times as you want, but if you want to get the actual underlying value, you need the Type.

Although the application is pure C++ (no .Net), I am willing to use .Net as inspiration for my developments, and I notice that in .Net you also have values that can easily be created on the stack, passed by value to functions, ... without the need for cloning.

Templates are not a solution in my application since this would make about 50% of my application templated.

Questions:

• Anyone experience with handling a generic Value and Type system in C++?
• Does .Net have a 'generic' value and/or type concept that 开发者_运维知识库can be used as inspiration?
• Any more arguments for keeping Value and Type in separate classes?
• Any more arguments for merging Value and Type into one class?

You should use a boost::variant or boost::any. That's what they're for. Using them doesn't mean that you have to template your entire solution. Moreover, if you don't need dynamic, run-time variance between types, then that IS what templates are for. The right tool for the right job - and this is templates for static variance, boost::variant for dynamic variance. There's neither need nor reason for you to roll your own dynamic typing system.

.NET has the design failing which is "object", but failing that, they could also use the same kind of technique used in boost::variant, as far as I know their generics are powerful enough to do that kind of thing.

Sounds like you're attempting to reimplement something along the lines of a VARIANT. Have you looked at Boost::Any? That solves quite a number of your problems nicely. However, even there they make sure that the type information comes with the object. You really shouldn't be passing two objects around like that. They need to be married.

On the template front, there's nothing wrong with 50% of your solution being templated. Something it solves the issues you're facing nicely. Templated traits are a wonderful invention:

template<typename T>
struct VarValue{
    VarValue(T _t) : m_T(_t){}
    typedef T value_type;
    T m_T;
};

and then the typedef allows you to use the contained object seemlessly without fear that something won't know what variable type it is.

I hate them (because of the memory management hassle), but there is the VARIANT, and the much preferred CComVariant. As far as I remember, type and value is in the same structure, VARIANT.

You should find them in win sdk, and ATL (CComVariant).

e.g.:

struct tagVARIANT
    {
    union 
        {
        struct __tagVARIANT
            {
            VARTYPE vt;  // here is stored the type
            WORD wReserved1;
            WORD wReserved2;
            WORD wReserved3;
            union     // there the value
                {
                LONGLONG llVal;
                LONG lVal;
                BYTE bVal;
                SHORT iVal;
                FLOAT fltVal;
                DOUBLE dblVal;
                VARIANT_BOOL boolVal;
                _VARIANT_BOOL bool;
                SCODE scode;
                CY cyVal;
                DATE date;
                BSTR bstrVal;
                IUnknown *punkVal;
                IDispatch *pdispVal;
                SAFEARRAY *parray;
                BYTE *pbVal;
                SHORT *piVal;
                LONG *plVal;
                LONGLONG *pllVal;
                FLOAT *pfltVal;
                DOUBLE *pdblVal;
                VARIANT_BOOL *pboolVal;
                _VARIANT_BOOL *pbool;
                SCODE *pscode;
                CY *pcyVal;
                DATE *pdate;
                BSTR *pbstrVal;
                IUnknown **ppunkVal;
                IDispatch **ppdispVal;
                SAFEARRAY **pparray;
                VARIANT *pvarVal;
                PVOID byref;
                CHAR cVal;
                USHORT uiVal;
                ULONG ulVal;
                ULONGLONG ullVal;
                INT intVal;
                UINT uintVal;
                DECIMAL *pdecVal;
                CHAR *pcVal;
                USHORT *puiVal;
                ULONG *pulVal;
                ULONGLONG *pullVal;
                INT *pintVal;
                UINT *puintVal;
                struct __tagBRECORD
                    {
                    PVOID pvRecord;
                    IRecordInfo *pRecInfo;
                    }   __VARIANT_NAME_4;
                }   __VARIANT_NAME_3;
            }   __VARIANT_NAME_2;
        DECIMAL decVal;
        }   __VARIANT_NAME_1;
    } ;