There is an alternative to using the transcode() member function in the DOMString. There are methods in the class XMLString that allow a caller to pass in buffers to transcode from/to. This means you allocate the memory for the buffer and you are responsible for deleting it. The only tricky thing is being able to calculate the size of the buffer required for the transcoding.
Samar Lotia -----Original Message----- From: Flint, Shmulik [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 24, 2002 10:37 To: '[EMAIL PROTECTED]' Cc: azoulay, uri Subject: deleting the buffer returned from DOMString::trancode() Hi, We�ve found a problem in our code. Our code is compiled in Visual C++, and uses the STL that comes with Visual C++. When we tried to delete (using delete []) the char* received from DOMString::transcode(), our code crashed. Our code is need to be with minimum dependency, so it is compiled with VC++ multithreaded runtime libraries as a static libraries. After a research, it seems that when using the static libraries, VC++ has different delete operator for the standard runtime libraries and the STL runtime libraries, and these two operator delete functions uses a different heap. Since Xerces doesn�t use STL, it is compiled with the standard library, and uses its operator delete. On the other side, our code uses STL, and use the STL library operator delete, so when our code deletes the pointer returned from DOMString::transcode() it crashes. Our workaround was to change DOMString and add a method to it: void DOMString::delete_buffer(char * pBuffer) { delete [] pBuffer; } My question is can such a method find its way to the standard release? It seem odd to me that the Xerces DLL is the one allocating the memory, but other code, from other executable file, which is linked with other libraries is in charge of deleting it. I think that DOMString should supply a method to delete the memory allocated by it, so the allocation and de-allocation will be performed by the same library and the same heap manager. Regards, Shmulik --------------------------------------------------------------------- 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]
