http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55841
Bug #: 55841
Summary: Unexpected behavior from STL's queue
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: n...@math.technion.ac.il
Apparently, when a std::queue is empty, front() returns some bizarre output (a
zeroed object?), and pop() breaks the queue by making its size -1... For
example, this code, which pushes only one object on the queue, and pops 3,
gives the following output::
#include <queue>
#include <iostream>
main(){
std::queue<int> q;
q.push(2);
std::cerr << "size: " << q.size() << '\n';
std::cerr << "popping element: " << q.front() << '\n';
q.pop();
std::cerr << "size: " << q.size() << '\n';
std::cerr << "popping element: " << q.front() << '\n';
q.pop();
std::cerr << "size: " << q.size() << '\n';
std::cerr << "popping element: " << q.front() << '\n';
q.pop();
}
Gives the following output:
size: 1
popping element: 2
size: 0
popping element: 0
size: 18446744073709551615
popping element: 0
Why doesn't front() throw an exception when there's no element?
And why does pop() break the queue?
If I understand correctly, the standard doesn't define what to do in this case
(I don't understand why), but even so, libstdc++ can do something sensible in
this case...
Sure, I can always check empty() before calling front() or pop(), but isn't
that very anti-C++-like, as exceptions were invented exactly so that code
doesn't need to be littered with sanity checks like this, and rare cases of
insanity cause exceptions?
