On Monday, December 13, 1999 at 8:17 PM [EMAIL PROTECTED] wrote: <<<And if someone wants to change the typedefs and recompile, they could create a 32-bit for efficiency, or 8-bit for ASCII-only with memory constraints.>>>
I'd be very keen to see an option to allow XMLCh to be equated to char. We currently have minimal interest in supporting anything other than ASCII. Storing non-ASCII characters using Java-style NUL-free UTF8 would be a simple way of handling the occasional non-ASCII character we might see as these will typically be in fields that we never examine but simply copy around and compare. Having XMLChs as some other than chars makes life a major pain. Suddenly all the regular facilities one's used to using aren't there any more. Suddenly your having to convert strings before you can pass them to any part of your existing system. The answer is of course transcoding: one can wrap every string access in a call to a transcoder. But this is clumsy and ineffecient -- it would be nice if the transcoding were done long before the input ever reached you! A define would be nice, e.g. XMLCH_IS_CHAR so that one could use #ifdefs to control the inclusion of potentially clashing overloads. I guess some people would like to see the same for wchar_t. Talking of potentially clashing overloads I've also found the theft of a basic type with a different meaning (a character is not an integer of any size, shape or form!) a pain. I can't see any way around this though (without the ADA-like ability to say "type XMLCh = new Integer;"). One could use a wrapper class with suitable non-explicit constructor and conversion operator but the cost of having a constructor would probably make this solution nacceptable. -- jP -- This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP, CREDIT SUISSE FIRST BOSTON, and each of their subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.
