On 9/24/13 1:02 PM, Dmitry Olshansky wrote:
24-Sep-2013 19:56, Andrei Alexandrescu пишет:
It could, but as I mentioned to Manu - at this level any cost is
significant. Even changing from a compile-time constant to a global
static dynamically-initialized constant has a cost. Making alignment an
instance variable turns stateless allocators into stateful ones.
Hm most could just get away with an enum. Am I missing something?
Right now I do things like:
struct DopeAllocator(Allocator, Dope)
{
static assert(Allocator.alignment >= Dope.alignof,
"DopeAllocator does not work with allocators offering a smaller"
" alignment than the dope alignment.");
static assert(!hasElaborateDestructor!Dope,
"DopeAllocator: ellaborate destructors for Dope not implemented.");
enum alignment = Dope.alignof;
...
}
Such code would be significantly more involved if Allocator had the
freedom to define alignment as either an enum, a static method, or a
member function.
(Background: DopeAllocator!(A, D) allocates an object of type D just
before every allocation and offers user code access to it. Allocations
are made using A.)
I'm hoping to get away with a static function "static uint alignment()"
that (a) is CTFEable for most allocators/platforms, (b) uses a
dynamically-initialized static constant for a few. Then derived
allocators will inherit CTFEability.
A check for CTFE-ablity might do the trick. The run-time dependent ones
usually would immediately hit a wall that is a sys-call or WinAPI.
It does. It's just some more work. Guess I'd need to put it in.
Would a per-allocator-type alignment suffice?
I see alignment as an inherent property of the way an allocator acquires
memory.
The question remains, is it a property of the allocator _object_ or a
property of the allocator _type_? I.e. do we need to support allocators
that store alignment as a nonstatic member variable?
Sad but true one can't determine the actual alignment of some
important ones at CTFE. Even worse adapters would in turn depend on
these system-specific run-time values such as half a page, 2 cache lines
etc.
auto my2PageAligner = AligningAllocator(page_size*2, rootAllocator)
where page_size is calculated elsewhere.
That can be made to work, it's just that page_size would be a static
variable that the user must set (not a template argument).
The global GC does offer manual deallocation. It's the presence of
collect() that indicates tracing abilities. If deallocateAll() is
present, user code must assume it will be called during destruction.
I was looking into how some library would have to tweak its code based
on presence/absence of some methods. For instance if there is collect,
it doesn't have to call deallocate (even if present). If not then it has
to call deallocate (again if present). Ditto with deallocateAll with or
without explicit deallocate.
Yah, my std.allocator prototype has a bunch of such logic.
expand should do the trick. I think that nicely saves on primitives
count. But we may have to add a 'shrink' if you are so bent on never
decreasing size in expand :)
And ... reallocate doesn't cut it as long as there is no big red tape on
it that says - if decreasing the size reallocation it is ALWAYS in-place
(it might not be true for some allocators - e.g. realloc doesn't
guarantee even this IIRC).
OK, I'm willing to add the optional method shrink(void[], size_t
newSize) if expand() and realloc() are insufficient. Indeed realloc()
does not guarantee immovability, and we also shouldn't because
Mallocator must be compatible the C API.
Andrei
