[Gc] Patches for C++ to support throw() declarations, and that
throw std::bad_alloc on OOM.
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
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?
Gc mailing list
Gc at linux.hpl.hp.com
More information about the Gc