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 12 Jul 2010 22:22 In article <98en365lqfgmj6ehatfklr962ga0goprko(a)4ax.com>, Stanley Friesen <sarima(a)friesen.net> wrote: >nmm1(a)cam.ac.uk wrote: > >>In article <i13i2b$jlb$1(a)news.eternal-september.org>, >>Walter Bright <walter(a)digitalmars-nospamm.com> wrote: >>> >>>Usually, yes, a breakpoint is better. But consider what a breakpoint is >>>- it's a debugger installing an exception handler! A debugger is >>>sometimes not available, and so it's nice to be able to build in a bit >>>of debugger capability into the program. >> >>Precisely. All competently engineered production applications >>have the ability to diagnose their own failures, and I can witness >>(from experience with ones that did and ones that didn't) that it >>can reduce the maintenance effort by a factor of ten. And more >>bugs get fixed rather than hacked around, of course. >> >>And that ignores the fact that most languages force you to take >>explicit action to ensure that all diagnostics are written to >>disk! Just doing that in a handler is often worthwhile. > >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? The same applies, no matter what the destination - that paragraph was about the majority of applications that at least nominally write diagnostics. Exactly the same applies to most critical embedded systems. When something goes haywire, a well-engineered application will write some diagnostics if it possibly can, and call any emergency system to recover. Any designer of critical systems who does not include both a diagnostic facility and something to handle unexpected failure should be shot. One of the reasons that so many non-critical embedded systems are so unreliable is precisely because they don't have any diagnostics, and so no bug that turns up in the field is investigatable - the 'solution' is to power-cycle them every time they misbehave, or replace them by another model with a different set of failures. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 14 Jul 2010 01:22 On Jul 13, 9:53 am, Stanley Friesen <sar...(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). Dump the debugging info to the serial output? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Stanley Friesen on 15 Jul 2010 00:04 nmm1(a)cam.ac.uk wrote: >In article <98en365lqfgmj6ehatfklr962ga0goprko(a)4ax.com>, >Stanley Friesen <sarima(a)friesen.net> wrote: >>nmm1(a)cam.ac.uk 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. -- 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: joe on 15 Jul 2010 00:04 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. > 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 am sure am glad I only program in English and only target English-speaking users. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 15 Jul 2010 10:35
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. Some embedded systems may not return from a write until the data has reached the far end, but it's not something that I would bet on (and certainly not for telnet!) 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. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |