My understanding is that calls to Transcode will perform the allocation, but it is the caller's responsibility to free the memory when it is no longer being used. That said, there have been suggestions that Xerces provides a "freemem" function to allow the caller to free the memory. I don't believe that such a function has been implemented. Technically it shouldn't be needed unless you are trying to address the problem of allowing multiple memory managers to exist.
From my own experience, I call Transcode in numerous places and (to the best of my knowledge) always perform a delete[] when I'm done with the buffer. To date, I have not seen the errors when freeing up memory as other have. My usage may not be typical. My application never retains the buffer returned by Transcode for more any length of time. Usually the data is acted upon immediately and released or the data is copied into private data structures and then released. I can't help but wonder if there is some memory corruption in Xerces that becomes apparent when the buffers allocated by Transcode are retained across numerous calls to unrelated Xerces functions. Don At 07:40 AM 11/13/2001 -0800, you wrote: >I am still fairly new to Xerces so perhaps I'm missing something here, but >it seems that there are some transcode methods available in the XMLString >class which take a buffer to write into. This way, the caller can be >responsible for allocating the buffer and cleaning it up, rather than have >the Xerces library allocate the buffer and have the caller be responsible >for cleaning it up. > >On a related question, does Xerces provide an interface to clean up memory >allocated using the transcode() method? If the API is to be maintained as >is, i.e. having the library allocate memory which is to be freed up by the >caller, and if there is no such 'deallocate' method, perhaps one should be >added as a static member of the class in question. > >Samar Lotia > >-----Original Message----- >From: Don Mastrovito [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, November 13, 2001 8:08 AM >To: [EMAIL PROTECTED] >Subject: Re: Freeing memory allocated by transcode() in Borland C++ >Builder > >Ralf, > >If you use the BCB5 project files to build your copy of Xerces, the DLL >produced will utilize the multi-threaded run time library CC3250MT.DLL and >memory manager BORLNDMM.DLL supplied with your copy of C++Builder5. I >chose not to statically link these libraries with Xerces so applications >and Xerces will use the same copy of the memory manager. The -tWM switch >tells the compiler that the target image is for Windows and is >multi-threaded. I believe this is the default setting for most >projects. Naturally, your application must use the same multi-threaded >runtime and memory manager as the Xerces library. If you are statically >linking these into your application, that's the source of your problem. > >I've read the most of the chatter about releasing memory returned by >Transcode. The problems seem to affect all build environments (VC++, Sun, >etc.). I have no reason to think what you are seeing is specific to the >BCB build of Xerces. > >BTW, I don't keep the BCB4 project up to date. So if you are building with >it, I'll lend words of wisdom, but you are largely on your own. Sorry, but >I no longer have BCB4 installed. > >Don > >At 06:02 PM 11/11/2001 +0100, you wrote: > >Hi, > > > >I just have a small problem with freeing the memory which was reserved > >by transcode(). The problem seems to be that my program just can't > >free the memory allocated by Xerces. I read about this problem very > >often here on the list and there was said, the solution is to use a > >multithreaded DLL version of the runtime library - but I couldn't find > >any option or something like this in C++ Builder. I found a flag > >called -tWM, but it doesn't help anything, the problem occurs even > >after a full build. > >Did anybody encountered the same problem with C++ Builder ? > > > >Regards, > >Ralf Ebert > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
