Massassi Forums Logo

This is the static archive of the Massassi Forums. The forums are closed indefinitely. Thanks for all the memories!

You can also download Super Old Archived Message Boards from when Massassi first started.

"View" counts are as of the day the forums were archived, and will no longer increase.

ForumsDiscussion Forum → Jon'C is awesome. Discuss.
12
Jon'C is awesome. Discuss.
2006-10-14, 8:55 AM #1
Jon's just helped me resuce my old and dying laptop (which Izzy currently uses for work) by doing some (I presume basic to you lot) terminal magic with mounting, kate-ing and other such things. Knoppix is good, but Jon is better.

Cheers.
2006-10-14, 8:56 AM #2
joncy ftw
free(jin);
tofu sucks
2006-10-14, 9:13 AM #3
hooray for Jon'C: the bitterest coder you ever did meet!
My girlfriend paid a lot of money for that tv; I want to watch ALL OF IT. - JM
2006-10-14, 9:22 AM #4
Jon'C is a goon therefore he wins.

Much like kyle90 and DSettahr.

But not Stinkywrix. He kept disrobing me. :argh:
Code to the left of him, code to the right of him, code in front of him compil'd and thundered. Programm'd at with shot and $SHELL. Boldly he typed and well. Into the jaws of C. Into the mouth of PERL. Debug'd the 0x258.
2006-10-14, 9:24 AM #5
Originally posted by JediGandalf:
Jon'C is a goon therefore he wins.

Much like kyle90 and DSettahr.

But not Stinkywrix. He kept disrobing me. :argh:


