Probably a quick and trivial question

**Epy** · 10-07-2009

Something I've always wondered is at what point one of the two methods becomes more efficient: casting a value whenever needed, or casting that value once to a new variable.

I.e., I need the double value of of an int a few times, should I cast it once (double x_f = (double)x

or cast it where needed (even if it's not going to change) ((double)x). I think for ints and doubles, the answer is to cast it to a new variable and use the variable, but what if the two different cases are likely the same, i.e. size_t and unsigned int? What would you do?

I know this is a trivial question, but I like to learn the most efficient way of doing things.

**MK27** · 10-07-2009

I think casting is actually "completely" efficient in the sense that it is dealt with at compile time, ie, there is no runtime expense. Hopefully someone will correct me if I'm wrong. Actually that can't be true. Hmmm.

**Epy** · 10-07-2009

I just don't know enough about computers to judge the time it takes to retrieve a value from memory that may or may not be a part of the local stack vs. casting another variable whenever needed.

**laserlight** · 10-07-2009

Originally Posted by MK27

I think casting is actually "completely" efficient in the sense that it is dealt with at compile time, ie, there is no runtime expense. Hopefully someone will correct me if I'm wrong.

From what I understand, unless you are casting a constant, whether there is a run time cost associated with a cast depends on the cast.

**Epy** · 10-07-2009

So if this is something that I initialize at the beginning of int main(), and I cast it throughout the program, the compiler will take care of it (as long as nothing else touches that first variable)?

i.e.

Code:

int main() {
int x = 5;
...
(float)x
...
(float)x
...
return 0;
}

The compiler will replace those (float)x's as if they were preprocessor defines?

**tabstop** · 10-07-2009

Maybe those can be replaced, depending on how fancy your compiler gets. On a basic level, no, those can't be replaced at compile time.

**MK27** · 10-07-2009

Originally Posted by Epy

I just don't know enough about computers to judge the time it takes to retrieve a value from memory that may or may not be a part of the local stack vs. casting another variable whenever needed.

In any case, it is probably trivial. However, you could approach it like this:

Code:

for (i=0; i<strlen(whatever); i++)

That's a bad idea because now strlen is called everytime, so it is much better to use an extra variable assignment (presuming the strlen isn't going to change):

Code:

int x = strlen(whatever);
for (i=0; i<x; i++)

In other words, if you have a block or a loop or a function that is getting called hundreds of times with a cast in it that could be replaced with a single temp variable, then maybe it is worth it.

But pretty sure most casts are way less expensive than strlen() calls...I don't think you need to sweat about it too much.

**cyberfish** · 10-07-2009

Casting between signed and unsigned integers should be free, because their representation in memory is the same, just "interpreted" differently. That's if they are of the same size. If they aren't, there will be a cost associated with sign or zero extension.

**Epy** · 10-07-2009

Oh yeah, I understand that...no way would I want to do that in a loop. I'm just talking about calling a casted value maybe 5 or 6 times throughout the problem...it really is trivial...I just like to optimize the hell out of things. A bit of OCD, I'm afraid.

The curiosity came from using LISP, where you might call functions that point to certain positions in a list frequently (car, cdr, cadr, etc.) and have wondered what the cost of that is versus just setting something to a new variable.

Thread: Probably a quick and trivial question

Thread Tools

Search Thread

Display

Probably a quick and trivial question