schveiguy at yahoo.com
Fri Oct 10 06:35:47 PDT 2008
"Hendrik Renken" wrote
>> "data" is a dynamic array reference, so STRUCT is really just this:
>> struct STRUCT
>> size_t length;
>> byte* ptr;
> This explains everything. Thanks.
>> So "data" is just a number of elements and a pointer to the first one.
>> When you do "new STRUCT(myData)", you're only allocating room for that.
>> There's no room for array contents allocated, just the reference.
>> If you do writeln(STRUCT.sizeof); it will always say 8 on a 32-bit
>> system, same goes for data.sizeof.
> let me modify your example:
>> STRUCT foo(byte myData)
>> STRUCT s = STRUCT(myData);
> return s;
> will the content of s now be copied when it is returned?
the pointer will be copied. If you want a copy of the data, try this:
STRUCT s = STRUCT(myData.dup);
This duplicates the data before setting the pointer. array.dup is a shallow
copy, so if you are duping an array of pointers, only the pointers get
copied, not the data they point to. If you want a 'deep' copy, you have to
loop and do it yourself at this point.
> > Your example should probably look like this, as there's no point in heap
> > allocating small structs:
> what means small? below how many bytes?
All heap allocations are a minimum of 16 bytes. So if you are allocating a
struct that just contains a pointer and a length (i.e. an array), that is an
8-byte struct on a 32 bit system. That means 100% overhead... Plus heap
allocations require grabbing a global thread mutex, finding a suitable
allocation block, possibly running a garbage collect cycle. They are slow,
much slower than using a stack allocated struct.
Of course if you are copying the data, a dup is going to do a heap
allocation, so not much is gained by putting your struct on the stack.
However, you probably don't *need* to use the heap for the struct data, I'd
recommend against it.
More information about the Digitalmars-d-learn