[Bug libstdc++/55841] New: Unexpected behavior from STL's queue

[nyh at math dot technion.ac.il]

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: unassigned@gcc.gnu.org
        ReportedBy: nyh@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?