On (13 Sep 97) Neil Heller wrote to All...
 NH> class button
 NH> {
 NH>     public:
 NH>         enum status (out, in);
Presumably you meant:
             enum status { out, in };
 NH>         void set(status s) {state = s;}
 NH>         status get() const {return state;}
 NH>     private:
 NH>         status state
Presumably the lack of a semicolon here is simply a typo.
 NH> };
 NH> int main()
 NH> {
 NH>     const button::status out = button::out;  // #1
 NH>     const button::status in  = button::in;   // #2
 NH>     button panic;
 NH>     panic.set(out);
 NH>     [some other stuff]
 NH> }
 NH> Had the line
 NH> button panic;
 NH> been declared first in main(), could the verbiage in the line marked
 NH> #1 above have been written:
 NH> const panic.status out = button::out;   ????
No.  panic.status is private, so only class member functions can refer
to it directly.  In addition, panic.status is a variable, not a type.
Therefore, when the parser gets to `out' above, it's going to choke -
you've given the name of a variable (albeit one that's not available to
this code) so simply putting another undeclared name after it is a
syntax error.
 NH> I _think_ the question can be rephrased as "why must enums be always
 NH> kept separate, apart from the objects to which they can apply?"
I'm not sure I follow the question.
 NH> I have never heard (nor seen) a REAL explaination of this.  Only
 NH> "here is the rule.  It is not subject to debate.  It must be
 NH> followed."
I'm not sure I even follow the subject of the rule, so I'm hard put to
say whether I agree with it or not.
    Later,
    Jerry.
--- PPoint 2.02
---------------