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 10 Jul 2010 04:01 On Jul 8, 2:33 pm, lucdanton <lucdan...(a)free.fr> wrote: > 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) ? As I said, you can't really avoid the duplication because function declaration and definition are separate. One way around this would be to not make compose a function but rather a polymorphic function object. > Also note that formally there is no guarantee that this code will do > as advertised: while the return type of std::bind is specified as > implementation-defined (instead of say, std::function<>), it could > still do type-erasure (like, say, std::function<>). I know that the > libstdc++ does use a functor template so all the signature (incl. > return type) is part of the type of what is returned. I don't understand why the type returned by bind is relevant for this code to work. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Dragan Milenkovic on 10 Jul 2010 04:16 Andre Kaufmann wrote: > Dragan Milenkovic wrote: [snip] >> [...] >> Because after quite a few generations of failures they finally got >> it right... Think AWT, MFC... or did they get it right? I don't know... > > I think QT got it right. Unfortunately it's not a standard. And IMHO, neither it should, since it uses moc preprocessor to generate additional code. I personally don't like that. -- Dragan [ 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:15 In article <i16ovn$e2l$1(a)speranza.aioe.org>, Dragan Milenkovic <dragan(a)plusplus.rs> wrote: >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. > >Even if a debugger is not available, on Linux, abort() will leave a core >file that contains the exact state of the frame that caused the problem. >Exception will pop up and leave the frame. Debugging is much easier >with abort(), and it is not equivalent to an exception handler, >since no stack unwinding. Not in my experience :-( Most of the time, the debugger claims that there is no stack, because the actual failure occurs deep in the run-time system (often while freeing memory). Unfortunately, this is an unavoidable consequence of the fact that calling sequences are designed for (benchmarketing) performance - the original IBM System/360 calling convention was doubly-linked, and you could almost always find out where a failure occurred. What I really can't understand, though I have never investigated in detail, is why this is so common even when the only exception cannot possibly have corrupted any data structures. My guess is that is because the compiled code leaves the stack in an invalid state in certain small windows, and the debugger isn't well integrated enough to recover from that. When I wrote my C operating system interface for MVS, it did handle that case correctly, despite the compiler using only a singly linked stack, and so did several other run-time system authors. Why is it so much less common today? Regards, Nick Maclaren. -- [ 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 23:27 In article <dek936du6p85f2unijjirl9j1n6pahdtmb(a)4ax.com>, George Neuner <gneuner2(a)comcast.net> wrote: >On Wed, 7 Jul 2010 06:11:44 CST, nmm1(a)cam.ac.uk wrote: >>Walter Bright <walter(a)digitalmars-nospamm.com> wrote: >>> >>>Does anyone use the [IEEE 754R] decimal formats? >> >>Not yet, obviously. But the reason for their introduction was the >>belief that they will. We shall see. > >I doubt we'll see much use until popular hardware (read "x86" and >maybe also ARM) supports decimal directly. AFAIK, only the Power6, >z10 and a couple of oddball chips currently have decimal capable FPUs. > >Power is certainly not "rare" but I don't think there are enough >installations to deserve calling it "popular" ... and the Power6 >hasn't been out long enough for most Power users to have upgraded. And then there is the question of when compilers and language standards will support it. Intel have stated that they intend to but I am not holding my breath. However, what many people miss is that there is the strong smell of a bandwagon gathering steam; most of them just fizzle out, a a very few blow up, but some do get going, squashing everyone else as they do. Fortran has just shrugged its shoulders, saying "been there - done that", and there is still plenty of collective expertise on writing radix-independent code. C++ did not regard it as relevant when I enquired but, like many such things, it might well get in via C. Regards, Nick Maclaren. -- [ 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 23:38
demo wrote: > On Jul 8, 5:56 am, Andre Kaufmann <akfmn...(a)t-online.de> wrote: > [...] > void foo() > { > using boost::phoenix::arg_names::arg1; > > auto Double = arg1 * arg1; > auto Tripple = arg1 * arg1 * arg1; > auto DoubleTripple = Double(Triple(arg1)); > printf("%d\r\n", DoubleTripple(3)); > } > Thank you - nice feature of Phoenix. If the generated code has no overhead it's definitively a library worth to use in C++. > [...] Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |