home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16735 < prev    next >
Encoding:
Text File  |  1992-11-22  |  2.9 KB  |  77 lines
  1. Path: sparky!uunet!cs.utexas.edu!ut-emx!jamshid
  2. From: jamshid@ut-emx.uucp (Jamshid Afshar)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: static data members of private types impossible?
  5. Summary: ARM says illegal, committee's debating it. I think it should be legal
  6. Message-ID: <84172@ut-emx.uucp>
  7. Date: 22 Nov 92 23:06:00 GMT
  8. References: <1992Nov12.151014.10610@debbie> <5207@holden.lulea.trab.se>
  9. Reply-To: jamshid@emx.utexas.edu
  10. Organization: The University of Texas at Austin; Austin, Texas
  11. Lines: 64
  12.  
  13. In article <5207@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
  14. >johnh@tt.com (John Hasselkus) writes:
  15. >: class A {
  16. >:     enum FOO { FOO_1, FOO_2 };
  17. >:     static FOO foo;
  18. >: };
  19. >: 
  20. >: A::FOO A:foo;    // <- Compiler won't let you use private types out here
  21.  
  22. While I would not have interpreted the ARM this way, I have been told
  23. that its intentions are that the above is illegal.  I've also been
  24. told this matter is being discussed by ANSI and that and they are
  25. leaning towards relaxing the rules to allow the above code.  Otherwise
  26. nested types would have to be made public in many situations where the
  27. class writer really doesn't want them to be.
  28.  
  29. >To support this, the compiler would need to parse the entire declaration,
  30. >before deciding if in fact the type name is accessible.  My guess is that
  31. >compilers rather not do that.
  32. >To prove my point, the following declaration should definitely be illegal:
  33. >A::Foo A::foo, anotherVariable;
  34.  
  35. The compiler could simply give an error that A::Foo is not accessible
  36. at file scope unless the object being declared has access.  I think
  37. this situation is very analogous to that of resolving overloaded
  38. functions, some of which might not be accessible.  From ARM 11.3c
  39.  
  40.     As mention in $11, C++ provides access control, not visibility
  41.     control; that is, the object, function or whatever referred to
  42.     in an expression is determined WITHOUT REGARD TO ACCESS
  43.     SPECIFICATION, then type checking is done, and only if no error
  44.     was found is access control applied.
  45.     [emphasis mine]
  46.  
  47. Making non-public types inaccessible at file scope even when declaring
  48. a member would also mean that member functions could only return
  49. non-public types:
  50.  
  51.     class A {
  52.        enum FOO { FOO_1, FOO_2 };
  53.        static FOO foo();   // impossible to define this
  54.     //...
  55.     };
  56.  
  57. Or, even weirder, it would mean they could only be defined inside the
  58. class.  Granted, this type of restriction does have precedence with
  59. local classes.
  60.  
  61. Btw, there's some code in ARM 9.7 p187 that uses a private type in
  62. file scope and I think contradicts the ARM intentions (unless typedef
  63. declarations don't count):
  64.  
  65.     class enclose {
  66.        class inner { ... };
  67.     };
  68.     typedef enclose::inner ei;
  69.     //...
  70.  
  71. Was this changed in the ARM reprinting (May92)?  Anyway, I hope ANSI
  72. does decide to allow the use of non-public types in file scope when
  73. declaring members and I hope compiler writers are quick to respond.
  74.  
  75. Jamshid Afshar
  76. jamshid@emx.utexas.edu
  77.