I guess this is to stop the stack from being recreated every time you call the function. This would use more memory but be faster... is that the gist of it?

static int do_something ()

is only visible from the file it resides in. This is to hide the complexity of a library to the functions that are only callable by the user of the library. It is not to be secret, but to reduce the complexity of the interface, and eliminate the potential of a user calling a function that might mess things up.

static does a couple of things. As far as general variables and functions, bishop_pass is correct that your compiler will compile it with internal linkage and visible only inside the file that contains it.

When used in C++, paticularly in classes, it guarauntees that each instantiated object will share one and only one copy of that variable. If it is a function, then it guarauntees that it will only operate on static member data/functions within that class. i.e. Can''t call normal/virtual functions unless they are static as well.

YAP YFIO,
deadlinegrunt

In C++ especially static members and functions can be quite useful for doing certain things. For instance...

non-static function call:
CClassType instance;
instance->function();

static function call:
CClassType::function();

non-static variable reference:
CClassType instance;
instance->variable;

static variable reference:
CClassType::variable;

The usefulness here may not be immediately obvious, but it ends up being a very convenient way of implementing class-specific global data in a way that is perfectly acceptable under accepted C++ coding conventions (because we all know real global variables/functions are icky).

As an example, in my 3D rendering engine there is some data that really needs to be accessible from every class (Direct3D devices and such). The best way I could think of doing this was to put them all in a single class as static member variables and make a bunch of static functions to initialize and manipulate them. Sure the same could be achieved with global variables and functions, but it made the code much cleaner to localize them within a single class.

I think the main use, as bishop_pass said, is for data hiding.

For instance, in C++ this is done with a class:

class foo{
public:
func1();
private:
func2();
};

Here, func1 is accessible from anywhere, whereas func2 is only accessible by member functions of foo.

You can accomplish the same thing in C.

foo.c
=====
void func1(void){ /*blah*/ }
static void func2(void){ /*blah*/}


So in fact, using static, you can make C program in an object-oriented style. I think the only things you can''t really do is inheritance, and operator overloading. Both are overrated imho.

(Don''t get me wrong, I use C++ almost exclusively, and I use operator overloading in a few of my programs. I just think these features tend to be overused)

Inheritance is great -- if it makes sense. I think most of the time it''s used it doesn''t make sense (As in an overelaborate design. It may be logical, but it''s not simple). The simpler the program is, the more I like it. "If it doesn''t make it simpler, don''t use it". (Someone famous must have said that, it''s so obvious )

The reasons I use C++ are mostly because of the STL. I like strings inifintely better then char*, I like how I can avoid pointers (and thus segfaults), and I like how associative arrays (map<>), linked lists (list<>), and adjustable arrays (vector<>) are all there for me to use. I also like iostreams and string streams - they just make sense. (which isn''t to say the C way doesn''t, it just requires more code to do the same thing)


Whoa, i kinda got off topic there. oh well.

quote: Original post by gimp

I guess this is to stop the stack from being recreated every time you call the function. This would use more memory but be faster... is that the gist of it?

Thanks guys, that''s quite a bit different that what I expected. Now I have to work out why some example code I have from another coder has every function in the whole project statically defined(except main I think)...

I have another example workspace with classes where every class member is static. Hrmm... if it''s for data hiding and single instancing then I''d expect that you would want to using it sparingly rather than on absolutely everything...interesting I''ll have to look in to this.

Shame it cant be used for what I suggested though.. as in to stop the stack creation process, that would be pretty cool...

gimp

How would a function work without a stack?

I think most experienced developers would agree that for standard functions, the default scope should have been static instead of extern. That would have greatly helped in keeping programmers from polutting the global namespace. If you want a function to truly be global, you should have to make it so explicitly. But since that isn''t the way it works, you SHOULD see many standalone functions declared as static when reading code. Most programmers aren''t aware of this though.

As for having lots of items of a class be static, that is a little strange. Hopefully there is a reason.

Rock

"How would a function work without a stack?"
Actually I was suggesting that I''d like it if the stack was only ever created once for oft used functions so you wouldn''t have to pay the price each time...just a wish.(of course I could be missing the point, I never went to uni)

Ahhh... I think i get static use now. Global namespace. Got it.

The C++ keyword static means different things depending upon the context it is used in.

If a class method is used as a call-back function it needs to be static (i.e. no this*). Static methods can only access static properties (because there''s no this*).

What kind of class is it? What''s it do?

"Allocating" memory from the stack has less performance impact than accessing static variables, unless the data is large and/or has a complex initialization process (lpD3D7Device... transformation matrices, etc...)

//Local scope global
static func();

func()
{
//most intuitive use...
static int a;
}

class A
{
static long count;
static LRESULT CALLBACK WinProc(...);
}

//only one property accessible from all instances
long a::count = 0;

//this* not implicitly passed to function
LRESULT CALLBACK A::WinProc(...)
{
count++:
//...
}

Yeah, the stack allocation is darn quick. Omitting initialization of variables (constructors,.....), the only thing that really happens is that the stack pointer is incremented by the amount of memory the function needs for local variables (or decremented, I don''t keep track). It would be far slower to keep track of multiple stacks and to switch between them.

Rock