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
