Clearly Rick is correct about the need for this problem to be solved.

But why not use exceptions? This is EXACTLY what they're in the language for. A good overall exception handling system can make a software system easier to write and more reliable.

Seems like an obvious question.

C++ exceptions are not up to snuff on all platforms; see http://www.mozilla.org/docs/tplist/catBuild/portable-cpp.html for details, and tell Ramiro (mailto:ramiro@netscape.com) if you have new data.

Here are some links and prior art that should be incorporated into rickg's fine proposal:

Step 4: we already have an nsIAllocator, it has existed for a while: http://lxr.mozilla.org/mozilla/source/xpcom/public/nsIAllocator.h

Use it either by getting its service (for example, http://lxr.mozilla.org/mozilla/source/base/src/nsBuffer.cpp#324), or by statically linking with the xpcom library and calling the nsAllocator class's static methods (http://lxr.mozilla.org/mozilla/source/xpcom/public/nsIAllocator.h#88).

Arena links: http://lxr.mozilla.org/mozilla/source/base/src/nsIArena.h http://lxr.mozilla.org/mozilla/source/nsprpub/lib/ds/plarena.h

Smart pointers links: http://lxr.mozilla.org/mozilla/source/xpcom/public/nsCOMPtr.h http://lxr.mozilla.org/mozilla/source/xpcom/public/nsXPIDLString.h

/be

Since mozilla usually is not the only thing running in the system it is important to use recyclers only when they really have huge benefits .

In other cases it would be best to return as much memory as possible back to the system.

Re: exceptions:

I'd prefer mozilla not to use exceptions. Code generated by gcc seems much better/smaller when they are not used. Has anyone tried to compile mozilla with -fno-exceptions (and possibly with -fno-rtti)?

The only safe approach is to provide your own allocator that throws bad_alloc for platforms that don't yet support it. It's too easy to make mistakes, otherwise. Furthermore, have you considered that require in "if (blah==NULL) { do_whatever(); }" *also* results in additional code? I'd be somewhat surprised if gcc's implementation of exceptions is any worse than that. In any event, standard c++ will become more common over time, and all that NULL testing will no longer work on newer platforms.

If you can't use exceptions then you'd almost be better off banning pointers altogether. Use smart pointers, auto pointers and references everywhere. Or maybe even change new() to never return NULL unless there really is no more memory, in which case you can panic there. Otherwise all the checking and specical casing will make the code bloated, buggy and impossible to comprehend.

As for exceptions, you can establish rules for object ownership and transfer thereof so that a generic goto error label will know how to clean up before returning an error code. Error checking then becomes a simple, unobtrusive macro. Or how about adding an exception arg to (most) every funtion? The jmc approach. It's ugly but it works.

Simply calling free() or delete is not enough to give the memory back to the system in most cases. An object allocated from the middle of a page can't be returned until everything else on that page is released, and even then you can't sbrk() back down if there are other things allocated ``after'' it.

As far as exceptions go, we do currently use -fno-exceptions and -fno-rtti with gcc/egcs, and the space savings are considerable. Also, use of exceptions across XPCOM boundaries is pretty much begging for pain. I don't think that even MS COM permits exceptions across COM interface boundaries, and they're a lot more prescriptive about compiler behaviour than we are.