🚀 go-pugleaf

According to Tony Cook <tony@online.tmx.com.au>:
>Why don't iterators support the '->' operator - which would be more
>convenient than '(*i).'?

>I know this has been asked before - but the response has usually been
>that -> won't work where the container is an 'int'.

What C++ really needs is implicit relationships between operators, which
could greatly simplify programming.  Example: In C, "a->b" is semantically
identical to "(*a).b".  This relationship should be true in C++ as well.
Why the hell when I define operator* (unary) should I also have to define
operator-> ?  

In fact, there's a whole list of operator relationships that compilers
should infer when an operator is used that has no definition, but a related
operator is defined:

a += b		=>  a = a + b
a + b		=>  tmp = a; a + b; tmp
Similarly for other composite operators.

a != b		=> !(a == b)	and vice versa
a >= b		=> !(a < b)	etc
a < b		=> a - b < 0	etc
a - b		=> a + (-b)	and vice versa
-b		=> 0 - b
+b		=> b
a++		=> a += 1	also --
a->b		=>  (*a).b

One obvious benefit of this is reduced verbosity.  For example, most classes
will need to define only composite operators, or non-composite operators;
the other category will take care of itself.  if your class is amenable to
it, you only need to define a single numeric-valued subtraction operator to
get all six relational operators.

But the relationships between composite/non-composite operators would yield
a huge benefit for many classes such as strings or matrices.  Consider the
expression "a = b + c + d" when all the variables are strings.  With most
string class implementations, the code generated for this is quite
inefficient.  Lots of needless temporary creation, copying, and destruction
is carried out.  If the programmer using the string class were familiar with
its implementation, and wanted the best performance, he would instead write:

	a = b; a += c; a += d;

But this is not as natural as the first expression, and it's unreasonable to
expect programmers to write like that.  Besides, replacing an expression
like "func(a + b + c + d)" is even harder.  Other string classes work around
this by inventing extra "helper" classes that are basically encoded
instructions for which strings to add together during an assignment.

The best solution is for the compiler to feel free to translate the first
expression into the second, taking advantage of implicit relationships
between operators, like C does.

I know this kind of thing will never be accepted as C++ standard, but it
should.	
---
John Scott Peter XXXIII I/III  // Wrong thinking is punishable
Programmer of Pixels          // Right thinking will be as quickly rewarded
Venice, CA                   // You will find it an effective combination



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]