Re: C++ Memory Management Innovation: GC Allocator

In fact, "GC Allocator" is NOT "GC".

"GC Allocator" focus:

1. It is a better "Smart Pointer".
2. Deleting objects manually is no need if you use "GC Allocator".
3. Use non-static allocator instances to allocate memory instead of
global new/delete procedures. Then multithreads locks are OPTIONAL and
you can use explicit locks if you need.

You can consider "GC Allocator" as a "Smart Pointer" or a "Allocator",
but It isn't a "GC".

Regards,

****wei Xu

On 4ÔÂ22ÈÕ, ÉÏÎç10ʱ13·Ö, "Chris Thomasson" <cris...@[EMAIL PROTECTED]
> wrote:
>
> I just want to know if I can use this proposal to efficiently allocate
in
> one thread and free in another. As for the GC aspect, well, that's fine
as
> long as there are no mandatory requirements. I personally would think
about
> dropping C++ _if_ it "forced" me to use a GC. Even if the GC was
> transparent, I need to be able to manually manage memory most of the
time. I
> don't want a GC running under my nose, so-to-speak... IMVHO, that would
go
> against the low-level nature of C++. I want to be able to use C++ to
create
> state-of-the-art allocators and garbage collectors... OS kernels, device
> drivers and other low-level applications... Its the low-level nature of
C++
> that's particularly attractive... This is only my personal take on the
> matter... Indeed.


-- 
      [ See http://www.gotw.ca/resources/clcm.htm
for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]