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?
> (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.
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
This C++ library is for accessing to Java Messaging System, so I think to
handle strings
as Unicode(UTF-16) in my application because a string object in received
message from
a system's broker is Unicode encoding, maybe.
Could you give me some more advice?
Thank you.
Ken
_________________________________________________________________
Hotmail に直接アクセス！MSN がさらに使いやすく http://jp.msn.com/
