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: Dragan Milenkovic on 16 Jul 2010 17:03 On 07/17/2010 12:37 AM, Walter Bright wrote: > Dragan Milenkovic wrote: >> 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? > > They're non-recoverable in the sense that language guarantees may not > hold if > they are caught. For example, destructors may not have been called > during stack > unwinding. Function purity guarantees may have been violated. But does this mean that resources are not freed and some lock might not have been released? I wouldn't like to continue executing under those circumstances. Someone mentioned earlier that they would restart a connection, while Nick Maclaren (if I understood correctly) states that the process termination is the only option, and I agree. On non-embedded applications I would still prefer abort() with a core dump; I don't have enough experience with embedded applications to judge... -- Dragan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: joe on 16 Jul 2010 17:04 "Stanley Friesen" <sarima(a)friesen.net> wrote in message news:pih046hqtdh3fqbqbeh92n4oppe7u1bl83(a)4ax.com... > "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. The exceptional case should not taint the common case. >> >>> 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. That is what the parenthetical "here" alluded to: I only have a need for English. For me, anything outside of that is an exceptional case. BTW, I was censored again, but I asked Mathias in the censored post to name one English grapheme that needed more than one codepoint, since he indicated that there was such an animal. > 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). -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 17 Jul 2010 07:28 On Jul 17, 1:27 am, Stanley Friesen <sar...(a)friesen.net> 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). Really? XML specifies NFC IIRC. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: joe on 17 Jul 2010 07:25 Jens Schmidt wrote: > 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é. No, that is not correct. English does not have diacritics. Should one chose to use them, for romantic reasons or whatever, is fine (have fun typing that on your computer), but that is not English. It is someone's idea of a composite language that combines French and English. 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. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 17 Jul 2010 07:25
In article <i1qo8u$dom$1(a)speranza.aioe.org>, Dragan Milenkovic <dragan(a)plusplus.rs> wrote: >On 07/17/2010 12:37 AM, Walter Bright wrote: >> >>> 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? >> >> They're non-recoverable in the sense that language guarantees may not >> hold if >> they are caught. For example, destructors may not have been called >> during stack >> unwinding. Function purity guarantees may have been violated. > >But does this mean that resources are not freed and some lock might >not have been released? I wouldn't like to continue executing >under those circumstances. Someone mentioned earlier that they >would restart a connection, while Nick Maclaren (if I understood >correctly) states that the process termination is the only option, >and I agree. On non-embedded applications I would still prefer >abort() with a core dump; I don't have enough experience with >embedded applications to judge... Yes, that's what I meant, and I agree with your position. I have implemented non-recoverable exceptions (for C, under MVS), and used signal handlers under Unix, and it just isn't practical to continue execution. In a language that was designed to include them, you could continue execution (with only the 'active' objects at the time of the exception being flagged as potentially corrupted and unusable), but C++ was not. Actually, I don't know of any that were .... Depending on the exact cause, Walter Bright's examples are not all of the guarantees that may be invalidated. If a 'system call' is interrupted by an exception (in modern usage, 'signal'), then something may be left in an unclean state. I/O is the classic example, but not the only one. Also, VERY few current run-time systems are signal-safe, even when they claim to be, and that can cause weird effects. It's not easy to get right. So, while I agree with the proponents that they are potentially useful, I agree with the opponents that the standard can't specify any defined behaviour for them! Which is the current state with signal handling .... Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |