Retrieve the Sum of Array Object Elements Project

Start course
2h 27m

Functions in C++ are reusable named pieces of code that we can call or invoke when we need them to do something. They help us to take large problems and break them down so that they are more manageable. This course explores functions and puts them to use in a range of projects.

Intended Audience

  • Beginner coders, new to C++
  • Developers looking to upskill by adding C++ to their CV
  • College students and anyone studying C++


To get the most out of this course, you should have a basic understanding of the fundamentals of C++.


In this lecture, you will once again sum the values in an array object. I'm going to continue to use the SumArrayObject Visual Studio project but you can create a new Visual Studio project if you'd like maybe SumArrayObject2 or something like that. You'll need to add an overloaded sumArray function, if you're reusing the same Visual Studio project that takes two parameters. The first will be again the array object. The second parameter will be an integer passed by reference to store the sum. You should also make the overloaded function a void function. Let's look at the finished project in Visual Studio continuing with the old SumArrayObject Visual Studio project but having been updated for this challenge. So, let's look at it. Debug, start without debugging. And the outputs fairly simple. We have the output from the previous exercise, the previous project. Same Visual Studio project because I'm reusing it and then we have the output from this challenge right here, this project. So, it's fairly straightforward. They both get the same results. So, no matter what you put in your array, if you're passing the same array to each of these functions, the results should agree. So, give it a shot, pause the video and see if you can figure it out or if you need some help, come back and we'll work on it together. So, how'd that go? That one was a little bit more challenging, but hopefully not too hard. The actual summing part is essentially identical to our original sumArray function. Let's code this. So, I'm going to close this solution where I got the output from, and we're going to reopen our sumArray project and for this one I'm going to add an overload, so void sumArray(array< int, 10> theArray, int& theSum); And as before, I will make this the header of the second function that we are working on. And for this one, you don't need to declare a separate sum because we've got the suming passed in. That's where we're going to store the result. So, we want to clear it out of whatever is in it. And then for (int item : theArray, take theSum += item; should look pretty familiar, right? We've done something very similar before. Then in main, we have to do this, we have to create an integer, lets say resultByRef; just declare it. Then we'll call sumArray(). We're not grabbing a return value because it doesn't return anything. We are however, passing sumArray(primaryArray, resultByRef); So, we are retrieving a value out of it but it's not from a return value. Now, we will print out something like cout<< "Result by ref is "<< resultByRef  <<endl; and let's run this guy and see what happens. And as expected we get the result is 110 for both of these, including the resultByRef. That's pretty awesome, isn't it? So, we do get the exact same result. Now, I don't do this a lot because there are often so many alternative implementations that are possible, but there is actually a really good alternative implementation that's very appropriate for this section. Assuming you continue to use the original SumArrayObject program that has the original sumArray function in it. Can you think of an alternative implementation of our new sumArray function that uses the old one? Note carefully that the code inside of our new sumArray function that has the void return type is extremely similar to the other one, right, except for the return value here. So, it's nearly identical except for some names and obviously the return statement, so that's the big hint. Often as developers, we want to reduce the amount of nearly identical code when possible. There's this rule of thumb, we say in software engineering called don't reinvent the wheel. So, if you already have something that does what you need, don't rewrite the code to do it. Let me show you what I have as an alternative implementation. What I'm going to do is actually called refactoring the code. This means I'm going to rework the implementation to improve it in some aspect. In this case, I'm reducing duplicate code and making it a little more clean. So, rewritten, I'm going to take this sumArray and all I'm going to do inside of our second implementation here, is I'm going to say theSum, which was passed by reference equals, theSum =sumArray (theArray) to it. So, this is actually going to call this one right here, since this one only takes one parameter, right? And it's going to return the sum of the array. That's exactly what we wanted. So, why not reuse it? So, it's very sleek. Again, since the sum the reference parameter needs the integer sum stored into it, I'm just using the version of summary that returns the integer sum for that array to get that value. It's pretty cool, but note that this is not recursion, recursion is when the function calls itself, even though these have the same name, they are not the same function. So, one of the overloads is calling the other overload, which is actually a very common thing to do in many circumstances. Especially when we get into object-oriented programming, and these things called constructors, you find that constructors actually will often call the other constructors. Recursion only occurs when you have a function calling itself directly or indirectly, which is more rare. Now, you might want to take a break or get an energy drink or something much healthier, preferably, but something that will help you to get your thinking cap on, because in many ways the next project is much more substantial than any other projects we've done before in this entire course so far, we're going to write a simple tic-tac-toe game. Now it sounds simple, but it's actually got a lot of interesting nuances to it, so take your break if you need to and then let's get going.

About the Author
Learning Paths

John has a Ph.D. in Computer Science and is a professional software engineer and consultant, as well as a computer science university professor and department chair.

Covered Topics