On 5/21/18 6:37 PM, Manu wrote:
On 21 May 2018 at 15:29, Steven Schveighoffer via Digitalmars-d
<[email protected]> wrote:
On 5/21/18 6:18 PM, Manu wrote:
On 21 May 2018 at 06:10, Steven Schveighoffer via Digitalmars-d
<[email protected]> wrote:
On 5/20/18 9:49 PM, Manu wrote:
On 20 May 2018 at 17:14, Walter Bright via Digitalmars-d
Yes, and only for delete.
Why? This doesn't make a lot of sense, since delete is freeing the
memory,
it shouldn't matter what state the memory is left in. I would argue that
should only be done in debug mode, and actually, I wonder if some other
kind
of sentinel memory pattern should be written instead.
destroy() also seems to do it.
Yes, because destroy leaves the memory available for reuse. This is
intentional.
It's uninitialised memory though, Wouldn't the same argument you made
above also apply?
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.
Surely it's not reasonable to just start using a class after calling
destroy(), as if it's a newly constructed class?
No, of course not. For classes, actually the vtable is zeroed out, so
any usage gets a segfault. You'd have to fix that before using again.
But potentially, yes, you can use it if you call a ctor on it.
Fun fact: originally destroy (clear at the time) was going to call the
default ctor on a class instance so it could be used again.
Surely we should expect that dead buffer is emplaced with a new construction?
This is a valid usage in D:
struct S
{
this(...) {...}
}
auto s = S(a, b, c);
destroy(s);
// s is now a fully initialized S ready to be constructed
s.__ctor(a, b, c);
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.
-Steve
