Re: Why the C programming language book was never updated past C89?

From	Bartc <bc@freeuk.com>
Newsgroups	comp.lang.c
Subject	Re: Why the C programming language book was never updated past C89?
Date	2015-02-05 19:38 +0000
Organization	A noiseless patient Spider
Message-ID	<mb0gqs$e4i$1@dont-email.me> (permalink)
References	(1 earlier) <54d34897$0$13647$882e7ee2@usenet-news.net> <maviu4$dht$1@dont-email.me> <mavqib$ah7$1@dont-email.me> <mavsi2$ibc$1@dont-email.me> <lnoap8kxf2.fsf@nuthaus.mib.org>
Show all headers | View raw
On 05/02/2015 18:47, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:

>> 2) intermingled declarations and code - makes code easier to write, but
>> harder to read. In my view, easy-to-read takes precedence.
>
> I disagree.  Mixing declarations and statements (the word "code" seems
> ambiguous) makes it easier to move declarations closer to where they're
> used, and to initialize objects with their declarations:
>
>      {
>          int x = ...;
>          /* do some computations that modify x */
>          const int y = x * 2;
>          /* code that uses y */
>      }
>
> In C90, I could do the same thing by introducing a new scope:
>
>      {
>          int x = ...;
>          /* do some computations that modify x */
>          {
>              const int y = x * 2;
>              /* code that uses y */
>          }
>      }
>
> The alternative is:
>
>      {
>          int x = ...;
>          int y;
>          /* do some computations that modify x */
>          y = x * 2;
>          /* code that uses y */
>      }
>
> but then it's difficult to tell at a glance that the assignment is the
> only thing that sets the value of y.

It only makes it harder to see that if it's the same y, or whether there 
are half a dozen variables all called 'y'.

Disadvantages of allowing declarations anywhere, and allowing the same 
name to be used in different block scopes:

* When encountering a variable name X, you have to scan backwards every 
line from that point, to the start of the function, to look for the 
nearest definition. [Instead of going straight to the start.]

* Given any two occurrences of the variable X, you can't easily see 
whether they refer to the same variable or not without analysing 
practically the entire function. [Normally there would only be a single 
X per function]

* With any occurrence of X, you can no longer rely on the declaration 
you remember seeing for X giving you its type, because there might be 
another, shadowing definition for X with a different type. In fact, 
every variable name you look at now has to be double-checked.

* Because declarations in blocks shadow outer ones, if a declaration is 
accidentally omitted, deleted, commented, or misspelt, then you will end 
up mistakenly using an outer version.

* Similarly, you can inadvertently shadow an outer variable (example: 
nested for-statements each starting for(int i=0...)).

* It's harder to see where the code actually starts. With declarations 
followed by statements, it's usually obvious where the declarations end 
and statements begin (if not you can so a sort of 'binary search'). 
Instead you now have to start at the very beginning and scrutinise every 
line.

* Mixed declarations clutter the code. Once declarations are out of the 
way, then algorithms are clearer with just the names.

* If you need to think of another variable, you have to scan the whole 
function to see if it's already been used. Then you have to decide 
whether you need to use a different name because the scopes cross, or 
can get away with using the same name.

* If you want to copy and paste fragments of code from one part of a 
function to another, you'd better make sure you take include the 
declarations of any variables! Otherwise there might be nasty surprises.

* If you want to document all the variables in a function, now it's a 
much harder job because the declarations are disseminated through the 
code with possibility of the same name used multiple times.

* (More of technical objection but I'm uneasy with the idea of having a 
name which is hard to pin down. If I want to talk about variable X in 
function F, I now have to specify exactly which block of F it's defined 
in, especially if there are several Xs; how do I do that?)

I can go on but you should get the idea.

Many of the objections can be overcome if multiple versions of the same 
name aren't allowed, so that there is only one 'X' in the function for 
example. But AFAIK I know the same name can be reused in different 
scopes, so people will make use of that either deliberately or 
inadvertently.

Actually, given that people are always suggesting to keep functions 
small, you have to wonder why it is necessary to declare a name right 
next to it's first use instead of at the beginning of the function a 
mere dozen lines away, if that.

-- 
Bartc


