[Gc] More doubts: (beginner)

Sean Middleditch elanthis at awesomeplay.com
Tue Jan 25 06:48:39 PST 2005

On Tue, 2005-01-25 at 10:17 -0200, Renato Tegon Forti wrote:

> class B: public A {...};
> B* b = new B; //-> b is collectable ????????

Yes.  The gc class over-rides the new operator, and that is inherited by
its children - normal C++ inheritance rules apply here.

> If I have a class structure, like this:
> 	A (: public gc)
> 	|
> -------------
> |	|	|
> B	C	D
> 		|
> 		------
> 		|	|
> 		E	F
> And I derive A of gc, all derived class's now is collectable?

Unless you over-ride one of their new operators, yes.  Something I do is
have a simple base class with an atomic allocator (the base class has no
pointers) and then I give some children normal gc allocators (by
inheriting from gc) if they have pointers.
> 3 - Constructors and Destructor:
> Constructor and destructors are called in natural order?
> B* b = new B; //-> Constructor is called in creation?, and destructor is
> called when 'b' is not more needful, and GC destroy it? 

Constructor is called by C++ when the new operator is used, so the GC
has no way to over-ride that.  The destructor *is not called*.  You
should not use destructors in garbage-collected programs.  The whole
purpose of a destructor is to free resources, and with garbage
collection, that usually isn't necessary.  If you have classes that hold
references to non-collected resources (file descriptors/sockets, etc.)
you should manually release them when you no longer need them.

In cases where you must have a destructor (it does happen, especially
when mixing collected and legacy non-collected code) you must have your
class derive from gc_cleanup, not gc.  The gc_cleanup class will
register a finalizer.

Note that only very simple classes should do this.  There are some
strict rules about when finalizers can be called, and complex classes
will often break those rules, causing their destructor to never be

The GC documentation goes into detail on this, so I'd recommend reading
it over again.

> 4 - Arrays:
> Arrays work the same way?
> A *a = new A[10]; (???)
> ...

Except that their destructor will never be called; C++ doesn't make it
possible for the GC to do.

> 5 - I don't understand this --> A* a = ::new (GC, MyCleanup) A;
> When I should use this: A* a = ::new (GC, MyCleanup) A; I don't understand,
> Can you explain-me in detail?

That causes the object of class A to be garbage-collected (if it isn't
nrmally, say) and causes the function MyCleanup to be called when the
object is no longer accessible - this function might just invoke A's
destructor, for example.  Again, the rules about the kinds of objects
that should have finalizers apply - don't use them unless you absolutely

> When the object is inaccessible?
> 6 - What more tricks I need know to use GC correctly in my C++ applications?

Basically, don't use any tricks. ;-)  The GC will function fine so long
as you are writing fully legal, portable C++ code.  A lot of
tricky/hacky code (which isn't even technically legal) can confuse the
GC.  For example, on many platforms, pointers returned by malloc/new are
always aligned by 4, so the lower two bits are always zero - a lot of
code will use those to store flags.  You can't do that while using the

The other thing to keep in mind, especially when using legacy code, is
that any objects/memory created without the GC (any code that calls
malloc, calls ::new without the (GC), doesn't derive from gc or
gc_cleanup, etc) won't be scanned for pointers.  So even though those
objects might have pointers to GC-managed objects, the GC won't know
about those pointers, and may free your collectable objects while
they're still in use.

> Thanks to all.
> This GC is excellent work...
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list