Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
July 09, 2017 Can't call destroy in nogc context, even though the class destructor being called is marked @nogc | ||||
---|---|---|---|---|
| ||||
I have submitted a bug report regarding this: https://issues.dlang.org/show_bug.cgi?id=17592 This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me. Alex |
July 10, 2017 Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc | ||||
---|---|---|---|---|
| ||||
Posted in reply to 12345swordy | On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:
> I have submitted a bug report regarding this:
> https://issues.dlang.org/show_bug.cgi?id=17592
>
> This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me.
>
> Alex
No responses!?
|
July 09, 2017 Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc | ||||
---|---|---|---|---|
| ||||
Posted in reply to 12345swordy | On 07/09/2017 01:27 PM, 12345swordy wrote: > I have submitted a bug report regarding this: > https://issues.dlang.org/show_bug.cgi?id=17592 > > This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me. > > Alex Seems related to https://issues.dlang.org/show_bug.cgi?id=17297. -- Andrei |
July 10, 2017 Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc | ||||
---|---|---|---|---|
| ||||
Posted in reply to 12345swordy | On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote:
> On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:
>> I have submitted a bug report regarding this:
>> https://issues.dlang.org/show_bug.cgi?id=17592
>>
>> This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me.
>>
>> Alex
>
> No responses!?
dtors not being virtual is the root cause of this issue (note the ctors aren't either but that's a bit different due to how super() works). This cant be fixed easily. Maybe the most simple workaround would be an @assumenogc attribute.
|
July 09, 2017 Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc | ||||
---|---|---|---|---|
| ||||
Posted in reply to 12345swordy | On 07/09/2017 09:51 PM, 12345swordy wrote:
>
> No responses!?
FWIW, traffic on this NG tends to slow down on the weekends. I've long wondered if most of the activity here is when people need a break during their workday ;)
|
July 10, 2017 Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lamex | On Monday, 10 July 2017 at 03:41:15 UTC, Lamex wrote:
> On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote:
>> On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:
>>> I have submitted a bug report regarding this:
>>> https://issues.dlang.org/show_bug.cgi?id=17592
>>>
>>> This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me.
>>>
>>> Alex
>>
>> No responses!?
>
> dtors not being virtual is the root cause of this issue (note the ctors aren't either but that's a bit different due to how super() works). This cant be fixed easily. Maybe the most simple workaround would be an @assumenogc attribute.
I redundant to create a poor man's destructor void function named "clear()" for every class it allocated, every workaround I come across here around involves ugly hacks. Even Automem has it's on way of calling the destructor in a @nogc context.
Regardless, this is very frustrating for me to do manual memory management with class in a @nogc context without resorting to hacks and third-party libraries. I hope that the current main devs would tackle this in the upcoming releases.
|
July 10, 2017 Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc | ||||
---|---|---|---|---|
| ||||
Posted in reply to 12345swordy | On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote: > On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote: >> I have submitted a bug report regarding this: >> https://issues.dlang.org/show_bug.cgi?id=17592 >> >> This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me. >> >> Alex > > No responses!? See long standing `rt_finalize` issue [1], it's unfortunately a non-trivial problem. [1] https://issues.dlang.org/show_bug.cgi?id=15246 |
July 10, 2017 Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Moritz Maxeiner | On Monday, 10 July 2017 at 17:27:54 UTC, Moritz Maxeiner wrote:
> On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote:
>> On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:
>>> I have submitted a bug report regarding this:
>>> https://issues.dlang.org/show_bug.cgi?id=17592
>>>
>>> This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me.
>>>
>>> Alex
>>
>> No responses!?
>
> See long standing `rt_finalize` issue [1], it's unfortunately a non-trivial problem.
>
> [1] https://issues.dlang.org/show_bug.cgi?id=15246
What's the progress regarding fixing it?
|
July 10, 2017 Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc | ||||
---|---|---|---|---|
| ||||
Posted in reply to 12345swordy | On Monday, 10 July 2017 at 20:10:58 UTC, 12345swordy wrote: > On Monday, 10 July 2017 at 17:27:54 UTC, Moritz Maxeiner wrote: >> On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote: >>> On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote: >>>> I have submitted a bug report regarding this: >>>> https://issues.dlang.org/show_bug.cgi?id=17592 >>>> >>>> This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me. >>>> >>>> Alex >>> >>> No responses!? >> >> See long standing `rt_finalize` issue [1], it's unfortunately a non-trivial problem. >> >> [1] https://issues.dlang.org/show_bug.cgi?id=15246 > > What's the progress regarding fixing it? AFAIK people disagreeing on how to proceed, because there's no one correct answer, it's a matter of policy. And then there's the fact that hardly anyone uses @nogc currently, anyway, because this is not the only issue with it, see the (somewhat) controversial @nogc Exception PRs by Walter for one other problem [1][2] - idiomatic D code is essentially impossible atm with @nogc, unless you use hacks like preallocated exceptions. Another issue is how std.experimental.allocator.IAllocator and @nogc can fit together (because the interface can't be declared as attributed AFAIK). I understand your frustration, but right now the best option imho (read as: least time expensive) remains not using @nogc (ouch, I know) and if you really fear hidden GC allocations, use the -vgc to have the compiler output all the placed where GC allocation may occur (grep through the result automatically, ensuring there are none reported); doesn't work for binary dependencies, unfortunately. [1] https://github.com/dlang/druntime/pull/1804 [2] https://github.com/dlang/dmd/pull/6681 |
Copyright © 1999-2021 by the D Language Foundation