pop_back() return value?

A

8

72

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?

Audubon answered 26/9, 2012 at 11:6 Comment(0)

R

66

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. 
}

Returnable answered 26/9, 2012 at 11:12 Comment(8)

+1 T container<T>::pop()cannot be implemented exception safe (gotw.ca/gotw/008.htm) – Misshapen 26/9, 2012 at 11:15

+1 this is the correct answer. It tells us the underlying principle which led to this design of pop_back with no return value. – Cullan 26/9, 2012 at 11:15

You wouldn't copy it, you would move it. That's a whole different ball game. – Phlegmatic 26/9, 2012 at 19:46

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). – Returnable 26/9, 2012 at 20:12

@DeadMG move constructors might not be noexcept either, if I'm not mistaken – Satang 26/9, 2012 at 22:28

@DeadMG: move or copy, that depends on the type of value, as not every type is movable, plus move might throw exception as well. – Cullan 27/9, 2012 at 10:14

@Misshapen 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? – Marcusmarcy 28/4, 2014 at 9:29

When discussing exception safety you need to consider the kind of safety you guarantee (en.wikipedia.org/wiki/Abrahams_guarantees). As I understand, the convention of avoiding element destruction and copy construction in the same pop method offers the possibility of "strong" exception safety (no data loss). However, STL does not make such guarantees in general, so IMHO they could very well have added a pop method that returns a copy (still guaranteeing "basic" safety, i.e. no leaks). Am I wrong? – Cannabin 26/5, 2014 at 12:14

I

76

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.

Inge answered 26/9, 2012 at 11:16 Comment(9)

+1 for the reference to Tom Cargill paper "Excpetion handling: a false sense of security". A MUST-READ. :-) – Returnable 26/9, 2012 at 11:19

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. – Sparing 26/9, 2012 at 12:24

@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.) – Inge 26/9, 2012 at 12:28

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? – Marcusmarcy 28/4, 2014 at 9:15

@Mikhail: The same way you can be sure that some function does what the spec says: You need to trust those who wrote the code that they didn't do anything stupid. – Inge 29/4, 2014 at 22:3

@Inge So we guarantee pop_back doesn't throw unless user is stupid? – Marcusmarcy 30/4, 2014 at 6:28

@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. – Inge 5/5, 2014 at 14:14

Interesting paper. However I don't immediately see that the paper shows it's impossible to design an exception-safe pop function. For example isn't it possible to copy the last element into a parameter passed by reference, e.g. void Stack::pop(T &oldTop), such that if this copy throws, the stack remains unchanged? – Bordure 9/12, 2018 at 14:17

If NRVO was mandatory would it not be possible to implement this safely? – Priory 9/9, 2023 at 9:2

R

66

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. 
}