[Gc] Patches for C++ to support throw() declarations, and that throw std::bad_alloc on OOM.

Talbot, George Gtalbot at ansarisbio.com
Tue Nov 10 04:19:14 PST 2009


Correct...OOM handling doesn't change unless you call gc_cpp_init().  I'll change that to a macro as suggested by Ivan when I have the chance on Wednesday.

As far as the GC_MALLOC() vs. GC_MALLOC_UNCOLLECTABLE(), I can understand where you're coming from.  My problem is the STL...if I leave this as GC_MALLOC_UNCOLLECTABLE(), then I have to use a custom allocator for any STL code that I use in my program.  This is really painful; the data types change (i.e. std::vector<int> becomes std::vector<int, gc_stl_allocator>, etc.) making interfacing bits together somewhere between difficult to impossible.  I tried going this way in my relatively decent sized program that uses the GC, and it was way too invasive.

I could add a function to the public interface to make this switchable through a function pointer called within operator new/new[].  Would that be better?

--
George T. Talbot
<gtalbot at ansarisbio.com>
________________________________________
From: gc-bounces at napali.hpl.hp.com [gc-bounces at napali.hpl.hp.com] On Behalf Of Boehm, Hans [hans.boehm at hp.com]
Sent: Tuesday, November 10, 2009 1:28 AM
To: Talbot, George; gc at linux.hpl.hp.com
Subject: RE: [Gc]  Patches for C++ to support throw() declarations, and that    throw std::bad_alloc on OOM.

> Slightly more controversially:
>
> *  The standard operator new that gc_cpp.h and gc_cpp.cc
> provides allocates memory with GC_MALLOC() instead of
> GC_MALLOC_UNCOLLECTABLE().
>
Thanks.

Unfortunately, I'm still concerned about this.  The problem is that this significantly changes the behavior of an interface that's been around for a while.  The original idea behind this interface was to use garbage-colelcted allocation only where it was requested.  Right or wrong, this would change that design decision retroactively.

I guess out-of-memory handling doesn't change visibly unless you call gc_cpp_init()?  Thus the behavior is backward compatible?

Can this be solved by just providing an alternate gc_cpp.cc to get the alternate behavior?

Hans
_______________________________________________
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