.(

And yes, Jon`C does rule. Hurray for Jon!
2006-10-14, 9:29 AM #6
Huzzah!
2006-10-14, 9:37 AM #7
yeah he's alright :P
2006-10-14, 10:42 AM #8
Originally posted by JediGandalf:
Jon'C is a goon therefore he wins.

Much like kyle90 and DSettahr.

But not Stinkywrix. He kept disrobing me. :argh:


Damn straight.

Whichever side Jon'C is on in a debate, wins automatically. Thus the ultimate debating strategy is simply to align one's self with Jon'C's opinion. Thankfully this is not hard to do because in general the other side is stupid.
Stuff
2006-10-14, 11:00 AM #9
Jon'C is a great guy. We need more Jon'C on these forums.
[This message has been edited. Deal with it.]
2006-10-14, 11:40 AM #10
I remember when Jon'C was so awesome, Massassi turned green.
2006-10-14, 12:43 PM #11
I'm waiting for the next release of Jon`C++
2006-10-14, 3:31 PM #12
There are only 2 beings on this plant more awesome than Jon`C.

Spe, and one individual who we are not allowed to discuss. I'm certain many of you know who I'm talking about.
I had a blog. It sucked.
2006-10-14, 3:54 PM #13
I KNOW YOU'RE TALKING ABOUT ME, I CAN TELL, ZLOC
Holy soap opera Batman. - FGR
DARWIN WILL PREVENT THE DOWNFALL OF OUR RACE. - Rob
Free Jin!
2006-10-14, 3:59 PM #14
Damn, make that 3 people cooler than Jon`C. Spe, and 2 people we aren't allowed to talk about, one of which is genks.
I had a blog. It sucked.
2006-10-14, 4:13 PM #15
*COUGH*

I said he awesome, but I never aligned my own level of awe with respect to Jon's.

<.<
>.>
2006-10-14, 11:12 PM #16
Originally posted by Zloc_Vergo:
Damn, make that 3 people cooler than Jon`C. Spe, and 2 people we aren't allowed to talk about, one of which is genks.


Brown-noser.
Star Wars: TODOA | DXN - Deus Ex: Nihilum
2006-10-14, 11:32 PM #17
It's ok Sam, I give you permission to talk about me.
2006-10-15, 5:47 AM #18
Did this thread perhaps fall out of an alternate universe?
Wikissassi sucks.
2006-10-15, 8:18 AM #19
omg JM >>>>>>>>> Non-C
My girlfriend paid a lot of money for that tv; I want to watch ALL OF IT. - JM
2006-10-15, 8:30 AM #20
Originally posted by Isuwen:
Did this thread perhaps fall out of an alternate universe?
Is that the same alternate universe where you forked Sith 2?
2006-10-15, 1:33 PM #21
Yes, it's the one where your code wasn't ugly.
Wikissassi sucks.
2006-10-15, 1:39 PM #22
Originally posted by Isuwen:
Yes, it's the one where your code wasn't ugly.
All that means is you're too retarded to understand it.

FYI: I'm not the only person to work on Sith 2. So it's only 25% likely that the code you're too retarded to understand was written by me.

Retard.

Edit: Oh, and you're also a pedophile. And you suck at drawing.

Edit 2: And your levels were dull and uninspired.

Edit 3: And incidentally, the guy who wrote the renderer (and now works for LEC) describes my code as though it were written 'like a C++ textbook'. I'm guessing you're one of the peanut gallery armchair coders so you probably started on the rendering code, which is completely uncommented and very messy, starting foaming at the mouth and, with a single tear, let your dream of a JK-based MMORPG die.
Because if you started on my code, you'd have to consider proper use of language features and regular commenting to be "ugly", meaning you are - in fact - retarded. Just explaining a few things to you.

Edit 4: And someone with your face probably shouldn't call anything else ugly.

Edit 5: Proof that JM/Isuwen is retarded and also a pedophile. Some source code from an older project (Sith 2 vintage).

sys_mqueue.h:
Code:
#ifndef _SYS_MQUEUE_H_INCLUDED_
#define _SYS_MQUEUE_H_INCLUDED_

namespace Engine
{
	namespace System
	{
		// MessageQueue Class
		// - Thread-safe message queue for inter-process communications.
		class MessageQueue
		{
		private:
			Data::Message* Buffer;
			const size_t BufferSize;

			volatile size_t ReadOffset;
			volatile size_t WriteOffset;

		public:
			MessageQueue(size_t = 512);
			~MessageQueue();

			bool PushMessage(const Data::Message&);
			bool PopMessage(Data::Message& Msg);
		};
	};
};

#endif // _SYS_MQUEUE_H_INCLUDED_


sys_mqueue.cpp:
Code:
#include <assert.h>

#include <string>

#include "util_strconv.h"
#include "data_dator.h"
#include "data_msg.h"
#include "sys_mqueue.h"

/* BEGIN: CLASS MessageQueue IMPLEMENTATION */

// Default constructor.
// - size_t argument dictates size of message queue buffer.
Engine::System::MessageQueue::MessageQueue(size_t bs) : BufferSize(bs), ReadOffset(0), WriteOffset(1)
{
	// Allocate buffer where messages will be stored:
	Buffer = new Data::Message[BufferSize];

	// Check to make sure memory was allocated successfully:
	if(Buffer == 0)
	{
		assert(0 && "Failed to allocate memory for message queue.");
	};

	return;
};

// Default destructor.
Engine::System::MessageQueue::~MessageQueue()
{
	// Free buffer to keep from leaking memory.
	delete[] Buffer;

	return;
};

// PushMessage()
// - Adds message to Message Queue.
bool Engine::System::MessageQueue::PushMessage(const Engine::Data::Message& msg)
{
	if(WriteOffset == ReadOffset)
	{
		// Not enough room in queue to add message.
		return false;
	}
	else
	{
		if(WriteOffset == 0)
		{
			Buffer[BufferSize - 1] = msg;
		}
		else
		{
			Buffer[WriteOffset - 1] = msg;
		};

		++WriteOffset;

		if(WriteOffset == BufferSize)
		{
			WriteOffset = 0;
		};

		// Message successfully added.
		return true;
	};
};

// PopMessage()
// - Removes message from queue for processing.
bool Engine::System::MessageQueue::PopMessage(Engine::Data::Message& msg)
{
	if(ReadOffset == (WriteOffset - 1))
	{
		// No messages in queue.
		return false;
	}
	else if((WriteOffset == 0) && (ReadOffset == (BufferSize - 1)))
	{
		// No messages in queue.
		return false;
	}
	else
	{
		msg = Buffer[ReadOffset];

		++ReadOffset;
		if(ReadOffset == BufferSize)
		{
			// Read offset has reached the end of the queue.
			// Bring it back to start position.
			ReadOffset = 0;
		};

		return true;
	};
};

/* END: CLASS MessageQueue IMPLEMENTATION */


Some code from JM/Isuwen's latest C++ game engine project:
Code:


Oh wait.
2006-10-15, 1:51 PM #23
:rolleyes:

Code:
#include "command_matchers.h"
#include <boost/spirit.hpp>
#include "construct_new.h"
#include "at_startup.h"
#include <boost/spirit/phoenix/primitives.hpp>
#include <boost/spirit/phoenix/operators.hpp>
#include <boost/spirit/phoenix/functions.hpp>
#include <list>

using namespace command_parser;
using namespace phoenix;
using namespace boost::spirit;

namespace
{

	struct push_back_impl
    {
        template <typename Container, typename Item>
        struct result
        {
            typedef void type;
        };

        template <typename Container, typename Item>
        void operator()(Container& c, Item const& item) const
        {
            c.push_back(item);
        }
    };

	function<push_back_impl> const f_push_back = push_back_impl();

	struct sequential_creation_impl
	{
		template <typename LIST>
		struct result
		{
			typedef Matcher type;
		};

		template <typename LIST>
		Matcher operator()(LIST list) const
		{
			if (list.size() == 1) return list.front();
			return Matcher(new SequentialMatch(list.front(), (*this)(LIST( (++list.begin()), list.end() ))));
		}
	};

	function<sequential_creation_impl> const f_sequential_creation = sequential_creation_impl();

	template <typename T> 
	struct closure_1 : boost::spirit::closure<closure_1<T>, T>
	{
		member1 _result;
	};

	template <typename T, typename _2> 
	struct closure_2 : boost::spirit::closure<closure_2<T,_2>, T, _2>
	{
		member1 _result;
		member2 _second;
	};

	template <typename T, typename _2, typename _3> 
	struct closure_3 : boost::spirit::closure<closure_3<T,_2,_3>, T, _2, _3>
	{
		member1 _result;
		member2 _second;
		member3 _third;
	};

	rule<boost::spirit::scanner<>, closure_1<Matcher>::context_t> node;

	rule<boost::spirit::scanner<>, closure_2<Matcher, std::list<Matcher> >::context_t> sequential;
	rule<boost::spirit::scanner<>, closure_2<Matcher, Word>::context_t> keyword;
	rule<boost::spirit::scanner<>, closure_1<Matcher>::context_t> optional;
	rule<boost::spirit::scanner<>, closure_1<Matcher>::context_t> rest;
	rule<boost::spirit::scanner<>, closure_1<Matcher>::context_t> none;
	rule<boost::spirit::scanner<>, closure_3<Matcher,Matcher,Matcher>::context_t> pivot;
	rule<boost::spirit::scanner<>, closure_2<Matcher, Word>::context_t> capture;
	rule<boost::spirit::scanner<>, closure_2<Matcher, Word>::context_t> object;
	rule<boost::spirit::scanner<>, closure_1<Matcher>::context_t> word;

	rule<boost::spirit::scanner<>, closure_1<Word>::context_t> identifier;

	OPEN_AT_STARTUP(A)
	
	node = (
		sequential[node._result = arg1]
		| keyword[node._result = arg1]
		| optional[node._result = arg1]
		| rest[node._result = arg1]
		| none[node._result = arg1]
		| pivot[node._result = arg1]
		| capture[node._result = arg1]
		| object[node._result = arg1]
		| word[node._result = arg1]
	);

	identifier = (+boost::spirit::alnum_p)
		[identifier._result = construct_<Word>(arg1,arg2)];

#define CREATE_MATCHER(TYPE) construct_<Matcher>(construct_new_<TYPE>())
#define CREATE_MATCHER_1(TYPE,A) construct_<Matcher>(construct_new_<TYPE>(A))
#define CREATE_MATCHER_2(TYPE,A,B) construct_<Matcher>(construct_new_<TYPE>(A,B))
#define CREATE_MATCHER_3(TYPE,A,B,C) construct_<Matcher>(construct_new_<TYPE>(A,B,C))


	sequential = ( ch_p('(') >> node[f_push_back(sequential._second,arg1)] >> 
		*( ch_p(',') >> node[f_push_back(sequential._second,arg1)] ) >> ch_p(')') )
		[sequential._result = f_sequential_creation(sequential._second)];

	keyword = ( identifier[keyword._second = arg1] )
		[keyword._result = CREATE_MATCHER_1(KeywordMatch,keyword._second)];

	optional = ( ch_p('?') >> node[optional._result = arg1] )
		[optional._result = CREATE_MATCHER_1(OptionalMatch,optional._result)];

	rest = ( ch_p('+') )
		[rest._result = CREATE_MATCHER(RestMatch)];

	none = ( ch_p('$') )
		[none._result = CREATE_MATCHER(NoneMatch)];

	pivot = ( str_p("[") >> node[pivot._result = arg1] >> ',' >> node[pivot._second = arg1] >> ',' >>
		node[pivot._third = arg1] >> ']')
		[pivot._result = CREATE_MATCHER_3(PivotMatch,pivot._result,pivot._second,pivot._third)];

	capture = ( ch_p('[') >> node[capture._result = arg1] >> ch_p('>') >> identifier[capture._second = arg1] >> ch_p(']') )
		[capture._result = CREATE_MATCHER_2(CaptureMatch,capture._result,capture._second)];

	object = ( str_p(":[") >> identifier[object._second = arg1] >> ch_p(']') )
		[object._result = CREATE_MATCHER_1(ObjectMatch,object._second)];

	word = ( ch_p('.') )
		[word._result = CREATE_MATCHER(WordMatch)];

	CLOSE_AT_STARTUP(A)
}

bool command_parser::create_matcher(const std::string& def, Matcher& store)
{
	Matcher result;
	if( parse(def.c_str(), (node[ assign_a(result) ])).full )
	{
		store = result;
		return true;
	}
	return false;
}


Also, wtf, use standard containers. Christ.
Wikissassi sucks.
2006-10-15, 1:57 PM #24
Originally posted by Isuwen:
:rolleyes:
* code *

What the christ?

Yes, surely you are the master. Your code is not the least bit messy* and it is well-commented so people can understand what it does at a glance**.

* it is
** there are ZERO comments

Quote:
Also, wtf, use standard containers. Christ.
The STL is not thread-safe downs boy.
2006-10-15, 2:02 PM #25
Quote:
so people can understand what it does at a glance


All that means is you're too retarded to understand it.

Quote:
The STL is not thread-safe downs boy.


Niether is your code. :)
Wikissassi sucks.
2006-10-15, 2:06 PM #26
Ok guys calm down, let's get a second opinion. From me.

Jon`C's code is awesome and I was able to speed read right through it and see what it was doing.

Isuwen's code made my eyes glaze over, and I sped through it not knowing WTF it was, faster and faster so I could finish reading it and say I tried.

2006-10-15, 2:09 PM #27
*throws down :10bux: for Jon'C*

Edit: I agree with The_MAZZTer. Your code is confusing and uncommented.
Code to the left of him, code to the right of him, code in front of him compil'd and thundered. Programm'd at with shot and $SHELL. Boldly he typed and well. Into the jaws of C. Into the mouth of PERL. Debug'd the 0x258.
2006-10-15, 2:11 PM #28
Originally posted by Isuwen:
All that means is you're too retarded to understand it.
No, your code is just stupid. You're the one who posted it, you're the one who picked it (which I can only assume means it's the "best" sample you could come up with).

Quote:
Niether is your code. :)
Yes it is, because - as a message queue - only one thread can call either PushMessage or PopMessage. This functionality is enforced by a separate two-way IPC class.
2006-10-15, 2:17 PM #29
Oh, of course, because you can't wrap up an std::dequeue in exactly the same way.

I picked that code because I knew you wouldn't know a thing about boost::spirit, wouldn't understand what it does, and then I could throw your own comment back in your face.

Also, did you know that identifiers begining with an under score followed by a capital letter are reserved for the implementation?
Wikissassi sucks.
2006-10-15, 2:45 PM #30
Originally posted by Isuwen:
I picked that code because I knew you wouldn't know a thing about boost::spirit, wouldn't understand what it does, and then I could throw your own comment back in your face.


Ummm but this is a competition of whose code was EASIER to understand... :saddowns:

2006-10-15, 2:50 PM #31
:saddowns:

Seems to work now.
Code to the left of him, code to the right of him, code in front of him compil'd and thundered. Programm'd at with shot and $SHELL. Boldly he typed and well. Into the jaws of C. Into the mouth of PERL. Debug'd the 0x258.
2006-10-15, 3:07 PM #32
Originally posted by Isuwen:
Oh, of course, because you can't wrap up an std::dequeue in exactly the same way.
Of course you could. Naturally because STL containers do not have virtual destructors you couldn't inherit from dequeue, meaning it would literally be a wrapper.

Then you have a choice. Are you going to make the entire dequeue class volatile? Or you could pass your push/pop functions a volatile this pointer. Either way you just neutered your optimizing compiler.

Now, since you went to all of the effort of wrapping dequeue, you might as well expose some of the additional functionality you gain from using the STL container. So those get slapped inside of a critical section. But accessing the class while it's resizing is a horribly unsafe operation, so at that point you're stuffing the whole thing into a mutex.

Also, STL containers throw C++ exceptions in the case of critical errors (such as failure to allocate, full container, etc.)

Considering the fact that the actor model (and similar systems like a microkernel) already suffer a considerable amount of performance loss due to the IPC mechanism alone, and practically speaking I won't be able to use any of dequeue's features that might make wrapping it worthwhile, I think I'll stick with my design instead. Thanks though.

Quote:
I picked that code because I knew you wouldn't know a thing about boost::spirit, wouldn't understand what it does, and then I could throw your own comment back in your face.
Sith 2 uses exactly three common APIs and two extremely common utilities.
1.) OpenGL
2.) OpenAL
3.) DirectInput

