Oozing poison

[Ian Collins]

The exception never occurs (i.e., I never run out of memory). It's the
added code to handle the exception and it's effect on a (very) hot codepath
that causes the 4% hit in performance. That is the only change in the
codebase, and I ran the benchmark three times with each flavor (try/catch/new
vs. malloc). I have to admit that I was surprised by the difference and I'm
going to take a look at the actual codepaths and do some profiling to see why
adding a try/catch clause has such a large effect, when the exception is never
taken.

How about new (without the exceptions) compared to malloc? new is doing
more work than malloc, one reason I suggested a specialised allocator.

 

[88888 Dihedral]

在 2012å¹´1月29日星期日UTC+8上åˆ6æ—¶32分57秒，Ian Collins写é“：

How about new (without the exceptions) compared to malloc? new is doing
more work than malloc, one reason I suggested a specialised allocator.

Well, an object with some methods to generate new objects not to be garbagecollected very soon following the o stack push-pop mechnism of auto varibles are somewaht evil in C++ if the programmer does not think carefully and write codes to chain these methods in class B arbitrarily then there might be a definitely expoenti ally growth rate of the heap used by a lousy fatprogramming hog in some programs.

 

[Ian Collins]

在 2012å¹´1月29日星期日UTC+8上åˆ6æ—¶32分57秒，Ian Collins写é“：

Well, an object with some methods to generate new objects not to be garbage collected very soon following the o stack push-pop mechnism of auto varibles are somewaht evil in C++ if the programmer does not think carefully and write codes to chain these methods in class B arbitrarily then there might be a definitely expoenti ally growth rate of the heap used by a lousy fat programming hog in some programs.

Do what?

 

[Ian Collins]

Which will have additional overhead to allocate, construct,
destroy and deallocate the application class derived from std::exception, nicht wahr?

Only in the exceptional circumstances where one is thrown. As I said,
the state has to be returned somewhere.

I think you would find that "small nested functions" is exactly what is
used, and in this case, the object passed doesn't necessary _return_ the state
passed so much as provide a channel for returning the state to the final
receipient.

Now in the core processor simulation code sigsetjmp/siglongjmp are used to reset
the simulated processor to the start of the instruction processing loop when
an exception occurs executing an instruction (an address error, invalid instruction,
etc). These could possibly be converted to exceptions, but I'm quite sure that
the performance would be worse and the RAS characteristics of the application
wouldn't change appreciably.

By using exceptions, you are able to utilise the full power of the
language, such as RAII which out of band jumps preclude.

One point I have been trying to make is bolting exceptions onto an
existing design is seldom a good idea. Neither is having to take them
out, which was a situation I once found myself in! Error handling is a
fundamental part of a system's design and mixing paradigms invariably
ends in tears.

I remember reading Tom Cargill's article on exceptions back when they were
introduced to the language - I think many of his points still apply - exceptions
are not a universal panacea and careful analysis of all codepaths need be done
to prevent memory leaks or access to deallocated data when exceptions are being
thrown.

This is true and the language provides us with the tools to achieve
this. Tools which cannot be used with out of band jumps!

The same caveats, of course, apply to setjmp/longjmp as well, but I
don't need to allocate an exception object (just set one of 10 bits in a member
field of the current 'this' when the longjmp is issued; the jmp_buf also a member
of the current object).

The cost of constructing an exception object are far outweighed by the
cost of throwing it *in the exceptional case*.

I haven't seen this in practice, but then my sole exposure to C++ code
has been in the Operating Systems/Microkernel/Hypervisor area none of which
used exceptions (most of which predated exceptions , aside from one
application at a major internet certification authority, which also predated
exceptions.

That's where our experiences diverge, I've been comparing the
performance of exceptions on various platforms for many years and I've
found exceptions are generally faster (always on the Unix and Linux
platforms I use). From my perspective, the exceptions vs error returns
argument was settled long ago.

Let me be clear, I never actually took an exception in the test I described above;
the sole difference was changing the

buf = malloc(XXX); if (buf == NULL) { YYY}

test to

try {buf = new uint8[XXX];} catch (std::exception& e) { YYY }

(and of course, the corresponding 'free()'<-> 'delete []' changes).

You have introduced two variables, exceptions and new. Try eliminating
both.

 

[Jorgen Grahn]

I agree, of course, but when you have to deal with legacy C or low level
code casting appears (and I have to say that there is a lot of legacy C
code)

Yes, and I think part of what I was trying to say was: When you have a
chance to rewrite such code, it pays to first check if you can
eliminate the cast in some other way (e.g. with a wrapper function
which does the casting) rather than replace the C-style cast with the
best C++ cast.

/Jorgen

 

[Robert Miles]

So, you're not coding in C++, and you come to a C++ community hangout to
complain about C++ being difficult to comprehend, and you expect what,
sympathy?<shrug>

I'm not coding in C++ ANYMORE
I could not possibly see how it can be used to write robust code

You expect us to trust your judgement?

[I've found C++ _much_ easier to write robust code in compared to C.
It is clearly no proof against incompetent coders (nothing is), but it
does offer some really good tools to help competent ones...]

Well, objective-c (and it's inherent to all c based languages, unless
you start ripping out pointers, etc) is prone to allowing a single fly-
idiot
poisoning the whole barrel, and java like languages
were designed precisely to keep idiots at bay, but c++ seems to be
especially
susceptible to providing morons with tools to automate
writing some crap code.

Looks like you've been fired from a programming management job
for incompetence in choosing which programmers you hired, but
weren't fired fast enough to keep you from becoming familiar
with those incompetent programmers.