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 14:49 +0000
Organization	A noiseless patient Spider
Message-ID	<mavvtm$nr$1@dont-email.me> (permalink)
References	<5478fb0c$0$22069$426a74cc@news.free.fr> <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>

Show all headers | View raw

On 05/02/2015 13:52, Richard Heathfield wrote:
> On 05/02/15 13:18, David Brown wrote:

>> Apart from a few
>> technical details of floating point support, and perhaps some library
>> choices, C99 seems to me to be a solid improvement over C90.  Of the
>> list at <http://en.wikipedia.org/wiki/C99#Design>, which features of C99
>> make it a "ghastly mess" ?

> 2) intermingled declarations and code - makes code easier to write, but
> harder to read. In my view, easy-to-read takes precedence.

Completely agree. I've already posted in past about all the 
disadvantages of mixing up declarations and code.

> 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.

Not sure about this. We do need ways of specifying 8, 16, 32 and 64 bit 
ints, as well as ints where we don't care what the size is. What's the 
best way of doing that? But typing, for example:

unsigned long long int x;

perhaps isn't the most succinct way of doing so.

> 6) one-line comments: unnecessary, since we already had
>     /* one-line comments */

Well, we need one-line comments, as they seem to be the vast majority of 
them. The point of a one-line comment is that it can be written quickly 
without needing to delimit the end of it.

But I would have preferred a single-character symbol rather than // and 
its associated bug. Note that /* ... */ comments introduce bugs of their 
own, for example:

puts("one");     /* first
puts("two");     /* second */
puts("three");   /* third */

Displays "one" followed by "three". With a /properly implemented/ 
one-line comment terminated by eol, that wouldn't happen.

Another problem with /* ... */ comments is that they don't nest. So you 
can't comment out a block of code that includes /* ... */ as you can 
with //.

> 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();

That must surely be a design error in the language? Everything after // 
must be comment, and you wouldn't need a continuation character for a // 
comment; you'd just start another // comment on the next line.

Any actual line continuation character would need to go before the //.

-- 
Bartc

Thread

csiph-web