How would I go about comparing the tag to the user's name to see if it matches?

VB 6.0

Here is a more generic answer to match your question. Read up on your language’s string/character parsing libraries. Find a method/function/subroutine that will tell you whether or not a string contains another string. Then translate the following psuedocode into whatever language you are using, and everything should work.

[code]
IF username CONTAINS tag THEN
   SEND “/ban “ + username
[/code]

Keep in mind this is only a simple solution to tag bans. You could make it more useful and integrate wildcard matching.

Sorry for not posting language...I'll go engrave upon my screen.

Thnx for the help

VB: instr()
C++: strstr()

[quote author=indulgence link=board=17;threadid=1555;start=0#msg11726 date=1054928320]
C++: strstr()
[/quote]

Correction:

C: strstr()
C++: basic_string::find()

[quote author=Yoni link=board=17;threadid=1555;start=0#msg11731 date=1054931231]
[quote author=indulgence link=board=17;threadid=1555;start=0#msg11726 date=1054928320]
C++: strstr()
[/quote]

Correction:

C: strstr()
C++: basic_string::find()
[/quote]

you can use strstr in c++

[quote]
you can use strstr in c++
[/quote]

C++ allows you to use it to provide backwards compatibility with C. Just because you can do something doesn't mean you should. So pick a language and use it's functions.

[quote author=Tuberload link=board=17;threadid=1555;start=0#msg11740 date=1054935181]
[quote]
you can use strstr in c++
[/quote]

C++ allows you to use it to provide backwards compatibility with C. Just because you can do something doesn't mean you should. So pick a language and use it's functions.
[/quote]

i would hardly call that backwards compatibility. the only difference between c and c++ from a compiler standpoint is the existance of classes (which are the same thing as structs but they can have functions in them). everything else is just operators that could, in theory, be modified to work in c.

imo, c++ is crap. if you dont like pointers, dont use c. it's that simple.

[quote author=Yoni link=board=17;threadid=1555;start=0#msg11731 date=1054931231]
[quote author=indulgence link=board=17;threadid=1555;start=0#msg11726 date=1054928320]
C++: strstr()
[/quote]

Correction:

C: strstr()
C++: basic_string::find()
[/quote]

That sort of thinking is the reason for a lot of the bloat in today's software. Sure, you can buy the state of the art machine with 1TB of memory to run a program written with all the bloat. Or you can get an old system and run it with 64MB if it were written with resource limits in mind. Memory overhead for a string used in strstr: 1 byte. Overhead for a basic_string class: depends on the compiler but you can bet it's well over 16 bytes. That doesn't include the extra overhead in using the vtables. C++ can make life easier, but use the right thing for the job. If you want safer type-checking/bounds-checking, use some other language like BASIC, Java, or some scripting language. If you want power, use C. If you want the power of C with a few extra bells/whistles to make OOP easier, use C++. If you're not good with static strings or have to deal a lot with dynamic strings, use some string class. Classes can make life easier and easier to maintain (for strings, an example would be switching to Unicode instead of ASCII) but you do pay some price for it. Same thing applies with the bloated (though useful) iostream system (do most objects need to know how to print info about themselves? rarely. so why use that over something like fprintf?). The decision should be made based upon your needs, what code you currently have access to, the amount of time you have, and how comfortable you are with an API you have no/little control over. It shouldn't be made by some professor or book that said you shouldn't because it doesn't fit into the "C++" way of doing things.

[quote author=Camel link=board=17;threadid=1555;start=0#msg11754 date=1054942062]
imo, c++ is crap. if you dont like pointers, dont use c. it's that simple.
[/quote]

Depends on how you use it. Use it llike a better C and it's very powerful. Use it as strictly an OO language and adhering to the lame philosphy many professors/books try to impose on you all the time and other languages like Small Talk/Java look a lot better.

[quote author=herzog_zwei link=board=17;threadid=1555;start=0#msg11756 date=1054944250]That sort of thinking is the reason for a lot of the bloat in today's software. Sure, you can buy the state of the art machine with 1TB of memory to run a program written with all the bloat. Or you can get an old system and run it with 64MB if it were written with resource limits in mind. Memory overhead for a string used in strstr: 1 byte. Overhead for a basic_string class: depends on the compiler but you can bet it's well over 16 bytes. That doesn't include the extra overhead in using the vtables. C++ can make life easier, but use the right thing for the job. If you want safer type-checking/bounds-checking, use some other language like BASIC, Java, or some scripting language. If you want power, use C. If you want the power of C with a few extra bells/whistles to make OOP easier, use C++. If you're not good with static strings or have to deal a lot with dynamic strings, use some string class. Classes can make life easier and easier to maintain (for strings, an example would be switching to Unicode instead of ASCII) but you do pay some price for it. Same thing applies with the bloated (though useful) iostream system (do most objects need to know how to print info about themselves? rarely. so why use that over something like fprintf?). The decision should be made based upon your needs, what code you currently have access to, the amount of time you have, and how comfortable you are with an API you have no/little control over. It shouldn't be made by some professor or book that said you shouldn't because it doesn't fit into the "C++" way of doing things.[/quote]

+1 for flaming c++ in >3 sentances

[quote author=herzog_zwei link=board=17;threadid=1555;start=0#msg11756 date=1054944250]
Depends on how you use it. Use it llike a better C and it's very powerful. Use it as strictly an OO language and adhering to the lame philosphy many professors/books try to impose on you all the time and other languages like Small Talk/Java look a lot better.
[/quote]

a better c? the only thing that's useful at all is the ability of classes to have functions, and that can be used without violating *any* other of the definitions of c (not that there are any others).
as i said before, the only difference between c and c++ is overhead and classes. use classes, but dont use all that other iostream crap or whatever; it's a waste. printf is cooler than cout, anyways.

[quote author=Camel link=board=17;threadid=1555;start=0#msg11757 date=1054944546]
a better c? the only thing that's useful at all is the ability of classes to have functions, and that can be used without violating *any* other of the definitions of c (not that there are any others).
as i said before, the only difference between c and c++ is overhead and classes. use classes, but dont use all that other iostream crap or whatever; it's a waste. printf is cooler than cout, anyways.
[/quote]

Agreed. C++ is C with classes, polymorphism, (limited/broken) inheritance, and templates. Aside from polymorphism and templates, the other things can be done in standard C (take a look at X-Windows) but can leave room for lots of mistakes (or you can consider that a "feature"). Most of the C++ libraries are crap and you should just use the C ones. You should write C++ programs with a OO C mindset instead of an OO C++ one. Even most built-in C++ RTTI implementations are bloated and not too useful; you should just write your own RTTI. C++ does have better exception handling (you can do that in C as well but not quite as well) but it's not that great and should be used sparingly due to overhead incurred in its use (even when exceptions aren't thrown). Templates are useful, but most of the time isn't needed (though a good application of it would be easy and almost effortless reference counting for objects). Polymorphism is useful and what makes the compiler know what function to use. Some forms of it can be done in OO C easily, but the one with the same name and varying arguments can't be done as easily (you can go out of your way and use variable args and extra logic to dispatch to the correct one, but why not just let the C++ compiler do it for your C code?). One very useful thing about C++ over C is its automatic calling of the destructor when an object falls out of scope (not to mention you can declare variables in places other than the beginning of a scope); this ability lets you do things like lock a critical section of code by declaring a lock object on the stack, which will unlock when the destructor is called. Example:

[code]
C++:
{
Lock _lock(mutex);
if(!a()) return;
if(!b()) return;
c();
}

C:
{
mutex.Lock();
if(!a()) { mutex.Unlock(); return; }
if(!b()) { mutex.Unlock(); return; }
c();
mutex.Unlock();
}

or better:
{
mutex.Lock();
if(!a()) goto done;
if(!b()) goto done;
c();
done:
mutex.Unlock();
}
[/code]

Anyone saying you should never use goto is an idiot and probably writes buggy code that doesn't handle errors well (or quickly if they use exceptions). Goto has its uses but it shouldn't be abused when it's not needed. In the latter case, it's being used as a common exit point for the function (that handles resource cleanup) when errors occur (which sometimes isn't as simple as a single line of code).

I'm left breathless.
I don't believe in Internet flaming, so I won't elaborate.

[quote author=Yoni link=board=17;threadid=1555;start=0#msg11764 date=1054947769]
I'm left breathless.
I don't believe in Internet flaming, so I won't elaborate.
[/quote]

I don't want this to sound like flame, but it'll probably be taken that way.

Since when did not agreeing with your philosphy become flaming? Flames have very low SNR and are generally attacks on individuals. Most of this thread contains good info from various people, though some of it is off topic. The way I see it is it's a debate that should be taken elsewhere if it wants to continue. Debates do not need to reach a definite conclusion but they do educate people and open them up to different POVs.

[quote author=herzog_zwei link=board=17;threadid=1555;start=0#msg11759 date=1054946453]
Agreed. C++ is C with classes, polymorphism, (limited/broken) inheritance, and templates. [/quote]

Hmm, you missed a few features: http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1047588051&id=1043284376

[quote author=herzog_zwei link=board=17;threadid=1555;start=0#msg11759
Anyone saying you should never use goto is an idiot and probably writes buggy code that doesn't handle errors well (or quickly if they use exceptions). Goto has its uses but it shouldn't be abused when it's not needed. In the latter case, it's being used as a common exit point for the function (that handles resource cleanup) when errors occur (which sometimes isn't as simple as a single line of code).

[quote][/quote]
uhh goto in C and most other languages with control structures is usually bad form, instead use statements like break and continue.

Actually, there are some very practical uses for goto that make code much cleaner and less repetitive.
[code]
int foo(void)
{
if( bar1() != SUCCESS ) goto FINISH;
if( bar2() != SUCCESS ) goto FINISH;
...

if( bar<n>() != SUCCESS ) goto FINISH;

<clean up stuff>

return SUCCESS;
FINISH:
<clean up stuff here>
return FAIL;
}
[/code]

Now, there are some major drawbacks to using goto and labels. The main one is variable instanciation. For instance, in C++, the following just doesn't work since the compiler has no idea how to handle the stack pushs and pulls.

[code]
int foo(void)
{
int bar1;

goto FINISH;

int bar2;
FINISH:

int bar3;
}
[/code]

[quote author=Yoni link=board=17;threadid=1555;start=0#msg11764 date=1054947769]
I'm left breathless.
I don't believe in Internet flaming, so I won't elaborate.
[/quote]

I, also, am left breathless.

Edit:

My god, just saw smoke's post. How can such idiocy have been advocated twice on the same post? Is this the final bullet in the head for the botdev forum?

[quote author=herzog_zwei link=board=17;threadid=1555;start=0#msg11756 date=1054944250]Sure, you can buy the state of the art machine with 1TB of memory to run a program written with all the bloat. Or you can get an old system and run it with 64MB if it were written with resource limits in mind. Memory overhead for a string used in strstr: 1 byte. Overhead for a basic_string class: depends on the compiler but you can bet it's well over 16 bytes. That doesn't include the extra overhead in using the vtables.[/quote]Don't forget processor overhead. People with old processors (*cough*) are usually left unheard when it comes to how inefficient a program is, simply because "Hey, it runs fast on our brand new machine, so it must be completely fast and efficient, right?"

There's more programs than I can count which run much slower on my machine than they should if the programmer actually took the time to test for older machines' run times; and these are small programs which shouldn't be processor intensive (For one prime example, a fricking text editor runs like shit, and a brand new IDE with almost the same exact features as the version before it runs literally 20x slower than the version before it!)

[quote author=Moonshine link=board=17;threadid=1555;start=0#msg11785 date=1054969015]
Hmm, you missed a few features: http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1047588051&id=1043284376
[/quote]

True, but that list is not complete either. The point is C++ extends C to make it easier/safer to do certain things.

[quote author=c0ol link=board=17;threadid=1555;start=15#msg11786 date=1054969473]
uhh goto in C and most other languages with control structures is usually bad form, instead use statements like break and continue.
[/quote]

If you're using goto when break/continue would suffice, you're abusing it. I am in no way advocating gotos over structure. What I am saying is there is a use for goto in good coding. Just to give you an idea of how often I use it, I'd say it's in less than 0.01% of all of my code. Don't use it often, but do realize that there is a time and place for it. FYI, there are even people that advocate not ever using break/continue since they are just hidden gotos and break the flow.

[quote author=smoke link=board=17;threadid=1555;start=15#msg11787 date=1054970147]
Now, there are some major drawbacks to using goto and labels. The main one is variable instanciation. For instance, in C++, the following just doesn't work since the compiler has no idea how to handle the stack pushs and pulls.

[/quote]

Yes, that is one of the drawbacks of C++'s ability to declare variables at use time instead of at the beginning of a scope. However, the compiler should catch that problem and tell you to fix it (which usually just means move the declaration up further).

[quote author=Arta[vL] link=board=17;threadid=1555;start=15#msg11791 date=1054975039]
My god, just saw smoke's post. How can such idiocy have been advocated twice on the same post? Is this the final bullet in the head for the botdev forum?
[/quote]

You might want to read this long reply by a famous person and ponder on why he doesn't think the same thing as you:

[code]
On Sun, 12 Jan 2003, Rob Wilkens wrote:
>
> However, I have always been taught, and have always believed that
> "goto"s are inherently evil. They are the creators of spaghetti code

No, you've been brainwashed by CS people who thought that Niklaus Wirth
actually knew what he was talking about. He didn't. He doesn't have a
frigging clue.

> (you start reading through the code to understand it (months or years
> after its written), and suddenly you jump to somewhere totally
> unrelated, and then jump somewhere else backwards, and it all gets ugly
> quickly). This makes later debugging of code total hell.

Any if-statement is a goto. As are all structured loops.

Ans sometimes structure is good. When it's good, you should use it.

And sometimes structure is _bad_, and gets into the way, and using a
"goto" is just much clearer.

For example, it is quite common to have conditionals THAT DO NOT NEST.

In which case you have two possibilities

- use goto, and be happy, since it doesn't enforce nesting

This makes the code _more_ readable, since the code just does what
the algorithm says it should do.

- duplicate the code, and rewrite it in a nesting form so that you can
use the structured jumps.

This often makes the code much LESS readable, harder to maintain,
and bigger.

The Pascal language is a prime example of the latter problem. Because it
doesn't have a "break" statement, loops in (traditional) Pascal end up
often looking like total shit, because you have to add totally arbitrary
logic to say "I'm done now".
[/code]

Who might the author be? Linus Torvalds, of course. Scan through the Linux source code and you'll find a few gotos. I haven't looked through all of it but if Linus did his job right, the gotos he allows aren't very abusive and lead to much cleaner/easier to read code (not to mention it'd run faster since there's less code to read in, execute, and cache). I don't think anyone would agree with all of Linus' views, but few would doubt that he's sharp and tends to make good judgement calls... not to mention he's the maintainer of a very big project spanning continents and many different developers with different coding styles/philosophies.

http://www.elegant-software.com/software/punditry/linus.html

If that doesn't get you out of the goto brainwashing, O'Reilly's "Linux Device Drivers" book even mentions that it is okay to use:

[code]

Error recovery is sometimes best handled with the goto statement. We normally hate to use goto, but in our opinion this is one situation (well, the only situation) where it is useful. In the kernel, goto is often used as shown here to deal with errors.

...

This code attempts to register three (fictitious) facilities. The goto statement is used in case of failure to cause the unregistration of only the facilities that had been successfully registered before things went bad.

Another option, requiring no hairy goto statements, is keeping track of what has been successfully registered and calling cleanup_module in case of any error. The cleanup function will only unroll the steps that have been successfully accomplished. This alternative, however, requires more code and more CPU time, so in fast paths you'll still resort to goto as the best error-recovery tool.
[/code]

http://www.xml.com/ldd/chapter/book/ch02.html#buierr

That's not what you said in your original post...

I will agree, tentatively, that it might sometimes be ok to use goto in a situation where conditionals don't nest, maybe, but even in that situation nesting is often advantageous in terms of clarity, since it's much more obvious what code will execute when - it's similar to the theory behind layered architectures such as OSI. That's not to mention the fact that gotos can also be nested, intentionally or otherwise, which is immeasurably worse than nesting IFs.

Anyway, this was your original post...

[quote]

C:
{
mutex.Lock();
if(!a()) { mutex.Unlock(); return; }
if(!b()) { mutex.Unlock(); return; }
c();
mutex.Unlock();
}

or better:
{
mutex.Lock();
if(!a()) goto done;
if(!b()) goto done;
c();
done:
mutex.Unlock();
}


[/quote]

...which is just horrific and is is an example of exactly when NOT to use goto (Aside from never, obviously).

I'll overlook the fact that you're apparently using a class in C and assume that was a typo. Both of those code snippets are very badly coded and would be better written thus:

[quote]
{
mutex.Lock();
if(a() && b()){
c();
}

mutex.Unlock();
return;
}
[quote]

In the huge, immeasurably vast number of cases, goto is simply an excuse for bad logic.[/quote][/quote]

[quote author=herzog_zwei link=board=17;threadid=1555;start=0#msg11759 date=1054946453]
Anyone saying you should never use goto is an idiot and probably writes buggy code that doesn't handle errors well (or quickly if they use exceptions). Goto has its uses but it shouldn't be abused when it's not needed. In the latter case, it's being used as a common exit point for the function (that handles resource cleanup) when errors occur (which sometimes isn't as simple as a single line of code).
[/quote]

+1 for using goto
the reason goto is so taboo is because it's possible to jump to a different function or position in code and crash because the registers aren't all set to what they should be (any half decent compiler will never allow this to happen, though)

[quote author=Arta[vL] link=board=17;threadid=1555;start=15#msg11807 date=1054991298]
I'll overlook the fact that you're apparently using a class in C and assume that was a typo. Both of those code snippets are very badly coded and would be better written thus:

[/quote]

I see what you're complaining about now. That example was just some quick thing I came up with to show one advantage of using C++ to handle something like automatic unlocking versus C++ in a C manner. The goto thing was just an afterthought. Anyway, if it were in pure C, just replace mutex.Lock() with with lock(&mutex) and mutex.Unlock() with unlock(&mutex).

As an example for using goto, it is incomplete and bad. I didn't want to spend time writing up lots of code but basically the intention was that the if(a()) is followed by other code and then the if(b()) followed by some other ones, thereby you won't be able to optimize it with a simple if(a() && b()). If you want a better example, I'll take a more complete one from O'Reilly that looks closer to a real example. It's specifically written in C.

[code]
int init_module(void)
{
int err;

/* registration takes a pointer and a name */
err = register_this(ptr1, "skull");
if (err) goto fail_this;
err = register_that(ptr2, "skull");
if (err) goto fail_that;
err = register_those(ptr3, "skull");
if (err) goto fail_those;

return 0; /* success */

fail_those: unregister_that(ptr2, "skull");
fail_that: unregister_this(ptr1, "skull");
fail_this: return err; /* propagate the error */
}
[/code]

You can't optimize that into a single if() any more and you can certainly do it w/o using goto, but how much more code are you willing to add and how much time are you willing to spend maintaining the code if you needed more complicated deinitializers?

Linus even thinks it's okay to split up a long if line into multiple ifs if it gets too long. Instead of:
[code]
if(a && b && c && d)
doSomething
[/code]

or:
[code]
if(a)
if(b)
if(c)
if(d)
doSomething
[/code]

(where the if's can't be optimized for some reason), he'd rather see:
[code]
if(!a || !b) goto next;
if(b && c)
doSomething
next:
[/code]

This is assuming that a, b, c, d are long names and not something cryptic like a 1 letter function/variable name and doSomething isn't just a 1 liner. His reasoning is it's easier to comprehend if you don't need to scroll/wrap. I've never done that even with long ifs in my code, but I have no problems with it.

If it were written in C++, the alternative to using goto in some cases would be to use exceptions. If speed/size were an issue, you wouldn't want to use exceptions. Exceptions are rarely (maybe even never) faster and incur lots of overhead (compared to checking error codes) per try. Checking for errors with ifs (which you still need to do with exceptions, but you won't need as many) is still cheaper than setting up the stack for a try and unwinding it when there's an exception thrown. I revisited it last year to see if it was feasible to use last year (after reading that they've figured out how to implement exceptions with negligible overhead) and it was still a noticeable difference under both Linux and Windows. I don't remember the exact details any more but it was something like: things they said you should do to incur less overhead (like declaring functions as nothrow if they don't throw exceptions) didn't seem to make any difference, while trying made some impact and throwing made a huge impact.

Like Linus, I don't really see what the big fuss is about when people that advocate the use of break/continue cry when other people use of goto. break/continue are just goto statements with a different name, but with less room for mistakes since it uses implicit labels/goto addresses. All conditionals are also gotos (try writing a program in Assembly without using any branches). The deciding factor should be which to use to make it clear (to you as well as others). People don't have time to audit every line of code written by someone else so they skim it. If they see a break/continue, they know what to expect. If they see goto deinit, they know what to expect. If you repeatedly make code do a, b, c because you want "structure", they'll expect it to always say it'll do a, b, c and won't catch the bug where you made it do a, b or a, b, c, d because they'll just assume it's another one of those repetitive snippits. The overall factor should be readability/maintainability, not complete adherence to an old paradigm that's good for most cases but not all (and thought up of during the times when, as Camel pointed out, compilers sucked).

Religion has no place in computer science.

Belief that goto is always bad and should never be used is based on what you were taught.

Especially those people in college (or high school) courses should beware they are repeating the gospel of their professors. Do it for the final exams but, later, do try to deprogram.

If Linus thought it was a good idea to go skydiving without a parachute and drink arsenic shooters, would you do it to?

That is an example of good goto use, I agree, but situations like that don't occur often. Not for me, anyway.

[quote author=herzog_zwei link=board=17;threadid=1555;start=0#msg11759 date=1054946453]
[quote author=Camel link=board=17;threadid=1555;start=0#msg11757 date=1054944546]
a better c? the only thing that's useful at all is the ability of classes to have functions, and that can be used without violating *any* other of the definitions of c (not that there are any others).
as i said before, the only difference between c and c++ is overhead and classes. use classes, but dont use all that other iostream crap or whatever; it's a waste. printf is cooler than cout, anyways.
[/quote]

Agreed. C++ is C with classes, polymorphism, (limited/broken) inheritance, and templates. Aside from polymorphism and templates, the other things can be done in standard C (take a look at X-Windows) but can leave room for lots of mistakes (or you can consider that a "feature"). Most of the C++ libraries are crap and you should just use the C ones. You should write C++ programs with a OO C mindset instead of an OO C++ one. Even most built-in C++ RTTI implementations are bloated and not too useful; you should just write your own RTTI. C++ does have better exception handling (you can do that in C as well but not quite as well) but it's not that great and should be used sparingly due to overhead incurred in its use (even when exceptions aren't thrown). Templates are useful, but most of the time isn't needed (though a good application of it would be easy and almost effortless reference counting for objects). Polymorphism is useful and what makes the compiler know what function to use. Some forms of it can be done in OO C easily, but the one with the same name and varying arguments can't be done as easily (you can go out of your way and use variable args and extra logic to dispatch to the correct one, but why not just let the C++ compiler do it for your C code?). One very useful thing about C++ over C is its automatic calling of the destructor when an object falls out of scope (not to mention you can declare variables in places other than the beginning of a scope); this ability lets you do things like lock a critical section of code by declaring a lock object on the stack, which will unlock when the destructor is called. Example:

[code]
C++:
{
Lock _lock(mutex);
if(!a()) return;
if(!b()) return;
c();
}

C:
{
mutex.Lock();
if(!a()) { mutex.Unlock(); return; }
if(!b()) { mutex.Unlock(); return; }
c();
mutex.Unlock();
}

or better:
{
mutex.Lock();
if(!a()) goto done;
if(!b()) goto done;
c();
done:
mutex.Unlock();
}
[/code]

Anyone saying you should never use goto is an idiot and probably writes buggy code that doesn't handle errors well (or quickly if they use exceptions). Goto has its uses but it shouldn't be abused when it's not needed. In the latter case, it's being used as a common exit point for the function (that handles resource cleanup) when errors occur (which sometimes isn't as simple as a single line of code).

[/quote]

I really think you're missing the point of C++. It's a tool. It's job is to make it easier for you to write programs. Sure, you can write the same stuff in C, but so what? I don't know about you, but I'll take C++ over C for the simple reason that it makes writing and maintaining things significantly easier. Of course, there will be some lost efficiency for [u]some[/u] things - but with a good compiler, the vast majority of C++ features will operate just as fast, if not faster, than your C versions of them, and without all the lost productivity (read: lost money, in a professional programming environment) writing and debugging them.

I'm not saying everything about C++ is great and all, but on the whole, it's a good thing. My development software includes an efficient implementation of binary trees and linked lists, for instance - it saves me a great deal of time to be able to use these instead of writing my own (or copying and pasting code and making mistakes in the progress) for all of my programs. Furthermore, I don't have to worry about debugging these implementations, because I know they will work out of the box. No trying to make sure that there wasn't something I forgot to change in a copy-pasted linked list C "template" from another program, no long hours (read: lost money) spent tracking down subtle logic errors in sophisticated data structures such as associative arrays. Instead, I get to focus on writing the program, as opposed to rewriting the same thing over and over.

Furthermore, most of the compiler-supplied libraries will be geared specifically towards the platforms for which the compiler and linker are designed to build programs for. This means that, regardless of which platform you use, you can (or should) be able to expect good performance out of the standard libraries. Unless you want to write and optimize your own libraries to do the same thing for every platform you're writing code for (again, lost money in a real environment), it's highly possible that you might be losing performance by relying on your own implementations.

Now, I know it isn't a perfect world, and I know there are lots of C++ standard library implementations which are less than ideal - however, I strongly believe that many of your comments about C++ are unfounded and, in general, untrue. I mean, just because you can do something the hard way [u]doesn't mean that you SHOULD do something the hard way[/u]. There's [u]nothing wrong[/u] with using standard libraries and language features to save valuable development and debugging time. Being able to spend all the time you want on a program, optimizing away every single piece of it and reimplementing standard features with custom versions that run at the absolute maximum speed for your specific needs is [u]an unrealistic luxury[/u] in the "Real World" programming environment. The "Real World" places emphasis on things like: [u]Code readability and maintainability[/u] - C++ certainly has many features which can be used to make code look much nicer and be a whole lot easier to follow, if used properly, [u]short development cycles[/u] - getting your software out before the competition can earn you a lot of money, and [u]reliability[/u] - mistakes can be very costly, especially if you end up having to rewrite software for free for customers because you screwed something up - C++ [u]makes it easier[/u] to get it right the first time.

C and C++ both have their uses, but your bashing of it seems rather uninformed to the least. Hopefully I'll be able to at least communicate some of why I think C++ is a good language through this discussion, but flat out uncompromising disagreement doesn't help anyone learn.

[quote author=Moonshine link=board=17;threadid=1555;start=0#msg11785 date=1054969015]
[quote author=herzog_zwei link=board=17;threadid=1555;start=0#msg11759 date=1054946453]
Agreed. C++ is C with classes, polymorphism, (limited/broken) inheritance, and templates. [/quote]

Hmm, you missed a few features: http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1047588051&id=1043284376
[/quote]

Almost every one of those is directly based on the fact that classes were added (with the exception of inline)

[quote author=iago link=board=17;threadid=1555;start=15#msg11866 date=1055085797]
[quote author=Moonshine link=board=17;threadid=1555;start=0#msg11785 date=1054969015]
[quote author=herzog_zwei link=board=17;threadid=1555;start=0#msg11759 date=1054946453]
Agreed. C++ is C with classes, polymorphism, (limited/broken) inheritance, and templates. [/quote]

Hmm, you missed a few features: http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1047588051&id=1043284376
[/quote]

Almost every one of those is directly based on the fact that classes were added (with the exception of inline)
[/quote]

With the exception of inline? What about:

References
Templates
Default arguments
Function overloading
Namespaces
Exception handling
Run-time type identification
// comments
True const
Declarations as statements
Automatically typedef'd struct tags
Type safe linkage
new and delete
bool keyword
Safer and more robust casting

Edit: Let's not forget the invaluable STL library.

Skywing:
I never said you should never use C++. I think it's a good language as well. I generally choose to write in C++ with the extra bells/whistles over using C because of the things you pointed out. The point of the things I've been discussing is you should choose the right thing for the job, not because some professor/book said you should do it one and only one way. In order to do a good job of choosing the right thing (language/API/etc), you have to consider the strengths/weaknesses of that thing you're looking at, how much experience you have with it, how much time/resources you have, and most importantly, what would make it more manageable in the long run. I generally choose C++ because it's a better C that makes it easier for me to program using the OO paradigm with. I don't choose C++ because I think it's a good OO language (which it really sucks at compared to other OO languages like Java/Small Talk). If you choose C++ for every single thing you do, you're not picking the right thing for the job at hand. When you're starting out, that's fine because you want to learn. Once you get past that stage, you should open your mind and look at things from an intellectual's POV and not blindlessly follow the teachings of professors/books.

Moonshine:
That list is not very good considering one of the more important things C++ has is left out: polymorphism. It's what makes classes, same named functions, overloading, implicit casting, etc. work the way they do. Many of the things on the list is related to the things I mentioned, but not all of them.

[quote author=herzog_zwei link=board=17;threadid=1555;start=15#msg11890 date=1055115283]
Skywing:
I never said you should never use C++. I generally choose to write in C++ with the extra bells/whistles over using C because of the things you pointed out. The point of the things I've been discussing is you should choose the right thing for the job, not because some professor/book said you should do it one and only one way. In order to do a good job of choosing the right thing (language/API/etc), you have to consider the strengths/weaknesses of that thing you're looking at, how much experience you have with it, and how much time/resources you have, and most importantly, what would make it more manageable in the long run. I generally choose C++ because it's a better C that makes it easier for me to program using the OO paradigm with. I don't choose C++ because I think it's a good OO language (which it really sucks at compared to other OO languages like Java/Small Talk). If you choose C++ for every single thing you do, you're not picking the right thing for the job at hand. When you're starting out, that's fine because you want to learn. Once you get past that stage, you should open your mind and look at things from an intellectual's POV and not blindlessly follow the teachings of professors/books.

Moonshine:
That list is not very good considering one of the more important things C++ has is left out: polymorphism. It's what makes classes, same named functions, overloading, implicit casting, etc. work the way they do. Many of the things on the list is indirectly related to the things I mentioned, but not all of them.

[/quote]
I'm not blindly following teachers or books - as a matter of fact, I've had compatatively little "formal" education on the subject of C++; most of what I've learned I picked up on my own. I can certainly say from my own experience that C++ is successful, though; here's from the output of a project-stats dumper I made for a long-term (multi-year) project of mine, done almost entirely in C++:
[quote]372 source file(s), totalling 3534622 byte(s) and 116770 line(s) of code.[/quote]
I'd say 3.5MB of code (yes, a large portion of it is object oriented, and it is efficient according to my benchmarks) is more success than blindly following something unrealistic, wouldn't you?

Just for the record, this project also incorporates C and even some x86 assembler code too - but the majority of it is C++. I don't use C++ to the exclusion of other things; I've simply found that [u]for the vast majority of what I do[/u], it's the right tool for the job. That program would be significantly larger and would have taken a great deal more time to do if it was written in mostly C, considering how much it uses standard library features that C simply doesn't provide.

I wasn't saying you were blindlessly following the masses. The thread ended up with some people thinking you should never do certain things such as using strstr in C++ or using goto in C/C++. I was trying to point out that the world isn't just black and white and you should think for yourself, doing the thing you think is more correct. I myself have worked on such projects as well, incorporating multiple languages C/C++/Asm/Perl/custom languages/etc within the same project, with the majority being in C++ because it's the better language for most of the job.

[quote author=herzog_zwei link=board=17;threadid=1555;start=15#msg11890 date=1055115283]
Moonshine:
That list is not very good considering one of the more important things C++ has is left out: polymorphism. It's what makes classes, same named functions, overloading, implicit casting, etc. work the way they do. Many of the things on the list is related to the things I mentioned, but not all of them.

[/quote]

I left out polymorphism and class related features for a reason, read iago's post in which I was replying to.

I believe he was referring to the list at faq.cprogramming.com which doesn't explicitly list polymorphism, but I think is implied with the virtual function listing.

[quote author=Eibro link=board=17;threadid=1555;start=30#msg11907 date=1055127189]
I believe he was referring to the list at faq.cprogramming.com which doesn't explicitly list polymorphism, but I think is implied with the virtual function listing.
[/quote]

Yeah I was referring to that list. Polymorphism is what enables virtual functions to work. When you do something like ChildA->go(), ChildB->go(), and Parent->go(), the compiler (either at compile time or code added to handle it at run time) will know which to use due to polymorphism. It's the same thing that lets you use operators the way you do and what allows you to have the same name (with varying qualifiers or arguments) for multiple functons. Leaving out polymorphism from that list is leaving out one off the language's greater features.

I think Moon probably knows what polymorphism is ::)

Well, I gues this post has been productive for you all, but I'm still lost. Sorry it took me to get back on but I was gone.

Any help would still be appreciated! ;)
Thnx

[code]
if lcase(username) like (*azeroth) then
send "/ban " & username
endif
[/code]

Ok, & just change the *azeroth to the thing I get from taglist, thnx
That actually helped ____

lol, this could go down in the off-topic recordbooks

Conclusion: Everyone agrees that c++ should be avoided except when in cases of rebellion or invasion.
Err, was that Habeas Corpus...

[edit] i hope whoever decided to spell 'habeas' like that died a slow and painful death

[quote]Everyone agrees that c++ should be avoided except when in cases of rebellion or invasion[/quote]

replace("c++", "vb");

Oh by the way, I doubt you know what Habeas Corpus means, or what language it is in ;)

habeas corpus: some one is goes before a court to try & get out of imprisonment.

Such simple terms I use.

No, I meant its literal meaning and language

[quote author=DarkMinion link=board=17;threadid=1555;start=30#msg12882 date=1056503790]
Oh by the way, I doubt you know what Habeas Corpus means, or what language it is in ;)
[/quote]
enlighten me

[quote author=DarkMinion link=board=17;threadid=1555;start=30#msg12882 date=1056503790]replace("c++", "vb");[/quote]

don't you mean [code]Replace Code, vbCPlusPlus, vbVB[/code]? :P

delete [] vb;

memset(&DarkMinion, 0, sizeof(ego::huge));

Huge is static? Seems a little inflexible to me. :)

Camel = pot.kettle.black();

Try evaluating yourself first ;)

if(Camel < DarkMinion)
Camel->Seppuku();

Alrighty then, I've got it half way there....my problem is that the bot uses the taglist & compare entire name to it. If the entire name matches, only then will it ban the user upon entering.

Any help?
[code]
Public Function GetTags(ByVal strAccount As String) As Boolean
Dim found As Boolean
For DF = 1 To frmDB.TagBans.ListCount
If LCase(strAccount) Like LCase(frmDB.TagBans.List(DF)) Then
found = True
Exit For
Else
found = False
End If
Next DF
GetTags = found
End Function
[/code]
That's what I got.....& this is what is under Event_Join
[code]
If Commands.GetTags(strAccount) = True Then
Send "/ban " & strAccount & " TagBan"
BanCount = bancoun + 1
UpdateBanCount
End If
[/code]
I'm lookin' for a point in the right direction from here please.

Step 1: Option Explicit.

[quote author=Zakath link=board=17;threadid=1555;start=45#msg12975 date=1056593990]
Huge is static? Seems a little inflexible to me. :)
[/quote]It doesn't necessarily have to be static, it could be part of namespace ego :)

[quote author=Camel link=board=17;threadid=1555;start=45#msg13005 date=1056643204]
Step 1: Option Explicit.
[/quote]
?....What do I need to do in there?............& why?

If you're serious, then don't attempt a bot yet.

I have everything that I need declared already, I don't beleive I need an Option Explicit.

[quote author=CrAz3D link=board=17;threadid=1555;start=45#msg13067 date=1056721492]
I have everything that I need declared already, I don't beleive I need an Option Explicit.
[/quote]

I am a good driver, but I still wear a seatbelt!

[edit] Go in to vb options and do yourself two huge favors: 1) Turn on "require variable declaration;" this will automaticly add Option Explicit to new project files. 2) Set it to prompt you to save your work every time you start your app. It's a pain losing work, especially when SetTimer crashes vb. :(

[quote author=Eibro link=board=17;threadid=1555;start=45#msg13006 date=1056646657]It doesn't necessarily have to be static, it could be part of namespace ego :)[/quote]
+1 to Eibro for picking up on the namespace first. :)