Boris Kolpackov wrote:
Hi David,
David Bertoni <[EMAIL PROTECTED]> writes:
The recent changes to MemoryManager.hpp break deriving classes.
That shouldn't be a problem since 3.0.0 is allowed to break
interfaces.
Yes, but we shouldn't be gratuitous about it.
- virtual MemoryManager* getExceptionMemoryManager() = 0;
+ virtual MemoryManager* getExceptionMemoryManager() { return this; }
I realize this introduces some implementation into the MemoryManager
class, but I think it's worth it for compatibility.
There is a more important drawback in doing this: the pure virtual
function forces users who implement their own memory managers to
pay attention and decide what to return from this function. In
fact, memory managers that are used locally should probably return
the global memory manager (XMLPlatformUtil::fgMemoryManager), not
'this'. Otherwise there is a good chance that the exception thrown
will outlive the memory manager which manages its guts. So I would
say we should keep it pure virtual.
If they were using a local MemoryManager instance in their code, they would
likely have already tripped this bug. I'm painfully aware of the problem,
since I ran into in my own code. And if they haven't tripped over it, my
change doesn't modify the behavior of their code.
If we leave this as pure virtual, we need better documentation in the
header file so users understand the issues. Just saying "If the same
memory manager can be used, simply return 'this' from this function" isn't
going to help them make a decision.
I will add some more verbiage and a URL that references the Jira issue.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
