Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!pp!riunite!rfg From: rfg@riunite.ACA.MCC.COM (Ron Guilmette) Newsgroups: comp.lang.c++ Subject: nit-picking - Edition #3 Keywords: nits Message-ID: <203@riunite.ACA.MCC.COM> Date: 10 May 89 20:24:59 GMT Reply-To: rfg@riunite.UUCP (Ron Guilmette) Organization: MCC Austin, Texas Lines: 256 Well friends... it's that time again. I've built up another store of language nits to pick at and I would like to get some more answers. I know that a lot of these nits that I have been picking at are in the dark little corners of the language where most people never venture, but I believe that these questions (and more importantly, the answers) will help to insure that those few brave souls who do go into these places will not be forever lost in a twisty maze of little language features (all different). I should clarify that (once again) I am looking for responses from qualified language lawyers regarding the state of affairs which will exist once cfront 2.0 bursts upon the scene. In my previous two installments of nit-picking questions, both Bjarne and Andrew K. have very generously given their time to respond to my nits. I do appreciate it. I hope that everyone else who reads this newsgroup also appreciates it because I know that Bjarne and Andrew are very busy guys right about now. After all, there is a new release to get shipped and a new Reference Manual to get finished! Either one, all by itself, constitutes a good bit of work indeed! Anyway, the point is that I hope that I'm not stretching their patience too much by posting this third edition of nits at this very busy time. I (and some others who have sent E-mail to me) are just getting too much enlightenment for me to pause right now and wait for the software to get out and catch up to my curiousity. So here goes... ---------------------------------------------------------------------- Is it legal to declare an operator such that one or more of its formal arguments have default values? If this is allowed, and if one of the operators which can be either unary or binary (i.e. +, -, *, &) is declared globally (i.e. outside of any class/struct/union declarations) as a binary operator with exactly one default formal argument value, then is this operator invoked for those cases in which the given operator is used as a unary operator? Is it legal to declare a unary operator with more than one formal argument (or more than zero formal arguments if the operator is a class member). Is it legal to declare a binary operator with either more that two or less than two formal arguments (or more than one or less than one formal arguments if the operator is a class member). Is it legal to explicitly declare the return type of a type conversion operator? If so, is it legal to explicitly declare the return type of a type conversion operator to be some type other than the type whose name is the name of the conversion operator itself? For example: type1 operator type2 (type3 x); If the declaration above is legal, then is it legal for the return type of an operator to be type "void"? Is it legal to declare an operator to return a type "void"? In particular, is it legal to declare a type conversion operator which converts objects of a given type to objects of type "void"? When you take the address of a function which is itself a member of a given class, and you do it within some member function of the same class, are you required to explicitly qualify the entity with "class_name::" or is that implicitly provided by the compiler? For example: struct base { typedef void (base::*PMB) (); void member_1 () {} void member_2 () { PMB pmb = &member_1; // legal ? } }; Is it legal to take the address of a (data) member of a class? For example, consider the various cases shown below: struct base { int data_member; void function_member () { void* p0 = &this->data_member; // legal ? void* p1 = &data_member; // legal ? void* p2 = &base::data_member; // legal ? } }; If the uses of the address-of operator shown above are legal, what do they yield? If you take the address of a member function or operator, and the name of that member function (or operator designator), when taken alone, is sufficient to fully disambiguate your reference (such as when there are *no* other overloadings of the given function name or operator designator defined for the given (context) function), is the reference legal even though it would have been considered ambiguous (and therefore illegal) if there *had* in fact been overloadings? For example: struct base { void not_overloaded (); int operator ! (); }; int test () { void* p1 = &base::not_overloaded; // legal ? void* p2 = &base::operator!; // legal ? } Is it legal to define operator[] outside of a class declaration? If so, what effect does this have? Is it legal to define operator() outside of a class declaration? If so, what effect does this have? Is it legal to define operator-> outside of a class declaration? If so, what effect does this have? Is operator[] classified as a binary operator? Can operator[] accept either more or less than two arguments? Is operator() classified as a unary operator? Can operator() accept either more or less that one argument? Is operator-> classified as a unary operator? Can operator-> accept either more or less that one argument? Why are type conversion operators only allowed as members? According to the original Reference Manual, it is legal for a switch statement to contain cases which are positioned so as to circumvent the (sensible) restriction placed on goto's that control cannot be transfered past a point at which a class "auto" object would be constructed. Are the rules regarding such disgustingly unstructured switch-initiated transfers going to be tightened up so that pathological cases (like the following) will be strictly prohibited? struct base { base (int i); ~base (); }; void main () { switch (1) { case 0: { base base_object (1); case 1: // entering the twlight zone... break; } // is base_object destructed here ???? } } Are there any such things as "implicitly" declared X::X(X&) constructors for builtin types? Specifically, is the following legal: struct base { int data_member; base (int i) : data_member (i) // legal? { } }; May a static member function be (a) virtual, or (b) inline? When allocating space for vectors of objects, are (or can) constructors be called for each (object) member of the vector? Specifically, is the following code legal? class base { int member1; int member2; public: base (int i, int j); base (); }; base* bp; int main () { bp = new base[20]; bp = new base (7,8)[20]; // legal ??? } Is it legal to obtain the address of a member function "dynamically" through a dereferenced and qualified pointer to an object? Specifically, which (if any) of the following examples are legal? class C { public: void f1 (int, int); virtual void f2 (int, int); }; typedef void (C::*C_member_func_ptr) (int, int); C* Cp; C_member_func_ptr p; void test () { p = Cp->f1; // legal ? p = Cp->f2; // legal ? p = (*Cp).f1; // legal ? p = (*Cp).f2; // legal ? p = & Cp->f1; // legal ? p = & Cp->f2; // legal ? p = & (*Cp).f1; // legal ? p = & (*Cp).f2; // legal ? } Does the second declaration statement below declare two references, or one reference to an object of type T and one actual object of type T? T T_object; T & one = T_object, two = T_object; Is it legal to create references to functions? To operators? To member functions? For example: struct S { int member (S s2); }; typedef int (func_ref&) (S s1, S s2); // legal ? typedef int (S::&S_member_ref) (S s2); // legal ? int global_func (S s1, S s2) { return 0; } int operator% (S s1, S s2) { return 0; } func_ref fr1 = global_func; // legal ? func_ref fr2 = & global_func; // legal ? func_ref fr3 = operator%; // legal ? func_ref fr4 = & operator%; // legal ? S_member_ref smr_1 = S::member; // legal ? S_member_ref smr_2 = & S::member; // legal ? -- // Ron Guilmette - MCC - Experimental Systems Kit Project // 3500 West Balcones Center Drive, Austin, TX 78759 - (512)338-3740 // ARPA: rfg@mcc.com // UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg