From: Mathias Gaunard on
On Jul 8, 2:33 pm, lucdanton <lucdan...(a)> 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

> 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 for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Dragan Milenkovic on
Andre Kaufmann wrote:
> Dragan Milenkovic wrote:
>> [...]
>> 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.


[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: nmm1 on
In article <i16ovn$e2l$1(a)>,
Dragan Milenkovic <dragan(a)> 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

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?

Nick Maclaren.

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: nmm1 on
In article <dek936du6p85f2unijjirl9j1n6pahdtmb(a)>,
George Neuner <gneuner2(a)> wrote:
>On Wed, 7 Jul 2010 06:11:44 CST, nmm1(a) wrote:
>>Walter Bright <walter(a)> 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.

Nick Maclaren.

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Andre Kaufmann on
demo wrote:
> On Jul 8, 5:56 am, Andre Kaufmann <akfmn...(a)> 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++.

> [...]


[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]