[xsd-users] Returning data by criteria

[Bidski]

Hi Boris,

What I was missing in the code to pre-load the schema file was a call to 
::xercesc::XMLPlatformUtils::Initialize();. Apparently this is needed for 
the calls to SAX2XMLReader.

Loading time is still hovering at the 3 second mark, even with the addition 
of my other schema/xml files (6 schema/xml files total). The problem I have 
now are memory leaks. Looks to be as though I have 1 memory leak for each 
for schema/xml file. Can you point me in the direction of any specific 
clean-up calls that I need to make to the xerces library? I found that I was 
getting a fairly substantial memory leak from the SAX2XMLReader which was 
resolved with a call to ~SAX2XMLReader();, but I am at a loss to what is 
causing these other memory leaks and Visual Studio is not giving me much to 
go on. Following is an example of one of the memory leaks I am getting.

Detected memory leaks!
Dumping objects ->
{7541} normal block at 0x00727CA0, 148 bytes long.
 Data: <H k      z   ~  > 48 DC 6B 00 CD CD CD CD 84 7A 1E 12 90 7E 1E 12

Any thoughts?

Bidski

--------------------------------------------------
From: "Boris Kolpackov" <boris at codesynthesis.com>
Sent: Saturday, February 20, 2010 2:48 AM
To: "Bidski" <bidski at bigpond.net.au>
Cc: <xsd-users at codesynthesis.com>
Subject: Re: [xsd-users] Returning data by criteria

