On Thu, 12 Nov 2009 19:49:58 +0300, dsimcha <[email protected]> wrote:
== 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?
I can't give a formal definition of that, but for me a is allowed to
allocate if it produces something new or unique.
For example, void mkdirRecurse(string pathname) shouldn't allocate, but it
does, because the author didn't care about allocations when implemented 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.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
