[EMAIL PROTECTED] wrote:

> A long time ago, Bernd Abel wrote:
> ...
> Is there a reason why you force the code to use macros instead of setting
trap addresses?

and Ben Combee wrote in reply:

> 1) settings traps won't work on future ARM-based Palm OS devices

Well, I was not directly writing that stuff with PalmOS 5 in mind, I simply
use to play by the API rules. And, remembering David Fedor's "Next Generation
OS" talk at PalmSource 2000, it seems to be a good idea to do so.

However, palm.palm-dev, do you think there's an alternative to using macros?
Just tell me your ideas.

> 2) Only by using a macro can you store information about the source file
and line number where the allocation was originally made.  I've not looked at
Bernd's library, but I'm fairly sure he's using __FILE__ and __LINE__ to pass
in information that helps track the allocation.

You're absolutely right, Ben. The C macros are:

#ifdef USE_HEAPSPY
#    define HANDLENEW(handle, size) handle = MemHandleNew(size),
HeapSpyPrintNewHandleTag(#handle, (unsigned long) handle, size, __FILE__,
__LINE__)
#    define HANDLEFREE(err, handle) HeapSpyPrintFreeHandleTag(#handle,
(unsigned long) handle, __FILE__, __LINE__), err = MemHandleFree(handle)
// ... some more macros
#else
#    define HANDLENEW(handle, size) handle = MemHandleNew(size)
#    define HANDLEFREE(err, handle) err = MemHandleFree(handle)
// ...
#endif

thus optionally writing corresponding XML tags to the host file after each
allocation/deallocation. Additionally, since I want to see the MemHandles'
variable names in my XML file, I'm using unary macro calls.

and there is a top 3)

Some folks are using wrappers around MemHandleNew/Free during debugging their
apps. Since these wrappers could be useful during hunting for memory leaks,
they should be usable inside my macros.

BY THE WAY: Does anyone out there have further comments on HeapSpy? I noticed
a large number of downloads, but was never getting any feedback, so either
it's unuseable or working perfectly for everyone ;-). I'm still thinking
about some more Java tools which deal with the XML code, e.g. a program which
generates an HTML table from the XML code, thus showing me the memory
structure etc.

However, builtin memory leak detection in POSE, as announced for version 3.4
will be a much better solution, so, hopefully, using extra tools would become
obsolete soon.

Cheers,

--Bernd--
<http://www.berndabel.de>




-- 
For information on using the Palm Developer Forums, or to unsubscribe, please see 
http://www.palmos.com/dev/tech/support/forums/

Reply via email to