In article <MATT.92Nov12234242@physics16.berkeley.edu>, matt@physics16.berkeley.edu (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
|> (510) 644-2618                    crowd, then a constituency, a movement, a
|> austern@lbl.bitnet                faction, an army!  If you don't have any
|> matt@physics.berkeley.edu         solutions, become a part of the problem!

--

=============================================================================
Klaus Lindemann                        linde@iai.kfk.de (email)
Kernforschungszentrum Karlsruhe GmbH
Abt. IAI
Postfach 3640                          +49 7247 82 5708 (voice)
7500 Karlsruhe 1                       +49 7247 82 5786 (Fax)
Germany

In <comp.lang.c++,comp.std.c++> linde@iai.kfk.de writes:
>
>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.

I don't think this argument is valid.  If we have a piece of code that
calls pow(), for example:

 y = pow(x, 2);

In C++ this code would call pow(double,int).  However, in plain C, the
same code would still compile and produce the desired result, although
the code would call pow(double,double).

The addition of pow(double,int) has two benefits:

 - faster execution, in particular if simple cases
   like pow(x,2) are handled inline

 - most likely higher precision, if exponentiation
   is implemented by repeated multiplication

Any program that really relies on pow(double,int) giving a better
result is extremely fragile, and should probably be rewritten.


  -- Dag

dag@control.lth.se (Dag Bruck) writes:

>In <comp.lang.c++,comp.std.c++> linde@iai.kfk.de writes:
>>
>>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.
>
>I don't think this argument is valid.  If we have a piece of code that
>calls pow(), for example:
>
> y = pow(x, 2);
>
>In C++ this code would call pow(double,int).  However, in plain C, the
>same code would still compile and produce the desired result, although
>the code would call pow(double,double).

Furthermore, the C compiler is still allowed to optimize calls to pow()
with integer exponents; for example y=pow(x,2) could just
generate inline code y=x*x. So there is no efficiency advantage in
making exponentiation an operator.

(Personally I do believe that an exponentiation operator is worthwhile,
but for syntactic/political reasons rather than efficiency considerations.
However, the committee has considered and rejected the proposal, so it seems
to me that further discussion on the topic would not be very useful.)

--
Fergus Henderson             fjh@munta.cs.mu.OZ.AU
This .signature virus is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!

In article <9233301.16475@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
> Furthermore, the C compiler is still allowed to optimize calls to pow()
> with integer exponents; for example y=pow(x,2) could just
> generate inline code y=x*x.

Are you sure about this ?

Is there something in the ANSI standard that states that standard library
functions can not be re-written to do something entriely different ?

I'd better go and re-write all those Karate games programs where pow()
makes your opponent fall over :-)

--
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.

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.

(Oh, since this is the Net, and words here are even more subject to
misinterpretation than they usually are, I just want to make this
clear: I am not attacking anyone, I am not accusing anyone of
anything, and I am not trying to start an argument.  I really am just
posting this for the reason I gave above: I thought that some people
might want to know this, and might not learn it through other
channels.)

The following is an excerpt from the analysis of my proposal, which
was written by Dag Bruck (dag@control.lth.se).  Actually, this is
pretty much the entirety of the analysis, including the comments that
I made in response to it.  That's the easiest way to make sure I don't
take anything out of context!

------------------------------------------------------------

The proposal was rejected for the following reasons:

1.  People who do not write numerical programs will probably find a
C++ exponentiation operator neither beneficial nor detrimental,
according to the proposal.  However, every user of C++ must learn this
new feature.

2.  An operator provides syntactic convenience, but does not provide
any new functionality.  Members of the working group, representing
heavy users of scientific/engineering computation, indicated that the
operator syntax provides minor syntactic convenience.

3.  Users have stressed the importance of substituting their own
specialized power functions for the system default, which would not be
possible with an intrinsic operator.

4.  The proposal is not well motivated; in particular, by analyzing
one 30.000 line FORTRAN program, it does not show that the operator
would be widely used.

5.  The propsal requires adding a new operator and adding another
precedence level, thus increasing the complexity of the language.

Consequently, the working group did not consider that the advantages
of the proposal outweigh the disadvantages.

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
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 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).

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 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
(510) 644-2618                    crowd, then a constituency, a movement, a
austern@lbl.bitnet                faction, an army!  If you don't have any
matt@physics.berkeley.edu         solutions, become a part of the problem!

In article <MATT.92Nov12234242@physics16.berkeley.edu>, matt@physics16.berkeley.edu (Matt Austern) writes:

> 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.

I don't think so. At least the assignment operator is not merely
syntactic sugar. Together with the copy constructor it is used to
describe object cloning; thus it must be overloadable. Allowing the
other operators to be overloaded was then only the removal of a
restriction instead of a syntactic extension.
Hey, since the predecessor of C++, ``C with Classes'', didn't provide
operator overloading _except_ for operator=, this might have been the
way the language evolved. Maybe someone from AT&T can comment on this?
--

Harald Fuchs <hf@telematik.informatik.uni-karlsruhe.de>

hf@telematik.informatik.uni-karlsruhe.de (Harald Fuchs @ Karlsruhe University, Germany) writes

 > Hey, since the predecessor of C++, ``C with Classes'', didn't provide
 > operator overloading _except_ for operator=, this might have been the
 > way the language evolved. Maybe someone from AT&T can comment on this?

The story is of course somewhat longer than this, but yes, operator overloading
and overloading in general in C++ started with overloading of assignment and
initialization.

In article <MATT.92Nov12234242@physics16.berkeley.edu> matt@physics.berkeley.edu 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++.
> ...
>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."

One more reason for you to evaluate the other language alternatives
in earnest, I suggest.  Perhaps your colleagues have even other grounds
than pure stubbornness to favour some other languages.  (Although
I can imagine that there are people who continue to write "Fortran II"
from decade to decade, and refuse to learn anything else.)

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------