🚀 go-pugleaf

In article <56586@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>What you don't do it make a counterproposal as to how to resolve the 
>present problems with const.  Any suggestions?  Four different approaches
>might be:
>
>1) Const means const.  Period.  No exceptions.
>
2) Volatile const, const volatile, and so forth
>3) Volatile const verses const volatile distinction.
>4) Leave things the way they are now -- a muddle where people cast away from

My current C++ practice (also ANSI C) is to take option 1.
I think the best way to handle this -- in an ideal world-- is to expand
the concept of interface files so that they can report detailed information
about the functions that they describe.  This might allow objects to
be partially const (use for cacheing information), and might allow
deeper optimization (in cases where a const object contains a pointer
where the pointed-to data might or might not be affected by the function).
The question is "how?"
Well, an off-the-cuff idea (no more than 10 min of thought) is the
following:
Extend the concept of function prototypes to also contain sortof pseudocode.
The pseudocode would bethe minimum C++ necessary to describe what
parts of an object change (or other interesting properties).
Take a function   int f(someclass& x),
where 
class someclass	{
	int sum_of_all_ps;
	public:
	int *p;
	int q;
	int sum() C {return sum_of_all_ps ? sum_of_all_ps : add_em_up(p);}
	};
Here, sum_of_all_ps is a cache which is presumably hard to calculate.
So, if f is the following:
int f(someclass& x)
{
 x.q += x.sum();
 return x.sum();
}

We might have the following pseudocode:
prototype int f(someclass& x) { x.q=0; }
which would mean that f() can change x.q, but nothing else in x.
Note that the need for 'const' as a keyword in function calls
goes away entirely.

Any comments?

Greg Kochanski gpk@physics.att.com
AT&T Physics Research -- Physics for fun and profit.