Re: So what Standard are we working off?

Richard Heathfield <invalid@xxxxxxxxxxxxxxx> writes:
Keith Thompson said:
<snip>

I wouldn't avoid "new" and "class" in C code; C++ is a different
language. But C99 is a new version of the same language, and it just
might catch on.

Yes, it might, and so of course I /do/ avoid clashes in C90 code. I might
/think/ about using restrict as an identifier, but I don't actually do it.

(In fact, a few years ago I discovered that I had done precisely that, in a
program written before I'd ever heard of C99. Although that program has
never encountered a C99 compiler, I changed the code anyway. ISTR that I
used "constrain" instead.

But C0X people should bear in mind that our namespace is already crowded
enough, and should invade it no more.

On the other hand, there's something to be said for a clean language
design. Assuming that the functionality of "restrict" is something
worth having in the language, I can't think of a cleaner way to
specify it than with a new keyword. (It could have been "_Restrict",
I suppose.)

Or they could have invented yet another meaning for "static". 8-)}

There's always a conflict between (a) preserving existing code, and
(b) adding new features using the clean syntax they would have had if
they'd been in the language in the first place. I'm certainly
sympathetic to both needs. In the case of "restrict", I tend to think
that breaking the small amount of code that used it as an identifier
wasn't too high a price to pay.

In the case of "bool", the committee chose to add "_Bool" as a
keyword, and put the "bool", "true", and "false" identifiers in a new
predefined header. Since the new identifiers are already in common
use, I think that was a good choice -- though of course it wouldn't
have been done that way in the first place.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
.

Relevant Pages

  • Re: So what Standard are we working off?
    ... continuing to improve the language. ... standard, the addition of "auto" alone seems to make the standard ... there are basically no C99 compilers and there is no demand from ... support), and 2) Non-determinable integer scalar sizes, that are not ...
    (comp.lang.c)
  • Re: Is C99 the final C? (some suggestions)
    ... I can't think of a single feature in C99 that would come as ... There are a number of features in C99 that I will steer away from if ... > * a library function that allows the retrieval of the size of a memory ... With the restrictions of the C language, I think you are going to find ...
    (comp.lang.c)
  • Re: The problems in comp.lang.c
    ... I do remember when I started posting to receive ... to the C language here, no matter how good they are. ... I need to digress into talking about C99. ... uncertain about the amount of machine code generated for a simple ...
    (comp.lang.c)
  • Re: Is C99 C?
    ... free applications in C90 and C99. ... C is no more a single language than English or even French. ... I write code TODAY that maps onto a C90 with long long ... freedom of speech was made the First Amendment to the United States ...
    (comp.lang.c)
  • Re: FACTORIAL PROGRAM C99F
    ... important to prefer C99 to C90. ... neither C90 nor C99 to be perfect languages. ... because IMHO they didn't have the guts to change the language spec whenever it was possible to just change the library instead. ... I can even imagine a C with rudimentary support for try/finally exception handling. ...
    (comp.lang.c)