Skip to main content
gamedev.net
🔒 Locked

Enginuity & ringbuffer

Started by Koshmaar 0 replies 1k views
Original Post
Koshmaar
Koshmaar
Hi, I think I found a bug in Enginuity's implementation of ringbuffer (or at least don't know how it should be working). Simple test:



// all it does is it creates ringbuffer with 10 buckets and fill it with 50 ints, thereby it should contain last 10 ints

#include <iostream>

using namespace std;


template<class T, long bufSize>
class ringbuffer
{
	protected:
		T buf[bufSize];
		signed long read;
                signed long write;
	public:
		ringbuffer()
		{
			read=0; write=1;
		}

       

		bool operator << (const T & obj)
		{
			buf[write]=obj;
			++write;
			while(write>=bufSize)write-=bufSize;
			if(write==read)
			{
				--write; //make sure this happens next time
				while(write<0)write+=bufSize;
				return false;
			}
			return true;
		}
		bool operator >> (T &res)
		{
			++read;
			while(read>=bufSize)read-=bufSize;
			if(read==write)
			{
				++write; //make sure this happens next time we call and the buf is still empty
				while(write>=bufSize)write-=bufSize;				
				return false;
			}
			res=buf[read];
			return true;
	   }
		unsigned long dataSize()
		{
			signed long wc=write;
			while(wc<read)wc+=bufSize;
			return wc-read-1;
		}
		void flood(const T &value)
		{
			//loop through all indices, flooding them
			//this is basically a reset
			read=0;
			for(write=0;write<bufSize;write++)
			{
				buf[write]=value;
			}
			write=1;
		}
};

int main()
 { 

  const int count = 50;

  {
   ringbuffer<int, 10> ring;


   // populate
   for (int i = 0; i < count; ++i)
    ring << i;



   // read
   for (int i = 0; i < count; ++i)
    {
     int out;
     ring >> out;
     cout << out << endl;
    }

  }

return 0;


and the effect:

 0
 1
 2
 3
 4
 5
 6
 7
 7
 7
 7
 7
 7
 7
 7
 ...
while it should look more like


41
42
43
44
45
46
47
48
49
41
42
...


Above code contains fix to bug observed by some user: should be "signed long read" instead of "long read". Superpig wrote in Enginuity #2 topic that ringbuffer contains bug and that it was already fixed in his local version but should be included in next release. However, looking at Enginuity #5 I can't see any difference, and it even still has "long" instead of "signed long". I suspect he thought about some other bug or that he forgot to mention about some other bug. Anyway, end of explanations - does anyone knows what's wrong with this code / test? Or do you know alternative C++ templated implementation that's proven to work correctly?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.