James,
We don't have a "formal" guidelines. Just a few notes:
1. Use XMLCh instead of char so that Unicode is handled
2. And thus you have to use those utility functions defined in XMLString for
character manipulation.
3. And also make use of those constants in XMLUni and XMLUniDefs, e.g.
instead of doing something like this:
bool bad (XMLCh sign) {
if (sign == '+')
return true;
return false;
}
it should be something like this:
bool good (XMLCh sign) {
if (sign == chPlus)
return true;
return false;
}
4. And similarly for string comparison, e.g.
instead of doing something like this:
bool bad (XMLCh* encoding) {
if (encoding == "iso8859-1")
return true;
return false;
}
it should be :
bool good (XMLCh* encoding) {
if (!XMLString::compareString(encoding,
XMLUni::fgISO88591EncodingString))
return true;
return false;
}
5. When issuing messages, should always use the emitError method.
=> XML error, use XMLScanner::emitError
=> Validating error, use XMLValidator::emitError
All messages are listed in src/NLS/En_us/XMLErrList_EN_US.Xml, and generated
by tools/Xlat
Never print message directly using printf("[Error] cannot find element ... ")
nor sprintf nor cout ... etc.
6. Platform specific (#ifdef) code should be localized to utils (such as
utils/Platforms, utils/Compilers ...). Avoid coding #ifdef outside this folder.
7. and of course, as C++ does not have garbage collector, when we port Java code
over, we must take special care for "memory leak". If you "new" it, then you
"delete" it. (Don't make the same stupid mistake as we did in Xerces 1.5 :-< ).
8. ......
Tinny
"Murphy, James" wrote:
> 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]
