(First off, thanks to Arta, your articles are helpful )

I searched around in some posts to see if someone had answered it, my guess is yes but I can't find it and my internet keeps going out. Right now, I am just coming up with the theory of how to make a bot, then working it out and making it work. Right now I was questioning the safelist. I came up with two possible ways to do it but I am not sure which one would be effective.

First, is a list view effecitve? I was thinking about when you load the bot to add everyone in a file called Safelist and everytime you accessed the file the Listview would update then when someone tries to ban to check that listview

Second, an array. Same idea just using an array

Which way is more pratical?

I am guessing your using vB...

I would say an array.

Reading the file from start up and keeping it in a gloabal array might me more efficent. So...
(Pseudocode)
[code]
banuser(username)
if username = safelisted[any]
     donothing
else
     ban username
[/code]

If you were to add a person to the safelist while the bot is running (thru the bot), simply add the person to the array and when the bot is exiting, write the array to the file.

You could also have your bot update from the file every minute or so, and keep the ones added via the bot in a seperate array. Then when the bot closes, update the file, and check for any doubles.

heh yes im using vb sorry about that :)

thanks for answering my question :-D

Here's what I do which in a generic sense is more efficient than just creating a data structure dedicated to safe listed users.  Keep in mind I will demonstrate code examples in C++ but you should be able to convert it mentally into VB as you go along.

First, I have many structs that I use to hold data values.  On such is called DatabaseUserData and it has public members like username and flags (keep in mind this info is derived from the database not from dynamic Battle.net activities, that's for ChannelUserData).

I store all my database users into a data structure called a map (refer to STL -> std::map).  Each time I want to add a user I add it to my map after filling out a DatabaseUserData struct object.

Here's an example:
struct DatabaseUserData {
    std::string _username;
    ULONG _flags;
};

std::map<std::string, DatabaseUserData> DatabaseUserMap;

DatabaseUserData user;
user._username = "Mephisto";
user._flags = FLAG_A|FLAG_B|FLAG_C; // can add more flags if you want...
DatabaseUserMap["Mephisto"] = user; // added a user to the database which I can access with the key "Mephisto"

Now, when you want to check the safelist (probably to determine whether to kick/ban/ignore someone you can do something like this):
if(DatabaseUserMap[user]._flags & FLAG_S) { // mask out all their flags but S
    // take action resulting if the user is safelisted
} else if((DatabaseUserMap[user]._flags & FLAG_S) == 0) { // == is evaluated first, so we use parenthesis (and you could just use an else instead of an else if here)
    // ban target
}

Umm...why check that the user doesn't have S when you just barely checked if they DID have S? It's fairly plain that if you even get to the second conditional that they don't have the S flag, so why are you checking?

Also, unless the compiler is extremely smart, it's going to assemble that into multiple lookups of the flags.  You should instead retrieve the flags into a local variable and do all computations with that variable.

[quote author=Kp link=topic=10229.msg95825#msg95825 date=1106183111]
Also, unless the compiler is extremely smart, it's going to assemble that into multiple lookups of the flags. You should instead retrieve the flags into a local variable and do all computations with that variable.
[/quote]eww--! Compilers should *never* cache results from functions!! Suppose you do something that would cause a different result to be returned, even with the very exact same data being passed to it? For example, an encryption function that takes only the data to be encrypted and returns different results each time would either get the encryption key itself, or generate random data for the result. Regardless of whether or not the result is validly-encrypted (*cough*), the result is still different. Subsequent use of that data, if using cached data, would generate invalid data!

[quote author=tA-Kane link=topic=10229.msg95895#msg95895 date=1106249544]
eww--! Compilers should *never* cache results from functions!! Suppose you do something that would cause a different result to be returned, even with the very exact same data being passed to it? For example, an encryption function that takes only the data to be encrypted and returns different results each time would either get the encryption key itself, or generate random data for the result. Regardless of whether or not the result is validly-encrypted (*cough*), the result is still different. Subsequent use of that data, if using cached data, would generate invalid data!
[/quote]

That's why he said "extremely smart."

[quote author=dxoigmn link=topic=10229.msg95897#msg95897 date=1106249806]
[quote author=tA-Kane link=topic=10229.msg95895#msg95895 date=1106249544]
eww--! Compilers should *never* cache results from functions!! Suppose you do something that would cause a different result to be returned, even with the very exact same data being passed to it? For example, an encryption function that takes only the data to be encrypted and returns different results each time would either get the encryption key itself, or generate random data for the result. Regardless of whether or not the result is validly-encrypted (*cough*), the result is still different. Subsequent use of that data, if using cached data, would generate invalid data!
[/quote]

That's why he said "extremely smart."
[/quote]

So smart, in fact, that it knows how to code what the programmer meant, instead of what he said. :P

[quote author=tA-Kane link=topic=10229.msg95895#msg95895 date=1106249544][quote author=Kp link=topic=10229.msg95825#msg95825 date=1106183111]Also, unless the compiler is extremely smart, it's going to assemble that into multiple lookups of the flags. You should instead retrieve the flags into a local variable and do all computations with that variable.[/quote]eww--! Compilers should *never* cache results from functions!![/quote]

Of course they should.  However, it should be limited to functions which are marked as being pure or const.  That is, if the programmer notes that the function can safely be called fewer times than the code says, the compiler should take that hint and reduce the number of calls.  If you have a function which produces changing results, just don't mark it as pure.

I did the else if conditional for demonstration purposes.  Besides which, I don't see what's wrong with doing that anyways, seems to be more illustrative to and clearer to anyone else who would read the code, and I don't think it causes much overhead at all (or does it?).

As for not storing the flags into a local variable...I didn't know that you should do this.  I thought it was perfectly fine to retrieve it from the object each time you needed to access it.

[quote author=Mephisto link=topic=10229.msg95950#msg95950 date=1106264193]As for not storing the flags into a local variable...I didn't know that you should do this.  I thought it was perfectly fine to retrieve it from the object each time you needed to access it.[/quote]

From a correctness perspective, you're right.  The program should get the same answer whether you fetch to a local or keep requerying the data.  However, from a performance perspective, there's a potential hit if the query is expensive (which depends on how efficiently the STL you're using has implemented operator[], how big your map is, etc.).

Makes sense.  I'm not sure either; but I'm assuming since STL is specifically modified for performance, and with the compiler optimizations it should be as *good* as it can be.  :)

[quote author=Mephisto link=topic=10229.msg95966#msg95966 date=1106274877]Makes sense.  I'm not sure either; but I'm assuming since STL is specifically modified for performance, and with the compiler optimizations it should be as *good* as it can be.  :)[/quote]

As I recall, you use Microsoft's C compiler.  If so, it's not as good as it can be: afaik, it doesn't support the concept of a pure function, so the compiler cannot make the optimization I described.  The lookup may be fast, but it won't be optimized out.