On 09/09/2011 03:45 PM, Christophe wrote:
dsimcha , dans le message (digitalmars.D:144200), a écrit :
But RAII makes things simple and relatively safe. What would you
suggest as the alternative?
I guess from the rest of his post to make the allocator a class,
scoped on demand, and provide a freeAll function.
Personally, I like to have structs and templates rather than classes and
interfaces in phobos.
Hmm, I really like the idea of the stack memory getting freed
automatically and deterministically by ref counting.
Just an idea, such class could provide a little refCounter to make it
possible to enclose it in a RAII struct, or it could be allowed to
be derived to the same class with a refCounter.
Usually you want RAII. So that should be the simpler thing to have, not
the other way round.
I really like the transparent "just works" design for big objects.
Again, this goes back to the high-level vs. simple point. You seem to
be calling for the Unix way (everything is simple, stupid and
composable, implementation simplicity is most important).
I think a std lib should provide simple, stupid and composable tools
first, before it provide "just working" big objects (#). That does not
remove any value to your work, but I think your RegionAllocator may come
a little early. IMO, one reason of the disagreement is that People
expect a simple stupid region allocator, and what you provide is a
complexe "shared region allocator".
I must say I come from Unix world, and I am also in favor of
composition.
I come from an Unix world, and I don't care about the implementation of
a tool if it is simple to use, efficient and correct. ;)
# At the moment, and with the current documentation your allocator is
not really a "just work" object, since it still creates mental
codebloat.
Basically, if it stops to just work for big objects, users have to be
aware of the fact that it might not work, even if there is plenty of
memory available. What does that add in value?
9. The allocator interface should have a flag to advice GC range adding.
Could be:
alloc(size_t nbytes, GCScan scan = GCScan.no)
RegionAllocator could deduce it's scan flag from the first use and
enforce it never changes afterwards. I'm not to sure about this,
but requiring the user to add memory to the GC seems error prone and
reduce the design space for allocators.
I don't understand. If they have to set a flag to get it added, then I
fail to see how adding it manually is any more difficult.
I don't really see the point of this either (your implementation of
regionAllocator.alloc does not use GCscan, so we can hardly get how it
is supposed to work).
12. Ideally RegionAllocator would be AlignedAllocator!(16,
RegionAllocator!(FreeListAllocator!(LibcAllocator))).
That's maybe composition power pushed a bit far, but that's a good
analysis of what dsimcha provides.
This composition, with an alias to make it more friendly, has some
kind of beauty...
Beautiful compositions usually come with an overhead that can be avoided.
Example 1: FreeListAllocator!(LibcAllocator) has to be able to handle
allocations of all possible sizes, while the RegionAllocator only needs
a free list for allocated chunks of one fixed size.
But I agree that the internal free list could be opt-out, so that the
allocator is still usable for composing.
Example 2: The AlignedAllocator has to allocate size+alignment bytes
from the RegionAllocator (composeable™) to guarantee the correct
alignment, while if it is built-in, the region allocator can be much
more efficient.
