Return to Answer

Being C++ is not just about writing code that can be compiled by the C++ compiler. It is a style of writing code. This is a typical C style. It just happens to compile under C++ compiler but its not C++.

In this case its not just a pointer its an array, the trouble here is that the array has decayed so we can't actually tell that it is an array anymore and just have to assume the caller has not done something stupid. In C++ we like to understand the object being passed so we can use it correctly.

In C++ (upto C++17) we would normally represent this as iterators:

Note a Range basically supports begin() and end() and is interchangeable with a View. If I got the incorrect sorry, we are still getting used to these concepts as they are new to C++.

What are you trying to achieve. Vertical space-saving is not a good style. Make it clear as possile to use.

I know a lot of people use i/j for loop variables (especially coming from C or FORTRAN). But it is objectively a bad choice. Once you start adding comments to your code searching for i and j in the code gives you way to many false hits when trying to find all the use cases. So unless your loop is literally one line obvious and the loop variable is only used in one place don't do it. Even if all the above is true don't do it because the code will change over time and writing it expressively now will save time later.

I would separate this addition line out into its own function (with a very explanation based name) so it documents why you are adding this up in a particular order. This will be important for future maintainers as they may not immediately understand why all the braces are there (and do what I did and just remove them to make the code easy to read).

As a side note: prefer ++j over j++. For integers there is n difference. But if you are looping with other types it can make a minor differences and the idea is that you want to be optimal whatever the loop type. A lot of C++ code is modified by simply changing the type of the objects and you don't want to change the type then go back and change how it used as well.

Being C++ is not just about writing code that can be compiled by the C++ compiler. It is a style of writing code. This is a typical C style. It just happens to compile under C++ compiler but it's not C++.

In this case its not just a pointer: it's an array. The trouble here is that the array has decayed so we can't actually tell that it is an array any more and just have to assume the caller has not done something stupid. In C++ we like to understand the object being passed so we can use it correctly.

In C++ (up to C++17) we would normally represent this as iterators:

Note a Range basically supports begin() and end() and is interchangeable with a View. If I got that incorrect, then sorry: we are still getting used to these concepts as they are new to C++.

What are you trying to achieve? Vertical space-saving is not a good style. Make it clear as possible to use.

I know a lot of people use i/j for loop variables (especially coming from C or FORTRAN). But it is objectively a bad choice. Once you start adding comments to your code searching for i and j in the code gives you way too many false hits when trying to find all the use cases. So unless your loop is literally one line obvious and the loop variable is only used in one place don't do it. Even if all the above is true, don't do it because the code will change over time and writing it expressively now will save time later.

I would separate this additional line out into its own function (with a very explanation-based name) so it documents why you are adding this up in a particular order. This will be important for future maintainers as they may not immediately understand why all the braces are there (and do what I did and just remove them to make the code easy to read).

As a side note: prefer ++j over j++. For integers there is no difference. But if you are looping with other types it can make a minor difference and the idea is that you want to be optimal whatever the loop type. A lot of C++ code is modified by simply changing the type of the objects and you don't want to change the type then go back and change how it used as well.

In this case its not just a pointer its an array, the trouble here is that the array has decayed so we can actually tell that it is an array anymore and just have to assume the caller has not done something stupid. In C++ we like to understand the object being passed so we can use it correctly.

In this case its not just a pointer its an array, the trouble here is that the array has decayed so we can't actually tell that it is an array anymore and just have to assume the caller has not done something stupid. In C++ we like to understand the object being passed so we can use it correctly.

There is no precedence rules you are trying to acoud here. Those extra braces are just adding noise to the code:

      sums[3]=(((a[i]+a[i+1])+(a[i+2]+a[i+3]))+((a[i+4]+a[i+5])+(a[i+6]+a[i+7])));

Why not:

      sums[3]=a[i]+a[i+1]+a[i+2]+a[i+3]+a[i+4]+a[i+5]+a[i+6]+a[i+7];

Why not use a standard algorithm:

      auto start = a + i;
      auto end   = start + 8;
      sums[3]    = std::accumulate(start, end, 0);

      sums[3]=(((a[i]+a[i+1])+(a[i+2]+a[i+3]))+((a[i+4]+a[i+5])+(a[i+6]+a[i+7])));

      sums[3]=a[i]+a[i+1]+a[i+2]+a[i+3]+a[i+4]+a[i+5]+a[i+6]+a[i+7];

      auto start = a + i;
      auto end   = start + 8;
      sums[3]    = std::accumulate(start, end, 0);

As it turns out the parentheses here is for a reason. Because we are dealing with doubles. The parentheses reduces the amount of error that creeps into the sum by making sure we do addition in a particular order.

I would separate this addition line out into its own function (with a very explanation based name) so it documents why you are adding this up in a particular order. This will be important for future maintainers as they may not immediately understand why all the braces are there (and do what I did and just remove them to make the code easy to read).

sums[3] = sumValuesBecauseOfSomeReasonIHaveThatReducesErrors(a + i)

inline double sumValuesBecauseOfSomeReasonIHaveThatReducesErrors(double* a) {
    return (((a[0]+a[1])+(a[2]+a[3]))
         +((a[4]+a[5])+(a[6]+a[7])));
}