Dave wrote:
I was thinking of something similar, but decided that exceptions should
_always_ use the static MemoryManager instance. Your idea will certainly
work, but can you think of a real use case where this would be valuable?
...
...
It would certainly work, although I wonder if it the function should
really be called "getExceptionMemoryManager," since the global
MemoryManager instance is always available through the static pointer. It
could be confusing if an implementation returned something other than the
global instance, and a user thought they were really getting the global
one.
I agree in renaming it to "getExceptionMemoryManager" or whatever name makes
its intention more obvious to the user.
But in my opinion it's a much cleaner and more usable approach manifesting
this special case into the pluggable memory management API than
using an unwritten convention like always using the global memory manager
instance for exceptions.
The main reason for this approach is the requirement to have fine-grained,
pluggable control over the memory allocations
not only for normal program flow but in exceptional circumstances as well.
This enables one to form a hierarchy of memory manager instances for each
exception-scope
in almost the same manner as in the normal, non-exceptional scope this is
about.
use cases for this are a thread-specific and/or multiple nested memory
manager instances that
can serve memory requests of exceptions without synchronizing with the
global memory manager.
an additional useful side-effect is that all remaining allocation requests
on the global memory manager (after initialization)
could be thought of as a gap in the memory management hierarchy for
diagnostic purposes.
tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
