Hi, Alberto. Makes sense. Will try it when I get that far. Thank you.
Hiran > -----Original Message----- > From: Alberto Massari [mailto:[EMAIL PROTECTED] > Sent: Friday, February 06, 2004 1:14 PM > To: [EMAIL PROTECTED] > Subject: RE: MemBufInputSource with CString > > > At 12.36 06/02/2004 +0100, Chaudhuri, Hiran wrote: > >Hi, Lei. > > > >Having followed this thread, a question arises for me. > >I am in a similar situation with an application that keeps its > >configuration in an XML file. This file is also intended to contain > >localized messages. I thought that to be a good idea as XML > should handle > >Unicode, and of course I'd compile my VC++ appication with Unicode, > >expecting CString to work on 16 bit characters (or whatever > appropriate) > >to support Japanese messages. > > > >Now how do I have to use the unicode CString with Xerces? Is there a > >suitable XMLString::transcode method? > > When the CString is used with _UNICODE defined, its internal > storage is the > same Xerces uses; so you should just cast it using (LPCTSTR). > > Alberto > > >Hiran > > > > > > > -----Original Message----- > > > From: jiang lei [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, February 04, 2004 9:41 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: MemBufInputSource with CString > > > > > > > > > Hi Jimmy, > > > > > > A few suggestions: > > > > > > 1.in your function void X(CString setting, CString changeval) , > > > Passing parameters by object is usually not a good idea. > > > Unless, of course > > > you want to make copies and leave the masters intact.( > CString's copy > > > constructor, however, will share the master's buffer if the > > > LPCTSTR() cast > > > is not used.) > > > > > > 2. Notice that CString's internal buffer is of type "TCAR" > > > rather than the > > > intrinsic c type "char". It will change into "wchar_t" if > > > someone compiles > > > your program with a "UNICODE" directive. I'd preffer > > > std::string in this > > > case. But in your program I did not see any necessity to > use a string > > > object. A simple "const char*" pointer will work just fine. > > > > > > 3. AFAIK XercesDOMParser will delete it's internal > document in it's > > > destructor. So if you delete the parser in ParseDocument(), the > > > "DOMDocument"pointer you returned will be invalid and cause a > > > protection > > > fault if you try to use the object. On the other hand if you > > > don't delete > > > it, there will be a memory leak. So your program can either: > > > keep a pointer to the parser when you use "new" to > > > create it. Make sure > > > the parser lives long enough until you've finished using > it's internal > > > document object. and then delete the parser. > > > or > > > make a copy of the parser's internal document and > > > delete the parser in > > > ParseDocument(); > > > > > > remember in C++ every object created with "new" should be > > > destructed with > > > "delete", and it's up to you to keep those objects valid. > > > > > > > > > > > > regards > > > > > > Lei > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
