Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

While there is such operator - ** in Python , i was wondering why java and c++ havent got one too.

It is easy to make one for classes you define in C++ with operator overloading ( and i believe such thing is possible also in java) , but when talking about primitive types such as int, double and so on , you'll have to use library function like Math.power (and usaully have to cast both to double).

So - why not define such operator for primitive types ?


migration rejected from stackoverflow.com Oct 29 '13 at 13:16

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by gnat, Kilian Foth, MichaelT, World Engineer Oct 29 '13 at 13:16

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

In C++, we cannot create our own operators. You can only overload the existing operators. –  Mahesh Mar 3 '11 at 8:54
@Mahesh , so i can create my own Number class and overload ^ operator to be a power. That realy doesnt mather. –  RanZilber Mar 3 '11 at 8:56
@RanZilber: It does matter because the precedence of the ^ operator do not match the precedence of exponentiation. Consider the expression a + b ^ c. In mathematics, the exponentiation is performed first (b ^ c), then the resulting power is added to a. In C++, the addition is performed first (a + b) then the ^ operator is performed with c. So even if you did implement the ^ operator to mean exponentiation, the precedence will surprise everyone. –  In silico Mar 3 '11 at 8:58
@RamZilber - ^ is an XOR in C++. It is advised that overloaded operator should do no different what a primitive data type does using it. –  Mahesh Mar 3 '11 at 9:01
@RanZilber: Because it's not at all intuitive to use any of those operators you mention to mean exponentiation. I would seriously question the competence of any C++ programmer that overloads the ++ operator or the ! operator et. al. to mean exponentation. But you can't anyway, because the operators you talk about accept only one argument; exponentiation requires two arguments. –  In silico Mar 3 '11 at 9:03

5 Answers 5

up vote 24 down vote accepted

Generally speaking, the primitive operators in C (and by extension C++) are designed to be implementable by simple hardware in roughly a single instruction. Something like exponentiation often requires software support; so it's not there by default.

Also, it's provided by the language in the form of std::pow.

Finally, doing this for integer datatypes wouldn't make much sense, because most even small values for exponentiation blow out the range required for int, that is up to 65,535. Sure, you could do this for doubles and floats but not ints, but why make the language inconsistent for a rarely used feature?

While I agree with most of this, the fact that the modulus operator can not be used on floating point types is inconsistent for primitive data types, but that too probably would not be a single instruction on any hardware I imagine is any way prevalent now. –  Sion Sheevok Mar 3 '11 at 9:05
@Sion: At least on x86, modulus is a single instruction. (DIV does both division and modulus) You've got me on the consistency point though. –  Billy ONeal Mar 3 '11 at 9:09
@Billy ONeal: Floating point modulus in a single instruction? I haven't mucked around in assembly as of late to know for my self. If that's the case, then the modulus operator should be made applicable to floating point types. –  Sion Sheevok Mar 3 '11 at 9:12
@DonalFellows: FORTRAN had the exponentiation operator long before it had anything resembling bignum support. –  supercat Feb 13 '14 at 22:05
@DonalFellows: A power operator isn't as useful with integers as with floats, but for small powers (especially squaring) it could definitely have its uses. Personally I like the approach of making operators out of letters (as Pascal does with div or FORTRAN with .EQ.); depending upon the language whitespace rules, it may be possible to have arbitrary number of operators without requiring that they be reserved words. –  supercat Feb 14 '14 at 20:53

This question is answerable for C++: Stroustrup, "Design and Evolution of C++" discusses this in section 11.6.1, pp. 247-250.

There were general objections to adding a new operator. It would add to the already overcomplicated precedence table. The members of the working group thought it would give only minor convenience over having a function, and they wanted to be able to substitute their own functions sometimes.

There was no good candidate for an operator. ^ is exclusive-or, and ^^ invited confusion because of the relationship between & and | and && and ||. ! was unsuitable since there would be the natural tendency to write != for exponentiation of an existing value, and that was already taken. The best available may have been *^, which apparently nobody really liked.

