On Sat, 11 Jun 2011 12:35:43 -0400, Jose Armando Garcia
<jsan...@gmail.com> wrote:
On Sat, Jun 11, 2011 at 1:26 PM, dsimcha <dsim...@yahoo.com> wrote:
I've overhauled my TempAlloc proposal based on some of the suggestions
I've
received. Here are the major changes:
1. I've reconsidered and decided TempAlloc belongs in its own Phobos
module
(std.tempalloc) instead of in core.memory, mainly because it uses
Phobos in
ways that aren't easy to get rid of.
2. Move uninitializedArray (formerly newVoid) to its own pull request
for
inclusion in std.array. This keeps the TempAlloc proposal more tightly
focused.
3. Make alignedMalloc and friends private for now, again to make the
proposal more tightly focused.
4. Rename tempdup to tempArray to emphasize that is semantics are more
similar to std.array.array than .dup w.r.t. narrow strings.
5. Move newStack into the TempAlloc namespace and rename it
TempAlloc.newArray.
6. TempAlloc.newArray now handles multidimensional arrays. Its syntax
is
slightly modified to accommodate this. Before:
double[] foo = newStack!double(100);
After:
double[] foo = TempAlloc.newArray!(double[])(100);
Code:
https://github.com/dsimcha/TempAlloc
Docs (NOT the same as the old URL):
http://cis.jhu.edu/~dsimcha/d/phobos/std_tempalloc.html
Just a high-level comment.
Now that you moved it to its own namespace do you have a need for a
struct with only static method? I think it is an abuse of the language
to use struct as a way of namespacing.
First, TempAlloc was originally developed in its own namespace. Second,
there are no name conflicts between core.memory and TempAlloc which would
require a sub-namespace. Third, Structs don't provide a true namespace.
What you're neglecting is that each of those function names can't stand by
itself. For example, people assume malloc and free always refer to the C
functions. So, the TempAlloc functions would normally be TempAllocMalloc
or TempAllocFree. But once the number of functions like this grows past a
certain size, using TempAlloc.free, becomes syntactically nicer than
TempAllocFree.
