On 5/22/18 1:01 AM, Manu wrote:
On 21 May 2018 at 15:51, Steven Schveighoffer via Digitalmars-d
<[email protected]> wrote:
On 5/21/18 6:37 PM, Manu wrote:
On 21 May 2018 at 15:29, Steven Schveighoffer via Digitalmars-d
<[email protected]> wrote:
Uninitialized, but allocated and usable. The difference between this and
delete is that delete is going to unallocate that memory. The next time
it's
allocated, it will be overwritten with an init pattern for the new type.
Basically, in D when you have access to memory, it should be in a valid
state.
Why is it reasonable to expect that the buffer after `destroy()`
should be 'valid'?
Who's to say that the init state is 'valid'?
It's valid in that it's not garbage, and that it's not full of dangling
pointers.
Ah! Dangling pointers... that might conservatively retain garbage.
That's a good reason.
Well, I was thinking more along the lines of accessing memory that is no
longer valid :) A destructor can, for instance, free C malloced memory.
And you've demonstrated exactly what I'm saying... there's no need for
destroy() to return initialised memory here. It could return
0xfeeefeee memory or something (for debugging purposes).
No, the ctor assumes all values are in init state. If that's not the case,
then the code will crash or corrupt memory.
....so, assign init immediately before construction? Rather than
assigning init on destruction, which makes destroy more expensive, and
it may or may not be re-used (most likely not).
Why isn't assigning init built into the constructor?
It provides for slight efficiencies. For example, if you allocate an
array of 100 structs, whose init value is all 0, you can do one memset
on the entire array.
When you split the init blitting from the constructor, you have more
options.
Note: you can "destroy" without blitting init, all the tools are there
(the same ones destroy uses, it's not a magic function). Might be a good
addition -- unsafeDestroy.
-Steve
