Arlo Belshee on 2 Jul 2003 20:17:01 -0000


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

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


>> 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.
>
> Unfortunately, allocation is tightly coupled with automatic memory
> management, at least of high-performance implementations.
>
> It's true that custom allocators are frequently not a win, but there is a
> whole ton of overhead in managing a manually-managed heap. The 1000
> millisecond times for allocating a raw are clearly much worse than can be
> achieved with a managed heap (typically they can allocate with just a few
> instructions).

I was thinking to make them orthogonal, and use a type computer to set a
default to be the fastest heap that will work for arbitrary timed new and
delete. Then, you can just provide a single partial specialization (for
gc_ptr) to use an optimized heap for gc objects, and still use whatever heap
you want for reference-counted objects.

I think that the code that I just posted allows that.

>> 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.
>
> I hear Java has a nice one. The CLR's is supposed to be pretty nice too. ;-)

;) Yeah, they both are. But neither of them seem to work so well in my vanilla
C++ projects, and they both prevent me from using the stack for RAII
(bastards).

Arlo


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