I am not experienced in the d programming langage, so rather than writing a real review, I will just ask questions when I am confused. I may be confused because I am not very experienced, but I may also valuables hints to make things clearer to other experienced or not so experienced d programmers.
Concerning the gcallocator API, why is there no template method that forwards to new T? Is the user obliged to call allocate, and then initialise the object manually? Would it not be useful if all Allocators use Exceptions that derives from the same Exception subtype ? Now about RegionAllocator... I took me a lot of time to understand how it works, and I am not 100% sure about how it works. I had to rewrite my review when I understood something new and discovered what I had understood before was false. This is how I think it works now: Several copies of a RegionAllocator works just the same. When the last is destroyed, all the memory allocated is cleared. You can build a RegionAllocator that uses the same stack as the previous RegionAllocator. This "pauses" all the copies of the previous allocator: they can no longer allocate or free memory until all the copies of the new RegionAllocator are destroyed. Is this "pause" behavior really a desirable functionnality? This makes the whole behavior of RegionAllocator very confusing, because you have to make the disctinction between copies of a RegionAllocator and RegionAllocator that shares the same Stack. Well... copies of a RegionAllocator do share the same Stack, so it is confusing. Moreover, it is rather dangerous to use. What if a copy of a RegionAllocator sharing the same stack as a previous RegionAllocator is kept unexpectedly alive somewhere while the previous RegionAllocator goes back into action? What happens if all copies of a RegionAllocator dies when a RegionAllocator using the same Stack and created later is still alive? I use 'die' and 'alive' to emphasize the fact that when you copy those objects you don't control everything that happens to them. Those allocators are supposed to be put in containers or things like that, aren't they ? They might really have a life of their own (I would rather have them being classes that you eventually make scope classes, but that is not the main point). This behavior is IMO too dangerous to be desirable in the standard library, especially if users just start to make newRegionAllocator and do not realize they prevent each other from working fine. If I admit that the behavior of RegionAllocator sharing the same stack but are not direct copies of each other is really what expert users want, this is badly documented: - regionAllocatorStack.newRegionAllocator does not tell it invalidates the use of previously created newRegionAllocators. - Same for .newRegionAllocator. Moreover, the name of this function is very confusing. One could think it is brand new, whereas it reuses the same thread-local stack. - Introduction of RegionAllocator comment do not tell that copies of a RegionAllocator are different from RegionAllocators sharing the same stack (but that do not share the same correctRegionIndex). - regionAllocator.allocate do not tell it checks it is the lastly created RegionAllocator that shares the same stack (but not the same correctRegionIndex). Now, do the users of RegionAllocator really want memory to be automatically freed when the RegionAllocator is destructed with no explicit request, and no way to prevent this? Important point: opAssigns seems not to support self assignment of a unique copy of a RegionAllocator. I am really sorry if I sound too agressive, and make it sound like all these functionality are not useful. This RegionAllocator may have applications and advantages that I am not aware of. I just tought when I started to read the documentation and the code that this allocator would bring to the standard library an easy and rather safe way to allocate memory on a stack by moving a pointer up and down when memory is requested or discarded, whereas this allocator is much more complicated than that. -- Christophe Travert
