On Tuesday, 14 July 2015 at 00:22:21 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 13 July 2015 at 18:32:11 UTC, Laeeth Isharc wrote:
Today, one wouldn't want to build a business around depending
on Andrei's allocator.
Not really sure what you are referring to.
It will be dependable soon enough, so I wanted to head off any
discussion centred around it not yet seasoned.
So in which cases could one not use the allocator to manage
memory comfortably enough?
Allocators generally don't manage memory, they structure
allocation patterns and may (or may not) provide initialization
optimizations, release information and release optimizations.
It's my understanding that in a language like D in the end the
programmer is responsible for making choices about managing
memory, but I certainly don't claim to be on top of many
developments in computer science.
If I think about the concrete problems I myself might have to
deal with (and these may well be simpler and easier than the
things you have in mind, but it is what I am personally most
familiar with) - reading a lot of bars in from somewhere,
performing some kind of computation on them, and disposing of the
bars and retaining the results: the allocator helps me a lot as I
can allocate lots cheaply and free the whole lot - bang! - when I
am done. In addition there is instrumenting etc built into the
allocators that I suppose will help track down many kinds of
problems.
In this kind of problem, it strikes me as an unhelpful dichotomy
to distinguish only between 'regular memory management' and
everything else, because the former has connotations of having to
remember to call free or delete that don't apply here (scope +
depending on struct destructors being run).
I imagine it may be very different where you have shared
ownership of lots of little objects and these aren't centralized
in one place, but that isn't mostly my sort of problem. I
suppose implicitly from what you write it must be for web
services on a large scale, and if you have anything you can point
me to on this then I would be curious to see it.
Laeeth.
