|
Hello
Ellis, Thanks a lot for a detailed explanation. Yeah it is very helpful. But right now on practical grounds, I need
to know how I can convert the BSTR data into something that Xerces-C++ can
understand. Right now I am only aware of something
like DOMString. Do you have any suggestions like using transcode() etc.. If yes� could you please detail it out. Thank you so much pankaj -----Original Message----- Pankij, The previous replies to your question did not really
explain why BSTR and DomString are not compatible. I hope this helps you
to understand why: The only difference between a Unicode BSTR and an
ordinary LPWSTR is that the memory allocated to the BSTR includes the two bytes
(May be 4 bytes - don't manipulate directly!) before the one that is pointed to
(these hold the length of the string). The buffer that holds the
characters can contain nulls, but they do not determine the end of the
string. In my experience, however almost all BSTR stings do have a null
in the first unused character. DomString is a class (much like the MFC CString and
C++ standard library's string) that makes the handling of variable length
string data much simpler for the programmer. Its underlying data type is
XMLString, which has a memory image similar to that of BSTR. Indeed you
can get away with using a BSTR with a null following the last character as a
parameter into Xerces functions that do not modify the value (Xerces does not
know about the length information and cannot update it). This is the same problem with trying to use a BSTR
instead of a DomString (since DomString's methods do not know about the BSTR
length information). It would not make sense for the Xerces developers to
add support because BSTR does not exist in the other platforms supported by
Xerces. When using BSTR in place of other (null-terminated)
Unicode string types, remember that as Microsoft says in the documentation for
SysAllocStringLen: "The pch string can contain embedded null
characters and does not need to end with a NULL" NB if you try the reverse (passing a DomString cast to
a BSTR) the function you are calling is going to look for the non-existent
length information just before the string (you are getting into serious
problems here and asking for different behaviour between debug and release
builds) A little bit of trivia: BSTR comes from Visual Basic
which has stored its variable length stings like this (but using bytes for
characters) since the early days (useful to know when you are manipulating a
string passed from VB to a C++ DLL). When 16-bit OLE automation came out,
BSTR was the obvious format because it already existed in VB. This was
them migrated to 32 bit with the change to wide characters. I hope this helps. Ellis Mr Ellis J Birt Dip. Comp.(Open) StruMap, Geodesys Ltd, Astwood House, 1296 Evesham
Road, Astwood Bank, Redditch, Worcestershire B96 6AD, UK Tel: +44 (0) 1527 893758 Fax: +44 (0)1527 893833
|
Title: Re: BSTR
