downing@elysium.sw.mcc.com (Glenn Downing) (05/07/90)
Is it a bug in the GNU 1.37 compiler that it does not allow me to define a
typedef within a class definition and have its scope be global? The Sun
compiler does define it with global scope.
class foo
{typedef bar int;};
main()
{bar i = 2;} // bar is not accessible here with GNU, but is with SUN
--
Glenn Downing (downing@mcc.com)
Microelectronics Computer Corporation (MCC)
3500 West Balcones Center Drive
Austin, TX 78759-6509rfg@ics.uci.edu (Ronald Guilmette) (05/08/90)
In article <3748@elysium.sw.mcc.com> downing@elysium.sw.mcc.com (Glenn Downing) writes: > >Is it a bug in the GNU 1.37 compiler that it does not allow me to define a >typedef within a class definition and have its scope be global? The Sun >compiler does define it with global scope. > >class foo > {typedef bar int;}; > >main() > {bar i = 2;} // bar is not accessible here with GNU, but is with SUN >-- >Glenn Downing (downing@mcc.com) >Microelectronics Computer Corporation (MCC) >3500 West Balcones Center Drive >Austin, TX 78759-6509 I really should let Michael answer this one but... The C++ language rules have changed recently with respect to the scope of things declared within classes/structs/unions. It used to be that if you defined a type (via a typedef statement, or via a struct, class, union, or enum type definition) within a class, that the scope of the new typename was made "global". Nowadays, the scopes of such names are (or will soon be) restricted to the class itself (and its member functions of course). Cfront 2.0 doesn't implement this fully yet. I haven't seen what 2.1 does in such cases, so I don't know. g++ (1.37.1) went part of the way by making names defined via typedef statements local to the containing class. Whether that is a bug or a feature is (i think) in the eye of the beholder. // Ron Guilmette (rfg@ics.uci.edu) // C++ Entomologist // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
horstman@sjsumcs.sjsu.edu (Cay Horstmann) (05/09/90)
In article <26462BED.5865@paris.ics.uci.edu> rfg@ics.uci.edu (Ronald Guilmette) writes: > >I really should let Michael answer this one but... > >The C++ language rules have changed recently with respect to the scope >of things declared within classes/structs/unions. > >It used to be that if you defined a type (via a typedef statement, or via >a struct, class, union, or enum type definition) within a class, that the >scope of the new typename was made "global". > >Nowadays, the scopes of such names are (or will soon be) restricted to >the class itself (and its member functions of course). > Fascinating feature... Does that mean that one can have private, protected and public typedefs, all of which live in the name space of the class, with type scope resolution operators when a public type is used outside member functions, like this? class X { public: typedef ... T; ... }; X::T a; Cay
rfg@ics.uci.edu (Ronald Guilmette) (05/09/90)
In article <1990May9.032300.14501@sjsumcs.sjsu.edu> horstman@sjsumcs.SJSU.EDU (Cay Horstmann) writes: >In article <26462BED.5865@paris.ics.uci.edu> rfg@ics.uci.edu (Ronald Guilmette) writes: >> >>I really should let Michael answer this one but... >> >>The C++ language rules have changed recently with respect to the scope >>of things declared within classes/structs/unions. >> >>It used to be that if you defined a type (via a typedef statement, or via >>a struct, class, union, or enum type definition) within a class, that the >>scope of the new typename was made "global". >> >>Nowadays, the scopes of such names are (or will soon be) restricted to >>the class itself (and its member functions of course). >> >Fascinating feature... Does that mean that one can have private, protected >and public typedefs, all of which live in the name space of the class, with >type scope resolution operators when a public type is used outside member >functions, like this? > >class X >{ >public: >typedef ... T; > >... > >}; > >X::T a; NO. One *cannot* (as of now anyway). I have it on good authority however that all such things ought to be allowed at some (unspecified) point in the future. At that time, nested types will become like other categories of members (i.e. data members, function members, and enumeral members) and access-specifiers will apply. Scope resolution via :: will operate for type members just like for other categories of members. // Ron Guilmette (rfg@ics.uci.edu) // C++ Entomologist // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
davidm@uunet.UU.NET (David S. Masterson) (05/10/90)
In article <2647C248.28683@paris.ics.uci.edu> rfg@ics.uci.edu (Ronald Guilmette) writes: I have it on good authority however that all such things ought to be allowed at some (unspecified) point in the future. At that time, nested types will become like other categories of members (i.e. data members, function members, and enumeral members) and access-specifiers will apply. Scope resolution via :: will operate for type members just like for other categories of members. All this talk on typedefs reminded me to ask a couple of things about quirks that I've run into, but not explored enough to understand. 1. Does C++ treat typedef'ed types as derived types from a parent, base type? For instance, are there quirks in casting variables back and forth between a typedef'ed type and its equivalent base type? 2. Conceptually, why do people use typedefs? Are they just there to "beautify" code with better names or do they serve some deeper purpose? Does C++ enforce anything where typedefs are concerned to help this conceptual purpose? Thanx -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"