Library Development: What to finish/flesh out?

dsimcha dsimcha at yahoo.com
Thu Mar 24 12:52:50 PDT 2011


== Quote from Sean Kelly (sean at invisibleduck.org)'s article
> On Mar 17, 2011, at 11:56 PM, Don wrote:
> > dsimcha wrote:
> >> I've accumulated a bunch of little libraries via various evening and
> weekend
> >> hacking projects over the past year or so, in various states of
> completion.
> >> Most are things I'm at least half-considering for Phobos, though some
> belong
> >> as third-party libs.  I definitely don't have time to finish/flesh
> out all of
> >> them anytime soon, so I've decided to ask the community what to
> prioritize.
> >> Below is a summary of everything I've been working on, with its
> current level
> >> of completion.  Please let me know the following:
> >
> >> 3.  TempAlloc:  A memory allocator based on a thread-local segmented
> stack,
> >> useful for allocating large temporary buffers in things like numerics
> code.
> >> Also comes with a hash table, hash set and AVL tree optimized for
> this
> >> allocation scheme.  The advantages over plain old stack allocation
> are that
> >> it's independent of function calls (meaning you can return pointers
> to
> >> TempAlloc-allocated memory from a function, etc.) and it's segmented,
> meaning
> >> you can allocate huge buffers w/o risking stack overflow.  Its main
> weakness
> >> is that this stack is not scanned by the GC, meaning that you can't
> store the
> >> only reference to a GC-allocated piece of memory here.  However, in
> practice
> >> large arrays of primitives are an extremely common case in
> >> performance-critical code.  I find this module immensely useful in
> dstats and
> >> Lars Kyllingstad uses it in SciD.  Getting it into Phobos would make
> it easy
> >> for other scientific/numerics code to use it.  Completion state:
> Working and
> >> used.  Needs a litte cleanup and documentation.  (Phobos candidate)
> >
> > This is #1. Far and away. Belongs in druntime.
> Stuff like this is why core.memory isn't called core.gc.

Ok, this seems like a popular choice.  I should have time after my )#*#$ thesis
proposal and after std.parallelism is done to clean this up and submit for review.
 I'm sure the documentation will need to be improved, but as with std.parallelism
I'm not sure **how** it will be judged deficient by people not as intimately
familiar with the library as I am.


More information about the Digitalmars-d mailing list