Thread: Bit fields and hex

Oh. I think I understand now, thank you (and sorry for taking up your time).

EDIT:

Slightly off-topic, but I don't really want to make a new thread just for this:
Performance-wise, what is the best way to do things?

Code:

// Alternative 1: #define
#define Multiply(a, b) (a * b)

// Alternative 2: function without return
void Multiply(unsigned long* a, unsigned long b)
{ (*a) *= b; }

// Alternative 3: function with return
unsigned long Multiply(unsigned long a, unsigned long b)
{ return (a * b); }

I don't know which one to use. I assume alternative 3 is the slowest, since (if I understand it correctly) it creates two new variables (a and b) and alternative 2 only creates one (b). So, by that logic, shouldn't the #define be the fastest, or am I misunderstanding something?

Originally Posted by MeNeedsHelp

I don't know which one to use.

Personally, I prefer to use a function-like macro only when a normal function is impractical or impossible.

Originally Posted by MeNeedsHelp

I assume alternative 3 is the slowest, since (if I understand it correctly) it creates two new variables (a and b) and alternative 2 only creates one (b). So, by that logic, shouldn't the #define be the fastest, or am I misunderstanding something?

You're not completely misunderstanding, but there's a lot of factors that go into this. Keep in mind that passing a pointer to an object is still a separate variable. Compilers are allowed to do just about whatever they like with the code, when optimizing, so long as it doesn't alter the output of the unoptimized program. With full optimization turned on, it's likely that alternative 2 and 3 would be just as fast as 1, with a good compiler. It would probably just inline such a simple function, and make it as if it did exactly what the macro does. Alternative 2 is not necessarily a good idea, especially if you don't want to modify either of the original values, but you want their product.

Changing stack frames (calling another function) isn't the problem. The problem is always branching. It's because the processor must wait for the condition to be resolved before more instructions are fed to it. If you want to improve performance, minimize your if-statements. However, it is impossible to do so the majority of the time or it is often not worth the effort involved vs the impact to performance.

There are things to mitigate this such as branch prediction but Lord forbid you miss.

What I'm saying is, you can evaluate if a bit is set or not just by using the & operator or any other operator. The performance hit comes from :

Code:

if (this_bit_is_set)
{
    /* ... */
}
else if (this_other_bit_is_set)
{
    /* ... *.
}
...

But if you're really worried about functions calls, doesn't C have the inline keyword? Or is that just C++?

Originally Posted by MeNeedsHelp

Even if I'm working with bits, is it fine to use a function to check if a bit is enabled? Wouldn't that slow the program down?

It can, but you should be more concerned with writing correct programs, and worry about speed after you have achieved the desired program behavior. In most cases, the overhead of a function call to test a bit isn't going to be sufficient to cause a noticeable impact on performance.

Originally Posted by MeNeedsHelp

Even if I'm working with bits, is it fine to use a function to check if a bit is enabled? Wouldn't that slow the program down?

I believe a function like macro would work for that (they use text replacement I think). Assuming the types are the same, something like:

Code:

#define CHECKFLAG(uiType, uFlags) ((uiType & uFlags) == uFlags) // Just have it evaluate to true/false

You would need to or( | ) the flags together when sending it to check.

Code:

   if( CHECKFLAGS( uType, FLAG1 | FLAG 4 ) )
   {
      ///   FLAG1 and FLAG4 are set
   }

If you do want to go with a function-style macro, then remember to add parentheses to force the precedence expected, e.g.,

Code:

#define Multiply(a, b) (a * b)

should be:

Code:

#define Multiply(a, b) ((a) * (b))