4.) Flex
5.) Bison.

Everything else in Sith 2 is written in straight C++ using the STL. I'm not sure how referencing a library I'm admittedly unfamiliar with is supposed to prove when the code you're talking about doesn't use anything you shouldn't be familiar with, but alright.

Quote:
Also, did you know that identifiers begining with an under score followed by a capital letter are reserved for the implementation?
I do, but for the most part this is used to decorate the name of user-defined types so it is rarely (if ever) an issue. Since writing Sith 2 I've stopped using them, although Sith 2 only ever uses them as constructor arguments.
2006-10-15, 3:38 PM #33
Originally posted by Isuwen:
I picked that code because I knew you wouldn't know a thing about boost::spirit, wouldn't understand what it does, and then I could throw your own comment back in your face.


Does that mean I can ramble on about Euphoria or 68HC11 assembly and throw it back at you?

2006-10-15, 3:46 PM #34
Quote:
Of course you could....Thanks though.

All your code does is push and pop. And making the members volatile doesn't make them thread safe. You still have to serialize access to the queue. You lose absolutly nothing by serializing access to a dequeue instead.

Now, the real question is, are you still going to claim I don't know the language?
Wikissassi sucks.
2006-10-15, 3:49 PM #35
What's wrong with making your own Queue? It's not exactly a difficult data structure to make.
Code to the left of him, code to the right of him, code in front of him compil'd and thundered. Programm'd at with shot and $SHELL. Boldly he typed and well. Into the jaws of C. Into the mouth of PERL. Debug'd the 0x258.
2006-10-15, 3:55 PM #36
Originally posted by Isuwen:
All your code does is push and pop. And making the members volatile doesn't make them thread safe. You still have to serialize access to the queue. You lose absolutly nothing by serializing access to a dequeue instead.
Except because only one thread can ever read from the ring buffer, and only one thread can ever write to the ring buffer, you obtain something functional, fast and threadsafe without the use of mutexes or critical sections (which your suggestion would require).

