Redirected to c.l.c++.

In article <rfgCu8CBD.Kp0@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>In article <325eu3INN727@marble.summit.novell.com> jls@summit.novell.com (-mlc-+Schilling J.) writes:
>>In article <rfgCu5ptE.78u@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>>In contrast, operator overloading only provides a cutsey shorthand [...]
>>
>>One of the major design goals of C++ is to make user-defined types as
>>straightforward to use as built-in types, right?
>
>Beats me!  It sounds like you are reading from a list of `major design
>goals of C++'.  Where can *I* get a copy of that list?

At your better technical bookstores.  Stroustrup's _C++ Programming
Language 2nd Ed_

 1.1 Introduction

 The C++ programming language is designed to be
  - a better C
  - support data abstraction
  - support object-oriented programming
 [...]
 Section 1.4 presents features needed to make data abstraction
 effective.  In particular, it introduces classes, [...],
 constructors and destructors, OPERATOR OVERLOADING,
 user-defined type conversions [...]
 [...]

 1.4 Support for Data Abstraction

 The basic support for programming with data abstraction
 consists of facilities for defining a set of operations
 (functions and operators) for a type and for restricting the
 access to objecs of the type to that set of operations.  Once
 that is done, however, the programmer soon finds that language
 refinements are needed for convenient definition and use of
 the new types.  Operator overloading is a good example of
 this.

So, at least the designer of C++ thought that operator overloading was
necessary to support one of the goals of C++.  In CPL2 and his other
books, Stroustrup often mentions the desire to let user-defined types
be used like built-in types (and vice versa!).  Also see _The Design
and Evolution of C++_ 3.6 for a brief analysis of why he didn't feel
the reasons against adding operator overloading proved to outweigh the
advantages.

You, of course, may disagree with the belief that operator overloading
is necessary to implement data abstraction in C++.  I certainly don't
think it's necessary for every language (eg, a language that doesn't
have operators), but I firmly believe that without operator
overloading former C programmers would not be using C++ and array
classes and many numerical programmers wouldn't have given C++ a
second glance since it would have require them to either write
something as ridiculous as:

 void foo(Matrix& m1, const Matrix& m2) {
    plus(m1,m2);
    assign(m1, multiply(m1,m2));
 }

or use C's very limited built-in arrays.

Everyone knows operator overloading can be abused via overuse or
programmers trying to be too cute.  But, I'd sure hate to use an array
or string class without operators.  I certainly don't think using an
overloaded + or [] for those classes makes the code less readable.  In
fact, I think it greatly contributes to its readability.

>[...]
>First, let me make it clear that I never though that operator overloading
>in Ada was such a hot idea either.  So I'm not being prejudiced against
>C++ in particular.

Btw, didn't Meyer cave in and add operator overloading to Eiffel?  I
seem to remember numerical programmers can now write Eiffel code using
a more "natural" (to numerical programmers) syntax.  No point, I just
find it interesting.

>Second, I never said that it was ``necessary'' to ``reject'' operator
>overloading in C++.  Rather, I look at it from the opposite angle and
>say that it was never necessary to include it (way back when).

Well, if you define ``necessary'' as ``necessary in order for C++ to
have achieved the success it has today'', then yes, I do believe
operator overloading was a necessary choice.  I don't think C
programmers would have been as interested in a language in which they
weren't able to map many concepts and syntax they were already using,
for example [] to access string and array elements or + to add two
values together or & to "and" two bit sets.

Jamshid Afshar
jamshid@ses.com

In article <rfgCu5ptE.78u@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In contrast,
>operator overloading only provides a cutsey shorthand notation for something
>we could have done already (with functions) anyway... and there is a case
>to be made that the resulting code would have been more maintainable (and
>thus, in a sense `better engineered') if we had all just been forced to
>use functions anyway.

One of the major design goals of C++ is to make user-defined types as
straightforward to use as built-in types, right?  For those user-defined
types that have numeric or quasi-numeric properties, where infix operators
are the natural means of expressing actions upon those types, you'd fall
far short of the goal if you didn't support overloaded operators.  For example,
if you wanted to the change the implementation of something to use a
user-defined numeric type instead of a built-in one (or vice versa), you'd
be faced with a massive editing job.

Other languages have included overloaded operators without much grief
(e.g. Ada; of all of Ada's problems, this isn't one of them).  What is
it about C++ that makes it necessary (in your view) to reject this feature?

--
Jonathan Schilling
Novell, UNIX Systems Group (UNIX System Laboratories)
jls@summit.novell.com

In article <325eu3INN727@marble.summit.novell.com> jls@summit.novell.com (-mlc-+Schilling J.) writes:
>In article <rfgCu5ptE.78u@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>In contrast,
>>operator overloading only provides a cutsey shorthand notation for something
>>we could have done already (with functions) anyway... and there is a case
>>to be made that the resulting code would have been more maintainable (and
>>thus, in a sense `better engineered') if we had all just been forced to
>>use functions anyway.
>
>One of the major design goals of C++ is to make user-defined types as
>straightforward to use as built-in types, right?

Beats me!  It sounds like you are reading from a list of `major design
goals of C++'.  Where can *I* get a copy of that list?

>Other languages have included overloaded operators without much grief

Please define `much grief'.  I'm sure that the presence of operator
overloading in Ada never caused much grief amount the users, but as
regards to the implementors... well... I've met a few who are prematurely
gray, and some of them even have bald patches in unusual places on their
heads.  (That's what happens when you start tearing your hair out. :-)

>(e.g. Ada; of all of Ada's problems, this isn't one of them).  What is
>it about C++ that makes it necessary (in your view) to reject this feature?

First, let me make it clear that I never though that operator overloading
in Ada was such a hot idea either.  So I'm not being prejudiced against
C++ in particular.

Second, I never said that it was ``necessary'' to ``reject'' operator
overloading in C++.  Rather, I look at it from the opposite angle and
say that it was never necessary to include it (way back when).

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -