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: Mathias Gaunard on 16 Jul 2010 07:35 On Jul 16, 5:30 pm, "Martin B." <0xCDCDC...(a)gmx.at> wrote: > Mathias Gaunard wrote: > > On Jul 15, 4:04 pm, "joe" <jc1...(a)att.net> wrote: > >> Mathias Gaunard wrote: > >>> On Jul 6, 1:48 pm, "joe" <jc1...(a)att.net> wrote: > >>>> Andre Kaufmann wrote: > >>>>> Agreed, C# and Java strings are not perfect, but better than C++ > >>>>> standard strings regarding Unicode. I think C# has been influenced > >>>>> by Windows Unicode support. > >>>> What is wrong with fixed-width Unicode (UCS-2 or UCS-4)? > >>> UCS-2 doesn't allow to represent all Unicode characters. > >> Most application programs don't need them. > > > You might as well say most application programs don't need Unicode. > > I might be noted that the Basic Multilingual Plane[*] seems to be enough Given that the cost of dealing with the whole of Unicode properly isn't any higher than that of dealing with just the BMP properly, I don't see any advantage in restricting oneself to a subset. Of course, dealing with UCS-2 naively, without concern for normalization or combining characters, isn't what I would call "proper" here, albeit it should just work. > for everyone except for *extended* CJK characters. > (Whatever that is. I > guess only east-asian native speakers can tell if they need that.) Those characters are not used in modern script, which is why they're not in the BMP. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 16 Jul 2010 07:33 In article <i1p728$h53$1(a)speranza.aioe.org>, Dragan Milenkovic <dragan(a)plusplus.rs> wrote: > >> None of that is portable, or practical to specify in standards like >> those, but non-recoverable exception handlers are a good place to >> put the system-dependent incantations needed to achieve the effect. >> The point is that they are a syntactically portable hook to achieve >> a semantically non-portable effect. > >May I ask why are they constantly being called "non-recoverable" >exceptions, while in the same time they are used to recover >the process instead? Just to be sure - I'm not talking about >"log and reboot" solution, but "log and restart connection". I was talking about the "log and reboot" solution - I can't speak for anyone else. Of course, except on very old or embedded systems, you are running under an operating system and the "reboot" merely means "abandon program execution and return to shell". >While those mentioned may be non-standard exceptions >(like the one resulting from a null pointer dereference), >if I'm not mistaken, their usage shows recoverability. Yes and no. They aren't usable without ANY recovery, but they don't support continuing execution of the current program after they have been called. They can't return, jump out or raise an exception trapped by a recoverable handler - all they can do is execute and quit. 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 16 Jul 2010 09:26 nmm1(a)cam.ac.uk wrote: >In article <lfos36los6n56ere5rqeoi4unljqts9k3k(a)4ax.com>, >Stanley Friesen <sarima(a)friesen.net> wrote: >> >>>>But what if you don't *have* a disk, or any other easily accessible >>>>persistent store? This is true of many, if not most, embedded systems >>>>(such as the one I am currently working on). >>> >>>Eh? Then where are you writing diagnostics to? >> >>A telnet terminal. Or perhaps a serial port. > >Then you STILL need to take special action, in general, to ensure >that all of your diagnostics get written! The most that C++ (and >Fortran, C and POSIX) promise is that your output has been passed >on for delivery. We have other issues in our systems. The fielded units have telnet and FTP completely disabled at the OS level (i.e. not even compiled in), and there are no externally accessible serial ports. This is done for good reasons, and is indeed one of the system requirements. So neither the field user nor the user level maintenance depots would have access to any debugging logs, even if we *did* store them in flash. In addition the end user is almost never in a situation where calling tech support is possible (for much the same reason all external access to the innards of the product are sealed off). So the only way to get at any logs would be to send the unit back to the factory, and have a telnet enabled OS installed so the techs there could access the log. At that point we almost might as well just have the techs try to reproduce the problem with engineering test builds on units already *at* the factory. I admit, it would be nice to have more diagnostic information available on units shipped back to the factory to enable post-hoc analysis of failure modes. -- 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: Stanley Friesen on 16 Jul 2010 09:27 "joe" <jc1996(a)att.net> wrote: >Mathias Gaunard wrote: >> On Jul 6, 1:48 pm, "joe" <jc1...(a)att.net> wrote: >>> Andre Kaufmann wrote: >>> >>>> Agreed, C# and Java strings are not perfect, but better than C++ >>>> standard strings regarding Unicode. I think C# has been influenced >>>> by Windows Unicode support. >>> >>> What is wrong with fixed-width Unicode (UCS-2 or UCS-4)? >> >> UCS-2 doesn't allow to represent all Unicode characters. > >Most application programs don't need them. True, but more do than one might suppose. A Web browser, for instance, should be able to handle the entire Unicode repertoire provided that suitable fonts are installed on the system. > >> UCS-4 is a waste of memory. >> >> And more abstract characters, like graphemes, are not fixed-width >> anyway (think combining character sequences). > >Those, again (here), are the exception to the rule. I disagree, or at least this is only true in English. Even for German, the fact that the Web standard specifies NFD for transmission means any useful application would need to support combining characters (think umlauts). -- 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: Jens Schmidt on 16 Jul 2010 17:03
Stanley Friesen wrote: > I disagree, or at least this is only true in English. Even for German, > the fact that the Web standard specifies NFD for transmission means any > useful application would need to support combining characters (think > umlauts). For an example where more than one code point for one character can be used in English: résumé. -- Greetings, Jens Schmidt [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |