Re: [9fans] NaN, +Inf, and -Inf, constants?
why does being able to switch on any enum trump the ability to define constants without #define? Because enum's legacy is that of a 'first class' int-like object, which can be subject to the usual set of int-like operations. switch() is one of those. #define isn't. if you try, sizeof(foo)==4, but you'll need to remove 'd' since you can't have a string. you can't switch on a vlong or float. would be nice, though. Why not a string? If you can extend an enum to include floats, why not an integer representation of a pointer? And yes, I also think switching on vlongs would be useful. the plan 9 style is never to typedef or name enums. It may not be the style for the Labs, but that's not the case for everyone. The compile time type checking named enums provide isn't something I'd want to lose. if it were an error to name or typedef an enum containing non-int members, there would be no problem. This could work. But I have to agree with Bakul: 'static const' is a much better fit for the language. --lyndon
Re: [9fans] NaN, +Inf, and -Inf, constants?
we could spend a lot of time debating proposed changes, but i think it's fine to leave as is. there appears to be a good, justifiable reason for it, and it's already implemented. russ
Re: [9fans] NaN, +Inf, and -Inf, constants?
h% cat en.c
enum{
Fred= 1.5
};
double f = Fred;
h% 8c -S en.c
DATAf+0(SB)/8,$(1.5e+00)
GLOBL f+0(SB),$8
END ,
bug or quirk?
what do you think?
Re: [9fans] NaN, +Inf, and -Inf, constants?
i didn't even think to check earlier. even better:
enum{
Fred= 1.5,
Sam,
};
double f = Fred;
double g = Sam;
h% 8c -S en.c
DATAf+0(SB)/8,$(1.5e+00)
DATAg+0(SB)/8,$(2.5e+00)
GLOBL f+0(SB),$8
GLOBL g+0(SB),$8
END ,
sound!
Re: [9fans] NaN, +Inf, and -Inf, constants?
On Sun, Feb 7, 2010 at 2:46 AM, Charles Forsyth fors...@terzarima.netwrote:
h% cat en.c
enum{
Fred= 1.5
};
double f = Fred;
h% 8c -S en.c
DATAf+0(SB)/8,$(1.5e+00)
GLOBL f+0(SB),$8
END ,
bug or quirk?
what do you think?
i swear i tested this before i replied...
seems like a bug to me. the spec is pretty clear:
6.7.2.2 Enumeration specifiers
Syntax
[#1]
enum-specifier:
enum identifier-opt { enumerator-list }
enum identifier-opt { enumerator-list , }
enum identifier
enumerator-list:
enumerator
enumerator-list , enumerator
enumerator:
enumeration-constant
enumeration-constant = constant-expression
Constraints
[#2] The expression that defines the value of an enumeration
constant shall be an integer constant expression that has a
value representable as an int.
russ
Re: [9fans] NaN, +Inf, and -Inf, constants?
[#2] The expression that defines the value of an enumeration constant shall be an integer constant expression that has a value representable as an int. the spec also doesn't allow vlong enumerations. should we remove that ability, too? - erik
Re: [9fans] NaN, +Inf, and -Inf, constants?
seems like a bug to me. the spec is pretty clear: it's quite deliberate, having looked at the code. i suspect the rationale was that, finally, C provided a way outside the preprocessor to give symbolic names to constants. why restrict that to int? you can't easily get the same effect by adding #define names to the output symbol table, because those are arbitrary text, not guaranteed either to be constants, or to be safe for substitution (without surrounding ())
Re: [9fans] NaN, +Inf, and -Inf, constants?
enum {
a = 1,
b = 2.4400618549L,
c = 2.44F,
d = this is weird,
e = 1LL62,
} foo;
How on earth do you switch() on it? And what's its sizeof()?
why does being able to switch on any enum trump
the ability to define constants without #define?
if you try, sizeof(foo)==4, but you'll need to remove
'd' since you can't have a string. you can't switch on
a vlong or float. would be nice, though.
the plan 9 style is never to typedef or name enums.
(though i saw one creep into the source recently.)
so the sizeof problem would naturally never come up.
if it were an error to name or typedef an enum
containing non-int members, there would be no
problem.
- erik
Re: [9fans] NaN, +Inf, and -Inf, constants?
On Sun, 07 Feb 2010 15:19:58 MST Lyndon Nerenberg (VE6BBM/VE7TFX)
lyn...@orthanc.ca wrote:
i suspect the rationale was that, finally, C provided a way
outside the preprocessor to give symbolic names to constants.
why restrict that to int?
Because enum's have been int's since their inception?
I'm sympathetic to the underlying need, but making a fundamental
type of the language suddenly become variable does not seem to
be the right way of going about this.
E.g., what is the type of:
enum {
a = 1,
b = 2.4400618549L,
c = 2.44F,
d = this is weird,
e = 1LL62,
} foo;
The cleanest solution would be to treat C's _static const_
variables as as compile time constants. I wish the standard
dictated this.
Re: [9fans] NaN, +Inf, and -Inf, constants?
One thing leading to another, I am currently centralizing constants, and found that enums can hold doubles (which is quite nice), but I have no way of defining NaN or Inf as a constant, is there such a way? Or is there a way to evaluate constant functions at compile time (eep)? NaN(2) and Inf(2) are not constant functions. the result depends on the settings of the fcr (getfcr(2)). - erik
Re: [9fans] NaN, +Inf, and -Inf, constants?
NaN(2) and Inf(2) are not constant functions. the result depends on the settings of the fcr (getfcr(2)). Really? My reading of /sys/src/libc/port/nan.c makes me think NaN(2) returns a uvlong value of 0x7ff1, miss I something? On the other hand, the assignment of NaN to a double depends on the fcr. (And on my machine, curiously changes 0x7ff0...1 to 0x7ff8...1). So if I think of enum definitions as assignment, it makes sense, mostly. thanks, tristan -- All original matter is hereby placed immediately under the public domain.
Re: [9fans] NaN, +Inf, and -Inf, constants?
On Sat, Feb 6, 2010 at 7:38 AM, Tristan Plumb 9p...@imu.li wrote: enums can hold doubles (which is quite nice) Umm, no they can't. Russ
