Re: [9fans] kenc
Saint Sexburga wrote:[color=blue]
> surely you can sympathise with those of us who feel that they are
> drowning in the rising tide of complexity of modern computing
> "standards". C99 is the least of our worries, but even here, do you
> feel that Dennis Ritchie was entirely wrong in his answer to the
> question "Are you satisfied with C99?", when he said, amongst other
> "I was satisfied with the 1989/1990 ANSI/ISO standard. The new C99
> standard is much bulkier, and though the committee has signaled that
> much of their time was spent in resisting feature-suggestions, there
> are still plenty of accepted ones to digest. I certainly don't desire
> additional ones, and the most obvious reaction is that I wish they had
> resisted more firmly" and "Of the new things, restricted pointers
> probably are a help; variadic macros and bool are just adornment."[/color]
It's certainly true that the bulk of C99 seems excessive; largely
it is due to having a parallel set of wchar_t-oriented functions
duplicating the functionality of the char-oriented ones (which I
predicted back in 1986 when we were still debating how to
accommodate extended character sets). A lot has also been added
in areas such as floating-point that is of interest to a limited
portion of the programming community. Unfortunately, a lot of
useful things naturally fall into the "limited interest" category;
we try to accommodate those interests with libraries when feasible,
but the key point is standardization so that applications are
readily portable across platforms (including Plan 9, to the extent
that it supports such standards).
Variadic macros are sufficiently useful (typically for printf-like
error handling) that GCC had already invented a form of them; we
would have liked to simply adopt that existing practice, but found
enough potential problems with it that we adopted a slightly
Bool is another example of numerous incompatible extensions to
achieve the effect (usually by programmers in this instance, rather
than in compilers), which is a good indication of a facility crying
out for a standardized solution. It obviously isn't a "deep"
feature, which it can't be given the need to remain compatible with
existing C, but it is useful to have.
> Doug, I'm not getting at you, but do you never feel, enough is enough?[/color]
I understand the frustration. Many standards and portions therefof
can be ignored if you don't need to use certain specified features.
Unfortunately, a very large amount of "infrastructure" has evolved
and a very large amount of current software has been built upon it.
Not long ago I tried to build GCC 4.0 on Solaris 8 and found that I
needed to install about a dozen nonstandard support libraries before
I could get it to build. (I think that current releases of Solaris
and Linux are shipped with most or all of those libraries.) In fact
I ran out of disk space and had to devise a workaround to get the job
done. You can imagine that adapting such software is a problem due
to the large number of library interfaces that must be understood.
I don't see any way to undo the situation..
Re: [9fans] kenc
On Wed, 2007-05-02 at 08:32 +0000, Douglas A. Gwyn wrote:[color=blue]
> I don't see any way to undo the situation..[/color]
C at least has a luxury of vectoring off all the eager beavers
to a C++ committee, where languages like Fortran don't have
a Fortress to protect them from mutilation yet (pun intended).