Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!ames!killer!texbell!bellcore!faline!thumper!ulysses!andante!alice!bs From: bs@alice.UUCP (Bjarne Stroustrup) Newsgroups: comp.lang.c++ Subject: Re: nit picking questions Summary: answers Message-ID: <9189@alice.UUCP> Date: 12 Apr 89 02:45:21 GMT References: <161@riunite.ACA.MCC.COM> Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 150 ***> Ron Guilmette writes: Sorry to trouble you all, but I am still trying to absorb the fine points of this language. Can one of the language lawers who frequent this group please take a minute or two to answer a few simple legality questions for me. I would appreciate it a lot. ***> Simple? :-) I would like answers based either on cfront 2.0 or on the more abstract notion of the "formal language" rules" as they are now. ------------------------------------------------------------------------ What should (or does) happen if a given class inherits multiple new operators or multiple delete operators from multiple base classes? (This question assumes that MI has been implemented). ***> The usual algorithm for detecting ambiguities in a class lattice (see the evolution paper) is applied and if there is exactly one delete operator you use it; otherwise you have a compile time error. Is it legal for an "operator new" to return anything other than a type "void*" result? ***> No. Is it legal for an "operator new" to accept anything other than a single argument of type "long"? (By the way... why is the argument type "long" rather than type "unsigned long"?) ***> Yes. operator new can be overloaded (details ``real soon now'') Is it legal for an "operator delete" to return anything other than type "void"? ***> Yes. It can take an additional argument of type long (a size) Is it legal for a "global" operator delete to have a formal argument list which consists of anything other than a single formal parameter of type "void*"? ***> Yes (as above) Is it legal for a "class-specific" operator delete method to have a formal argument list which consists of anything other than a single formal argument of type "pointer to C" where type "C" is the containing class type? ***> Yes (as above) (I also have to wonder why class-specific delete operators need to have any "explicit" formal arguments. Don't these operators get a "this" pointer?) ***> No. They are applied after destruction. Can a union have public, private and protected parts? ***> No (though, this is being debated) Can a union contain member functions? ***> Yes. Can a data member and a method member declared within the same class have the same name? If so, what does &class_name::member_name yield in such cases. ***> No. If a data member is declared in a base class, can it be redeclared as either data member or as a method member in a class derived from the given base class? ***> Yes. If it can be redeclared as a data member in the derived class, must it be redeclared with the same data type? ***> No. (Do the same rules apply as for method members which are redeclared in a derived class, i.e. can this mechanism be used to change the visibility of of an inherited data member in the same way that the visibility of method members may be modified, i.e. the way it is described on page 4 of the 1987 workshop proceedings?) ***> Yes (but what is a ``method member'' I don't remember putting such a beast into C++ :-) If this kind of redeclaration is allowed, what would the expression &class_name::member_name yield in such cases? ***> A pointer to the member found in class_name or its bases using the usual ambiguity resolution mechanism. Essentially the one from the most derived class. If a method member is declared in a derived class, can it be redeclared in a derived class as a data member? ***> No (assuming you mean in the same derived class). You can only overload functions. If this kind of redeclaration is allowed, what would the expression &class_name::member_name yield in such cases? ***> It isn't. Is it legal or illegal to try to take the address of an overloaded method or function using the '&' operator? Given a particular overloaded function or method that you absolutely *must* get the address of, is there any way of uniquely specifying a particular one of the overloadings? ***> Yes. See the reference manual section 8.9. Essentailly, you can only take the address of an overloaded function if the context uniquely identifies which version. Specifically, is the following allowed (or will it ever be)? &class_name::overloaded_method_name(int,int) ***> no and no (that would be ambiguous with a call) Is it legal to try to take the address of an overloaded operator for a given class (e.g. &my_class::operator+) even if that operator may have both unary and binary forms, so long as only one of these two forms is actually defined for the given class? ***> Yes - even if they have both been declared. Is it legal to declare a virtual method in a base class with a given parameter profile and then to declare a (virtual or plain) method with the same name but with a different parameter profile in a class which is derived from the given class? (GNU G++ thinks this is illegal). An example: class base { public: virtual int method (int, int); }; class derived : public base { public: int method (float, float); // is this an error? }; ***> It is legal, but probably not what you want. The second method() hides the first one and do not redefine it (in the vtbl). Cfront thinks you made a mistake: "", line 9: warning: derived::method() hides virtual base::method() Is there any acceptable way of getting at the address of a vtable for a given class. ***> No. -- // 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