Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!pp!riunite!rfg
From: rfg@riunite.ACA.MCC.COM (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: nit picking questions
Message-ID: <173@riunite.ACA.MCC.COM>
Date: 14 Apr 89 17:21:03 GMT
References: <161@riunite.ACA.MCC.COM> <9189@alice.UUCP> <10161@socslgw.csl.sony.JUNET>
Reply-To: rfg@riunite.UUCP (Ron Guilmette)
Organization: MCC  Austin, Texas
Lines: 124

In article <10161@socslgw.csl.sony.JUNET> diamond@diamond.csl.sony.jp (Norman Diamond) writes:
>In article <9189@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup)
>very kindly answers most of the questions that were asked by
>Ron Guilmette.  If Mr. Stroustrup has time, please kindly try
>to answer some of them again.

Yes please.

>
>>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)
>What about the _return_ type?

Ditto!

>>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.
>Mr. Guilmette must have meant:
>If a method member is declared in a _base_ class, can it be
>redeclared in a derived class as a data member?

Right.  I did make a mistake in phrasing my question.  What I did mean
(and what Mr. Diamond correctly realized) was: is the following legal:

	class base {
	public:
		int member (int i);
		base ();
	};

	class derived : public base {
	public:
		int member;			// legal ??
		derived ();
	};

	int test ()
	{
		derived derived_object;

		&dervied::member;		// what does this mean?
		&derived_object.member		// what does this mean?
	}


>>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.
>How do you provide the context?  Mr. Guilmette's suggestion (following)
>seems very reasonable.
>>
>>		&class_name::overloaded_method_name(int,int)
>>***> no and no (that would be ambiguous with a call)

I don't see any problem with disambiguating such a notation and allowing
the compiler to conclude that this is (obviously) a "name" of a particular
overloaded function.  After all, one look at the "actual parameters" and
the compiler should be able to see that these are TYPES and not VALUES.

Anyway, this is not a terribly important issue because there is a way
(that I have just learned about from Stroustrup's reply above) to get
the address of a particular overloading of a function.

Unfortunately, the wording of section 8.9 of the reference manual leaves
something to be desired when it comes to spelling out precisely what
sorts of context information may or may not be used to disambiguate
an overloaded function name when the & operator is applied to it.

I have found through experimentation that the GNU g++ compiler does do
disambiguation of overloaded function names in many cases which are
not spelled out in the Reference Manual.  Specifically, it seems to
take into account:

	a)	the type of the pointer being assigned to (or initialized)
	b)	the type to which the value yielded by the & operator is
		(explicitly) casted,
	c)	the type expected for the given actual function parameter
		(when the value yielded by the & operator is passed as
		an actual parameter to a function.

Are all these possible disambiguation factors "legal" for a "standard
conforming compiler" to take into account when performing disambiguation
of overloaded function names?  Are there any others?

Note that when factor (c) above is used for disambiguation by the GNU g++
compiler, it is apparently possible for truly ambiguous things to slip
by without any errors being generated, e.g.:

-----------------------------------------------------------------------
overload function;
overload function_of_function;

void function (char c);
void function (float f);

typedef void (*ptr_to_function_of_char)(char);
typedef void (*ptr_to_function_of_float)(float);

void function_of_function (ptr_to_function_of_float);
void function_of_function (ptr_to_function_of_char);


int test ()
{
	function_of_function (function);	// ERROR - ambiguous
}
-----------------------------------------------------------------------

What does cfront 2.0 do with this?


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