Volatility guarantees that the optimizing compiler will not cache the variable. size_t on a x86 machine is 32-bit, and since you are guaranteed 32-bit granularity on x86 you are also guaranteed that the variable will not be accessed by any thread in the middle of a write.

Quote:
Now, the real question is, are you still going to claim I don't know the language?
No, but I am going to claim that you don't know how to read.
2006-10-15, 4:13 PM #37
Volatile doesn't change increment into an atomic operation. It's still read-modify-write.

There are better lock-free algorithms for this, that don't rely on a constant sized storage. Which also begs the question, why aren't you using a vector instead of a raw array?
Wikissassi sucks.
2006-10-15, 4:26 PM #38
Originally posted by Isuwen:
Volatile doesn't change increment into an atomic operation. It's still read-modify-write.
Wrong. Prefix incrementation is modify-read. In a language sense, anyway. Assembly-wise yes, but what does it matter? The 'modify' part is atomic and that's what this implementation requires.

Secondly, I never stated that volatile changes incrementation into an atomic operation. I stated that x86 guarantees that a 32-bit store is atomic.

Quote:
There are better lock-free algorithms for this, that don't rely on a constant sized storage. Which also begs the question, why aren't you using a vector instead of a raw array?
1.) Link me to one that is both better and does not suffer any performance loss.
2.) I only require constant-sized storage, which is why I did not add any storage-increasing features to it.
3.) For exactly the same reason I'm not using a std::dequeue. A vector would offer absolutely zero features that my implementation would require, it still offers no bounds-checking, most extra features would require mutual exclusion or critical sections, the rest of my implementation would be exactly the same, and if you map it out in memory a vector is an array. Using a vector would offer absolutely nothing and tack on a great deal of what, in this case, would be bloat.

