Mike suggests:
> What we on the other hand would be able to do, is to use a specialized
> heap,
> telling it that "all allocations from this point is on the behalf of
> xxyy"
> and then when exiting telling it "xxyy is no more responsible for memory
> allocations". Probably then by C++ RAII. At least it would remove all
> those
> bad "UT_String" messages, but tell us "class FooBar allocated 'n'
> UT_strings
> that it didn't release". Perhaps it could be useful?
>
> The somewhat troublesome part is that we possibly need a new heap
> allocator.
> Trust me (I've done it before) when I say that it's not something we
> want to
> do. Even that it would make debug-builds of AbiWord become self-checking
> (in
> debug-mode) it's not something we want to do.
>
> ... I think.
FWIW, a company that I work for does something like this for its major
product/library. It's quite useful to keep track of memory allocations, leaks
(file and line number even), high-water marks, etc... and print those stats on
termination. Is it worth our time and trouble to do this in Abi? I'm less
convinced of that, but I'm open for suggestions.
I do know for a fact that heap allocations don't occur *for* UT_String or
UT_UCS2String classes (though these classes do allocate member variables on the
heap). So it's not like we're forgetting to call delete on them... or are we?
I'm thinking that the destructor should get implicitly called here: Expert
advice is sought after...
void foo() {
UT_String bar = "hiya";
doSomething(bar);
// destructor implicity gets called as we leave scope
}
Dom
