Karaki Kenichi wrote: > Hi, Dave. > > Thank you for your answering, and sorry about my incomplete assertion > message. > > Ok. I'd like to get high performance, so I give up using > std::ostringstream. > And Should not I use std::ostrstream too? > >> From: David Bertoni <[EMAIL PROTECTED]> >> >> > C. Tried using XalanDOMString and PrintWriter >> > because XSLTResultTarget accept Writer class object. >> > But, when I executed transform(), I encounterd the assertion >> > "npos == 0 | ..." >> > What's wrong? Not enough initializing? >> > >> >> Well, you provided an incomplete assertion, and didn't bother to include >> the file and line information, so it's impossible to say what went wrong. >> There are no "levels" of initialization, so, if you've initialized both >> Xerces-C and Xalan-C properly, it's not an issue of initialization. > > I initialize Xerces-C and Xalan-C to use following two line only: > XMLPlatformUtils::Initialize(); > XalanTransformer::initialize(); > > Is it not enough using XalanDOMString?
Yes, it's enough. > > >> > (C. Tried using XalanDOMString and PrintWriter) >> > XalanDOMString domStr; >> > DOMStringPrintWriter domSPW(domStr); >> > XSLTResultTarget result(&domSPW); >> > >> > XalanTransformer transformer; >> > int theResult = -1; >> > theResult = transformer.transform(source, stylesheet, result); >> >> This one should work, and that fact that you're getting an assert means >> there's probably a bug in Xalan-C, but it's hard to say without seeing >> the >> rest of the assert. > > I'm using pre-build Xalan-C 1.10 and Xerces-C 2.7 for win32. > Assertion message is following: > > Title: Microsoft Visual C++ Runtime Library > Assertion failed! > Program: ....\testXML.exe > File: C:\BuildClient\xalanc_roo\xalan-c_1_10_0-win32-m.... > (message abbreviated by Runtime Library) > Line: 114 > Expression: theLength == npos || lenght(s) >= theOffset + theLength > > and when ignore the assertion, then encounterd following assertion: > File: C:\BuildClient\xalanc_roo\xalan-c_1_10_0-win32-m.... > (message abbreviated by Runtime Library) > Line: 470 > Expression: thePosition < theSource.length() && (theCount == > size_type(npos) > || thePosition + theCount <=theSource.length()) > > I 'greped' by expression, and found that assertion at > DOMStringPrintWriter.cpp:114 in write() function > and XalanDOMString.hpp:470 in append() function. > These are the result of a bug in Xalan-C. You can see what was patched by looking at the Jira issue: https://issues.apache.org/jira/browse/XALANC-630 > >> This might not be the most efficient way of going this, depending on what >> you'll do with the result. For example, you could write a variation of >> DOMStringPrintWriter that appends the "vendor string object" directly, >> but >> I don't know what those APIs look like, so it's hard to say what might be >> better. > > I want to pass the result to SonicMQ C++ client library provided by > Sonic Software. > That library provide following APIs for creating "vendor string object": > StringRef createString(const wchar_t* c) > // StringRef is a wrapper class of a pointer to "vendor string > object", maybe.. > There are other APIs to create string object: > StringRef createString(const char* c) // for ASCII or MBCS > StringRef createString(const unsigned char* c, const char* encoding) // > for UTF-8 If you're only working on Windows, then you can use the DOMStringPrintWriter solution, as long as you apply the patch. You can then use XalanDOMString::c_str() to get a null-terminated pointer to the UTF-16 data. If your version of Visual C++ complains, you can cast this to wchar_t. If you want portability across multiple operating systems, you should transform to UTF-8, then use the UTF-8 version of the createString() function. Dave
