Re: C++0x two Unicode proposals. A correction one and a different one
Ioannis Vranos ha scritto:
Alberto Ganesh Barbati wrote:
Ioannis Vranos ha scritto:
I) Library, implementation defined types like utf8_char, utf16_char, and
utf32_char, leaving alone and not polluting the existing built in types
like char for now and in the future.
<snipped reason why they cannot be defined as typededs>
So perhaps they should not be introduced as typedefs in the library.
They must be implementation-defined types, either implemented as classes
or as built-in types or typedefs or a combination of them or whatever,
it is up to the compiler creator, the end user shouldn't care. The only
important thing is, these types must be visible only when the
appropriate header is #included and should support a specific interface.
They should be "regular" classes however. Some ABI might handle even
light-weight user-defined classes in a less efficient way than built-in
types. Once you require that:
1) it's not a typedef
2) it's as light-weight as a built-in type
well... that doesn't look much different from defining it as a new
built-in type in the first place.
String literals of these new Unicode types should also be visible only
when this appropriate header is #included.
I believe this is a weak point in your whole argument. You might put
*types* in a library, but how can you put *literals* in it?? I mean, if
I understand it correctly, u8"", u"" and U"" have to be detected as
being literals as early as in translation phase 5, while keywords are
not recognized until phase 7. You don't want the match u16"" -> char16_t
to be hard-coded in the compiler, that's ok... but how could a library
describe such a match?
Actually there is a proposal to achieve that and I suggest you to read
it. It's N2378 "User-defined Literals"
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2378.pdf)
Anyway, the fact is that it is believed that whatever character set or
encoding form we may need in the future, we should be able to describe
it in terms ISO/IEC 10646. In fact compilers are required to eventually
interpret any character in a source file as some ISO/IEC 10646 character
(see 2.1 and 2.2), so providing UTF32 literals is an easy 1-1 mapping.
You might object to UTF16 and UTF8 and but to UTF32. UTF8 and UTF16 are
included because they are indeed useful and programmers are asking them.
Anyways, with a paper like N2378 *and* UTF32 literals, I believe we may
be able to cope with any unforeseen situation. It's without UTF32
literals, that there might a be problem...
My second thought on this, is that Unicode support should also become
optional. This will further decrease pollution of built in types and
string literals. An implementation should be able to choose whether it
will support Unicode and which one.
What benefit a programmer would get to disable Unicode support? Would
the code run faster? Would it be smaller or require less RAM? Would it
be able to write things that would otherwise be illegal with Unicode
support enabled? The answer is no to all questions. All you gain is just
two identifiers that would no longer be keywords. So what? Are they so
important?
I am not an "absolute" supporter of what I said above (my second
thought- "different proposal"), but I have the feeling that compiler
vendors on systems not using Unicode, will not bother to provide all
these Unicode types and support. So I think Unicode support should be
optional, in the style, either all Unicode types are supported (in a
specific header), or none.
I disagree. Experience shows that if the support of one feature is
optional, then programmers will disregard the feature and prefer
work-arounds in order to achieve portability. Anyway, as I said before,
UTF32 support comes for free, as the compiler are required to use it
internally anyway, so I don't understand why it should be optional.
UTF16 and UTF8 are just a cheap translation from UTF32, so again, I
don't see why a compiler should have problems with them.
Regards,
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]