www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Can't call destroy in nogc context, even though the class destructor

reply 12345swordy <alexanderheistermann gmail.com> writes:
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
Jul 09
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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!?
Jul 09
next sibling parent reply Lamex <Lamex dfghjkl.iuyt> writes:
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.
Jul 09
parent 12345swordy <alexanderheistermann gmail.com> writes:
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.
Jul 10
prev sibling next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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 ;)
Jul 09
prev sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
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
Jul 10
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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?
Jul 10
parent Moritz Maxeiner <moritz ucworks.org> writes:
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
Jul 10
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 09