Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!quanta.eng.ohio-state.edu!raksha.eng.ohio-state.edu!rob
From: rob@raksha.eng.ohio-state.edu (Rob Carriere)
Newsgroups: comp.lang.c
Subject: Dialects, C++, Overloading
Summary: This is a followup.  References were lost.
Message-ID: <4267@quanta.eng.ohio-state.edu>
Date: 18 Feb 90 21:57:24 GMT
Sender: news@quanta.eng.ohio-state.edu
Reply-To: rob@raksha.eng.ohio-state.edu (Rob Carriere)
Organization: Ohio State Univ, College of Engineering
Lines: 62

I hope the attribution is correct, rn and postnews were both on the blitz...
In article <00017@meph.UUCP>, gsarff@meph.UUCP (Gary Sarff) writes:
>I think [...] the reason I have always distrusted
>overloading, [...] is that when you have overloading, you must have
>all source code, headers, module def's, whatever available to you (the way
>the compiler does) or the meaning of any statement you see that has operators
>in it cannot be deduced by you.  This is ease of maintainability??
>Even if you can determine the types of a,b, and c, and you see
>
>  a = b + c;
>
>do you _REALLY_ know the semantics of this, what if I overloaded + to do
>something really strange, like b + c = 1 if b and c are mutually prime?

Hmmm...  Do you claim it is any clearer if I write:

   assign( a, plus( b, c ));

instead?

>Doesn't make sense to you, (or me either), but that isn't the point.  The
>compiler won't stop me from doing this, the language definition allows it.
>The only restraint we have that something like this won't happen is the
>restraint of the originating programmer.  Features like that in any language
>are at least a bit scary to contemplate.

No more so than any type of procedure or function definition capability.  On
the other hand, you claim that such features should not be allowed because
they destroy the programmer's ability to read based on convention.  If the
programmer's only experience is in the writing of, say, C, this is true.
However, what is such a programmer doing with vectors (or whatever) anyway?
Such a person is a danger to himself and all around him.  If instead we make
the much more reassuring assumption that the programmer knows about the things
he is programming, then we have a second set of conventions to deal with:
those of the subject at hand.  Anybody who has linear algebra will have no
problem reading:

  x = A*x + B*u;

with x and u vectors, A and B matrices.  However,

  assign_vector( x, add_vector( mult_mat_vect( A, x ), mult_mat_vect( B, u )));

requires some deciphering[1].

Of course, you can screw your readers by using definitions of =, + and * that
run counter to the conventions observed in the area, but then, you can do the
same with the procedural version...

  make( glob( squeeze( x, A ), squeeze( u, B )), x );

is already rather sure to have everybody run for the docs, and it still hasn't
even touched the semantics... [2]

SR
[1] x.assign( (A.mult_vect( x )).plus( B.mult_vect( u ) ));
    isn't much better.
[2] If you want to drive everybody nuts, just give all your vectors uppercase
    names and all your matrices lowercase ones, and then use row-vector matrix
    multiplies...  Lynch mobs guaranteed, and you didn't even need overloading
    :-) 
---