NULL Pointer Works ?!?

If it's not virtual in anyway and it doesn't use any class members, you MIGHT be able to get away with it on some compilers.

C-Junkie is right - I leanred this from a post I had. If you have non-virtual functions - you are allowed to access and use them as long as they do not mmodify any class data.

ie:

I guess that function you are calling is a static function that does not modify or access non-static data.

just remember, the whole essence of C/C++ is that the langauge does no run-time checking whatsoever, for anything ...

so the only times using bad addresses (including null) actually ends up revealing itself is when you actually do something such as read from memory the OS doesn't give you rights to, or write to memory that screws something up ...

what happens when you call a member function is like this:

myObject->Foo(arg1);

is the same as non member function:

Foo(myObject, arg1);

so nothing bad happens unless you actually USE myObject to do something that you aren't allowed to do with a bad/null pointer.

Foo(0, 0) is not wrong ... but if inside foo you did this:

Foo(arg1)
{
someMemberVariable = 5;
}

then you would be trying to write to some piece of memory right near 0 ... which is almost definately going to cause a segment violation on any modern OS.

Quote:

Original post by Drew_Benton If you have non-virtual functions - you are allowed to access and use them as long as they do not mmodify any class data.

Actually, you are not allowed to. Non-static member functions can only be called when the this pointer resolves to an instance of the type or an instance of the derived type. Using a null pointer or pointer with an uninitialzied value, etc. has strictly undefined results by the standard (9.3.1 subsection 1). Even though it will often work, it also may potentially not work on a compliant compiler.

Quote:

If a nonstatic member function of a class X is called for an object that is not of type X, or of a type derived from X, the behavior is undefined.

Since a null pointer doesn't point to an object at all, let alone to an instance of X or a child of X, the behavior is undefined.

So in other words, don't ever do it.

As long as 'Enter' is a static method then you're simply passing NULL for the 'this' pointer (the implicit first parameter), which is why it is working for you.
Don't do this - It is bad in so many ways.

Bah, it's very useful [to me anyways] and I've seen it work on about 3 different compilers on 5 different platforms.

And as others have mentioned, if worse comes to worst it's a few find/replaces to make class->func(stuff) into func(class,stuff) [which of course violates some sort of orginizational mandate so don't mention that either]

[kidding!]

Quote:

And as others have mentioned, if worse comes to worst it's a few find/replaces to make class->func(stuff) into func(class,stuff) [which of course violates some sort of orginizational mandate so don't mention that either]

Actually, I used to think that way too. But, I recently read an article (wish I remembered the url, I found it in the forums) that showed it was actually better design to implement a function as a non-member function if it could be implemented reasonably without access to the class's private data members. So, func(class, stuff) is actually preferred, (at least according to this article, which seemed credible). It improved the encapsulation of the class by allowing fewer functions to access the private interface of the class.

Quote:

Original post by Telastyn Bah, it's very useful [to me anyways] and I've seen it work on about 3 different compilers on 5 different platforms.

class CStateManager{protected:    CMenuState* m_menustate;public:    static void EnterMenuState();};

I'm not sure if this makes access through void pointer legal, but it will be more likely to work, and it will then cause errors if you try to access non-static member variables or functions. Aka, if you try and do this:

void CStateManager::EnterMenuState( void ){    m_menustate = new CMenuState; //ERROR: using nonstatic member from static member function.}

your code won't go all fubar on you. If you later want to use nonstatic member data, you'll have horribly broken your useage anyways, and instead of attempting to debug what is causing your program to access near-0 memory, you'll be told right away that - oh guess what - naughty naughty, you've planned your code badly.

Quote:

And as others have mentioned, if worse comes to worst it's a few find/replaces

... assuming your program only uses the code in a few places, which would for large projects hint that it's only 1 of many classes probably programmed in similar manner, which will add up. Better to plan right from the start so things don't go haywire.

any non-virtual function which doesn't need access to instance variables, nor used the this pointer should NOT ever be an instance function - that would just be stupid, passing an extra instance pointer to the function for absolutely no reason ... if you wrote a function like this:

void foo(Object *placeHolder, int x, int y)

void foo(Object *, int x, int y)
{
}

people would ask you, why the hell are you passing an object pointer when you aren't using it? (and for those who don't know, not giving the variable a name in the implementation is how you let the compiler know you actual MEAN not to be using it. And it doesn't generate that stupid, is not used warning)

so once again, a non-virtual member function that doesn't use instance variables or the this pointer should either be static, or not a member at all.

Quote:

Original post by iMalc As long as 'Enter' is a static method then you're simply passing NULL for the 'this' pointer (the implicit first parameter), which is why it is working for you.

Static methods have no 'this' pointer at all.