Am 08.09.2011, 00:05 Uhr, schrieb Timon Gehr <timon.g...@gmx.ch>:
On 09/07/2011 11:43 PM, Christophe wrote:
Ok, don't drop this feature then. But the API is too complicated. I
think you can keep the same functionality with an API that is much
easier to understand:
- Make RegionAllocatorStack private. This is implementation detail no
one has to know about.
- Create a method for RegionAllocator that is called something like
"invalidatingCopy", which is the same as creating a new regionAllocator
with the same regionAllocatorStack. Tell about the fact that the
invalidatingCopy make the calls to the RegionAllocator being copied
throw until all instances of the invalidatingCopy go out of scope.
- Make a function to call "invalidatingCopy" on the default thread-local
RegionAllocator, to replace newRegionAllocator, but I insist, please use
a different name since it is confusing: it makes you think the allocator
is breand new, whereas it reuses a common stack.
It is a brand new allocator which operates on an existing stack.
- Make a function to create a brand new allocator with its own stack,
and specifies that the previous function may be more efficient.
With this, I think everybody will understand easily what is an
invalidatingCopy of your allocator. You can explain in allocate,
free and other methods that you check for the existence of an
invalidatingCopy without having to tell anything about
sharing RegionAllocatorStack with other RegionAllocators.
Actually, I think the current semantics are a lot less confusing than
the invalidatingCopy proposal:
alloc2 = alloc1.invalidatingCopy();
alloc3 = alloc1.invalidatingCopy();
now alloc2 is invalid, even though you called the invalidatingCopies on
alloc1 only. To get why this is the case, the programmer has to
understand that there is an underlying stack structure, confusingly
hidden away. Therefore, hiding the RegionAllocStack is a leaky
abstraction and does not help. It even hurts, because with it you cannot
pass around a RegionAllocStack without a RegionAlloc operating on it.
alloc2 = alloc1.exclusiveCopy();
alloc3 = alloc1.exclusiveCopy();
Exclusive sounds like it goes beyond the boundaries of the instance you
call it on. I'm all for speaking names if a function does more than what
is common sense. ;)
The sole purpose of GCScan is to feed additional, potential pointers to
the garbage collector, right?
