>
> I took a quick look with particular interest
> in what you have to say about scoped allocators.
> It seems to me that there is some overlap with
> what you are doing and the work by Pablo Halpern in
> his N2523 submission to WG21 entitled "The Scoped Allocator
> Model".
Seehttp://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2523.pdf
>
> IMO Pablo's proposal is more thought through.
> I recommend you take a look.
Before I post this article, I read submissions to WG21 related to
Allocator, such as n1850, n1509, n2387, n2523(n2446), n2436, n2486,
n2524, n2554.
You mentioned "The Scoped Allocator Model", so I read it though again
(
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2523.pdf and
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2446.pdf). I
don't find common points between them except the similar name:-) Would
you point out them for me?
"GC Allocator" focus:
1. It's a better "Smart Pointer".
2. Deleting objects manually is no need more if you use "GC
Allocator".
3. Use non-static allocator instances to allocate memory instead of
global new/delete procedures. Then multithreaded locks are OPTIONAL.
You can use explicit locks if you need.
>
> [ huge prose snipped ]
> The prose snipped seems to be a copy of the PDF article.
> I am suprised the moderator did not comment on this.
> It makes your post very long.
>
>> When you creating a GC Allocator, You can use STD_NEW, STD_NEW_ARRAY
>> to new objects.
>> Frankly speaking, I don't like STD_NEW and STD_NEW_ARRAY.
>
> Take a look at Pablo's article to see an alternative
> approach that does not use macros or concepts.
>
In fact, I can use a series of functions instead of STD_NEW. For
instance:
template
Type* New(AllocT& alloc) // new(alloc) Type
{
void* p = alloc.allocate(sizeof(Type),
DestructTraits::destruct);
return new(p) Type;
}
template
Type* New(AllocT& alloc, ArgT1 arg1) // new(alloc) Type(arg1)
{
void* p = alloc.allocate(sizeof(Type),
DestructTraits::destruct);
return new(p) Type(arg1);
}
...
Then you can use New(alloc, arg1, ...) instead of STD_NEW(alloc,
Type)(arg1, ...).
But I think it is better if I can get type-info when overriding
operator new:
template
inline void* operator _new(AllocT& alloc)
{
return alloc.allocate(sizeof(Type), DestructTraits::destruct);
}
template
inline void* operator _new[](size_t count, AllocT& alloc)
{
return DestructTraits::allocArrayBuf(alloc, count);
}
When new(alloc) Type(arg1, ...) is called, the C++ compiler will
detect if there is a mataching operator _new. If there isn't,
then it will try a normal operator new.
> One final point, it seems to me that there is a need
> to bear thread safety in mind. You just say "it's not
> needed". Can you explain why please?
** No Multithreaded Locks **
Why doesn't GC Allocator need multithreaded locks?
Memory allocation = System memory block management + Memory management
algorithm
The underlying system memory block management is provided by OS. It
will optimize large memory block allocation (allocating small objects
is supported, but doesn't need to optimize). And It is thread/process
safe.
Memory management algorithm is provided by C/C++ runtime library, or
other libraries. Memory management algorithms ARE only algorithms.
Most of them are designed to be thread safe.
If we use global new/delete or malloc/free procedures to allocate
memory, thread safe is a MUST (because all threads use these
procedures), not OPTIONAL. But if we use allocator instances to manage
memory, then thread safe becomes OPTIONAL.
Why? Sharing GC Allocator in multi threads is not recommended. It
means that sharing memory between threads is also not recommended. If
you REALLY want to share memory, use new/delete or anything else.
For users of GC Allocator, we suggest that only use ONE BlockPool
instance in ONE thread, and ONE thread may use multiple PRIVATE
"ScopeAlloc" instances (depend on your requirement) to allocate
memory.
Regards,
shiwei xu
