You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Giampiero Gabbiani <gi...@tin.it> on 2004/10/05 00:06:42 UTC
XMLCh vs wchar_t
Hi to all,
just a question, why during the development of c version of xerces, a new
'wide' character string has been developed, instead of using the standard
c++ wstring?
I find this a little confusing... 'cause it force to continuosly transcode()
between the two ones!
Regards
Giampiero
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: XMLCh vs wchar_t
Posted by Giampiero Gabbiani <gi...@tin.it>.
Scott Cantor wrote:
>> Because std::wstring is not so standard... for instance, gcc
>> 2.95 doesn't have it.
>
> Heh, if that was the reason (as opposed to the fact that the *encoding* of
> wstring isn't standard), I'd be screaming for the change. ;-)
>
> -- Scott
So, what's the problem with std::wstring's encoding (or, where can I read
something about it)?
Giampiero.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: XMLCh vs wchar_t
Posted by Sean Kelly <se...@f4.ca>.
Scott Cantor wrote:
>
>>Eh, all that's required is another transcoding jump from XMLCh* to
>>wstring in the XML code wrappers. Irritating and slow, but
>>not a major complication.
>
> Well, so, I've been punting for a while on actually building a usable
> wrapper that's STL container-friendly. Mostly because it's a pain to get the
> details right, and I figured if nobody had done one there might be a subtle
> reason I hadn't explored for why it won't work.
>
> Does somebody have one? If so, adding it to the distribution would be most
> welcome.
>
> If not, I guess I may end up doing it, instead of coding around this with
> hacks all over the place with ifdef HAVE_STL_THAT_DOESNT_SUCK.
One problem that I've run into with Windows is that I typically define
wchar_t as a real type (in VStudio project settings) and this breaks
some of the Windows-specific code in Xerces. In the past I cheated and
defined XMLCh as wchar_t but with this release I went in and put
reinterpret_casts everywhere. Next step is to address transcoding so
I'll post here if I have any brilliant ideas.
Sean
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: XMLCh vs wchar_t
Posted by Scott Cantor <ca...@osu.edu>.
> We asked this last time this conversation went round. No one replied.
I recall the topic, figured it was time to ask again. ;-)
> We would add it if anyone wanted to contribute.
If and when I ever manage to get it written and working, I'll certainly
contribute it.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: XMLCh vs wchar_t
Posted by Gareth Reakes <ga...@parthenoncomputing.com>.
Hi Scott,
On 6 Oct 2004, at 2:07, Scott Cantor wrote:
> Does somebody have one? If so, adding it to the distribution would be
> most
> welcome.
>
We asked this last time this conversation went round. No one replied.
We would add it if anyone wanted to contribute.
Gareth
>
--
Gareth Reakes, Managing Director Parthenon Computing
+44-1865-811184 http://www.parthcomp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: XMLCh vs wchar_t
Posted by Scott Cantor <ca...@osu.edu>.
> Technically speaking, it is legal C++, but it's a bit more involved than
> this. You also have to define type traits for XMLCh and then
> deal with the fact that your XMLCh strings won't work with char or
> wchar_t strings, can't be printed via cout or wcout, etc.
Right, I was glossing over details. It's not legal without significant
additional work.
> Eh, all that's required is another transcoding jump from XMLCh* to
> wstring in the XML code wrappers. Irritating and slow, but
> not a major complication.
Well, so, I've been punting for a while on actually building a usable
wrapper that's STL container-friendly. Mostly because it's a pain to get the
details right, and I figured if nobody had done one there might be a subtle
reason I hadn't explored for why it won't work.
Does somebody have one? If so, adding it to the distribution would be most
welcome.
If not, I guess I may end up doing it, instead of coding around this with
hacks all over the place with ifdef HAVE_STL_THAT_DOESNT_SUCK.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: XMLCh vs wchar_t
Posted by Sean Kelly <se...@f4.ca>.
On Tue, 5 Oct 2004, Scott Cantor wrote:
>
> > But you are right, Xerces internally uses
> > UTF-16 strings, and wchar_t isn't a cross-platform storage for
> > UTF-16. The point is that platforms that know this is true (like Windows)
> > would like to see XMLCh==wchar_t, even if they can just cast them to be
> > the desired type.
>
> I agree. The big advantage of this is that this:
>
> basic_string<XMLCh>
>
> is not legal C++. Nor does it work in any recent g++ version, because they
> chose strict compliance over continuing to let this work.
Technically speaking, it is legal C++, but it's a bit more involved than
this. You also have to define type traits for XMLCh and then deal with
the fact that your XMLCh strings won't work with char or wchar_t strings,
can't be printed via cout or wcout, etc. Personally, I'd much rather have
Xerces generate native wchar_t strings on whatever platform it's built on,
but this is obviously non-trivial.
> It's not a simple
> trade-off, but it's a serious bitch to work around, since it makes it really
> hard to do efficient STL programming.
Eh, all that's required is another transcoding jump from XMLCh* to
wstring in the XML code wrappers. Irritating and slow, but not a major
complication.
Sean
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: XMLCh vs wchar_t
Posted by Sean Kelly <se...@f4.ca>.
On Tue, 5 Oct 2004, Scott Cantor wrote:
>
> I'm sure there are good reasons for why the C++ committee didn't mandate
> UCS-2 for wchar_t, but whatever they were, they've gone a long way in
> convincing the XML community to stay with Java and ignore C++. So I hope it
> was worth it. ;-)
Too many people had settled on different encoding schemes, probably. But
in terms of XML processing, D (digitalmars.com) may be worth looking at as
its internal string representations are expected to be UTF (8, 16, 32).
And things will be even better once the port of ICU is complete.
Sean
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: XMLCh vs wchar_t
Posted by Scott Cantor <ca...@osu.edu>.
> So is there a silver bullet other then type casting to fix this issue ?
If you need portability, the only silver buller is one to the head to avoid
the obnoxious transcoding all over your code. ;-)
Otherwise, I don't know why for Windows they haven't just typedef'd it to
wchar_t, but I suspect it's because people would fall into the trap without
understanding the implications. Forcing the cast makes it a more conscious
decision to screw yourself.
I'm sure there are good reasons for why the C++ committee didn't mandate
UCS-2 for wchar_t, but whatever they were, they've gone a long way in
convincing the XML community to stay with Java and ignore C++. So I hope it
was worth it. ;-)
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: XMLCh vs wchar_t
Posted by Mark Jetson <es...@yahoo.com>.
So is there a silver bullet other then type casting to
fix this issue ?
Ryan
--- Scott Cantor <ca...@osu.edu> wrote:
> > But you are right, Xerces internally uses
> > UTF-16 strings, and wchar_t isn't a cross-platform
> storage for
> > UTF-16. The point is that platforms that know this
> is true (like Windows)
> > would like to see XMLCh==wchar_t, even if they can
> just cast them to be
> > the desired type.
>
> I agree. The big advantage of this is that this:
>
> basic_string<XMLCh>
>
> is not legal C++. Nor does it work in any recent g++
> version, because they
> chose strict compliance over continuing to let this
> work. It's not a simple
> trade-off, but it's a serious bitch to work around,
> since it makes it really
> hard to do efficient STL programming.
>
> But since you can cast on Windows, and since Windows
> is the only platform
> that you can do it on anyway, it's not really a big
> help for the library to
> do the definition for you. If all you need is
> Windows, there are lots of
> built in XML options now, and if you play these
> kinds of games, none of your
> Xerces code will port anyway.
>
> -- Scott
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail:
> xerces-c-dev-help@xml.apache.org
>
>
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: XMLCh vs wchar_t
Posted by Scott Cantor <ca...@osu.edu>.
> But you are right, Xerces internally uses
> UTF-16 strings, and wchar_t isn't a cross-platform storage for
> UTF-16. The point is that platforms that know this is true (like Windows)
> would like to see XMLCh==wchar_t, even if they can just cast them to be
> the desired type.
I agree. The big advantage of this is that this:
basic_string<XMLCh>
is not legal C++. Nor does it work in any recent g++ version, because they
chose strict compliance over continuing to let this work. It's not a simple
trade-off, but it's a serious bitch to work around, since it makes it really
hard to do efficient STL programming.
But since you can cast on Windows, and since Windows is the only platform
that you can do it on anyway, it's not really a big help for the library to
do the definition for you. If all you need is Windows, there are lots of
built in XML options now, and if you play these kinds of games, none of your
Xerces code will port anyway.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: XMLCh vs wchar_t
Posted by Alberto Massari <am...@progress.com>.
At 12.58 05/10/2004 -0400, Scott Cantor wrote:
> > Because std::wstring is not so standard... for instance, gcc
> > 2.95 doesn't have it.
>
>Heh, if that was the reason (as opposed to the fact that the *encoding* of
>wstring isn't standard), I'd be screaming for the change. ;-)
I was just pointing out that wstring is so standard that is not implemented
on every platform. But you are right, Xerces internally uses UTF-16
strings, and wchar_t isn't a cross-platform storage for UTF-16. The point
is that platforms that know this is true (like Windows) would like to see
XMLCh==wchar_t, even if they can just cast them to be the desired type.
Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: XMLCh vs wchar_t
Posted by Scott Cantor <ca...@osu.edu>.
> Because std::wstring is not so standard... for instance, gcc
> 2.95 doesn't have it.
Heh, if that was the reason (as opposed to the fact that the *encoding* of
wstring isn't standard), I'd be screaming for the change. ;-)
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: XMLCh vs wchar_t
Posted by Alberto Massari <am...@progress.com>.
At 00.06 05/10/2004 +0200, Giampiero Gabbiani wrote:
>Hi to all,
>just a question, why during the development of c version of xerces, a new
>'wide' character string has been developed, instead of using the standard
>c++ wstring?
Because std::wstring is not so standard... for instance, gcc 2.95 doesn't
have it.
Alberto
>I find this a little confusing... 'cause it force to continuosly transcode()
>between the two ones!
>
>Regards
>Giampiero
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org