FYI - mo' work on std.allocator

safety0ff via Digitalmars-d digitalmars-d at puremagic.com
Mon May 5 00:13:02 PDT 2014


On Monday, 28 April 2014 at 16:03:33 UTC, Andrei Alexandrescu 
wrote:
>
> Fair enough, I'll remove that part of the spec. Thanks! -- 
> Andrei

According to the docs, the "multiple of sizeof(void*)" 
restriction only applies to posix_memalign (and not to 
_aligned_malloc and aligned_alloc.)

On Monday, 5 May 2014 at 04:04:56 UTC, Andrei Alexandrescu wrote:
> On 5/4/14, 8:06 PM, Marco Leise wrote:
>> Virtual memory allocators seem obvious, but there are some
>> details to consider.
>>
>> 1) You should not hard code the allocation granularity in the
>>    long term. It is fairly easy to get it on Windows and Posix
>>    systems:
>>
>> On Windows:
>>   SYSTEM_INFO si;
>>   GetSystemInfo(&si);
>>   return si.allocationGranularity;
>>
>> On Posix:
>>   return sysconf(_SC_PAGESIZE);
>
> I've decided that runtime-chosen page sizes are too much of a 
> complication for the benefits.

Do the complications arise in the MmapAllocator or the higher 
level allocators?

I'd like to see a Windows allocator based on VirtualAlloc, and 
afterwards a "SystemAllocator" defined to be MmapAllocator on 
unix-based and VirtualAlloc based on Windows.
This "SystemAllocator" would ideally have an 
allocationGranularity property.


More information about the Digitalmars-d mailing list