http://d.puremagic.com/issues/show_bug.cgi?id=1845

           Summary: Variant and VariantN cannot handle structs of arbitrary
                    size
           Product: D
           Version: 2.010
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Phobos
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: dhasenan@gmail.com


Variant can only handle structs and static arrays of at most 2 * sizeof(size_t) bytes. VariantN can handle structs and static arrays of any specified size.

This is intended behavior. However, it wastes memory: if I know I might need to store a struct of 64 bytes, then I'll store a char with 63 bytes of padding. If I am writing a library, I cannot use Variant or VariantN because I do not know what size structs the end user might want to use.

I could store an array of VariantN and, if I need to store something larger than the current maximum size, copy everything into another array of VariantN with a larger maximum size. I'd have to store this array in a Variant, as well, since its type will continue to change. But that's just silly. Variant is supposed to be a solution for boxing, so I shouldn't have to concern myself with size. At least, I should be able to avoid those concerns, even if they are exposed.

For comparison, Tango stores large structs on the heap, and can store arbitrarily large structs.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1845


andrei@metalanguage.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|bugzilla@digitalmars.com    |andrei@metalanguage.com




------- Comment #1 from andrei@metalanguage.com  2008-02-16 16:23 -------
The intent was to not inflict heap allocation on Variant's user unwittingly. If large structs are to be stored in a Variant, they should be stored by pointer and allocated in user code.

However, transparent pointer storage has its appeal too. I'd like to collect more use cases before changing the implementation. All -- please advise.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1845





------- Comment #2 from dsimcha@yahoo.com  2009-04-05 16:40 -------
I'd say the best compromise between a well-encapsulated solution and a solution that avoids hidden allocations is to have something like a bigAssign(T) method in addition to the regular opAssign.  It would work something like this:

struct Huge {
    real a, b, c, d, e, f, g;
}

void main() {
    Huge huge;
    Variant v;
    v = huge;  // Compile time error.
    v.bigAssign(huge);  // Works, allocates on heap transparently.
    v.bigAssign(5);  // Works, equivalent to v = 5 or v.opAssign(5).
}

Heck, you could even make this a policy.  Let's say you have two functions: neverAllocate() and allocateAsNeeded().  You could make opAssign() an alias to one of these instead of a funciton.  The VariantN template could take an alias parameter for opAssign that defaults to one of the two, but can be overridden on instantiation.  Not sure which the default should be, but that's a minor detail.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1845


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Andrei Alexandrescu <andrei@metalanguage.com>  2009-08-25 00:40:25 PDT ---
Fix coming in the next release.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------