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 10 Jul 2010 03:57 In article <i13i2b$jlb$1(a)news.eternal-september.org>, Walter Bright <walter(a)digitalmars-nospamm.com> wrote: >Ian Collins wrote: >> On 07/ 8/10 08:16 AM, Walter Bright wrote: >>> Mathias Gaunard wrote: >>>> I personally don't understand the point of non-recoverable exceptions >>>> at all. If they're non recoverable, it means it is something that >>>> should *never* happen, and therefore is a bug in the program itself. >>>> The program might as well abort and terminate directly. Trying to >>>> clean up in the face of something that should never happen in the >>>> first place cannot work, and might actually lead to even more errors. >>> >>> Yes, you're quite right. >>> >>> Being able to catch them, however, can make debugging a program easier. >> >> Isn't a breakpoint on abort() a better alternative? I wouldn't want any >> unwinding or object clean-up to occur under those conditions. Along >> with the risk of more damage being done, valuable state information may >> be lost. > >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. MPI has specified just such a recovery mechanism. You can trap errors and produce diagnostics, but further use of MPI is undefined behaviour. 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 10 Jul 2010 03:59 On Jul 8, 4:56 am, Andre Kaufmann <akfmn...(a)t-online.de> wrote: > Sample: F# pattern matching > > let f x = match x with > | int -> "integer" > | _ -> "other" > > let value = f 8 > printfn "%A" value > > Prints: "integer" This is actually valid OCaml, but f "" prints "integer" as well, and you do get a warning saying the case is unused. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 10 Jul 2010 03:58 lucdanton wrote: > On Jul 8, 5:56 am, Andre Kaufmann <akfmn...(a)t-online.de> wrote: >> [snip] >> I tried to get a compilable template function of Compose with a >> combination of "auto" and "decltype" to forward the type, but couldn't >> get it compiled, without specifying the parameter type. >> [snip] > > C++0x: > > template<typename F1, typename F2> > auto compose(F1&& f1, F2&& f2) > -> decltype( > std::bind(std::forward<F1>(f1), > std::bind(std::forward<F2>(f2), > std::placeholders::_1)) > ) > { > using std::placeholders; > return std::bind(std::forward<F1>(f1), > std::bind(std::forward<F2>(f2, _1)); > } > > How about that for verbosity (and duplication) ? No comment about verbosity ;-). But cool you got it to compile. Respect! I still have trouble to get it compiled with VC2010, so I suppose you used GCC ? Comeau online also complains about: error: "auto" is not allowed here auto compose(F1&& f1, F2&& f2) But it's a rather new standard, so no wonder that multiple compilers "think/interpret different" ;-). It's also a good example, that the verbosity C++ forces us to use is contra productive regarding portability. IMHO the more complex the code is, the more problems you get regarding portability (between compilers and platforms) > We can only hope that > we will one day have true type inference (just auto prototype(Type > t, ..) without the "-> ret_t" late return specifier) ;). I suppose it > could easily come as an extension and once popular be enshrined in the > standard... > [...] Yes, C++ should use introduction of C++ modules to get rid of all the verbosity. It's time to strip it down, before it gets killed by it's own complexity - IMHO - Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Ian Collins on 10 Jul 2010 03:56 On 07/ 9/10 01:16 AM, Walter Bright wrote: > Ian Collins wrote: >> On 07/ 8/10 08:16 AM, Walter Bright wrote: >>> Mathias Gaunard wrote: >>>> I personally don't understand the point of non-recoverable exceptions >>>> at all. If they're non recoverable, it means it is something that >>>> should *never* happen, and therefore is a bug in the program itself. >>>> The program might as well abort and terminate directly. Trying to >>>> clean up in the face of something that should never happen in the >>>> first place cannot work, and might actually lead to even more errors. >>> >>> Yes, you're quite right. >>> >>> Being able to catch them, however, can make debugging a program easier. >> >> Isn't a breakpoint on abort() a better alternative? I wouldn't want any >> unwinding or object clean-up to occur under those conditions. Along >> with the risk of more damage being done, valuable state information may >> be lost. > > 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. Yes, but the installed handler (more likely a trap than an exception) does not change the context. The "exception" is handled at the point it is "thrown". I guess you could capture the entire machine state, including call stack and throw that. Although if the mechanisms to do that are available, the ability to dump core and about is probably there as well! -- Ian Collins [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 10 Jul 2010 04:08
In article <32b35341-4684-4c81-a8ca-3f073b0bca54(a)b35g2000yqi.googlegroups.com>, Edward Rosten <edward.rosten(a)gmail.com> wrote: >On Jul 6, 8:27 pm, Walter Bright <newshou...(a)digitalmars.com> wrote: > >> 3. Const may be legally cast away and the underlying data mutated. (When using >> const as a type constructor, not as a storage class.) >> >> Without transitive immutability of the pure function arguments, there's no way >> to guarantee that two calls to the pure function with the same arguments will >> produce the same result. > >Indeed. Basically, the C++ type system, including const allows one to >use the compiler to make sure certain classes of error can never >happen. Pure functions will help this by adding expressiveness. In >fact, I would argue that most of the time that const is used, what is >actually wanted is pure. I largely agree, but things aren't quite so simple once recoverable exceptions or threading are added. Purity can mean that THAT call must be purely functional, or that nothing else may change its state while it is executing, or both. Most parallelism models (including Fortran and C++) forbid such activities (but it's uncheckable), except for atomic objects and some of the library side-effects. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |