Cleanup patterns

[Default User]

Now I know why I haven't had any for the past 20 years

Because you're immortal? Wow.

(Apart
from the Social Security death 'benefit').

I have some freebie insurance from work, some multiplier times your
yearly salary.





Brian

 

[Keith Thompson]

Because you're immortal? Wow.

So far ...

 

[CBFalconer]

So far ...

Well, I only have experience to go by, and so far there have been
no exceptions. I've had a couple of near misses lately though. Is
this an omen? Maybe we need an ISO standard for reference.

 

[Richard Bos]

They don't crash the program, they call exit (which also calls
atexit).

To the end user, it's usually all the same.

In order to run your program primarily needs one resource, memory.
When it runs out of memory (e.g. due to a memory leak)

Well, _yes_. If you assume rampant bug that no C programmer should let
into a production program any more (and, therefore, some famous
companies regularly do), you might as well terminate the program there
and then. In fact, why not be pro-active, and terminate it at random
intervals?

there is hardly anything you can do except to (more or less)
gracefully terminate the program.

As shown upthread, for a _well written_ program, this is simply untrue.
It _may_ be the case, but often you have better options.

Not even that is always possible since some OS (IIRC, Linux)
never return NULL for malloc even when memory is exhausted.

Those OSes are broken. If you can't trust your OS not to lie to you, why
trust your computer at anything?

Richard

 

[Roland Pibinger]

That behavior is arguably non-conforming.

<offtopic>
When Linux Runs Out of Memory
http://www.linuxdevcenter.com/lpt/a/6808
</offtopic>

 

[Eric Sosman]

<offtopic>
When Linux Runs Out of Memory
http://www.linuxdevcenter.com/lpt/a/6808
</offtopic>

<offtopic>
http://lwn.net/Articles/104179/
</offtopic>

 

[Randy Howard]

Eric Sosman wrote

http://lwn.net/Articles/104179/

OT, Perhaps. Hilarious? Definitely.

Over-engineering a solution to a problem that doesn't even need
to exist.

 

[Bill Reid]

On a lot of modern CPUs the difference between a function call and a
jump (as in generated by switch or if) is nowhere near ten-fold when
compiled with an properly optimising compiler. One fold at most (note
that one-fold is ten times slower)

OK, I'm officially confused...I specifically said "two seconds or 20
seconds" as being "ten-fold" (as in, a thousand is a hundred "ten-fold"),
then you re-define "fold" as "ten times slower". So what you're saying
is that with a "properly optimising compiler", a function call is UP TO
"ten times slower"...which is basically what I was always told, it takes
somewhere around 4-8 extra cycles as overhead for a function call,
so I think we don't have a disagreement there?

or more typically up to 4 times
slower.

"6" was the magic number I was told (or actually read) to work with...

Indeed on at least two architectures I code for, a function
call (if not recursive) compiles to execute in exactly the same number
of CPU cycles as a regular jump/branch.

This may be true, and I don't doubt that it depends on the specific
function call and optimization "tricks" of the compiler in any event...

Of course, if you're programming for an architecture as archaic and
register-starved as the Pentium then function call overhead can be an
issue.

Yeah, slam the Pentium, then go ahead and slam "MIPS" and "SPARC"
while you're at it, since I've been able to significantly speed up or slow
down programs on all of them (in many cases, the exact same program
on all the different architectures).

Even so, improvements have been made to x86-64 which makes the
function call overhead for x86-64 even less than before.

I will admit that the ever-increasing power and speed of computer
hardware does make a lot of these considerations practically moot...but
that still doesn't excuse how I saw people coding back when it made
a TREMENDOUS practical difference, and these WERE what had
to be considered the elite systems software engineers in the entire
world...

 

[Bill Reid]

Maybe it's time for a 64 bit upgrade!

Then I'll re-write it all in Java!

 

[slebetman]

OK, I'm officially confused...I specifically said "two seconds or 20
seconds" as being "ten-fold" (as in, a thousand is a hundred "ten-fold"),
then you re-define "fold" as "ten times slower".

Sorry, I was confusing "fold" with "orders of magnitude". Fold, proper,
commonly means multiplication by that factor which makes what you said
correct and what I said wrong.

"6" was the magic number I was told (or actually read) to work with...

This may be true, and I don't doubt that it depends on the specific
function call and optimization "tricks" of the compiler in any event...

On a lot of modern architectures (this excludes x86-32 although it
includes x86-64) this is quite trivial (see below).

I will admit that the ever-increasing power and speed of computer
hardware does make a lot of these considerations practically moot...but

The point is not the speed of the hardware. No matter how fast the
hardware becomes a ten fold slowdown is STILL a ten fold slowdown. The
point is that x86-64 is not register starved allowing the compiler to
avoid using stacks to pass parameters and especially for the kind of
trivial functions we were discussing can also allow the compiler to do
*nothing* to pass parameters via overlays.

Hence for the kinds of functions we're discussing (small utility
functions to reduce indentation, remember that we're not discussing
function calling *in general*) passing parameters can be optimised to
generate zero instructions and calling the function itself generates
one instruction. On most modern machines that instruction takes the
same amount of time to execute as a conditional branch.

that still doesn't excuse how I saw people coding back when it made
a TREMENDOUS practical difference, and these WERE what had
to be considered the elite systems software engineers in the entire
world...

And now we have the conclusion. Your trick programming and inlining
WERE useful in the age of dino-mainframes where workstation CPUs were
nothing more than glorified microcontrollers. Today even lowly 50 cent
microcontrollers don't break a sweat executing deeply nested function
calls (unless you're doing something silly like directly generating
video signals on output pins without the help of graphics hardware).