Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28510 Discussions

is it possible to create += to mimic C

New Contributor II

Is it possible to create += to mimic C.  If not, is this something planned for a future standard?


0 Kudos
7 Replies
Honored Contributor III

No and no. The standards committee has discussed += and -= but decided that it is just "syntactic sugar" that doesn't add any capabilities. 

0 Kudos
New Contributor II

Well, you can't argue with that logic.  I guess the only real gains would be cleaner code and maybe prevent a bug or two, which I suppose was the motivation for the creators of C.

What's your opinion on it, Steve?

0 Kudos
Honored Contributor III

I don't think it's worth the effort to add it to the language, though I have no objection to the feature itself. I often say that every change to the standard has a cost, in terms of time spent defining the feature and vendors time implementing it. I weigh such costs against other things we could be doing instead, and for something like this, it loses.

We often see people saying "language X has this feature, why not add it to Fortran?" If the feature truly enhances the development of scientific and engineering applications, which is Fortran's reason for being, then it should be seriously considered. But if it's just yet another way of doing something Fortran already has, and I'd disagree that it prevents bugs, then I'd rather be working on something else (such as conditional expressions, which I am working on.)

0 Kudos
Honored Contributor II

"I guess the only real gains would be cleaner code and maybe prevent a bug or two"

I don't get that argument at all. I can't see any real situation where the lack of a += operator would lead to bugs. "Cleaner" is very subjective!

0 Kudos
Honored Contributor II

With the technical/software solutions with your business, if you're seriously committed to Fortran, you may want to consider engaging and discussing closely and collaborating with the developing Fortran 'community' online at sites such as GitHub:


0 Kudos
New Contributor I

Probably should not be allowed for the same reason that overloading ** is not allowed in C++ to mimic the power function. Overloading by definition is for existing operators so unless Fortran adds += to its current list of operators, += would remain unavailable for that purpose (as would ++, -- etc.).

Interestingly, I have seen the Bitwise exclusive OR operator (^) being overloaded with the power function in C++. C++ does not care whether the overloading actually does what it is supposed to do and ^ is a convenient choice since it is the analog of ** in and VBA. Don't know if Fortran does any logical checks either.

0 Kudos
Honored Contributor III

Fortran allows extending intrinsic operators but, like any generic extension, the arguments (operands) can't match an existing definition. So while you are free to have INTERFACE OPERATOR (+), you can't use this to replace intrinsic addition. Similarly if you have INTERFACE OPERATOR (.OR.), you can define this on non-LOGICAL types, but not on two LOGICALs. Fortran doesn't care what your extended routine does.

This caused me to wonder what Intel Fortran does for cases where it already extends certain operators, such as .OR. with integer arguments (see Doctor Fortran in “To .EQV. or to .NEQV., that is the question”, or “It’s only LOGICAL”)

So I tried this:

module myfuncs
function myextor (a,b)
integer :: myextor
integer, intent(in) :: a,b
myextor = a + b
end function myextor
end module myfuncs

program test
use myfuncs
implicit none
!interface operator (.OR.)
!  module procedure :: myextor
!  end interface
print *, (3 .OR. 6)
end program test

I was pleased to see that, even though ifort provides a definition for 3 .OR. 6, it let me replace that with my own function. With the generic interface enabled, the program prints 9, with it disabled, it prints 7.


0 Kudos