🚀 go-pugleaf

I'm not sure that this is appropriate for comp.std.c++, but I suppose that's 
what moderation is for.  Maybe this is an issue for the subsequent standard 
(C++ 2007?).

[Moderator's note: we do accept articles that deal with C++ language
design issues, even if they discuss a possible change to the language
that's unlikely to make it into the standard.  Consider, for example,
the recent operator. discussion.  Note also that questions about why
the language was designed one way, instead of another, are usually
legitimate topics for this group.  mha]

I've never been particularly happy with the -> operator in C, much less C++.  
It strikes me as being quite redundant.  In C, an expression with the form 
p.m has no legitimate meaning if p is an instance of a pointer type.  To 
access the m member of the object addressed by p one needs to write p->m.  
In C this was just a little ugliness, but in C++, where one may legitimately 
wish to alter the access mechanism for an object from ponters to references 
or vice versa over the lifetime of a project, it's a downright nuisance.  If 
the compiler knows that p is a pointer type and therefore has no m member 
itself, why can't it automatically dereference the pointer in the same manner 
that the built in operator() automatically dereferences a pointer to function?

Obviously this would significantly blur the distinction between pointers and  
references.  Perhaps this would have been a good thing.  Do we really need  
pointers and references in the same language?  Wouldn't the following rules,  
had they been added to C++ around 1983, have been sufficient to implement the  
basic functionality of references without adding the new concept?

1. Whenever the expression p.m appears and p has no member named m, the 
   expression is replaced by (*p).m if and only if there is an operator* 
   applicable to the type of p.

2. Whenever the expression f(x) appears and there exists no overload of 
   f which takes an argument matching the type of x, the expression is 
   replaced by either f(*x) or f(&x) depending on which yields a valid 
   expression.  If both do, the expression is ambiguous.

Rule 2 would extend to overloaded operators as well, so that the b - c case 
that Dr. Stroustrup mentions in D&E 3.7 would implicitly be replaced by 
operator-(&b, &c) when b and c are large objects.

With these rules in place, could not delegation be implemented transparently 
via a "smart pointer" class and without any need to overload operator. (or 
operator-> for that matter)?

Perhaps I've missed some crucial aspect of references.  I haven't devoted a 
great deal of contemplation to this, but the only feature of references not 
replicated by the above that I can see right offhand is that pointers lack 
the prohibition against rebinding.  Obviously there would be occations when 
coding in a language implemented with the above rules, especially when 
applying operators, that pointers would not be as transparent as the current 
C++ references are.  Nevertheless, I wonder if this might not have been a 
cleaner approach overall.

I suppose this would have been a much better topic for discussion a decade 
ago, but I was still a lisp hacker back then and had barely heard of C++.  
:-)

--Bruce

----------------------------------------------------------------------------- 
Bruce A. Florman    \ Software Engineer specializing in OO Languages and C++. 
bflorman@indy.net    \ Former Lisp hacker.  Former skydiver.  Ex-Virginian. 
BAFlorman@softart.com \ Fan of Joe Gibbs Racing and the Washington Redskins. 
-----------------------------------------------------------------------------
 "Tragically, this serene metropolis lies directly beneath the Hoover Dam."
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]