memory leaks: transcode patch for consideration

[h h <se...@hotmail.com>]

Dear all,

I sent a message earlier in january concerning memory leaks arising when you 
use DOMString::transcode(). There is currently no way to deallocate the 
memory if xerces is running with different RTL.

My only option for the moment is that my system will go in production with a 
xerces-c dll that has been hacked locally.

I proposed a patch to provide a free function in the cpp file that allocates 
the char *, and Curt sent me this mail where he proposed a better solution.

I think that we should have the patch proposed by Curt below in the xerces-c 
source. What is the procedure to include it?

regards.
-- Sebastien

>From: "Curt Arnold" <ca...@houston.rr.com>
>To: <se...@hotmail.com>
>Subject: Fw: transcode patch for consideration
>Date: Mon, 29 Jan 2001 16:53:29 -0600
>
>Here was a more comprehensive patch that I submitted for
>consideration a week or so ago.  Unfortunately, to no action or
>discussion.
>
>----- Original Message -----
>From: "Curt Arnold" <ca...@houston.rr.com>
>To: <xe...@xml.apache.org>
>Sent: Friday, January 19, 2001 11:27 PM
>Subject: transcode patch for consideration
>
>
> > I've put a zip file
>(http://home.houston.rr.com/curta/xalloc.zip)
> > with modified versions of a handful of files from the Xerces
>CVS
> > that I think provides a fairly nice solution to the debug RTL
> > problem that we have been discussing recently plus has some
>very
> > nice behavior for use with STL and other strings.
> >
> > There are a couple of aspects to the modifications:
> >
> > 1. A DOMString::free() and XMLString::free() are added that
> > indirectly call delete[] of the C++ RTL used by Xerces.  Using
> > these instead of an inline delete[] should eliminate the debug
> > mode crashes.
> >
> > 2. Existing code that uses delete[] inline has unchanged
> > behavior, crashes when Xerces and the calling app have
>different
> > RTL's and works if they are the same.
> >
> > 3. Parallel versions of char* transform() and XMLCh*
>transform()
> > are added that take an XMLTransAllocator* as an argument that
>is
> > used in the buffer allocation.  When these method are used, the
> > free() method of the same allocator should be used to release
>the
> > returned buffer.
> >
> > 4. Custom implementations of XMLTransAllocator can be used to
> > optimize the performance of transcoding for specific uses.  For
> > example, if you are transcoding a large number of short strings
> > sequentially and assigning them to STL basic_strings's, you
>could
> > write an allocator where free() is a NOP, something along the
> > lines of (grossly simplified)
> >
> > class MyAllocator : public XMLTransAllocator {
> > public:
> >     char* alloc(unsigned int size) { return mBuf; }
> >     XMLCh* alloc(unsigned int size) { return mXMLChBuf; }
> >     void free(char*) {}
> >     void free(XMLCh*) {}
> > private:
> >     char mBuf[1024];
> >     XMLCh mXMLChBuf[1024];
> > };
> >
> > void MyClass::DoSomething() {
> >     MyAllocator alloc;
> >     for(int i = 0; i < 100000; i++) {
> >         DOMString attr = ...
> >         str::basic_string<wchar_t> a(attr.transcode(&alloc));
> >     }
> > }
> >
> > All the available platform transcoders seemed to be readily
> > adaptable to passing in an arbitrary transcode with the
>possible
> > exception of the Mac which use ArrayJanitors and other fun
>stuff.
> > If that is needs to be maintained, then the implementation of
> > XMLTransAllocator::getDefaultAllocator() just needs to be moved
> > into the platform specific code.
> >
> >
> >
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com