Sure does - and that makes sense.  I take it then that there is NOT an
implementers guide that discusses things like this...  That's fine - I'll
forward questions I have to the list.  
thanks

Jim

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 18, 2001 1:30 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Xerces Coding Guidelines
> 
> 
> 
> Hi James,
> 
> String constants are bad in the C++ version of the parser 
> because they are
> not Unicode.  In Java, it's not problem, because all Java 
> characters and
> strings are Unicode.
> 
> Likewise, sprintf() is fairly useless because it doesn't 
> handle Unicode
> strings.  wsprintf() is available on some platforms, but even 
> that is not
> guaranteed to handle Unicode strings because the C++ compiler is not
> obliged to encode wchar_t in Unicode.
> 
> Hope that helps...
> 
> Dave
> 
> 
> 
>                                                               
>                                     
>                     "Murphy, James"                           
>                                     
>                     <James.Murphy@exce        To:     
> "'[EMAIL PROTECTED]'"             
>                     lergy.com>                
> <[EMAIL PROTECTED]>                       
>                                               cc:     (bcc: 
> David N Bertoni/CAM/Lotus)            
>                     07/18/2001 10:07          Subject:     
> Xerces Coding Guidelines               
>                     AM                                        
>                                     
>                     Please respond to                         
>                                     
>                     xerces-c-dev                              
>                                     
>                                                               
>                                     
>                                                               
>                                     
> 
> 
> 
> Hey Tinny - I was wondering if you had anything I could 
> review (besides the
> src) to get a feel for coding style and idioms.
> 
> For example I noticed the string function wrappers in 
> XMLString.  But was
> wondering if there is any kind of manifesto concerning what 
> is cool and
> what
> is not.  For example I dont see many sprintf calls or and 
> string constants
> anywhere.  In the Java version there were plenty sprinkled through the
> code.
> 
> 
> Thanks,
> Jim
> 
> > -----Original Message-----
> > From: Tinny Ng [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, July 18, 2001 11:20 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: memory usage/performance for xerces-c 1.5.0
> >
> >
> > There is a known memory leak in Xerces 1.5.  A bug-fix
> > release Xerces 1.5.1 is
> > going to be released soon (within these two days).  You can
> > try our latest
> > nightly build
> > http://xml.apache.org/dist/xerces-c/nightly/2001-07-17/ which is
> > the candidate for Xerces 1.5.1 and see if this solves your problem.
> >
> > Tinny
> >
> > Jeremy Ford wrote:
> >
> > > I'm involved with a project that is trying to parse xml
> > files of size 20
> > > Megs or greater.  We are using xerces-c 1.5.0 xml parser on
> > Windows 2000.
> > > Validation is turned on.  We are consistently running out
> > of memory (Windows
> > > 2000 reports that we are running out of virtual memory and
> > then programs
> > > promptly start to crash as they can't allocate more) around
> > the 3rd or 4th
> > > file.  As a test, I decided to run the parser repeatedly
> > with one 3kb file
> > > instead.  At first, the parser went very quickly, parsing
> > the same file
> > > approximately 1000 times in 1 minute.  After letting it run
> > for several
> > > hours (10+), it now takes the parser over 3 minutes to
> > parse the file.
> > > Also, using the task manager, I noticed that memory usage
> > peaks at 190,000 K
> > > while parsing the file over the 3 minute period.
> > >
> > > My assumptions:
> > >
> > > When parsing over a 3k file, memory should increase to some
> > small finite
> > > level and then go back down when parsing is finished (but
> > not to previous
> > > level due to overhead).  This should happen repeatedly.  I
> > didn't expect to
> > > see 190,000K and the slow down.
> > >
> > > XML Description:
> > >
> > > Very simplistic.  Root node contains multiple nodes that
> > are PCData.  It
> > > also contains a few nodes that have children.  The children
> > are PCData as
> > > well.
> > >
> > > This leads me to the following questions.
> > >
> > > 1)  How large of a file can xerces handle?
> > > 2)  Is this the kind of performance I should expect after 
> continuous
> > > parsing?
> > > 3)  Is there anything that I can do differently?  Is there
> > anything that I
> > > should be calling that I'm not.
> > >
> > > Here is the code that I'm using.
> > >
> > > void main(int argc, char* argv[])
> > > {
> > >         XMLPlatformUtils::Initialize();
> > >
> > >         for(;;)
> > >         {
> > >             DOMParser parser;
> > >             parser.setDoValidation(true);
> > >             parser.setIncludeIgnorableWhitespace(false);
> > >             parser.setErrorHandler(new XmlErrorReporter());
> > >             parser.parse("test.xml");
> > >
> > >             DOM_Document doc = parser.getDocument();
> > >             DOM_Element root = doc.getDocumentElement();
> > >         }
> > >
> > >         XMLPlatformUtils::Terminate();
> > >         return 0;
> > > }
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com
> > >
> > >
> > 
> ---------------------------------------------------------------------
> > > 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]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to