You certainly seem to "know the language" (or else you are consulting friends who do), but you certainly don't seem to understand how to design code to fit criteria (such as run-time performance or implementation time). I'm guessing that the people who are helping you are computer scientists. Protip: Ask an engineer next time. They may not be smarter but they certainly are more wise.
2006-10-15, 4:48 PM #39
Quote:
Wrong. Prefix incrementation is modify-read.

No, prefix incrementation is read-modify-write. It must read that memory location into a register, than increment the register, then write that register back to memory. All volatile does is tell that compiler that that memory address might be written to by another process. It does not, and cannot, change the behavior of prefix increment.

Quote:
Using a vector would offer absolutely nothing and tack on a great deal of what, in this case, would be bloat.


Exactly two pointers of 'bloat'. Oh, also, it would make your constructor exception-safe.

Quote:
(such as run-time performance or implementation time)


The run time difference between a vector and a raw array is exactly nothing - unless, of course, you actually change it's size, in which case the vector will favor execution speed over memory usage.
The implementation time difference is, in this case, neglibible, as all you are doing is allocating and deleting it. Naturally, you wouldn't have to write a destructor at all if you used a vector. You certainly wasted time there.

Quote:
1.) Link me to one that is both better and does not suffer any performance loss.


You are using the algorithm described here http://www.ddj.com/dept/cpp/189401457?pgno=3

