• dsimcha (17/17) Apr 18 2009 I've started looking at implementing arbitrary sized Variant, and
• Andrei Alexandrescu (7/27) Apr 18 2009 I suggest you go with copying. There won't be many heap allocations

dsimcha <dsimcha yahoo.com> writes:

I've started looking at implementing arbitrary sized Variant, and
I've hit a point where I need some opinions.  The idea of
arbitrary sized Variant is to heap allocate when things get too
big to be stored inline in the VariantN struct.  However, how
should copying a VariantN struct with the contents stored on the
heap be handled?

If I don't copy the underlying heap space (thus giving reference
semantics), then the semantics of Variant depend in a non-
intuitive way on the size of the item stored in it.  This is
obviously bad.

If I do copy the data, this results in a ridiculous number of
hidden heap allocations.  This is obviously bad.

I guess the available options would be to make a completely
separate Variant type for arbitrary size (annoying, not as
transparent as anyone would like), or to try to implement some
kind of copy-on-write semantics (would require much deeper/more
fundamental changes to the existing code).

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

dsimcha wrote:
 I've started looking at implementing arbitrary sized Variant, and
 I've hit a point where I need some opinions.  The idea of
 arbitrary sized Variant is to heap allocate when things get too
 big to be stored inline in the VariantN struct.  However, how
 should copying a VariantN struct with the contents stored on the
 heap be handled?
 
 If I don't copy the underlying heap space (thus giving reference
 semantics), then the semantics of Variant depend in a non-
 intuitive way on the size of the item stored in it.  This is
 obviously bad.
 
 If I do copy the data, this results in a ridiculous number of
 hidden heap allocations.  This is obviously bad.
 
 I guess the available options would be to make a completely
 separate Variant type for arbitrary size (annoying, not as
 transparent as anyone would like), or to try to implement some
 kind of copy-on-write semantics (would require much deeper/more
 fundamental changes to the existing code).

I suggest you go with copying. There won't be many heap allocations 
because you only allocate the struct once to keep it inside Variant, and 
you copy it on the stack out whenever someone asks for it.

If someone wants to use reference semantics, they'll use Variant with a 
pointer.


Andrei