1001010

intitializing a static member of a template class

Note to self: the format of static template class member is
template<class T> int Test<T>::s_counter = 0;

And don't I forget it!
(what I originally forgot was the <T> - D'oH!)

// testtemplate.cpp : Defines the entry point for the console application.
#include "stdafx.h"

template <class T>
class Test
{
public:
    static int s_counter;

    Test()
    {
        s_counter++;
    }

    ~Test()
    {
        s_counter--;
    }

    static int getInstanceCount()
    {
        return s_counter;
    }
};

template<class T> int Test<T>::s_counter = 0;

int main(int argc, char* argv[])
{
    Test<long> a,b,c,d,e,f,g[3];
    printf("InstanceCount: %d\n", Test<long>::getInstanceCount());
    return 0;
}

TODO: Find out if devstudio is stopped at a break point

I need to find a good book on dev studio scripting.

Maybe I haven't thought this all through yet, but what I think I want is something that will automatically set my "away" status text in messenger based upon events in DevStudio.

But why would you need that?

Well, just as when your status is "away" when the screen saver starts - it would nice to do the same when a break point hits or set it to "busy" when your typing in the editor.

In my scenario as soon as a break point was hit - the status would change to "Can't talk now - I'm in the debugger baby!!"

I know that nearly everything is scripted in DevStudio, there's got to be a way to monitor user / debugger events. I would hate to hack together some solution where I monitor the child processes of MSDEV.EXE and install a DirectInput global keyboard hook - and match up keyboard input to the active window.

Visitied Walla @ Blizzard for lunch

It took me a while - I got lost again.

{mockingly shakes fist} Damn you UC regents for moving streets around so that my car's GPS gets overly confused!

I was allowed in after being buzzed in through two separate doors. Since I signed an NDA & don't want to do another full cavity search I can't and don't really want to say anything. But I could possibly describe the office as what would happen if all the stuff from every trade show Blizzard ever went to, around the world, exploded in the old GameSpy Irvine office.

Things I dislike: Hard Coded IP Addresses

I seem to remember an incident or two where various game developers set the address of their master server to a specific IP address, rather than a DNS name.

Can you guess what happened to those games when that server was moved to a different IP?

DING DING DING DING DING DING! That's right - it all broke. Vana - tell our lucky player what s/he's won!

Well, if you're lucky (there are more than 100 servers, the game company is still in business, there is at least one person still working activly on the codebase, and management is willing to QA, support and publish it) they might release a patch. But only if you're lucky ;-)

But if you're unlucky - well... say hello to a new friend - the ulcer.

Things I dislike: Copy'n'Paste Comments

OK, I get it - you copied a function that did 75% of what you want to accomplish and updated it to do your evil bidding.

But why then did you keep the original function comment???

it would be as if you had the code....

// Sometimes we need have someone else multiply radius by two
bool getDiameterFromRadius(float radius, double & rDiameter) { ... }

And somebody copied the function to do something else....

// Sometimes we need have someone else multiply radius by two
bool getCircumferenceFromRadius(float radius, double & rCircumference) { ... }

AND LEFT THE SAME COMMENT IN PLACE.

.ugh.

Things I dislike: Hard-coded variable menu items

Hmm, that's not the best title - but maybe a contrived code sample or two will help out in explaining why sometimes I weep when I look at certain bits of code.

Imagine if you would, creating a context menu with a few dynamic elements without IDs

menu->append("Hello");
menu->append("This");
menu->append("is a");
menu->append("Test");

And you responded to the elements not by an ID number, but by a position index.

switch(selectedIndex):
{
    case 0: doHello(); break;
    case 1: doThis();  break;
    case 2: doIsA();   break;
    case 3: doTest();  break;
}

And then when you look at the code that creates the menu item with greater scrutiny, you notice it's not as simple as you once thought...

menu->append("Hello");
if(hasPermission(SECURITY_RIGHTS_THIS))
    menu->append("This");
menu->append("is a");
menu->append("Test");

That's why I wept.
If an unlucky user doesn't have SECURITY_RIGHTS_THIS all the following menu items will be off by one!
This isn't a hard coded COM interface contract, but it IS a handshake usage contract that a future maintenance programmer (such as myself) may not even be aware of!

So here's a simple solution (if you can't change it to use proper IDs because it would effect to many systems):
Keep a table of what menu items were added and their appended menu index. Maybe something along the lines of

enum PossibleMenuItems { pmiHello, pmiThis, pmiIsA, pmiTest, pmi_MAX };
typedef map<int, PossibleMenuItems> IndexToMenuItem;
IndexToMenuItem m_IndexToCommand;
...
int nMenuIndex = 0;
// For each item you add, append it AND record it...
menu->append("Hello");
m_IndexToCommand[nMenuIndex++] = pmiHello;

if(hasPermission(SECURITY_RIGHTS_THIS))
{
    menu->append("This");
    m_IndexToCommand[nMenuIndex++] = pmiThis;
}
...

Then in the menu handler...

IndexToMenuItem::iterator itFind = m_IndexToCommand.find(selectedIndex);
if( itFind != m_IndexToCommand.end() )
{
  switch( (*itFind) )
  {
    case pmiHello: doHello(); break;
    case pmiThis:  doThis();  break;
    case pmiIsA:   doIsA();   break;
    case pmiTest:  doTest();  break;
  }
}

Now it no longer matters if an item is not added to the menu. As long as the table is updated - I'm happy.