Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!ucbvax!tut.cis.ohio-state.edu!rutgers!att!ulysses!andante!alice!bs
From: bs@alice.UUCP (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: nit picking questions
Summary: more answers
Message-ID: <9199@alice.UUCP>
Date: 14 Apr 89 13:17:35 GMT
References: <161@riunite.ACA.MCC.COM> <9189@alice.UUCP> <10161@socslgw.csl.sony.JUNET>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 108




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.

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

Sorry. I shouldn't try answering questions at the end of a long hard day.

There is nothing in the language that prevents you from chosing a return
type, though it seems that all current implementations require void*.
The default operator delete() in the library is:

	void* operator delete(void*);
	void* operator delete(void*, long);

where `long' will be replaced by `size_t' as part of the ANSIfication.


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

I thought that was one of the other questions. The answer to this last
question is, Yes, this is legal:

	struct A { int f(); };
	struct B : A { int f; };

 > (method member == member function)
I forgot that humor should be pre- or suffixed by a :-) in this forum :-)

But I was also making a semi-serious point. Referring to member
functions as `methods' makes some people believe they have a semantics
and/or implementation very similar to Smalltalk methods. That can cause
confusion. Also, some people use `method' to refer to all member functions
and others use `method' to refer to virtual functions only. Another source
of confusion.

 > >If this kind of redeclaration is allowed, what would the expression
 > >&class_name::member_name yield in such cases?
 > >***> It isn't.
 > Probably it is, when the preceding question is corrected.  Isn't
 > the rule the same, finding the most derived type in the class lattice?

Yes, given the declarations above B::f the integer member B::f.
	A::f will give you the function. Please remember we are talking
	language definition here and not about style. I would hope that
	examples like these will remain rare in real code.

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

It IS very reasonable, but I did give an alternative, and Andy Koenig in
a separate message gave an example of its use. Here is another example:

	void f();
	void f(int);
	// ...
	void (*pv)() = &f;	// gets void f();
	void (*pi)(int) = &f;	// gets void f(int);

 > >  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)
 > It would not be ambiguous.  & cannot be applied to the result of a
 > call.  More obviously, "int" cannot be an actual parameter of a call,
 > only an expression can be, but this does not help when a function
 > takes no parameters.

You are right. One could key the analysis on the `int'. This would make
the syntax analysis of C++ even more horrid than it already is, but the
main point is that C++ already has a mechanism for expressing this so
why add mechanism?

 > ------ cut here and discard everything below this point. ------
 > 
 > >Can a union have public, private and protected parts?
 > >Can a union contain member functions?
 > 
 > Gee, I thought the most interesting unions are those of private parts,
 > one of which is a ...
 > Never mind.

I think C++ is an even better source of silly puns and jokes than C is :-)