The biggest problem is the fixed-sized buffer. If you fill it, you're sunk.

This option can be implemented using any linear standard container. http://www.cs.rochester.edu/research/synchronization/pseudocode/queues.html
Wikissassi sucks.
2006-10-15, 5:02 PM #40
Jesus Christ you're thick. Okay, some of this might be stuff I've already said, because you can't read. At all. Whatsoever.

Originally posted by Isuwen:
No, prefix incrementation is read-modify-write. It must read that memory location into a register, than increment the register, then write that register back to memory.
Wrong. Prefix incrementation is modify-read. In a language sense, anyway. Assembly-wise yes, but what does it matter? The 'modify' part is atomic and that's what this implementation requires.

Quote:
All volatile does is tell that compiler that that memory address might be written to by another process. It does not, and cannot, change the behavior of prefix increment.
Secondly, I never stated that volatile changes incrementation into an atomic operation. I stated that x86 guarantees that a 32-bit store is atomic.

Quote:
Exactly two pointers of 'bloat'. Oh, also, it would make your constructor exception-safe.
I'm sure that would be important if I were using C++ exceptions or anything that can throw a C++ exception in this code.

Quote:
The run time difference between a vector and a raw array is exactly nothing - unless, of course, you actually change it's size, in which case the vector will favor execution speed over memory usage.
The implementation time difference is, in this case, neglibible, as all you are doing is allocating and deleting it. Naturally, you wouldn't have to write a destructor at all if you used a vector. You certainly wasted time there.
Sure, I'll give you the fact that it would be about the same implementation time. But what actual features would it offer me? Apart from resizing, which I have said repeatedly is of absolutely no use or consequence to me?

Oh right. Nothing. You're arguing this for the sake of arguing, even though you know you're wrong.

Quote:
You are using the algorithm described here http://www.ddj.com/dept/cpp/189401457?pgno=3
It's called a ring buffer and the algorithm is as old as dirt. It's described in many places, and I am neither the first nor the last person to implement it. It was invented by people much smarter than you and used by a person much smarter than you. Also that last person was named Jon`C.

Quote:
The biggest problem is the fixed-sized buffer. If you fill it, you're sunk.
No, really? It's sure a good thing you're here to tell me that, because I'm apparently stupid and never designed my code to return an error value in that case or anything. I definitely am not using my very simple high-speed ring buffer to route messages between variable-sized message queues or anything like that, because to do that I would have to realize that my fixed-size buffer can possibly become full.

Quote:
This option can be implemented using any linear standard container. http://www.cs.rochester.edu/research/synchronization/pseudocode/queues.html
...unfortunately, while that solution is "better", it is also slower.

Oh, and just in case you missed it, here is the rest of my post that you ignored completely. Possibly because you have no way to argue against it whatsoever.

2.) I only require constant-sized storage, which is why I did not add any storage-increasing features to it.
3.) For exactly the same reason I'm not using a std::dequeue. A vector would offer absolutely zero features that my implementation would require, it still offers no bounds-checking, most extra features would require mutual exclusion or critical sections, the rest of my implementation would be exactly the same, and if you map it out in memory a vector is an array. Using a vector would offer absolutely nothing and tack on a great deal of what, in this case, would be bloat.

You certainly seem to "know the language" (or else you are consulting friends who do), but you certainly don't seem to understand how to design code to fit criteria (such as run-time performance or implementation time). I'm guessing that the people who are helping you are computer scientists. Protip: Ask an engineer next time. They may not be smarter but they certainly are more wise.
12

↑ Up to the top!