Re: How to convert from wchar_t* to XMLCh*?

[Per Bernhardsson <pe...@gmail.com>]

Windows uses UCS2 which is very similar to UTF-16 but not the same.
See here<http://en.wikipedia.org/wiki/UCS2>for more information. So a
wchar_t * might point to a UCS2 string just as
well as a UTF-16 string. Assuming they are the same can (admittedly very
rarely) lead to unwanted results.

 / Per

2008/2/29, Alberto Massari <am...@datadirect.com>:
>
> If you are sure that mlEventPtr->getComponentName().c_str() returns a
> wchar_t*, you can directly use that pointer (on Windows, XMLCh* and
> wchar_t* points to UTF-16 data). If you don't want to use casts all over
> the place, you can also recompile Xerces with the 'treat wchar_t as a
> native type' and this will defined XMLCh to be a synonym for wchar_t.
>
>
> Alberto
>
>
> Kamdar, Devang (MLITS) wrote:
> > Hi,
> > When I am using the following function transcode
> >
> > XMLCh* xmlChComponentName =
> > XMLString::transcode(mlEventPtr->getComponentName().c_str());
> >
> > Compiler is throwing following error:
> > Error 1       error C2440: 'initializing' : cannot convert from 'char
> > *' to 'XMLCh *'
> > c:\working\instrumentation\vc++_projects\mllog4cxx_working\mllog4cxx\sou
> > rce\mllog4cxx\mlsoaloggerlayout.cpp   78
> >
> > mlEventPtr->getComponentName().c_str() returns string of type wchar_t*
> >
> > I am using Visual Studio 2005 to compile this.
> >
> > I need to do this transformation, because I need to pass this as a
> > parameter in DomDodumentPtr->createTextNode() function which accepts
> > only XMLCh* as a parameter.
> >
> > Can some one suggest, how to transcode a value of type wcaht_t* to
> > XMLCh* using the transcode function or by any other way?
> >
> > Thanks
> > Devang Kamdar
> >
> >
> >
>
>
>

Re: How to convert from wchar_t* to XMLCh*?

[David Bertoni <db...@apache.org>]

Per Bernhardsson wrote:
> Windows uses UCS2 which is very similar to UTF-16 but not the same.
> See here<http://en.wikipedia.org/wiki/UCS2>for more information. So a
> wchar_t * might point to a UCS2 string just as
> well as a UTF-16 string. Assuming they are the same can (admittedly very
> rarely) lead to unwanted results.
UCS-2 is a proper subset of UTF-16, so all legal UCS-2 strings are legal 
UTF-16 strings.  In addition, the many Windows APIs are well on their way 
to accepting UTF-16, so soon, even that won't be a problem:

http://blogs.msdn.com/michkap/archive/2005/05/11/416552.aspx

Can you be more specific about what you think these rare, unwanted results 
might be?

Dave