Static member functions more efficient?

Hi guys, I'd really appreciate any help on some implementation details I'm not clear on.

I've been trying to get my head around how c++ class objects exist at runtime but I've not had much luck in pinning it down. The way I think it works is that a class object is like a lookup table with addresses of member functions and variables in it, or at least the object is a reference to that table.

One thing is I'm not sure on is if the table (if that's even the right thing to call it) is optimised at compile-time so some member functions - like the ones that don't access member variables - are just treated like standard functions and the finished program doesn't even know they are part of the class (so its object table is smaller). Does that happen? Can it?

So I stumbled on static member functions. I used to think they were only for manipulating static member variables, but now I'm not sure. Are they just standard functions that are effectively 'wrapped' in the class in source code only (making the class equivalent to a namespace for them).

Basically the question is (if you can't be bothered answering any of the others): should all my class functions that don't access member variables be declared static?

>> Basically the question is (if you can't be bothered answering any of the others): should all my class functions that don't access member variables be declared static?

Well, does it have any particular reason to be associated with the class if it isn't manipulating or using any of the instance fields?

You should read about these things. The first being ordinary member functions, the other being about virtual functions.

this keyword: http://www.codeguru.com/forum/showthread.php?t=343480
virtual functions: http://www.parashift.com/c++-faq-lit....html#faq-20.4

The static members I'm talking about are conceptually related to the class. For example, logOut could be a static member of class User, but doesn't need to access the User variables for now. That's a fair use for a static member then?

I think this answered my questions. I think, although any extra comments would be more than welcome.

Yes, this is the answer. Non-static member functions are implemented once for each class, not once for each instance. They operate on the correct data because the "this" pointer is passed automatically when you call a member function. A static member function is the same, except no "this" pointer is passed, since a static member function doesn't work on a particular instance of the class.

>> should all my class functions that don't access member variables be declared static?
That's not a bad idea. If your member function doesn't depend on the state of the instance variables, then making it static is a good choice. You can also make it a non-member function. Making it a static member allows you to control its scope (maybe you want only derived classes to be able to call it), and it couples the function to the class.

Quote:

---

Originally Posted by drrngrvy

I think this answered my questions. I think, although any extra comments would be more than welcome.

---

All I know is I don't like the 'tude on host Danny Kalev's face.

Quote:

---

Originally Posted by drrngrvy

The static members I'm talking about are conceptually related to the class. For example, logOut could be a static member of class User, but doesn't need to access the User variables for now. That's a fair use for a static member then?

---

You're rarely in the situation where the overhead of a member functions vs a static member function will be in any way significant. Thus, your primary concern in deciding whether a function should be static or not is one of design, not efficiency. Static members are those that affect the class as such, not an individual object.
logout(), for example, does not really affect a single user, so it should not be a non-static member of User. Whether the user is logged in is really a property of the session (whatever that is - could be a HTTP pseudo-session, for example), not of the User class at all, so I don't think it should be a static member of User either. You could put it into a Session class, or perhaps a UserDB class, which represents the collection of all users in the system.