std.allocator ready for some abuse

[Andrei Alexandrescu]

On 10/25/13 7:23 AM, Manu wrote:
> 1. I'm still sad there are no allocAligned() functions or something of
> that type to request explicit alignment with allocations. I'm not sure
> there is sufficient support for requesting alignment with allocations.
> The set-able alignment property approach seems a little weird (and only
> seemed to be supported on one allocator?).

Woke up this morning with the following idea.

1. We add two optional API functions:

void[] alignedAllocate(size_t, uint);
bool alignedReallocate(ref void[], size_t, uint);

These would satisfy aligned allocation requests. The pointer thus 
allocated should be deallocated the usual way (there is no 
alignedDeallocate).

2. We make alignment a statically-known enum and delete all code that 
allows it to be get and set at runtime.

Consequences:

1. The API gets larger due to the two new APIs. However, that is offset 
(probably more than enough) by the removal the option to set the 
alignment at runtime, which currently is causing severe ripple effects. 
I think the result will be a simpler overall design and implementation.

2. HeapBlock should be able to implement the two functions. All regions 
should be able to implement the first.

3. Mallocator could also implement these on Posix: 
http://man7.org/linux/man-pages/man3/posix_memalign.3.html. However, 
Windows requires a specific call for deallocating aligned memory. To 
accommodate both portably, we leave Mallocator as is and create 
AlignedMallocator that uses the _aligned_* family on Windows and the 
respective functions on Posix. On Windows, allocate() requests would 
pass a default of platformSize (i.e. 16 I suspect) to _aligned_malloc.

Is this satisfactory for everyone?


Andrei