I have a textbook question that's a two parter, the first part asks me to write the definition for a sumStack function (conceptually) with the prototype as:

void sumStack(stack<int> istack)

I can do that part simply enough, by having it pop each value of the stack and adding that value to a sum, but then it asks me why if I called it in the application like this:

total = sumStack(mystack)

Why would mystack still have the values it started with?

Is it because its a void function and that all the 'popping' is done to a copy? And/or because mystack is passed by value? Any help would be appreciated!

I have to say that I'm also a bit at a loss here...

As you point out, the function prototype is passing the stack by value, so it's copying the stack. That function can do whatever it wants with the copy, and when returning from this function, this copy will be destroyed. This function doesn't return anything, so no chance to return the sum...

To me the code total = sumStack(mystack) will make the compiler complain, as your trying to assign void to total.

I assume I didn't understand correctly the question or the givens. Sorry. (still a noob too ;) )

No I'm totally with you there, this is a homework assignment written out of a book , so I was asking here because I thought I was missing something, but it APPEARS to simply be a serious mistake on the author's end.

Actually I just realized I forgot to mention that the stack of integers is an ARRAY, not sure if that changing things? Since if I remember correctly, arrays are always passed by reference.

Actually I just realized I forgot to mention that the stack of integers is an ARRAY, not sure if that changing things? Since if I remember correctly, arrays are always passed by reference.

Yep, changes it A LOT. You remember correctly. Arrays are passed by reference.

total = sumStack(mystack)

Yes, that's a mistake. Doesn't make any sense for a void function.

Why would mystack still have the values it started with?

Well, since we're MIMICKING a stack rather than using the real one, seems like we're missing something. The size of the stack and/or the top of the stack. Depending on how you're mimicking things, that may be just one element of the array or you're missing a parameter (i.e. size). And heck, how about a capacity too to prevent segmentation faults? So if you're mimicking things with an array and that's the function definition, the array must contain the size and capacity, say at elements 0 and 1, and element 2 would be the bottom or maybe element capacity minus 1 would be the bottom. A little arithmetic on the size and capacity tells you what element to pop. Presumably you're supposed to make a deep copy of that array in the function, do the popping on THAT array and leave the original alone. That's my guess.

Edited 5 Years Ago by VernonDozier: n/a

Is it "stack<int>" or an array? Because stack<int> is a standard container (adaptor), named std::stack. It is very possible that the author sloppily said it is an array, because many C++ programmers (including myself) will often forget that the general term "array" (which can mean any kind of homogeneous data-set) is sometimes directly associated with old C-style arrays (as in int[10] or a dynamic one). C++ programmers can often forget this because C-style arrays are so rarely used. So, it is possible that the author used the general term "array" without necessarily meaning a C-style array.

In this case, the only real mistake is that the function should return something, like an integer:

int sumStack(stack<int> istack)

And, yes, if the above is the code involved (and stack<int> is the standard implementation), then the original stack is left unchanged because it is passed-by-value (and thus, the function has its own internal copy of the stack, that can safely be emptied).

Our teacher let us know it was supposed to be int sumStack, not void. Stinks how much trouble you think you're in because you assume the teachers never make mistakes and you just don't know the answer haha! Thanks for the help guys!

This article has been dead for over six months. Start a new discussion instead.