Thread: Bit fields and hex

  1. #16
    Registered User
    Join Date
    Sep 2014
    Posts
    26
    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?
    Last edited by MeNeedsHelp; 09-26-2014 at 12:42 PM.

  2. #17
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by MeNeedsHelp View Post
    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.

    Quote Originally Posted by MeNeedsHelp View Post
    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.
    Last edited by Elkvis; 09-26-2014 at 12:51 PM.
    What can this strange device be?
    When I touch it, it gives forth a sound
    It's got wires that vibrate and give music
    What can this thing be that I found?

  3. #18
    Registered User
    Join Date
    Sep 2014
    Posts
    26
    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?

  4. #19
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    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++?
    Last edited by MutantJohn; 09-26-2014 at 01:07 PM.

  5. #20
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by MeNeedsHelp View Post
    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.
    What can this strange device be?
    When I touch it, it gives forth a sound
    It's got wires that vibrate and give music
    What can this thing be that I found?

  6. #21
    Registered User
    Join Date
    Sep 2014
    Posts
    26
    All right, thank you for all the help.

    (I won't be asking any more questions here, so the thread can be locked.)

  7. #22
    Registered User Alpo's Avatar
    Join Date
    Apr 2014
    Posts
    877
    Quote Originally Posted by MeNeedsHelp View Post
    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
       }
    Last edited by Alpo; 09-26-2014 at 02:10 PM.
    WndProc = (2[b] || !(2[b])) ? SufferNobly : TakeArms;

  8. #23
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,360
    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))
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Bit-Fields in C.
    By Mr.Lnx in forum C Programming
    Replies: 5
    Last Post: 06-29-2014, 07:22 AM
  2. Bit fields
    By juice in forum C Programming
    Replies: 7
    Last Post: 12-13-2011, 08:38 AM
  3. Bit fields
    By Edelweiss in forum C Programming
    Replies: 5
    Last Post: 08-23-2011, 10:01 AM
  4. bit fields before non-bit fields . . .
    By dwks in forum C Programming
    Replies: 10
    Last Post: 10-13-2005, 02:36 AM
  5. Bit fields
    By GaPe in forum C Programming
    Replies: 8
    Last Post: 01-22-2002, 02:01 PM

Tags for this Thread