irving says: > char *foo = str.transcode();
transcode() allocates space for the char* using new[]; the caller is responsible for delete[]ing it. This isn't clearly documented; the description of transcode() says that it returns a copy of the string, but it doesn't explicitly say that the caller must delete[]. --- That's not my memory leak. Spotlight will give you a stack trace with the function name, source file name and line at each point in the stack trace. The place in my code where the memory that leaks is fetched is: DOMString str = el.getAttribute( attributeName ); the actual place where the memory is allocated with new is in a call to cloneStringHandle somewhere in the DOMString implementation. I think I do have another leak as you describe, come to think of it. I had thought that the caller I passed it to would dispose of it, but it doesn't since that caller can also take static strings. It happens that I have a huge number of memory leaks in my code. The text file giving the stack traces is about 400k. I've actually been fairly careful to delete memory as best I could - to have that many leaks is pretty suprising. It happens that both the Xerces library and the GUI library I'm using use reference counted things (with different implementations of a reference counter - it's hidden in Xerces). That's a nice idea if it's used right but I have the impression that making a small mistake with forgetting to delete something can leave a whole forest of objects in memory referring to each other. Mike [EMAIL PROTECTED] http://www.goingware.com Michael D. Crawford GoingWare - Expert Software Development and Consulting http://www.goingware.com [EMAIL PROTECTED] Tilting at Windmills for a Better Tomorrow