>> 3) long long int et al: utterly unnecessary. Implementations were
>> already free to make long int 64 bits (or more). We already had a type
>> menagerie, but now we have a type safari park. There's this enormous
>> herd of types, just roaming around the place looking for victims.
>
> Backward compatibility often prevents changing the sizes of fundamental
> types, or at least makes it difficult.
>
> I know you find the name "long long int" ugly, which is understandable,
> but I don't share your dislike.
>
> I do think we need to be able to have a number of distinct integer
> types, and it's not clear just how many.  Making long int 64 bits means
> imposes restrictions on the smaller types; we'd pretty much have to have
> 8-bit char, 16-bit short, and 32-bit int if we want to cover all the
> obvious sizes.  (This is for typical implementations; exotic things like
> 37-bit one's-complement integers are another matter.)
>
> Very old (pre-K&R) C didn't have the short, long, or unsigned keywords.
> It soon became obvious that just having a single integer type `int`
> wasn't sufficient.  The problem is that additional integer types were
> added to the language in an ad-hoc manner.
>
> I'd like to see a mechanism that permits an implementation to provide an
> arbitrary collection of integer types in a coherent manner.
> Unfortunately, it's too late to change C, though <stdint.h> does provide
> a reasonably coherent layer o top of the "type safari park".
>
> I do think that adding long long was a goodd idea.
>
>> 4) variable-length arrays: totally unnecessary, and introduces an
>> undetectable point of failure.
>
> As others have mentioned, that point of failure (insufficient memory to
> allocate a VLA object) applies to fixed-size arrays as well.  VLAs do
> make it easier to run into it.
>
> I've previously pointed out that you can use VLA types without having
> local VLA objects.  You can define a type:
>
>      size_t height = /* ... */;
>      size_t width  = /* ... */;
>      typedef vla[height][width];
>      vla *p = malloc(sizeof *p);
>
> You can check whether the allocation succeeded or failed, and you can
> then use ordinary indexing operations on *p, and they'll automatically
> adjust for the non-constant array dimentions.
>
> On the other hand, such a type can only be defined inside a function,
> which seriously limits its usefulness.
>
> One thing I find annoying about C11 is that VLAs were made *optional*.
> As a programmer, I can choose whether or not to use VLAs.  Why should
> the implementer of my compiler make that choice for me?  Were there
> vendors who refused to implement C11 unless they could omit VLAs?
>
>> 5) flexible array members: in my view a rather pointless change; if they
>> were going to codify what lots of people were already doing, it might
>> have been a good idea to codify it in the way that lots of people were
>> already doing. But it doesn't bother me that it's there, since lots of
>> people were already doing that anyway.
>
> Nothing to add.
>
>> 6) one-line comments: unnecessary, since we already had
>>      /* one-line comments */
>> and introduces a particularly hard-to-find bug. A friend of mine working
>> at Oracle once complained to me that they'd spent days trying to find
>> out why bar() wasn't being called, in:
>>
>>     foo(); // does the foo thing in c:\path\morepath\bin\
>>     bar();
>>
>> (The code is of course invented, but it accurately mirrors the bug.) And
>> it took them *days* to find it. At Oracle, that adds up to a fair amount
>> of lost money.
>
> If I were designing a new language from scratch, it would probably
> *only* have end-of-line comments.  Multi-line comments can trivially be
> built from them, and comments in the middle of a line are rarely useful.
> If it did support comments in the middle of a line, they wouldn't be
> permitted to occupy more than one line.
>
> I'm sure a lot of people would hate such a language.  Don't worry,
> there's little risk that I'll ever get around to designing or
> implementing it.
>
> The trailing backslash problem is potentially serious.  It can be partly
> addressed by having compilers warn about line continuations within
> end-of-line comments (which very likely to be mistakes).  One other
> thing I'd change is to make a trailing backslash *followed by
> whitespace* act aa a line continuation.  An invisibly modified version
> of your example:
>
>     foo(); // does the foo thing in c:\path\morepath\bin\
>     bar();
>
> would call bar (given a conforming compiler), because I added a space
> after the final \.  But I think some preprocessors get this wrong (or
> perhaps they justify it via some kind of transformation in translation
> phase 1).
>
>> 7) new library functions: well, I'm not going to bitch too much about
>> these, but I don't personally feel the need to use any of them, and I'm
>> hard-pressed to even think of a name or two. snprintf, yeah, I remember
>> that one.
>
> snprintf() is very nice; it lets you *safely* build formatted strings.
>
> C99 also added float and long double versions of the mathematical
> functions.
>
>> 8) new headers: naturally, I see no need for these, given the above.
>
> Personally, I really like <stdint.h> and <stdbool.h>.  (I'm not crazy
> about the way bool was added to the language, but I think adding it was
> a good idea, and the ugliness was probably necessary for backward
> compatibility.)
>
>> 9) type-generic math: not something I personally have any need for, but
>> I can see why it might be useful.
>
> Likewise.
>
>> 10) improved support for IEEE floating-point: was this actually
>> necessary? And did it really have to take twenty pages to define it? One
>> of the best things about the ISO C standard was the brevity of the text,
>> but C99 adds over 200 pages to the document, almost doubling its size.
>>
>> 11) designated initialisers: ugly syntax to solve a non-problem.
>
> In many cases I find code that uses them much more readable.
>
>      struct foo obj = { 2, true, "", 7 };
>
> What does `true` mean in this context?  Why should I have to care about
> the order in which the members were defined?
>
>> There we go. Plenty there for you to yell at me about. :-)
>
> As usual, I respect your opinions; I just don't share all of them.
>
Thread

csiph-web