"Dave" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Andrei Alexandrescu" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> KennyTM~ wrote: >>> The best solution I can think of, without compiler modification is a >>> struct/class that contains a static array member T[1024] and a dynamic >>> array member T[] initialized to null; and the code chooses which member >>> to use in the constructor. But this always occupies 1024*T.sizeof bytes >>> and there will always be a conditional (if) sticked to all access >>> methods. >> >> 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? >> > > That would be interesting and even better if it could be a built-in (not > clear on if that was the intention or not). > > The reason for having it be a built-in is (IMO) it's important for D to > provide language constructs that can improve performance for common things > like allocating temporary, scope-limited arrays and classes, especially > with > the new direction D2 discussions have been heading in lately (like pure > functions and such). >
Oh, and any built-in syntax needs to provide a way to allocate uninitialized data also (yeah, I know)... >> >> Andrei > >
