Re: [ALACPP] C++ GC (was smart pointers in C)

["Arlo Belshee" <arlo@xxxxxxxxx>]

> Ah! It seems like you are intending to still use the standard heap
> allocator. That will make it pretty hard for the mark/sweep allocator to
> win. Half the fun mark/sweep is having heap allocs that are almost as fast
> as stack allocs.

What I'd really prefer is to make the selection of allocator orthogonal to the
selection of memory management strategy. It'd be nice if the boost shared ptr
allowed you to easily specify an allocator as part of the type (you can use it
with an allocator, using a factory method and its custom destructor facility).
Then the final user could choose which one to use.

Hey! There's a use for monostate: provide a templated child for shared
pointers which have a monostate factory member and perform all of their
allocations from that allocator. Then, you get the best of both worlds: the
actual pointer type does not contain the allocator information, so can be
passed around between libraries without knowledge of the allocation strategy,
yet you can define the allocation strategy for a given type with a single
typedef. For that matter, you can re-define the default allocation strategy
for all types used in a given library with a single type computer.

Besides, they've sped up the default heap a lot over time - custom allocators
don't necessarily beat it any more. See earlier discussion on Alexandrescu's
small object allocator's performance vs MSVC 6.0's default heap.

If however, you know of a really high performance allocator, it might be nice
to provide that as an option one for the gc pointer.

Arlo


_______________________________________________
alacpp mailing list
alacpp@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/alacpp