I noticed how you didn't say never. So when you *have* needed some of
that functionality, what did you do about it?
Implimented in terms of the platforms I cared about, and documented
the platform restriction. Beyond those, I never received requests
to port to additional platforms.
Which is not to say that I paid lipservice to platform dependancies:
instead, it was the case that I paid close attention to what was or
was not promised by C, and in so doing, wrote code that avoided
the issues when possible, and isolated the affected areas when
dependancies were unavoidable.
Now here's the point: in NO case that I can remember, did I choose
another language because it offered portability guarantees that C did
not. Each time, I chose a language suitable for the nature of the
project.
The portability issues that you describe were never more than a
miniscule consideration in the work I did. Much more difficult was
portability at the OS level -- matters such as dealing with network
programming interfaces or serial port interfaces. The layers you
describe would be, for the work I did, essentially akin to
microoptimizations.
[...] Memory leak analysis sometimes, but only
one of the several extensions to heap functionality you propose would
make any difference to me (and that only on the odd occasion.)
So your argument then, is that you don't think there should be memory
leak assistance, because the other proposals I made are not something
you would be interested in?
Your proposals would, in my opinion, do almost nothing to save C
amongst the general populace of programmers: most of your proposals
are irrelevant for most programs, I believe. They might do an
admirable job of fixing one corner of the language, but I don't
believe for a moment that C is "crying out for" that set of
changes. You accuse the C99 committee of not addressing the "real"
problems of C, but in my assessment, what you propose would be
largely greated by a Hearty High-Ho "So What?" by the great majority
of C programmers.
Okay ... So here is another one that you would use, but only if they
were tied to Unix and named "nothl" and "htonl"?
No, if they were provided by the C library, my first question would
be how to override them to get at the implementation's routines
of the same name: unless the C standards committee -defined-
them as operating the same way as in POSIX, C's versions would
be of no utility to me. I have no use for the operations outside
of network programming, and I'm sure the C standards committee knows
to butt out of the network programming standards area.
Are you saying these
are only possibly useful to Unix and therefore must not be available to
other platforms in a portable way?
I'm not in the business of writing Linux drivers or OS kernels that
would, optimally, be writable without changes for every platform
that the code might -possibly- be ported to. The effort that the
implementors of my network stack have to go through to provide
ntohl() and htonl() are of little interest to me: that's host
implementation, and I don't care what compiler extension or whatever
that they hide away in a system library or system header file intended
for system use. Whether such extensions are built into C or not
wouldn't have made C more useful for much of anything I did in
the last decade; such extensions might have marginally increased the
-theoretical- portability of some of my programs, but not one iota
would they have increased the -practical- portability of what I did.
Alloca(), and better heap management is actually a reaction to garbage
collection. Garbage collection makes memory management in other
languages a complete non-issue.
I've been using the symbolic computation language, "maple" a fair
bit over the last year. I profiled one of my programs to figure
out where to expend the most effort in speed improvement... and
found that 68% of the execution time was being spent in garbage
collection. I would have had to have developed hefty mathematical
theorems able to operate on the terms in-place (with no pointers,
and with the order of the terms open to change without notice)
to mathematically bypass the need for the garbage collection in
order to have a chance of significantly improving the speed of
my program -- greatly improving my program complexity (if such
theorems could be found at all) just to work around the slow
garbage collection. Sometime later, one of the developers mentioned
in passing that the speed of the garbage collector is proportional
to the -amount- of memory allocated, not to the number of memory
allocations. I am at a loss for words to describe how glad I am
to have your assurance that "Garbage collection makes memory
management in other languages a complete non-issue."
You are saying that adding enhancements to C are not a good idea,
because adding them to C++ would be better?!?!
I have a copy of the official printed ISO C++ standard. It is
a bear to find anything useful in it, precisely because C++
added so many (mandatory) features of narrow utility that the noise
drowns out the signal. If I -had- mentioned C++ at all (and I
did not), then Yes, it might have been with the notion that it
would be better to add the features to C++ than to C -- better to
let C++ degrade even faster on its own obsiety than to inflate C
for little gain.
Sorry, but I find your entire response
completely vacuous.
And I found your response to my response to be full of bad logic
and strawman arguments.