On 6/13/15 4:16 PM, ZombineDev wrote:
On Saturday, 13 June 2015 at 15:48:31 UTC, Andrei Alexandrescu wrote:
On 6/13/15 3:14 AM, Dicebot wrote:
Andrei, have you considered creating additional std.allocator.impl
package and moving actual allocators there? Or, probably, the other way
around with std.allocator.core
Existing flat hierarchy does not hint about internal structure in any
way.
It's good documentation, not directories, that helps understanding
internal structure. There are 23 files in std/experimental/allocator,
which seems manageable. I think we're good as we are.
Andrei
I also think putting some of the files in folder will make things
cleaner and easier to understand.
These files:
std.experimental.allocator.affix_allocator,
std.experimental.allocator.allocator_list,
std.experimental.allocator.bucketizer,
std.experimental.allocator.fallback_allocator,
std.experimental.allocator.free_list,
std.experimental.allocator.free_tree,
std.experimental.allocator.gc_allocator,
std.experimental.allocator.bitmapped_block,
std.experimental.allocator.kernighan_ritchie,
std.experimental.allocator.mallocator,
std.experimental.allocator.mmap_allocator,
std.experimental.allocator.null_allocator,
std.experimental.allocator.quantizer,
std.experimental.allocator.region,
std.experimental.allocator.segregator,
std.experimental.allocator.stats_collector;
are great candidates for a std.experimental.allocator.building_blocks
folder.
Moved a bunch of these into building_blocks:
https://github.com/andralex/phobos/commit/14ccc3a02f3dd332cb435abaf3c35cb8847797c0
However, I kept gc_allocator, mallocator, and mmap_allocator outside of
it as "core" allocator that doesn't depend on any other.
Andrei