Stroustrup considered ** again, but it already has a meaning in C: a**p is a times whatever p points to, and char ** c; declares c as a pointer to pointer to char. Introducing ** as a token meaning "declaration of a pointer to pointer to", "times what the next thing points to" (if it's a pointer) or "exponentiation" (if followed by a number) caused precedence problems. a/b**p would have to parse as a/(b**p) if p were a number, but (a/b) * *p if p were a pointer, so this would have to be resolved in the parser.

In other words, it would have been possible, but it would have complicated the precedence table and the parser, and both are already too complicated.

I don't know the story about Java; all I could do would be speculate. As for C, where it started, all C operators are easily translated into assembly code, partly to simplify the compiler and partly to avoid hiding time-consuming functionality in simple operators (the fact that operator+() and others could hide great complexity and performance hits was one of the early complaints about C++).

Nice answer. I guess Java tried to be simplified C in this respect, so nobody wanted to add a new operator. That's a pity that nobody asked me, I surely would have liked *^. :D –  maaartinus Aug 12 '11 at 7:09
I think this is a much better answer than mine. +1. –  Billy ONeal May 29 '12 at 0:46
C was built to do text formatting. Fortran was built to do maths and had complex, power and matrix maths 20 years earlier. –  Martin Beckett May 29 '12 at 15:39
@Martin Beckett: Can you find evidence that C was built for text formatting? It seems to me a very clumsy language for that, and what I've read about the origin of C says it was designed for system programming for Unix primarily. –  David Thornley May 29 '12 at 18:09
+1: The existing meaning for a**p is the killer. (The hacks to work around that problem… Brr!) –  Donal Fellows Oct 29 '13 at 9:32

I suspect it's because every operator you introduce increases the complexity of the language. The barrier for entry is therefore very high. I find myself using exponentiation very, very rarely - and I'm more than happy to use a method call to do so.

I'd use x**2 and x**3 not that rarely. And a magic pow implementation that the compiler knows about and optimizes for the simple cases would be nice. –  CodesInChaos Mar 3 '11 at 10:43
@CodeInChaos: However x * x and x * x * x aren't bad substitutes for the square and cube. –  David Thornley Mar 4 '11 at 16:40
@David you can't simply write x*x if x is an expression. In the best case the code becomes unwieldy, and in the worst slower or even wrong. So you'd need to define your own Square and Cube functions. And even then the code would be uglier than using ** as power operator. –  CodesInChaos Mar 4 '11 at 21:58
@David I need to put parentheses yes, but don't need to repeat the expression several times and bloats the source-code. Which reduces readability a lot. And common subexpression elimination is only possible if the compiler can guarantee the expression being free of side effects. And at least .net jitter isn't too smart in that regard. –  CodesInChaos Mar 4 '11 at 22:36

The Java language and core library designers decided to relegate most math operations to the Math class. See Math.pow().

Why? Flexibility to prioritize performance over bit-for-bit precision. It would go against the rest of the language spec to say that the behavior of built-in math operators could vary from platform to platform, whereas the Math class specifically states that the behavior potentially sacrifices precision for performance, so buyer beware:

Unlike some of the numeric methods of class StrictMath, all implementations of the equivalent functions of class Math are not defined to return the bit-for-bit same results. This relaxation permits better-performing implementations where strict reproducibility is not required.

As I understood it, the question was why they chose to do so. –  sbi Mar 4 '11 at 8:19
Thanks for pointing that out. I've updated my answer to talk a bit about why that is so –  Kim Burgaard Mar 4 '11 at 14:11

Exponentiation was part of Fortran from the beginning because it was aimed squarely at scientific programming. Engineers and physicists use it often in simulations, because power law relationships are common in physics.

Python has a strong presence in scientific computing, too (e.g. NumPy and SciPy). That, along with its exponentiation operator, suggest that it was aimed at scientific programming, too.

C, Java, and C# have roots in system programming. Perhaps that's an influence that kept exponentiation out of the group of supported operators.

Just a theory.

Same reason c never had a complex type and had weird rules for floating point maths - it's a language for CS not for 'real' computer work ;-) –  Martin Beckett Mar 4 '11 at 19:47
@Martin, So you are saying that CS is not real computer work? –  Pacerier Aug 29 '14 at 22:28
@Pacerier computer science is not about using computers to solve non-CS problems –  Martin Beckett Sep 1 '14 at 18:13
What would you call a non-computer-science problem? Personally, I think any problem whose solution can be hastened along by a computer is fair game. Seems a silly argument to me. –  duffymo Sep 1 '14 at 18:30
@MartinBeckett, Exactly. I don't think there's a line between CS problems and non-CS problems. –  Pacerier Sep 1 '14 at 21:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.