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. > 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. # At the moment, and with the current documentation your allocator is not really a "just work" object, since it still creates mental codebloat. >> 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... -- Christophe Travert
