Also in general usage of custom allocator for temporaries is a
very bad @nogc approach and is only marginally better than GC
using code. Good @nogc must make no decisions about allocations
at all (and ideally minimize stack allocations too, especially if
fibers are to be used).
@nogc code is quite different from idiomatic "casual" D code and
one is expected to make sacrifices to go for it. Here are some
approaches I decided for myself:
On Sunday, 24 July 2016 at 15:34:55 UTC, Lodovico Giaretta wrote:
Now, there are some cases in which you cannot avoid the managed
On Sunday, 24 July 2016 at 17:04:43 UTC, Seb wrote:
On Sunday, 24 July 2016 at 15:34:55 UTC, Lodovico Giaretta
wrote:
DISCLAIMER: although I've been occasionally using D for a lot
of time, I only recently started to follow the forums and use
it intensively, so I may miss part of the history /
On Sunday, 24 July 2016 at 15:34:55 UTC, Lodovico Giaretta wrote:
DISCLAIMER: although I've been occasionally using D for a lot
of time, I only recently started to follow the forums and use
it intensively, so I may miss part of the history / long term
vision.
So, the current guidelines to
On Sunday, 24 July 2016 at 15:44:48 UTC, lqjglkqjsg wrote:
Note that for the arrays you have @nogc routines in
std.experimental.allocators. (expand/shrink can infer @nogc
from Mallocator).
I know. In fact I'm proposing two possible solutions based on
std.experimental.allocators. Both have
On Sunday, 24 July 2016 at 15:34:55 UTC, Lodovico Giaretta wrote:
DISCLAIMER: although I've been occasionally using D for a lot
of time, I only recently started to follow the forums and use
it intensively, so I may miss part of the history / long term
vision.
[...]
Note that for the arrays