> Hi Bidski,
>
> In the future please keep your replies CC'ed to the xsd-users mailing
> list as discussed in the posting guidelines:
>
> http://www.codesynthesis.com/support/posting-guidelines.xhtml
>
>
> Bidski <bidski at bigpond.net.au> writes:
>
>> Hi,
>>
>> Thank you for the reply Boris.
>>
>> I recompiled Xerces-C++ and my project making sure that optimizations
>> were turned (set to Full Optimization) and that has decreased the loading
>> time to about 3 secs.
>>
>> I added the following lines to try and per-load my schema but I got some
>> weird errors (seemingly unrelated and to do with other parts of the
>> program, but they disappear upon removal of the following code)
>>
>>                ::std::auto_ptr<::xercesc::SAX2XMLReader> parser
>> (::xercesc::XMLReaderFactory::createXMLReader ()); // errors are
>> generated on this line
>>
>>      parser->setFeature (::xercesc::XMLUni::fgSAX2CoreNameSpaces, true);
>>      parser->setFeature (::xercesc::XMLUni::fgSAX2CoreNameSpacePrefixes,
>> true);
>>      parser->setFeature
>> (::xercesc::XMLUni::fgXercesValidationErrorAsFatal, true);
>>
>>      parser->setFeature (::xercesc::XMLUni::fgSAX2CoreValidation, true);
>>      parser->setFeature (::xercesc::XMLUni::fgXercesSchema, true);
>>      parser->setFeature (::xercesc::XMLUni::fgXercesSchemaFullChecking,
>> false);
>>
>> wchar_t tmp[MAX_PATH];
>>      swprintf_s(tmp, MAX_PATH, _T("%sData\\Inventory.xsd"),
>> theApp.szAppDirectory);
>>      parser->loadGrammar (tmp, ::xercesc::Grammar::SchemaGrammarType,
>> true);
>>      parser->setFeature
>> (::xercesc::XMLUni::fgXercesUseCachedGrammarInParse, true);
>>
>> Am I missing something here?
>
> I don't see anything wrong with the above line. You may want to double
> check that you have included all the necessary headers (you can copy
> them from the performance example).
>
>
>> I am planning to add other documents to this part of the program once I
>> am satisfied with the operation of this part. These will be smaller
>> documents. The validation is doing some form of type-checking on my xml
>> document isnt it? If this is the case then I would prefer not to turn it
>> off. As I intend to use this as a database, extra type checking is always
>> a good thing in my opinion.
>
> Schema validation makes sure that your documents conform to the 
> constraints
> defined in XML Schema.
>
>
>> I am yet to try expat, would like to exhaust all possible avenues within
>> xerces before i try something new.
>>
>> During recompilation of the xerces library under visual studio 2010 I
>> encountered a load of warnings that I would like to check with you.
>
> You can ignore all of them, they are harmless.
>
> Boris
>
>
> [The rest of the email foolows for context].
>
>> First off, within XSValueTest there were some lines like these
>>
>> #if SIZEOF_LONG == 8
>>    XSValue::XSValue_Data act_v_ran64_v_1; act_v_ran64_v_1.fValue.f_long =
>> (long)+9223372036854775807;
>>    XSValue::XSValue_Data act_v_ran64_v_2; act_v_ran64_v_2.fValue.f_long =
>> (long)-9223372036854775808;
>> #endif
>>    XSValue::XSValue_Data act_v_ran32_v_1; act_v_ran32_v_1.fValue.f_long =
>> (long)+2147483647;
>>    XSValue::XSValue_Data act_v_ran32_v_2; act_v_ran32_v_2.fValue.f_long =
>> (long)-2147483648;
>>
>> The compiler was giving warnings about the unary minus operator being
>> used on a unsigned type ((long)-2147483648). I changed these lines to the
>> following
>>
>> #if SIZEOF_LONG == 8
>>    XSValue::XSValue_Data act_v_ran64_v_1; act_v_ran64_v_1.fValue.f_long =
>> _I64_MAX;
>>    XSValue::XSValue_Data act_v_ran64_v_2; act_v_ran64_v_2.fValue.f_long =
>> _I64_MIN;
>> #endif
>>    XSValue::XSValue_Data act_v_ran32_v_1; act_v_ran32_v_1.fValue.f_long =
>> LONG_MAX;
>>    XSValue::XSValue_Data act_v_ran32_v_2; act_v_ran32_v_2.fValue.f_long =
>> LONG_MIN;
>>
>> The values of LONG_MAX/MIN and _I64_MAX are still the same as the
>> hard-coded values originally there.
>>
>> The other warning was about " 'this' : used in base member initializer
>> list " after a little research on the matter it looked as though the
>> behaviour would be ok as long as the 'this' pointer wasnt derefenced
>> until after all construction had been completed. I added a
>>
>>    #pragma warning(disable:4355)
>>
>> to disable that warning. Here is an example of this warning
>>
>> DOMDocumentImpl::DOMDocumentImpl(DOMImplementation* domImpl,
>> MemoryManager* const manager)
>>    : fNode(this),                                // These two lines
>>      fParent(this),                              // generate this warning
>>      fNodeIDMap(0),
>>      fInputEncoding(0),
>>      fXmlEncoding(0),
>>      fXmlStandalone(false),
>>      fXmlVersion(0),
>>      fDocumentURI(0),
>>      fDOMConfiguration(0),
>>      fUserDataTableKeys(17, manager),
>>      fUserDataTable(0),
>>      fCurrentBlock(0),
>>      fFreePtr(0),
>>      fFreeBytesRemaining(0),
>>      fHeapAllocSize(kInitialHeapAllocSize),
>>      fRecycleNodePtr(0),
>>      fRecycleBufferPtr(0),
>>      fNodeListPool(0),
>>      fDocType(0),
>>      fDocElement(0),
>>      fNameTableSize(257),
>>      fNormalizer(0),
>>      fRanges(0),
>>      fNodeIterators(0),
>>      fMemoryManager(manager),
>>      fDOMImplementation(domImpl),
>>      fChanges(0),
>>      errorChecking(true)
>> {
>>    fNameTable = (DOMStringPoolEntry**)allocate (
>>      sizeof (DOMStringPoolEntry*) * fNameTableSize);
>>    for (XMLSize_t i = 0; i < fNameTableSize; i++)
>>      fNameTable[i] = 0;
>> }
>>
>> Are those actions in line with what should be happening within the 
>> program?
>>
>