sanityimpaired

My old textbook from NAIT was Learning C++: A Hand-On Approach, by Eric Nagler. I haven't looked at it in so long that I can't comment on how good it is, but there's the Amazon reviews might be helpful.

Mangos rev: 7398 Necrosis damage is properly applied after each auto-attack for a short while, and then starts giving the following error: "Necrosis failed. (Not enough mana)" Given that DK's do not use mana, this is very perplexing.

@Lighthouse: So this doesn't scale well with the number of players, then. I don't see any for loops and such, so what leads to it not scaling?

So the problem here is that a segment of the industry is pushing concepts which had a valid point historically but are no longer pertinent. I suspect this would be compounded by the fact that my employer was very tightly in bed with my academic institution; they recruited on-campus and hired a large portion of my graduating class. That gives me a great deal to think about. Thank you both!

@Vladimir: I noticed the returns for my second post, which is why I changed my question. @Freghar: In the example I gave, the type of organization you're describing isn't necessary. I can see how doing this makes code more modular, you can move pieces of it around and comment large pieces out without needing to redo any other code. It still rubs me the wrong way, though; I had it pounded into my head both in academia and in the workplace that multiple returns like this are only acceptible if the language doesn't support any other method - and in this case it does. Just to be clear, I'm not trying to be argumentative, I'm just having difficulty comparing what I'm seeing to how I've been trained.

That's exactly whatI mean, Balrok. After a little more digging, I noticed that many of these if statements actually use a return to end the function entirely, so the next if statement doesn't really matter. Which changes my question a bit. Consider the following snippet from EffectDummy() in SpellEffects.cpp, with most of the code cut out. switch(m_spellInfo->SpellFamilyName) { ... case SPELLFAMILY_WARRIOR: // Charge if(m_spellInfo->SpellFamilyFlags & 0x1 && m_spellInfo->SpellVisual[0] == 867) ... return; // Execute if(m_spellInfo->SpellFamilyFlags & 0x20000000) ... return; // Slam if(m_spellInfo->SpellFamilyFlags & 0x0000000000200000LL) ... return; switch(m_spellInfo->Id) { // Warrior's Wrath case 21977: ... return; // Last Stand case 12975: ... return; // Bloodthirst case 23881: ... return; } ... break; } So it works from an efficiency standpoint, but we've got multiple exit points everywhere, which goes against everything I've been taught about functional design. This whole thing could be done so much more elegantly as follows: switch(m_spellInfo->SpellFamilyName) { ... case SPELLFAMILY_WARRIOR: switch(m_spellInfo->Id) { // Warrior's Wrath case 21977: ... break; // Last Stand case 12975: ... break; // Bloodthirst case 23881: ... break; default: // Charge if(m_spellInfo->SpellFamilyFlags & 0x1 && m_spellInfo->SpellVisual[0] == 867) ... // Execute else if(m_spellInfo->SpellFamilyFlags & 0x20000000) ... // Slam else if(m_spellInfo->SpellFamilyFlags & 0x0000000000200000LL) ... } ... break; } So why are we doing the former rather than the latter?

There are many places within MaNGOS code in which we have an ID to compare against a list, typically using bit masks. Only one entry in the list is valid. Rather than using a series of else if statements so that the fucntion stops once it hits a positive, I am often seeing a chain of if statements, forcing the function to keep comparing bitmasks needlessly. A fantastic example of this is EffectDummy() in SpellEffects.cpp. Some clever use of case statements makes it less tedious, but even then the case statements usually run in addition to if statements. This seems to be fairly consistent, and it puzzles me. Wouldn't it be more efficient to use else if statements for every bit mask comparison after the first? Even better, if there's a case statement as well, wouldn't we be better off putting a chain of else if statements in the default case?