future of the C++
in [C++]
|
Prev: Generating a derived class from a base class
Next: Why is the return type of count_if() "signed" rather than "unsigned"?
From: nmm1 on 18 Jul 2010 05:26 In article <KLWdnT063s-6sN_RnZ2dnUVZ7sKdnZ2d(a)bt.com>, Francis Glassborow <francis.glassborow(a)btinternet.com> wrote: > > Yes, it is true that American has no diacriticals, but English this side > of the Atlantic does. Please do not try to clean up the muddy language > that is my mother tongue :) Or, rather, the muddy class of muddy languages :-( > Anyway this has got very far from C++ where we certainly do need a way > to handle text in more than just American English. IIRC it was the > narrow view of text in C that caused problems for the first C Standard > with the result that trigraphs were invented. No, it wasn't that. Trigraphs were invented to solve the 'non-ASCII' system problem - especially EBCDIC. One of the reasons that they are such a mess is that their designers were not experts on IBM mainframes and ignored those who were. The C99 solution is more-or-less what should have been done in C90. The narrow view of text is what caused wide characters and, later, UCNs to be invented. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Stanley Friesen on 21 Jul 2010 21:26 "joe" <jc1996(a)att.net> wrote: >Francis Glassborow wrote: >> joe wrote: >>> ..... The English word is: 'resume', and what distinguishes it >>> from the other meaning of the literal text is the surrounding >>> context, which surely will be unambiguous. Please don't litter my >>> nice clean language with diddly-do-dads from other languages thank >>> you. >> >> Yes, it is true that American has no diacriticals, but English this >> side of the Atlantic does. Please do not try to clean up the muddy >> language that is my mother tongue :) > >No need to here. :) Yes, you are stuck with an old fashioned, jettisoned >way. Not to worry though, Unicode is for you (whether you want it or >not!). > >> Anyway this has got very far from C++ where we certainly do need a way >> to handle text in more than just American English. > >Not far at all from C++ given that it has lame support for Unicode, In C++0X there is actually considerable support. It allows many non-punctuation characters in identifiers (e.g. variable names, class names &c.). It provides conversions between the three main representations (UTF-8, UTF-16, and UTF-32). It at least allows for tailorable Unicode collation. The only thing it lacks that I see as a substantial issue is UTF-16 and/or UTF-32 iostreams. This is unfortunate, as both Windows and modern Unix support such files at the OS level. > >> Whether an accented >> letter, an Arabic letter or a Chinese character is allowed as a >> variable name should not IMO be an issue for the language Standard but >> an issue for >> a code shop to decide. > >I believe that the defined phases of translation allow that (? you know >better than me about that). As long as it maps onto the defined source >character set, it's a go. It C++0X supports them, and maps them to a common *execution* character set, Unicode. They *can* be represented as escape codes, even in identifiers, but this just obscures the name. But any decent development environment will allow actual Unicode source files, and apply the as-if rule to treat valid non-ASCII characters identically to the escape codes. > >> Of course if you are writing a library you >> probably want it readable (but why assume that the Roman alphabet is >> the one true way and everyone must restrict themselves to that set of >> letters. > >I didn't say that at all. I just said that my target audience is that >which speaks primarily English. Primarily American English. But if your business is even moderately large, you will likely soon have an international market. -- The peace of God be with you. Stanley Friesen [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Martin B. on 22 Jul 2010 08:49 Stanley Friesen wrote: > "joe" <jc1996(a)att.net> wrote: > >> Francis Glassborow wrote: >>> joe wrote: >> [...] >>> Anyway this has got very far from C++ where we certainly do need a way >>> to handle text in more than just American English. >> Not far at all from C++ given that it has lame support for Unicode, > > In C++0X there is actually considerable support. It allows many > non-punctuation characters in identifiers (e.g. variable names, class > names &c.). It provides conversions between the three main > representations (UTF-8, UTF-16, and UTF-32). It at least allows for > tailorable Unicode collation. The only thing it lacks that I see as a > substantial issue is UTF-16 and/or UTF-32 iostreams. This is > unfortunate, as both Windows and modern Unix support such files at the > OS level. As I see it, some support is added for better handling of unicode at compile time. (Uni character literals, charXX_t, etc.) We are left with the same mess we always had at runtime. (modulo char32_t, maybe): * No unicode aware string class * No way to tell what character set a char* is encoded in (and this will get worse with compile-time u8 constants). * std::exception works only with char* * iostreams only works with narrow char* filenames (as you mention) I don't call that considerable support. (Rather I call it incomplete support with the most important thing for me, namely ease-of-use, missing.) cheers, Martin -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 22 Jul 2010 08:50 On Jul 22, 1:26 pm, Stanley Friesen <sar...(a)friesen.net> wrote: > It provides conversions between the three main > representations (UTF-8, UTF-16, and UTF-32). Not really in a way that is practical to use though. > The only thing it lacks that I see as a > substantial issue is UTF-16 and/or UTF-32 iostreams. This is > unfortunate, as both Windows and modern Unix support such files at the > OS level. basic_istream<char16_t> etc. should work just fine. > But any decent development > environment will allow actual Unicode source files, and apply the as-if > rule to treat valid non-ASCII characters identically to the escape > codes. So GCC, the most widely used C and C++ compiler, is not a decent development environment? As was clearly stated in the parent message, GCC only supports inputting unicode characters in identifiers as escape codes. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 22 Jul 2010 19:49
Walter Bright wrote: > Andre Kaufmann wrote: >> Walter Bright wrote: >>> Mathias Gaunard wrote: >>>> On Jul 8, 2:16 pm, Walter Bright <newshou...(a)digitalmars.com> wrote: >> >>> [...] >>> On windows, seg faults are catchable as C++ exceptions. >> >> Do you mean the "bug", where it was possible to catch C++ exceptions, >> if structured exception handling was enabled for an older version of VC ? > > No, as I don't know anything about how various versions of VC handle > SEH. The > Digital Mars C++ system allows catching of any Win32 system exceptions > with the > usual catch statements. It can be enabled for VC too and for any other C++ compiler one could "simply" use structured exception handlers and convert the structured exception to a C++ exception. But I can't imagine any situation, where it could make sense to handle structured exceptions like access violations as a C++ exception or to let them be catched by a catch ellipsis catch (...) There are few structured exceptions, where it makes sense however. > [...] > Why? It's pretty simple with Win32. Do you mean Win64, which has a very > different implementation of SEH? > No, I mean Win32. I don't know the details anymore, because I've implemented this some years ago. Since Vista the implementation has changed and before the structured exception handlers for access violations are called Windows will start WER (Windows Error Reporting - former Dr. Watson). As I wrote, I don't know the exact details anymore, but it wasn't that simple anymore as it has been under Windows 2000 / Windows XP. (could be also a VC runtime problem - so it might be different for Digital Mars C++). Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |