Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!ames!killer!texbell!bellcore!faline!thumper!ulysses!andante!alice!ark
From: ark@alice.UUCP (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: nit picking questions
Message-ID: <9190@alice.UUCP>
Date: 12 Apr 89 03:03:37 GMT
References: <161@riunite.ACA.MCC.COM>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 177

In article <161@riunite.ACA.MCC.COM>, rfg@riunite.ACA.MCC.COM (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.

I'll do my best.

> 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).

You had better define a third operator new in the derived class
if you intend to use `new' to allocate any objects of that class.
Otherwise it's ambiguous and you'll get an error message.

> 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"?)

Actually, the argument should be of type size_t.  It's long in
some present implementations but that'll change.

> Is it legal for an "operator delete" to return anything other than
> type "void"?

No.

> 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*"?

No.

> 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?  (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?)

Member operator delete has only a single argument, of type void*.
It isn't C* because by the time operator delete is called, the
memory in question no longer contains a C -- it has been destroyed.
Member operator new and delete functions are static, so they don't
have `this' available.

> Can a union have public, private and protected parts?

No.

> Can a union contain member functions?

No.

> 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.

You can't overload data members.  If you have a data member with
a given name, you can't have a function member with the same name.

> 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?  If it can be redeclared  as a data member
> in the derived class, must it be redeclared with the same data type?

Yes.  It need not be redeclared with the same type.

> (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?)

> If this kind of redeclaration is allowed, what would the expression
> &class_name::member_name yield in such cases?

I don't have my workshop proceedings handy -- how about an
example of what you mean?

> If a method member is declared in a derived class, can it be
> redeclared in a derived class as a data member?

Yes.

> If this kind of redeclaration is allowed, what would the expression
> &class_name::member_name yield in such cases?

If class_name is the base class, it's the function.  If class_name
is the derived class, it's the data member.

> 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?  Specifically, is the following allowed
> (or will it ever be)?
> 
> 		&class_name::overloaded_method_name(int,int)

It's almost legal.  For example, this works:

	struct X {
		void f(int);
		void f(double);
	};

	main()
	{
		void (X::*fp)(double) = X::f;
	}

However, it's illegal if I rewrite the declaration of fp this way:

		void (X::*fp)(double);
		fp = X::f;

> 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?

The answer to this is similar to the previous one -- you can use
an overloaded name as an initializer but usually not as an expression.
For instance, the following is legal:

	struct X {
		X operator+(const X&);
		X operator+();
	};

	main()
	{
		X (X::*fp)(const X&) = X::operator+;
	}

> 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:
> 		int method (int, int);
> 	};
> 
> 	class derived : public base {
> 	public:
> 		int method (float, float);	// is this an error?
> 	};

Your example is legal, even if you insert `virtual' in the
definition of base::method.  However, because the signatures
of base::method and derived::method are different, the two
functions are effectively completely unrelated.  You should
get a warning about this, but it's legal if it's really what
you want to do.

> Is there any acceptable way of getting at the address of a vtable for
> a given class.

No -- at least no way that is guaranteed by the language definition
or that I would personally consider acceptable.  Some things are
just not intended to be known.
-- 
				--Andrew Koenig
				  ark@europa.att.com