Why does my program halt when calling front() on a std::queue?

Question

I want to use the Irrnet network library in an Irrlicht game.

The source code uses Linux sockets and I'm trying to port it for Windows replacing it with code that uses Windows' Winsock2.

The library compiles successfully but when I try to run the Quake example it crashes. I located the line at which the program stops but i can't figure out how to solve the problem.

The program stops at the second call of the function getNextItem

class NetworkType {
    public :
        NetworkType();
        ~NetworkType();
        template<class T>
        void getNextItem(irr::core::vector3d<T>& data);

    private:
        typedef std::queue<std::string> Container;
        Container items;
};

template<class T>
void NetworkType::getNextItem(irr::core::vector3d<T>& data) {
    T X, Y, Z;

    std::istringstream item(items.front());
    // the program does not get here the second time it calls this function
    items.pop();

    item >> X;
    item >> Y;
    item >> Z;

    data = irr::core::vector3d<T>(X, Y, Z);
}

and exactly at this line

  std::istringstream item(items.front());

Can anyone tell me why does the program stop the second time it gets to this line ?

here is the link for the complete source code

This doesn't appear to be game development related and may be better suited for StackOverflow; I have flagged the question for migration consideration. — , Oct 14 '11 at 14:52
Assert(!items.empty()); you should always code your assumptions. — hiddensunset4, Oct 16 '11 at 21:35

score 4 · Answer 1 · answered Oct 14 '11 at 14:57

I assume by "stops" you mean "crashes" in some fashion? Likely causes for a crash on the line in question are:

The NetworkType instance that is invoking the getNextItem() method is garbage (the this pointer is garbage or null). This could happen due to bad pointer math elsewhere, a premature delete or destruction of the instance, et cetera. This would manifest as a fault when the program attempted to access the items member.
The items container is empty. In these cases the return value of front() is undefined (since it is a reference) and the constructor for istringstream may be crashing. front() itself may be raising a debug/runtime check error as well depending on your compiler and its configuration.

yes, by "stops" i mean "crashes". here is the link for the source code of Irrnet [link](https://github.com/bwright/gsoc). It might help to find the exact cause. — rxjsisfine, Oct 14 '11 at 15:18

score 1 · Answer 2 · answered Oct 16 '11 at 14:55

1

Actually you might have a runtime error on this one if the dequeue is empty: MSDN deque

So just check the deque isn't empty before you try to pop a value from it.

if(items.size()>0)
{
//do things
}
else
{
 //error deque empty
}

[edit] confounded std and (I guess) MSDN ( OP doesn't say) lib.

answered Oct 16 '11 at 14:55

Valmond

2,897
8
29
49

i finally found out that the queue was empty because the _recvfrom_ that return it was not successful. – rxjsisfine Oct 16 '11 at 15:47
This answer is wrong and confusing `front` and `begin`. `front` is undefined if the vector is empty. Josh's answer covers this. – Oct 16 '11 at 15:59
(EDIT Typos) Yeah you're right, I confounded the stl library (which doesn't even have a 'front') with I guess the MSDN lib. The stl::deque uses pop_front() and works as I told but I changed the answer. – Valmond Oct 16 '11 at 19:12
std::deque is part of the C++ standard library; MS's implementation, like most others, has a `front` and a `begin`. The question is actually about a std::queue adapter which is also in stdlib, and has a `front` but no `begin` nor `end` nor `push_front`, as queues are unidirectional. – Oct 16 '11 at 19:22

Why does my program halt when calling front() on a std::queue?

2 Answers2