Quote:Original post by SiCrane
1) For primitives allocating variables on the stack takes effectively no time at all, and using the static variable will probably not do good things to the cache. On the other hand, for classes with a non-primitive constructor it may save time, but again will still not be cache friendly. However, this falls firmly in the realm of micro-optimization. There are better things to concentrate your time on.

Right.
Imagine how the program lies in the memory.
Each process has its own address space.
This address space is mapped onto the virtual address space and this one is mapped onto the physical address space

The program is seperated into 4 sections

code segment: where the code lies
data segment: where all constants, static variables ... lie
heap segment: here are the dynamic allocated objects

stack segment: your program stack

Now in order to use the static variable you have to load its page from the data segment into the cache if it isn t there already.

Now dependent on your machine and its addressing operations you either copy the result of GetTime() directly to object's memory in the cache
or you need to load the content from the stack into a register and move it from the register into the cache.


And as already mention above multithreading will be a problem.
In general avoid static variables, they may lead to hidden bug sometimes, plus they lead the cache trashing if they aren t referenced very often. At least they waste space in the cache (4kb per page in general depending on your OS)

Quote:Original post by CyberSlag5k
Thanks for the additional info, guys.

And yeah, I meant I'd do something like this:

void idle()
{
static TimeObject time;
time = GetTime();
}

It's a waste of a default constructor call, of course, but that's of little consequence. It was a good thing to point out, however. I could see that causing some serious trouble were it to go unnoticed.

Wouldn't programming a copy constructor take care of this and eliminate the possible use of static?

void idle()
{
TimeObject time(GetTime());
}

Quote:Original post by wolverine

Wouldn't programming a copy constructor take care of this and eliminate the possible use of static?

void idle()
{
TimeObject time(GetTime());
}

Well that would work, and it would be the same thing semantically, but the point of the static was to avoid re-creating and dstroying the time variable every time the idle function is called. Unless I'm misunderstanding what you're saying, I don't believe that is done here.

Quote:Original post by CyberSlag5k

Quote:Original post by wolverine

Wouldn't programming a copy constructor take care of this and eliminate the possible use of static?

void idle()
{
TimeObject time(GetTime());
}

Well that would work, and it would be the same thing semantically, but the point of the static was to avoid re-creating and dstroying the time variable every time the idle function is called. Unless I'm misunderstanding what you're saying, I don't believe that is done here.

What i was thinking was only in saving a constructor call and avoid using static.

If you do want to avoid the price of having to pay the variable being constructed and destroyed in that function everytime you call it, then static will be of good use (being carefull with the multi-threaded issues pointed out) or to pass that variable as a private class member (although this last option looks kind of ugly to me).

Quote:Original post by Demus79

I didn't pay attention if anybody mentioned this, but if you declare your time as static, you must understand the consequences.

*** Source Snippet Removed ***

The code above won't do what the original code did. What'll happen is that the GetTime() is called only once during the program execution and that's not what you are after. Of course, it is rather simple to prevent this bug from occuring. Ie. to write the assignment to another line.

Just telling about my experiences with the static keyword and some hours spent on debugging :)

Cheers

This is not a bug, not according to the C++ Standard. However in your model of how things work it might be.