pop_back() return value?

Question

Why doesn't pop_back() have a return value? I have Googled regarding this and found out that it makes it more efficient. Is this the only reason for making it so in the standard?

Answer 1

Efficiency has little (or nothing, really) to do with it.

This design is the outcome of an important paper by Tom Cargill, published in the 90s, that raised quite a few eyebrows back then. IIRC, in it Cargill showed that it is impossible to design an exception safe stack pop function.

• yves Baumes: +1 for the reference to Tom Cargill paper "Excpetion handling: a false sense of security". A MUST-READ. :-)
• Konrad Rudolph: If I remember correctly then "The C++ Language" or some edition of "Effective C++" actually claimed that it was for efficiency reasons because they hadn’t figured out move construction and NRVO then.
• sbi: @Konrad: AFAIR, Meyers even pointed at Cargill's paper. (Come to think of it, I bet that's the actual reason why a copy of it exists, at Pearson's website.)
• Mikhail: How can we be sure that a removed object does not throw in destructor? I understand that it shouldn't, but how can we control it?
• sbi: @Mikhail: If destructors throw, you cannot guarantee anything. That's the reason they must not. Again: Destructors must never throw. Period. If you write a dtor that lets escape an exception, you might just as well dereference NULL.

Answer 2

I think there is something related to the fact that copying an instance of the last object could throw an exception. When doing so, you're losing your object, since pop_back() did remove it from your container. Better with a few lines of code:

std::vector<AnyClass> holds = {...} ;
try {
 const AnyClass result = holds.pop_back(); // The copy Ctor throw here!
} catch (...)
{ 
 // Last value lost here. 
}

• hansmaad: +1 T container<T>::pop()cannot be implemented exception safe (gotw.ca/gotw/008.htm)
• Sarfaraz Nawaz: +1 this is the correct answer. It tells us the underlying principle which led to this design of pop_back with no return value.
• yves Baumes: Right. I am not really (yet) knowledgeable with c++11. But I guess the answer still holds true. I mean, not with a compiler-provided move ctor, but a user-defined one. Moreover, afaik, I remember reading somewhere that a class may be defined to eludes any move ctor (= delete?). If so, then we fall back in the copy ctor case (if such is provided, otherwise I guess using a vector won't compile).
• sehe: @DeadMG move constructors might not be noexcept either, if I'm not mistaken
• Sarfaraz Nawaz: @DeadMG: move or copy, that depends on the type of value, as not every type is movable, plus move might throw exception as well.

Answer 3

It's because of the Command-query separation principle.

Answer 4

Efficiency is one thing. Another reason for pop_back() not returning an element is exception safety.
If the pop() function returned the value, and an exception is thrown by the copy constructor, you may not be able to guarantee that the container is in the same state as it was before calling pop().

You can find more infos in Herb Sutters books about exceptions. I think this topic is covered here. But I am not sure.

• sbi: The problem isn't that the container is changed, the problem is that the object might be removed, but you haven't gotten it back — so it's lost.

Answer 5

The reason is not so much efficiency as exception safety. The container class can be used to store any kind of objects. It would be impossible to implement pop_back() in an exception safe manner if the function would return the object after deleting it from the container, because returning the value of the object involves copy construction.

This is the actual implementation of vector::pop_back() in GNU C++ standard library:

 void
 pop_back()
 {
 --this->_M_impl._M_finish;
 this->_M_impl.destroy(this->_M_impl._M_finish);
 }

This is what it would look like should it return the last element in the end:

 value_type
 pop_back()
 {
 value_type save = back();
 --this->_M_impl._M_finish;
 this->_M_impl.destroy(this->_M_impl._M_finish);
 return save;
 }

This involves two copy constructions, at the save = back() statement and when returning a copy of the object. There are no guarantees that the return expression won't throw an exception after the element has been destroyed from the container.

Answer 6

Well, how many reasons there have to be?

This avoids potentially expensive copying of the object when you just want to remove it from the container. C++ has the philosophy of not paying for what you don't need.

• sbi: I believe this is wrong. See my comment to Ravindra's answer.
• Zdeslav Vojkovic: well, I am quite sure that exception related issue is likey one of the reasons, but I am also quite sure that this is another. I have yet to see any evidence that this design has nothing to do with performance issue (as move semantics is quite a new thing) and I haven't claimed there isn't another (OK, my first sentence might sound like that, but it was meant to clarify why one reason wouldn't be enough). Sutter claims in "Exceptional C++" that "here's one reason to do this: It avoids weakening exception safety.".
• sbi: "I have yet to see any evidence that this design has nothing to do with performance issue." You also have yet to see any evidence that this design has nothing to do with bananas. So? It's you who made a claim ("This is about performance!"), and it's me who challenged that. So it's you who need to back up the claim.
• Zdeslav Vojkovic: ok, you got me working there :) Stroustrup says in 'C++ prog. lang' [16.3.5]: It just pops, and if we want to know what was on the top of the stack before pop, we must look. This happens not to be my favorite style of stack, but it's arguably more efficient and it's the standard. OTOH, Josuttis book also refers to Cargill paper. My conclusion is that performance is one of the reasons, while I don't claim that it is the only one. However, upon reading all the references I would also agree that exception-safety might have been more important factor in deciding this way.
• user1095108: this is the best answer, why not avoid a needless copy?

Answer 7

In computer programming, orthogonality means that operations change just one thing without affecting others.

pop_back() does just one thing, it does not copy, hence it is orthogonal.

Answer 8

Why would it return the value? You can always access the value at any time prior to popping it off- there is no need for pop_back to provide this functionality.

• Sarfaraz Nawaz: -1. It doesn't answer the question. There is a rationale why pop_back doesn't return value, and this post doesn't talk about that rationale.
• Puppy: The fact that there is no reason for it to exist is an excellent reason for it to not exist, and that does answer the question.
• sbi: @DeadMG: I believe that there's a good usability case pro pop_back() returning a value. Traditionally, that's what a stack's pop function does. No, the reason is purely for exception safety.