Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

The C++ standard (I noticed it in the new one, but it did already exist in C++03) specifies universal character names, written as \uNNNN and \UNNNNNNNN and representing the characters with unicode codepoints NNNN/NNNNNNNN. This is useful with string literals, especially since explicitly UTF-8, UTF-16 and UCS-4 string literals are also defined. However, the universal character literals are also allowed in identifiers. What is the motivation behind that?

The syntax is obviously totally unreadable, the identifiers may be mangled for the linker and it's not like there was any standard function to retrieve symbols by name anyway. So why would anybody actually use an identifier with universal character literals in it?

Edit: Since it actually existed in C++03 already, additional question would be whether you actually saw a code that used it?

share|improve this question

4 Answers 4

up vote 7 down vote accepted

UPDATE - this answer, though it seemed to make sense to me and others, turns out to be largely wrong (and sufficiently wrong regarding the intent, as to be effectively just plain wrong). Since (as pointed out in a comment by AProgrammer) it's not permitted to use UCS outside of string constants when the same character could be represented normally in the base character set. So, no using it to escape keywords, as in my example; and no using it to make 'identifiers' like 23skiddo by escaping the 2. It could still be used to make names compatible with external languages, I guess, but only, it seems, when those names start with either a letter or an extended character, and contain only letters, digits, underline, and extended characters -- which seems much too restrictive to properly support that intent. So it must be that the main intent is (as in AProgrammer's answer) to allow these extra characters in identifiers, and to enable source editors where these characters are displayed graphically, while still allowing the source file to be in plain ASCII.

C++ programs may call functions written in other languages. It is good strategy on the part of the standardization committee to ensure that C++ will be interoperable with other languages which may allow non-alphanumerics or unicode characters in function names, even if such languages do not yet exist. The standard doesn't need to specify how this will work at the linker level, etc; but it's good to have a specified mechanism in place to allow it.

You don't need to look into the future to see a use for this. Suppose I have an old C library with a function in it called catch (or protected, or mutable)... and I want to call it from C++. And for whatever reason I can't or don't want to modify the C code (By the way, I have more than once had to deal with old C code that used a function name that had become a C++ keyword...)

With UC names I can write this in a header, and then just call 'catch_func()':

extern "C" {
       int catc\u0068( int a, int b );  // C 'catch()' function
inline int catch_func( int a, int b ) { return catc\u0068(a,b); }

Sure it's ugly, but it doesn't matter since it's only in one place in the header. The same approach could be used to make stubs to call functions in other languages, and works even if the names are C++ keywords or unicode, or have spaces, . or other punctuation embedded in them

Various other languages have devices allowing the creation of identifiers that don't follow the general pattern; for instance in Verilog, \abcd is an identifier equivalent to abcd, but \while and \23skidoo and \44.e2 are identifiers too, which need the backslash prefix to be seen as such. Due to the manner in which Verilog is used, it's important to allow any names at all, where they relate to external interfaces.

share|improve this answer
Interesting use case. Though I suspect (when possible) it would be nicer to write a small C file to translate the name (and thus can use the C++ identifier) and have C++ call that C function. – Thomas Eding Sep 6 '14 at 1:03
You can't write that for two reasons, first UCS outside string and character literals can't refer to character in the basic sets without making the program illformed, second if that clause was not present UCS are handled in phase 1 of the translation and thus there would be not difference in handling between an UCS refering to a character in the basic set and the character itself. – AProgrammer Sep 8 '14 at 8:29

Someone may want to create an identifier using a foreign language character that is not enterable on the keyboard or input device. Alternatively, the identifier may contain a character that is not printable using the font or output capabilities of the device but the IDE wants to show an accurate representation.

share|improve this answer
In the first case, the identifier wouldn't look like having that character, so the code would be unreadable and the identifier does not really matter to the machine. And for the second, representation in IDE is a completely separate problem. – Jan Hudec Sep 26 '12 at 8:02

It allows a system allowing unicode characters in identifier to export the source in a format compilable on any standard conforming compilers. I.E. it is a way to encode unicode over the basic character set (more or less like quoted-printable is used for email, systems who knows better are able to do a better job, other systems are still working).

share|improve this answer

C++ requires that actual extended characters appearing literally in source behave identically with Universal Character Names. Allowing Universal Character Names in identifiers permits programmers to use extended characters in identifiers.

share|improve this answer
It actual extended characters are supported, they have to behave as corresponding universal characters. But they don't have to be supported. – Jan Hudec Jan 17 '13 at 7:46
That's true but it sort of misses the point, which is that if the committee wants to specify that implementations supporting extended characters should support using those characters in identifiers then that requires UCNs to be allowed in identifiers. I.e. UCNs are allowed in identifiers, not necessarily because that's so readable and everyone loves manually encoding names in hexadecimal, but because if the spec wants to permit extended characters to be used in identifiers then it does so by specifying that UCNs are allowed in identifiers. – bames53 May 20 '14 at 17:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.