TITLE: Const and overloading of functions/methods

RESPONSE: maxtal@physics.su.OZ.AU (John Max Skaller), 31 Jul 93

	Overloading, constness, and lvalueness are hot topics.
If you depend on some interpretation of the ARM for your
desired semantics you may be in for a surprise.

	For example, anyone who wrote two functions:

	f(const int);
	f(int);

and attempted to discriminate them because their compiler allowed
this is in for a suprise right now. Anyone who write these functions
and tried to fiddle the fact that they could not be discriminated
in ordinary usage by taking their addresses is in for an
even bigger surprise.

	As of Munich, the above declarations declare the same 
function. There is only one function here. So this:

	f(const int x) {}
	f(int x) {}

is now an error: duplicate definition.

[ Objectcenter compiler catches this as an error. -adc ]

	Dont make any assumptions about the constness of
temporaries, including function returns. The code below
is undefined:

	class X {
		void mem()const;
		void mem();
	};

	X f();
	f().mem(); // which function is called? Ambiguity?

Whatever you *think* the rules are, the committee will have
to make a determination about this, and it may not
be the one you think is correct. In particular, there are
at least three proposals being discussed:

	1) Its const
	2) Its non-const
	3) It depends on the return type of the function

(The issue only applies to binding member functions to objects,
not to ordinary parameters of function calls .. although there
is at least one committee member proposing to allow
non-const references to bind to temporaries)

To use C++ succesfully, you have to a bit street-wise.