Hiro, > 1. BCB5
We had a set of BCB5 project files before, but just they are now out-of-date and thus are not distributed. You can find them from our CVS (http://cvs.apache.org/viewcvs.cgi/xml-xerces/c/Projects/Win32/BCB5/). So if you can submit your patch based on our structure, it is appreciated and we can just simply update them. Thanks! > 2: Memory Leak I think this is similar to the one reported in Bugzilla bug 9561 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9561). It is appreciated if you can post your suggestion in that bugzilla bug, and we will consider it once we are ready to fix this bug. Thanks! Tinny ----- Original Message ----- From: "Hiroyuki Shimada" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, September 29, 2002 8:06 AM Subject: Memory Leak > Hello, everyone. > > My name is Hiro. I am trying to use Xerces-C 2.1.0 with Borland C++ > Builder 5 Update 1. > > 1. Project Files For Borland C++ Builder 5 > > I succeeded to make a project group file and project groups for > XercesLib.dll, samples and tests for it. > They works quite well. > > The project files were converted the dsp files in the Project\Win32\VC6 > directory with the VC++ Project Conversion Utility of the C++ Builder 5 > and the project group file was created by the IDE of C++ Builder 5. > > I would like to send the project group file and project files to > Xerces-C project or to publish the archive of them at my site so that > every Xerces-C user to be happy. > Please tell me what the best way for the project team and every user is. > > > 2. Memory Leak > > I found some memory leak problems in Xerces-C 2.1.0 by CodeGuard (a > mamory and resource checker accessorized in C++ Builder 5) while I made > and test the project group file and project files for C++ Builder 5. > > For example in the RefVectorOf class template in the util\RefVectorOf.c. > When we add an element, we use: > > template <class TElem> void RefVectorOf<TElem>::addElement(TElem* const toAdd) > { > ensureExtraCapacity(1); > fElemList[fCurCount] = toAdd; > fCurCount++; > } > > and the destructor is: > > template <class TElem> RefVectorOf<TElem>::~RefVectorOf() > { > if (fAdoptedElems) > { > for (unsigned int index = 0; index < fCurCount; index++) > delete fElemList[index]; > } > delete [] fElemList; > } > > When TElem is XMLCh, the destructor should release each element as: > > delete[] fElemList[index]; > > I could fixed this problem to use an wrapper below such as: > > RefVectorOf<ArrayWrapper<XMLCh> > fMember; > > /** > * The ArrayWrapper class template is a very simple wrapper for the array > * created by the new[] operator and protects the memory leak of the array. > * > * The ArrayWrapper receives a pointer to the first element of an array > * created by the new[] operator with its constructor, and it release the > * array with the delete[] operator in its destructor. > */ > > // interface > template<class TArray> class ArrayWrapper > { > private: > TArray *m_Array; > protected: > ArrayWrapper(const ArrayWrapper<TArray>& o); > virtual ArrayWrapper& operator=(const ArrayWrapper<TArray>& o); > public: > ArrayWrapper(TArray *Array); > virtual ~ArrayWrapper(); > > virtual TArray *GetPointer() const; > }; > > // ------------------------------------------------------------------------- -- > template <class TArray> > ArrayWrapper<TArray>::ArrayWrapper(TArray *Array) > : m_Array(Array) > { > } > > template <class TArray> > ArrayWrapper<TArray>::~ArrayWrapper() > { > delete[] m_Array; > } > > template <class TArray> > ArrayWrapper<TArray>::ArrayWrapper(const ArrayWrapper<TArray>& o) > { > } > > template <class TArray> > ArrayWrapper<TArray>& ArrayWrapper<TArray>::operator=(const ArrayWrapper<TArray>& o) > { > return *this; > } > > template <class TArray> > TArray *ArrayWrapper<TArray>::GetPointer() const > { > return m_Array; > } > // ------------------------------------------------------------------------- -- > > > > > Also the RefHashTableOf class template seems to have a memory leak > problem. > The put member function receive the key as void *, but the > RefHashTableOf never release the put key object. > I don't purchase the code so much yet, the put seems to receive either > new-ed object or not new-ed object. And the type of key is either array > such as an XMLCh* string or not array such as IdentityConstraint* > which points only one IdentityConstraint instance. > > The RefHashTableOf is used in so many place that it is hard for me to > fix them... > > > ---------------------------------------------------------------------- > Mail: [EMAIL PROTECTED] > Home Page: http://www.din.or.jp/~shimaden/ > Hiroyuki Shimada > ---------------------------------------------------------------------- > > > --------------------------------------------------------------------- > 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]
