std.boxer vs Any

Daniel Keep daniel.keep.lists at gmail.com
Tue Oct 9 23:47:39 PDT 2007



Bill Baxter wrote:
> Daniel Keep wrote:
>>
>> Bill Baxter wrote:
>>> Daniel Keep wrote:
>>>> And just to throw a little more wood on the fire:
>>>> http://www.prowiki.org/wiki4d/wiki.cgi?DanielKeep/Variant
>>>>
>>>> :P
>>>>
>>>>     -- Daniel
>>> Maybe you could comment on what makes yours different/better than the
>>> alternatives, then.  Do we really need three different versions of this?
>>>  Are they suited for different purposes?
>>>
>>> --bb
>>
>> Well, the primary difference between mine and std.boxer is that mine
>> works in Tango out of the box.
>>
>> The other reason I wrote it was because of something Pragma posted about
>> on the Tango forums about making a Box that was easier to use.  The
>> major improvement is the use of opAssign that allows you to directly
>> assign to a Variant.  I also like to think that Variant is easier to use
>> than std.boxer.
>>
>> The whole "operator overloading" business was done mostly because I
>> wanted to see if it *could* be done.  :P
>>
>> Really, I think there's only so much you can do with a variant type in
>> D, and Box and Variant each do about 90% of it (not the *same* 90%, mind
>> you; Variant doesn't do the "call a vararg function using a Box array"
>> trick.)  In the case of Box and Variant, the differences are mostly just
>> implementation and interface issues.
> 
> Looks like maybe yours avoids the opaque storage gc problem too?
> 
> --bb

I doubt it.  One of its members an array, which should mark Variants as
containing pointers.  The problem is that it's just as valid to store an
array or pointer in a Variant as it is to store a value like an int or
float.  Also, since a Variant is a struct, I don't think I can use
gc.hasNoPointers.

Making Variant a class would allow one to properly inform the GC what
kind of data its storing, but then I wanted Variant to be a struct so I
could use the opAssign trick, not to mention value semantics.

	-- Daniel



More information about the Digitalmars-d mailing list