http://d.puremagic.com/issues/show_bug.cgi?id=3696
Summary: SuperStack Product: D Version: 2.036 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: druntime AssignedTo: s...@invisibleduck.org ReportedBy: chadj...@gmail.com --- Comment #0 from Chad Joan <chadj...@gmail.com> 2010-01-11 17:32:03 PST --- http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=79746 Quoted from Andrei: > This entire discussion gets me thinking - could an alternate stack be a > good (or even better) solution? Consider a global per-thread > "superstack" - a growable region that allocates memory in large chunks > and makes sub-chunks accessible in a strictly LIFO manner. The > primitives of the superstack are as follows: > void* SuperStack.allocate(size_t bytes); > void SuperStack.free(size_t bytes); > size_t SuperStack.slack(); > The SuperStack's management is a singly-linked list of large blocks. The > slack function returns how many bytes are left over in the current > chunk. If you request more than slack bytes, a new chunk is allocated > etc. A SuperStack can grow indefinitely (and is susceptible to leaks). > Some convenience functions complete the picture: > T[] SuperStack.array(T)(size_t objects); > enum Uninitialized { yeahIKnow } > T[] SuperStack.array(T)(size_t objects, Uninitialized); > Freeing chunks should not be done immediately in order to avoid > pathological behavior when a function repeatedly allocates and frees a > chunk just to fulfill some small data needs. > With the SuperStack in place, code could look like this: > void foo(in size_t s) > { > auto a = SuperStack.array(int)(s, Uninitialized.yeahIKnow); > scope(exit) SuperStack.free(s); > ... play with a ... > } > Is there interest for such a thing? > Andrei -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------