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

From	Richard Heathfield <rjh@cpax.org.uk>
Newsgroups	comp.lang.c
Subject	Re: Why the C programming language book was never updated past C89?
Date	2015-02-05 15:01 +0000
Organization	go, ion artisan!
Message-ID	<mb00je$3nc$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> <mavvtm$nr$1@dont-email.me>

Show all headers | View raw

On 05/02/15 14:49, Bartc wrote:
> On 05/02/2015 13:52, Richard Heathfield wrote:

<snip>

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

We'll have to agree to disagree about this one. (We recently had a 
discussion about it, and neither of us convinced the other.)

<snip>

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

FCVO 'we'. :-)

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

To be fair to both of us, modern syntax-colouring editors make both 
problems far less likely to hold us up for very long.

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

Good. Comments are supposed to be documentation, not disabled code. If 
you need to disable a block of code temporarily, use #if 0/#endif. Or, 
if you prefer:

#if FOO_ENABLE
  stuff(); /* comment */
  200 more lines
#endif /* FOO_ENABLE */


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

Line-splicing happens in TP2, but comment removal doesn't happen until TP3.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Thread

csiph-web