NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/cplus/16517

Internet Message Format | 1992-11-18 | 4.4 KB

Xref: sparky comp.lang.c++:16517 comp.std.c++:1597
Newsgroups: comp.lang.c++,comp.std.c++
Path: sparky!uunet!math.fu-berlin.de!unidui!Germany.EU.net!idtuva!idtsun6!linde
From: [e-mail] (Klaus Lindemann)
Subject: Re: The fate of my exponentiation operator proposal
Message-ID: <[e-mail]>
Sender: linde@idtsun6 (Klaus Lindemann)
Nntp-Posting-Host: idtsun6
Reply-To: [e-mail]
Organization: "Kernforschungszentrum Karlsruhe"
References:  <[e-mail]>
Date: Wed, 18 Nov 1992 16:05:10 GMT
Lines: 87

In article <[e-mail]>, [e-mail] (Matt Austern) writes:
|> A while ago, as some of you probably remember, I posted a proposal
|> (X3J16/92-0127 and WG21/N0204) for adding an exponentiation operator
|> to C++.
|>
|> The extensions working group has considered this proposal and rejected
|> it.  A number of people on the Net have talked about the idea of an
|> exponentiation operator, so I thought they might be interested in
|> hearing the reasons for this decision.
|>
|>  <stuff deleted>
|>
|> ------------------------------------------------------------
|>
|> The proposal was rejected for the following reasons:
|>
|>  <reasons deleted>
|>
|> The working group does however favour the suggestion to overload
|> function pow() to take an integer exponent, which would become part of
|> the standard C++ library.
|>
|> Matthew Austern, the author of the proposal, comments the rejection as
|> follows.  Some detailed comments on the causes of rejection have been
|> omitted.
|>
|> "I am glad to see that the working group supports adding operator
                                                            ^^^^^^^^
    do you mean operator or function?

|> pow(double, int) to the standard library.  Even without an
|> exponentiation operator, this change will be a real benefit, and will
|> rectify a noticeable omission.  As I said in my original proposal,
|> this change will remove all arguments in favor of an exponentiation
|> operator except for the syntactic argument.

I think there is another argument in favor of an exponentiation operator: C.
One can add a function pow(double, int) to C++ (because of overloading), but not
to C, you have to choose a name different from pow for this purpose. A real
operator can be added to C also. When modifying C++ for exponentiation, it should
be made in a way which also allows the modification of C.
(One could argue that this argument is of no
importance, because the ANSI-C standard is already too well established, so there is
no way to add a pow(double,int) or a new operator. But I think if a real operator is
added to C++, it will appear also in many available C-compilers, and quickly become
a de-facto standard for C also (which I would like to see)).

|>
|> I believe, however, that it is a mistake to dismiss the importance of
|> syntax so readily.  Syntax matters!  Syntax is the reason why C++
|> (unlike, for example, Objective C) supports operator overloading; for
|> that matter, syntax is the only reason why C++ (again, unlike, for
|> example, lisp) has operators at all.  On a smaller scale, syntax is
|> the reason why the language was extended to permit overloading of both
|> operator++() and operator++(int).
|>

I agree.

|> Users of most other languages have found the syntactic convenience of
|> an exponentiation operator to be useful, and I see no reason why C++
|> would be an exception.

I agree.

|>
|> I am sorry to see this proposal rejected because I still believe that,
|> of the currently popular languages, C++ is probably the best suited
|> for the type of scientific programs that I write.  The absence of an
|> exponentiation operator, however, will make it harder for me to
|> persuade my colleagues to that point of view."
|>
|> --
|> Matthew Austern                   Just keep yelling until you attract a
|> [phone]                    crowd, then a constituency, a movement, a
|> [e-mail]                faction, an army!  If you don't have any
|> [e-mail]         solutions, become a part of the problem!

--

=============================================================================
Klaus Lindemann                        [e-mail] (email)
Kernforschungszentrum Karlsruhe GmbH
Abt. IAI
Postfach 3640                          [phone] (voice)
7500 Karlsruhe 1                       [phone] (Fax)
Germany