== Quote from Denis Koroskin ([email protected])'s article
> I strongly believe that "No hidden allocation" policy should be adopted by
> D/Phobos (it is already adopted by Tango with a great success).
I can see the value in this, but two issues:
1. What counts as a "hidden" allocation? How non-obvious does it have to be
that
something requires an allocation? If something really has to allocate and it's
not obvious from the nature of the function, is it enough to just document it?
2. How do you really design high-level library functions if they're not allowed
to allocate memory? If you require the user to provide all kinds of details
about
where the memory they use comes from then you lose some of the high level-ness
and
make it seem more like an ugly C API that doesn't "just work" and requires
attention to the irrelevant the 90% of the time that you don't care about an
extra
allocation. The solution I personally use in my dstats lib, which works pretty
well in the limited case of arrays of primitives, but might not generalize, is:
a. For stuff that returns an array, the last argument to the function is an
optional buffer. If it is provided and is big enough, the results are returned
in
it. If it is not provided or is too small, a new one is allocated.
b. For temporary buffers used within a function, I use a thread-local
second
stack (TempAlloc). While this is not **guaranteed** never to result in an
allocation (if we're out of space in our current chunk of memory, a new one will
be allocated), it very seldom does and only when the only alternative would be
to
crash, throw an exception, etc.
