The cost [of a non-portable construct] must always be weighed
against the benefit.
The benefit is not quantifiable, here in comp.lang.c, because the
benefit achieved by non-standard code is not describable either.
(If you believe otherwise: What does adjSysIntObjPriority() do?
How much benefit is it to use it?)
The cost, here in comp.lang.c, is obvious: a program that calls
adjSysIntObjPriority() will not even compile.
Thus, in comp.lang.c, the quantified cost ("program does not
compile") always exceeds the unquantified benefit. If you want to
talk about the benefit, you need a different newsgroup.
You do not use directories in your programs?
You always work in the current directory?
This depends on the code. Much of my code does not use files at
all. Other code actually implements the underlying file system,
but to "use a directory" you do things like:
dvp = nd.ni_dvp;
error = VOP_READDIR(dvp, ...);
Do you believe I should post about this here in comp.lang.c? Will
you find such information useful?
Because that is not covered by C89.
I never said it was. I said: "the cost must be weighed against
the benefit." The benefit of the above (nonportable) code is not
quantifiable here in comp.lang.c, but the cost is clear: the above
will not work on Windows-based systems, nor on POSIX systems even
though it happens to be an internal implementation *of* a POSIX
system.
You never do any other output to the screen but using printf fwrite???
Many of the computers I program today do not even have a "screen".
(They do have serial ports.)
GUIs are not covered by C89
Indeed. But I have not programmed GUIs for almost a decade now.
You do not use the mouse, nor any other kind of input device?
Again, many of the computers I program today do not have a mouse
(or a keyboard, just a serial port).
You never use the network?
Not the way you think about it.
*ANY* useful program that DOES something MUST use the underlying OS in
some way or another.
Substitute "any useful hosted-implementation C program" for "any
useful program", and "underlying implementation" for "underlying
OS", and yes, it must -- but the only things guaranteed to be
*in* that underlying implementation are those in the standard(s)
to which it conforms. The only standards that are on topic here
in comp.lang.c are the C standards (C89, C95, and C99, mainly,
although even K&R-1 C is still reasonably topical, in my opinion).
And, as I said, the cost of a nonportable function must always be
weighed against the benefit. This equation is much clearer when
one is outside comp.lang.c: if you need to walk a directory, and
opendir(), readdir(), closedir() etc all exist because you are in
comp.unix.programmer, the benefit to using them is obvious. The
cost is also minimal, since they are POSIX-standard. The fact that
readdir() on vxWorks happens to be implemented via a "magic" ioctl()
is not important, and the cost of using the ioctl() directly is
clear (it does not work at all on Unix and Linux) while the benefit
is tiny. But in comp.lang.c, POSIX itself is off-topic, and only
the cost ("not available in the C standards") is clear.
Do you believe I should use comp.lang.c to talk about the benefit
of semBCreate() vs semMCreate()? Should I use this newsgroup to
describe the rtpSpawn() function? What will you get out of a
discussion of the parameters to ataDevCreate()?
"\n"); }