Arlo Belshee on 2 Jul 2003 18:52:01 -0000 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: [ALACPP] C++ GC (was smart pointers in C) |
> 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