Gerhard Fiedler wrote: > Right. My point was that if 8-bit strings are built-in and Unicode > strings are in a library, and you are claiming (elsewhere) that the > built-in syntax can be different from library syntax, then I need to > make the Unicode string syntax completely different -- structurally > different -- from 8-bit string syntax. Can you imagine that? What a > pain. Maybe not. If each type of string is a different data type, then the syntax can be simple and the compiler could even convert from one representation to another if this can be done unambiguously. For example, let's say the string concatenation operator is "+": strc <-- stra + strb could work as long as all three are some type of string data type. If the representations are well enough defined, it should be possible to define rules of how one representation is converted to another, and to produce a compile time error when this could not be done. With consitent promotion rules, you can use what looks like the same string constant in different circumstances. For example: stra is ascii_string_t stru is unicode_string_t stru <-- stru + stra + " blah" Let's say UNICODE_STRING_T is a superset of the string type ASCII_STRING_T. In that case STRA would be promoted to unicode before being appended to STRU. The string constant " blah" could either be defined as ASCII_STRING_T and thereby automatically promoted when needed, or possibly the compiler can tell from context which data type is needed. The point is that it is certainly possible to handle various string representations built into a compiler without operator or syntax bloat. Converting between the various representations could actually be quite useful. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist