[code]#include <iostream>
#include <queue>

using namespace std;

int main(void)
{
queue < char * > BnetMsgQueue;
char *msg = "test1";
char buf[512];

sprintf(buf, "%s", msg);
BnetMsgQueue.push(buf);

msg = "test2";

sprintf(buf, "%s", msg);
BnetMsgQueue.push(buf);

while (!BnetMsgQueue.empty())
{
cout << BnetMsgQueue.front() << endl;
BnetMsgQueue.pop();
}

system("pause");
return 0;
}[/code]

This is just a small test program that to an extent shows how my queue system works in my bot (excluding the message splitting/pausing, etc.). The problem I am having is that when I push the variable buf onto the queue, it doesn't turn out to be what it should if I push it twice with different values. I assumed that if the variable buf was pushed onto the queue with the string "test1", when I go to pop it off (or print it/send it) it would be "test1" and when I push buf onto the queue again with a different value ("test2") when I go to pop it off it would be "test2". But when I push them onto the queue, and I go to pop them off (pushing buf onto the queue twice, each time with different values before popping them off) the values are both the same (the value of the last time I pushed buf onto the queue). Is there a way to get around this limitation?

It is not a limitation. Look what you're doing. Pushing the address of buf into the queue twice. Of course they are going to have the same value when you pop them off.

I kind of figured that. Hmm, I suppose you could push an std::string on there instead of a char *. :P

If you want to be really suave you could use a std::priority_queue and implement a comparision operator to push commands (like /kick /ban) above normal chat messages.

Just a thought ;)

[quote author=K link=board=30;threadid=8569;start=0#msg79172 date=1094421795]
If you want to be really suave you could use a std::priority_queue and implement a comparision operator to push commands (like /kick /ban) above normal chat messages.

Just a thought ;)
[/quote]

Well, I suppose that would be a nifty idea if it was a chat/moderation, but since it's just a console (and perhaps command line driven in the future), there's really no need for a priority queue implementing that logic. We wouldn't want .ban to have higher precedence over .say and besides, the say command would probably have been executed before the ban was put in the queue. :)