jon@oddhack.Caltech.Edu (Jon Leech) (11/30/86)
I recently found that C++ (1.1) does not allow integral casts in
constant expressions in some cases; for example,
const int i = (unsigned)1; // Is legal
typedef enum { one = (unsigned)1 } ENUM; // Is not.
Unfortunately, this makes it impossible to include some of the graphics header
files on Suns which use the latter form (it also happens to disagree with
the ANSI C draft, sadly). Has anyone got a fix for this problem?
-- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon)
Caltech Computer Science Graphics Group
__@/shopiro@alice.UUCP (12/05/86)
In article <1252@cit-vax.Caltech.Edu>, jon@oddhack.Caltech.Edu (Jon Leech) writes: > > I recently found that C++ (1.1) does not allow integral casts in > constant expressions in some cases; for example, > > typedef enum { one = (unsigned)1 } ENUM; > > Unfortunately, this makes it impossible to include some of the graphics header > files on Suns which use this form (it also happens to disagree with > the ANSI C draft, sadly). Has anyone got a fix for this problem? This code (or any code that uses casts in constant expressions) is not legal C according to Ritchie* or the ANSI draft. Apparently some C compilers will accept it; I believe there are others that won't. C++ has already abandoned complete upward compatability with legal C -- it's unreasonable to expect it to be compatible with illegal C. I grant that it is clear what such casts would mean if they were legal, and that there are examples where they might allow you to write code that couldn't be written as directly otherwise. I am confident that if this extension were approved by the ANSI committee it would also appear in C++. However, in all the SUN header examples I have looked at, the cast is pure noise and can be eliminated with no effect whatsoever. That is what I suggest you do. (When you're done, I'm sure there will be many people who would like a copy). * Dennnis Ritchie, The C Programming Language - Reference Manual Sep. 1980.
news@cit-vax.Caltech.Edu (Usenet netnews) (12/06/86)
Organization : California Institute of Technology Keywords: From: jon@oddhack.Caltech.Edu (Jon Leech) Path: oddhack!jon In article <6426@alice.uUCp> shopiro@alice.UUCP writes: >In article <1252@cit-vax.Caltech.Edu>, jon@oddhack.Caltech.Edu (Jon Leech) writes: >> >> I recently found that C++ (1.1) does not allow integral casts in >> constant expressions in some cases; for example, >> >> typedef enum { one = (unsigned)1 } ENUM; >> >> Unfortunately, this makes it impossible to include some of the graphics header >> files on Suns which use this form (it also happens to disagree with >> the ANSI C draft, sadly). Has anyone got a fix for this problem? > >This code (or any code that uses casts in constant expressions) is not >legal C according to Ritchie* or the ANSI draft. Apparently some C >compilers will accept it; I believe there are others that won't. >C++ has already abandoned complete upward compatability with legal >C -- it's unreasonable to expect it to be compatible with illegal C. > >I grant that it is clear what such casts would mean if they were >legal, and that there are examples where they might allow you to >write code that couldn't be written as directly otherwise. I am >confident that if this extension were approved by the ANSI committee >it would also appear in C++. > >However, in all the SUN header examples I have looked at, the cast is >pure noise and can be eliminated with no effect whatsoever. That is >what I suggest you do. (When you're done, I'm sure there will be many >people who would like a copy). > >* Dennnis Ritchie, The C Programming Language - Reference Manual > Sep. 1980. In my April 30, 1985 copy of the draft, Section C.4 ``Constant Expressions'' says `` For constant expressions in initializers, in addition to integral constant expressions as discussed previously, one can also use floating constants and arbitrary casts...'' This is not allowed in K&R unless I'm missing something (Appendix A, Section 15, pg. 211). Unless this has been changed in later drafts, we are both partially right; you're right that the particular code I quote above is illegal, and I'm right that the usage is in fact acceptable - in initializers. What a stupid restriction. Time to comment to ANSI. It turns out to be far easier to write C hooks to the Sun graphics routines. Annoying, but less pain than changing header files. -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon) Caltech Computer Science Graphics Group __@/
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/06/86)
In article <1288@cit-vax.Caltech.Edu> jon@cit-vax.UUCP (Jon Leech) writes: > In my April 30, 1985 copy of the draft, Section C.4 ``Constant >Expressions'' says > ... >in initializers. What a stupid restriction. Time to comment to ANSI. This newsgroup is really incredible! First of all, if you're going to comment on the draft C standard, comment on the draft C standard (that is, the one released for public review and comment), not on an earlier working draft. Secondly, the draft proposed standard allows casts of arithmetic types to integral types in all constant-expressions except those tested in preprocessing conditional-inclusion directives. This is explained in the paragraph immediately preceding the one quoted. And people wonder why their comments "haven't been addressed"! (Reminder: I'm not an official spokesman for X3J11.)