Generic functions to convert to void* and from void*

TSalm TSalm at free.fr
Wed Feb 25 12:48:19 PST 2009


Le Wed, 25 Feb 2009 01:03:32 +0100, Daniel Keep  
<daniel.keep.lists at gmail.com> a écrit:

>
> TSalm wrote:
>> In my case, there's also no possibility to get the wrong type, because
>> it is managed by the type of the ColumnMem.
>
> You still have to get the code right.  There's a surprising number of
> corner cases trying to store arbitrary types.
>
>> And about Object, if I want to store base type like int,double,etc...,
>> if I do something like :
>>
>>  Object o;
>>  int a = 30 ;
>>  o = cast(Object) &a ;
>>
>> is this syntax is GC safe ?
>
> It's not safe, period.  If the compiler lets you do that, I'd be
> tremendously surprised; even more surprised if it doesn't cause major
> problems later.  This is what I'm worried about; you're doing dangerous
> things with a type system you don't understand.  Don't do this.
>
> Here's the problem: void* isn't going to work for everything.  It'll
> work for Object references, other pointers, and that's it.  You can't
> store arrays, and you can't store value types like structs or primitive
> types.  For that, you need to allocate heap storage, copy the value and
> then store the pointer to that.  Oh, and don't forget that fixed-length
> arrays have value semantics whereas dynamic arrays and slices have
> reference semantics; although you generally solve that issue by having a
> special template for your type which rewrites T[n] as T[].  Also,
> delegates won't fit, but function pointers will.
>
> This is why I was pointing you at Variant because I already went through
> the trouble to solve all this once.  :P
>
> If you still want to do this with void*, build that code in isolation
> and test the heck out of it.

You are right.
I will first use Variant to implements all functionnalities, and  
insolating the storage type.
And in the future, I will be able to use void* as an improvement.


More information about the Digitalmars-d-learn mailing list