what to do with postblit on the heap?
Michel Fortin
michel.fortin at michelf.com
Mon Jun 20 18:59:49 PDT 2011
On 2011-06-20 18:12:11 -0400, "Steven Schveighoffer"
<schveiguy at yahoo.com> said:
> On Mon, 20 Jun 2011 16:45:44 -0400, Michel Fortin
> <michel.fortin at michelf.com> wrote:
>
>> My feeling is that array appending and array assignment should be
>> considered a compiler issue first and foremost. The compiler needs to
>> be fixed, and once that's done the runtime will need to be updated
>> anyway to match the changes in the compiler. Your proposed fix for
>> array assignment is a good start for when the compiler will provide
>> the necessary info to the runtime, but applying it at this time will
>> just fix some cases by breaking a few others: net improvement zero.
>
> BTW, I now feel that your request to make a distinction between move
> and copy is not required. The compiler currently calls the destructor
> of temporaries, so it should also call postblit. I don't think it can
> make the distinction between array appending and simply calling some
> other function.
Well, if
a ~= S();
does result in a temporary which get copied and then destroyed, why
have move semantics at all? Move semantics are not just an
optimization, they actually change the semantics. If you have a struct
with a @disabled postblit, should it still be appendable?
> If the issue of array assignment is fixed, do you think it's worth
> putting the change in, and then filing a bug against the GC? I still
> think the current cases that "work" are fundamentally broken anyways.
That depends. I'm not too sure currently whether the S destructor is
called for this code:
a ~= S();
If the compiler currently calls the destructor on the temporary S
struct, then your patch is actually a fix because it balances
constructors and destructors correctly for the appending part (the bug
is then that compiler should use move semantics but is using copy
instead). If it doesn't call the destructor then your patch does
introduce a bug for this case.
All in all, I don't think it's important enough to justify we waste
hours debating in what order we should fix those bugs. Do what you
think is right. If it becomes a problem or it introduces a bug here or
there, we'll adjust, at worse that means a revert of your commit.
>> As for the issue that destructors aren't called for arrays on the heap,
>> it's a serious problem. But it's also a separate problem that concerns
>> purely the runtime, as far as I am aware of. Is there someone working
>> on it?
>
> I think we need precise scanning to get a complete solution. Another
> option is to increase the information the array runtime stores in the
> memory block (currently it only stores the "used" length) and then hook
> the GC to call the dtors. This might be a quick fix that doesn't
> require precise scanning, but it also fixes the most common case of
> allocating a single struct or an array of structs on the heap.
The GC calling the destructor doesn't require precise scanning.
Although it's true that both problems require adding type information
to memory blocks, beyond that requirement they're both independent.
It'd be really nice if struct destructors were called correctly.
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
More information about the Digitalmars-d
mailing list