On Monday, 29 September 2014 at 15:18:40 UTC, Andrei Alexandrescu
wrote:
On 9/29/14, 5:29 AM, Dicebot wrote:
Any assumption that library code can go away with some set of
pre-defined allocation strategies is crap. This whole
discussion was
about how important it is to move allocation decisions to user
code
(ranges are just one tool to achieve that, Don has been
presenting
examples of how we do that with plain arrays in DConf 2014
talk).
That's making exactly the confusion I was - that memory
allocation strategy is the same as memory management strategy.
Yes but neither decision belongs to library code except for very
rare cases.
In that regard allocators + ranges are still the way to go in
my
opinion. Yes, sometimes those result in very hard to use API -
providing
GC-heavy but friendly alternatives for those shouldn't do any
harm. But
in general full decoupling of algorithms from allocations is
necessary.
If that makes D poor cousin of C++ we may have a learn few
tricks from C++.
As long as things are trivial they can be done with relative
ease, albeit with more pain. But consider e.g. the recent JSON
library by Sönke. It needs to create a lookup data structure
and return things like strings from it. What primitives do you
think could it define?
Sounds like it may have to define own kind of allocator with
certain implementation restrictions (and implement it in terms of
GC by default). I have not actually read the code for that
proposal so hard to guess. Will need to do it if it really
matters.
