🚀 go-pugleaf

Comments on Mat Austern's proposal for an exponentiation
operator in C++ (posted to comp.lang.std and, I think,
also to comp.lang.c++).

(1) I think overloading and inlining can be used a bit
	more effectively than is assumed in tht proposal.
	For example:

	double pow(double,double); // what C gives us
	double _pow(double,int); // general pow(double,int)

	inline double pow(double d, int i) // inlining to catch
					   // important special cases
	{
		if (i == 2) return d*d;
		else if (i == 3) return d*d*d;
		else _pow(d,i);
	}
	
	
	void f(double d, int i)
	{
		pow(d,d);
		pow(d,i);
		pow(d,2);
		pow(d,3);
		pow(d,4);
	}

	will generate better code for small integer powers.
	This technique is fairly gaeneral and does not depend on
	cleverness beyond the average C++ compiler.

	I agree that a clever compiler can do better, but for now
	this technique might be helpful to some.

(2) I think we could actually get ** as the exponentiation operator.

	Consider the well-known counter-example:

		int a;
		int* p;

		a**b;

	For C compatibility, a**b must mean a * (*b). However,
	with a minor sleigh of hand this can be achieved even
	if we introduce and exponentiation operator represented
	by the single token **.

	All we need to do is to say that the exponentiation
	operator ** given a first operand `a' of arithmetic type
	and a second operand `b' of pointer type (that is, `a**b')
	mean multiply the first operand with the dereference value
	of the second operand (that is, `a*(*b)'). This would not
	be quite 100% compatible because a*b**p where p is a pointer
	would mean a*(b*(*p)) rather than (a*b)*(*p), but I suspect
	that it would be compatible enough.

	Similarly the token ** when used in a declarator must mean
	* * (that is pointer to pointer.

	
	I think this would take care of the compatibility problems.
	There may be other minor details to consider, but I don't
	see any insurmountable problems.