Queue with a circular array... nitpick !

Another one... Works fine(at least on my test cases); but .. for a second opinion.
Is there a better way to represent the [warping / wrapping (not sure which!)] of the queue ?

(Press Ctrl+W or Alt+F4 or the Big Red Button if terribly annoyed at these posts :P )

Code:

namespace mm
{
enum queue_error{overflow, underflow, beheaded};


template<typename T, int Size>
class queue
{
private:
    T mem[Size];
    int head_ptr;
    int tail_ptr;
    
    inline int diff(int pt1, int pt2) 
        {return pt1-pt2 >=0 ? pt1-pt2 : pt1+Size-pt2 ;}
    // pt1 - pt2 .. keeping 'circular' logic in mind
    inline void increment(int& ptr) { ptr++; ptr%=Size; };
    // incrementing, and wrapping around when necessary 
public:
    queue():head_ptr(1),tail_ptr(0){};
    void push(const T& in)
    {
        if(this->full()) throw(overflow);
        increment(tail_ptr);        
        mem[tail_ptr] = in ; 
    };
    
    void pop()
    {
        if(this->empty()) throw(underflow);
        increment(head_ptr);
    };
    
    T& head()
    {
        if(this->empty())throw(beheaded);
        return mem[head_ptr];
    };
    
    int size()
    {
        if(this->empty())return 0;
        else return diff(tail_ptr,head_ptr)+1;
    };
    
    bool empty(){return diff(head_ptr,tail_ptr)==1;};
    bool full(){return diff(head_ptr,tail_ptr) ==2;};
};
    
}

It's the same issue with modifying the container before throwing.

Code:

void push(const T& in)
    {
        ++tail_ptr;
        tail_ptr%=Size;
        if(diff(head_ptr,tail_ptr) ==2) throw(overflow);

And empty could be written as

Code:

bool empty(){return diff(head_ptr,tail_ptr)==1;}

Sorry anon, I should have updated the code yesterday.
I realized that in this case, modifying before throwing also introduced another bug, decrementing the effective size by 1.
As it is only one reply, I'd update the main post for convenience.

Thanks for the second point.
Reflected that.

The semicolons after your member functions have no practical purpose, but those should be defined after the declaration anyway.

Originally Posted by whiteflags

The semicolons after your member functions have no practical purpose, but those should be defined after the declaration anyway.

Why "should" ? I knew that there are no technical differences.
I put them inside because the alternative would look messy in a forum post.

Well it's the only way to separate the declaration from the implementation. This way you could compile the two separately if you used multiple files.

Originally Posted by whiteflags

Well it's the only way to separate the declaration from the implementation.

I am a little confused though: separate the declaration of what from the implementation of what?

Originally Posted by whiteflags

This way you could compile the two separately if you used multiple files.

We are dealing with a class template, so the class template would need to be specialised for this to work, but I do not see any of that here.

Oh.

I didn't see the template at all.

Incidentally, I notice that a number of member functions do not modify the observable state of the object, yet they are not declared const.

Originally Posted by laserlight

Incidentally, I notice that a number of member functions do not modify the observable state of the object, yet they are not declared const.

Thanks..did so.. for empty(), full() and size(). The private ones don't really matter .. right ?

Originally Posted by manasij7479

The private ones don't really matter .. right ?

They would, since constness is "viral".

Also, the empty and full member functions could be implemented as non-member non-friend functions (or rather, function templates) using the Size member function (of course, Size should then not depend on empty).

In diff, you probably should write pt1 >= pt2 instead of pt1-pt2 >=0. Since diff is already defined in the class definition, there is no need to declare it (and increment) inline with the inline keyword.

Originally Posted by laserlight

Also, the empty and full member functions could be implemented as non-member non-friend functions (or rather, function templates) using the Size member function (of course, Size should then not depend on empty).

Er.. couldn't understand this.
Can you give an example with either of those ?

Originally Posted by manasij7479

Can you give an example with either of those ?

They could be something like:

Code:

template<typename T, int Size>
bool empty(const queue<T, Size>& x)
{
    return x.size() == 0;
}

template<typename T, int Size>
bool full(const queue<T, Size>& x)
{
    return x.size() == Size;
}

Originally Posted by laserlight

They could be something like:...

Wouldn't that be a substantial deviation from the way the standard containers are designed ?
Also, what does the design gain by passing the container object to the functions, rather than be a member ?

Originally Posted by manasij7479

Wouldn't that be a substantial deviation from the way the standard containers are designed ?

full is not a member function in any standard container; empty is a potential problem since existing code might assume that a container would provide empty as a member function. For new code, you could write this instead:

Code:

template<typename Container>
bool empty(const Container& x)
{
    return x.size() == 0;
}

template<typename Container>
bool full(const Container& x)
{
    return x.size() == x.max_size();
}

in which case code that assumes that a container has empty as a non-member member would also work for standard containers. Note that you would then implement max_size as:

Code:

int max_size() const
{
    return Size;
}

Originally Posted by manasij7479

Also, what does the design gain by passing the container object to the functions, rather than be a member ?

Read:
Designing Simple Interfaces by Stroustrup
How Non-Member Functions Improve Encapsulation by Meyers
GotW #84: Monoliths "Unstrung" by Sutter