Engineering a list container. Part 1.

[Malcolm McLean]

The obvious counter example is a POSIX file descriptor.

A Turing machine can't do IO. It just shuffles bits. That's why I always
emphasise separating bit shuffling functions from IO. Then everything works
nicely, you don't have these problems of needing destructors that do anything
other than free memory, and you don't have any error conditions except out
of memory.

 

[Ian Collins]

A Turing machine can't do IO. It just shuffles bits. That's why I always
emphasise separating bit shuffling functions from IO. Then everything works
nicely, you don't have these problems of needing destructors that do anything
other than free memory, and you don't have any error conditions except out
of memory.

So your applications live in a snow globe?

 

[Malcolm McLean]

So your applications live in a snow globe?

Basically yes.

The clever part of the program, which takes all the hard work to write, takes
one pattern of bits, and shuffles it about. Sometimes it returns a new pattern
of bits, sometimes it modifies the original one, that's just a minor detail.

These bit shuffling functions ideally go in separate source files. There's no
reason ever to use non-portable constructs, except for silly marginal cases
like expecting eight bits in an unsigned char where the portable version is
fiddly and provides no practical benefit. There in C. Anything that supports
call to C can set up one pattern of bits, call them, and get back the resulting
pattern of bits.
The patterns are of course human-meaningful in almost all cases. They might
represent an empty crossword grid and a list of English words, and the output
is a filled grid with interlocking words. But the computer doesn't know it's
creating a crossword. All it sees is bits it has to shuffle about until it
reaches a situation where there are no blank cells and every continuous line
of more than one cell matches one of the patterns in the list.

That then has to be hooked up to IO so that you can see the result. This is
usually pretty trivial if you've got a decent IO library. Writing a decent
IO library isn't trivial of course, it's difficult in a different way. Baby X
is an example of an IO library.

 

[Eric Sosman]

So your applications live in a snow globe?

... and when they're not in a state of chaos, they're down. ;-)

 

[Ian Collins]

Basically yes.

The clever part of the program, which takes all the hard work to write, takes
one pattern of bits, and shuffles it about. Sometimes it returns a new pattern
of bits, sometimes it modifies the original one, that's just a minor detail.

Unfortunately some of us have to write dumb, easy to write programmes
that interface with the real world. One of these days I might be lucky
enough to move on to clever snow globe programmes.

 

[glen herrmannsfeldt]

... with a potential performance penalty. As things stand,
the compiler knows what calls to sqrt() or memcpy() or div() do,
and can achieve their effect by using special in-line instructions
like SQRT or MOVB or DIV. The compiler might even pre-compute the
results of some of these "function calls" at compile time,
eliminating not only the call but also the computation itself.
Were it not for the Standard's prescription of what these functions
do, optimizations of this kind would be difficult if not impossible.

As far as I know, many compilers will use FSQRT in place of a
call to sqrt(). Presumably if no reference to errno is in sight.

I am not sure how far away you would put a reference to errno
for the compiler to notice.

(Aside: Yes, I know that a typical machine's "bare" FSQRT
instruction probably isn't a drop-in substitute for sqrt() --
it's unlikely to set `errno' properly in the event of a domain
error, for example. Even so, the compiler could perfectly well
generate an FSQRT instruction followed by a conditional call to
a failure-fixer function, the latter executed only if FSQRT
reports trouble.

More interesting is to use FSINCOS in place of calls to sin().
For large enough values, it just leaves the value on the stack,
which could be surprising to some.

-- glen

 

[jacob navia]

Le 25/12/2013 03:48, Ian Collins a écrit :

Unfortunately some of us have to write dumb, easy to write programmes
that interface with the real world. One of these days I might be lucky
enough to move on to clever snow globe programmes.

Obviously C++ is the answer for that.

I would recommend you then, that you do not visit C related groups and
stick to the C++ group that is very easy to find.

Why do you participate in a C language group if C++ is so good?


Obviously you want to "preach the good word" here. Convince those
backwards C programmers that they are dead wrong and that C++ is the
alpha and omega of software engineering.

Please do that in other groups.

Can't you go to comp.lang.assembly.x86?

Try to convince those guys that assembly is OUT

Or to comp.lang.Fortran?

 

[Ian Collins]

Le 25/12/2013 03:48, Ian Collins a écrit :

Obviously C++ is the answer for that.

I would recommend you then, that you do not visit C related groups and
stick to the C++ group that is very easy to find.

Why do you participate in a C language group if C++ is so good?

Where did I mention C++ in the message you quoted?

 

[James Kuyper]

As far as I know, many compilers will use FSQRT in place of a
call to sqrt(). Presumably if no reference to errno is in sight.

I am not sure how far away you would put a reference to errno
for the compiler to notice.

errno acts like a global variable - checking the value of errno could
occur in a different translation unit from the sqrt() call, so the
compiler alone does not, in general, have enough information to perform
such an optimization.

 

[James Kuyper]

On 12/26/2013 11:58 AM, James Kuyper wrote:
....

errno acts like a global variable

Note: as of C2011, it's thread-local, not global - which doesn't affect
my conclusions.

 

[Öö Tiib]

errno acts like a global variable - checking the value of errno could
occur in a different translation unit from the sqrt() call, so the
compiler alone does not, in general, have enough information to perform
such an optimization.

Standard has such footnote: "Thus, a program that uses errno for error
checking should set it to zero before a library function call, then inspect
it before a subsequent library function call."

There certainly can be case when it is hard to decide but in common
code it does not take rocket science to detect that the program does
not behave like said above between subsequent library function calls.

 

[Eric Sosman]

errno acts like a global variable - checking the value of errno could
occur in a different translation unit from the sqrt() call, so the
compiler alone does not, in general, have enough information to perform
such an optimization.

The compiler can (or should) be able to discern many cases
in which `errno' is clearly not being inspected. My example was

y = sqrt(x); // might set errno
// errno not inspected here
z = log(y); // might set errno

Any program that's interested in the `errno' output from sqrt()
and fails to examine it before calling log() is erroneous. The
implementation is not obliged to set `errno' as part of sqrt()
only to see it overwritten as part of log().

Your observation is valid for any `errno' value produced
by log(), unless the context includes further library calls
that might contaminate it in turn.

It appears to be less well known that almost any library
function may change `errno', even those that don't actually
encounter any errors. FAQ 12.24 explains one such example.
Another anti-pattern one occasionally sees goes something like

stream = fopen(filename, "r");
if (stream == NULL) {
perror(filename);
return errno;
}

.... where an `errno' from an fopen() failure (if there is one;
fopen() is not required to set `errno' though many versions do)
may have been overwritten during perror(). If the idea is to
return fopen()'s `errno' value, use something like

if (stream == NULL) {
int errno_save = errno;
perror(filename);
return errno_save;
}