Let me see if I can add some more here.
I would say both approaches are not too good. The 2nd one we already explained why because the size of the other pile keeps changing and you are not starting the for loop from scratch every time. The 1st one works for you with the iterator because you are popping the elements in front of the iterator, which for a deque is ok becuase the iterator is not (?) bidirectional and it just so happens the iterator remains valid after you remove the element in the collection. If the collection is LIFO (only remove last available) then you are screwed.
I would argue that semantically, even the "for each" construct is misleading and may eventually lead to errors if the underlying implementation of the iterator (example: in .NET you are implementing an interface if you are creating a new collection class, and it could be a badly implemented one which is not as robust as the FCL).
Since the code is about removing elements from another collection into your own collection, to make the code more explicit you should probably not use the iterator approach at all (unless constrained by access restrictions and/or assignment instructions). If I were to write that piece of code I would do the following. The basic idea is to use the while loop and clearly express the logic as "while the otherPile still has something keep removing items from it". IMO it makes more readable code.
void CardPile::addToPile(CardPile& otherPile)
{
while (otherPile.size() > 0)
{
pile.push_back(&(otherPile.removeTopCard()));
} // end while
} // end addToPile
(In reality there can be a performance hit for this approach, but for CS assignments usually it is about logical correctness, right?)
Now, after all of us have given our input for your little assignment, how many more
Folding boxen are you contributing for our effort?
