Thread: Common header file for multiple modules

  1. #16
    Registered User
    Join Date
    Mar 2011
    Posts
    596
    If one is going to use local macros in the .c module, where does the discipline need to placed?
    Is it in being cognizant of the scope of the definitions?
    Or in the names of the definitions, making them all unique?

    If one is cognizant of the scope, the the names should not matter.
    If the names are unique, the scope should not matter.

    -

  2. #17
    Registered User
    Join Date
    Mar 2011
    Posts
    596
    Quote Originally Posted by grumpy View Post
    You're using the same macro name, but with a different expansion (value) in different translation units?

    It is a potential problem if two translation units interact (for example, one calls functions in the other) and each has that macro with a different value. Another way is if a person updates the expansion in one translation unit but not in the other, but expects the update to flow through. Errors can result whether the macro expansion involves code or values.

    Of course, both of those potential problems can be reduced by being careful. But, as a rule of thumb, your code will be more reliable if it doesn't rely on that. Even careful people make mistakes, not everyone is careful, and people over-estimate their ability to be careful.
    The modules do not interact, and the only one that might update things is myself. So those are not serious concerns in this particular project.

    But I am interested in producing proper and acceptable code also.

    How might a function call between modules cause a problem?
    Is it the assumption of the same defined value incorporated into the return value from a function in the other module? (hope that makes sense)

    I have a need for a fair number of macro values, for things like bitmap dimensions and x, y offsets for those bitmaps. These are all similar in purpose
    from module to module, but differ in value. My idea right now for handling these is to make their names nondescriptive aside from their function.
    Very much like a local loop counter is simply "n" or "i", my defined names might be "DOTX"' and "DOTY", for x and y offsets in each module.

    What I am really trying to do is eliminate "magic numbers", but at the same reducing the number of macro names. Is there no good way to do this?

    -

  3. #18
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Quote Originally Posted by brewbuck View Post
    That's why serious discipline with macros is required for any larger project.
    If, by "serious discipline", you mean avoid them unless they're really needed, I agree.

    Personally, if I'm using a macro for anything except an #include guard, my policy is to look pretty hard for an approach that achieves the same result without using macros.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  4. #19
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    [Edit]
    Well, these posts are showing up as new (I use the mixed view.) for me. However, the marker also has it listed as a week old. If a week old, I'm sorry about the delay in responding and/or popping up an older issue.
    [/Edit]


    [Edit]
    I have no idea why, but page two only showed up after I responded. I suppose that is why the week old response is listed as new.
    [/Edit]


    I wasn't describing a case where the header files need each other. I was concerned with whether it is common for a translation unit that needs one to need another.
    O_o

    I see that I did misread what you said.

    In that case, I'd say it would be an error for the headers to include each other for reasons matching those benefits you referenced earlier in the thread.

    This is an area I think where the language is rather loose, and whether you consider this an error is really up to your own coding standards.
    Obviously. I said "I'd say" not "according to the standard".

    Soma
    Last edited by phantomotap; 06-18-2014 at 05:25 AM.
    “Salem Was Wrong!” -- Pedant Necromancer
    “Four isn't random!” -- Gibbering Mouther

  5. #20
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by grumpy View Post
    If, by "serious discipline", you mean avoid them unless they're really needed, I agree.

    Personally, if I'm using a macro for anything except an #include guard, my policy is to look pretty hard for an approach that achieves the same result without using macros.
    That is my view as well. In most cases the alternative to the macro is extremely simple. Even in cases where it isn't, it's still a good pivot for your architecture.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Header file multiple inclusion question
    By Loctan in forum C++ Programming
    Replies: 16
    Last Post: 05-04-2008, 08:25 PM
  2. #include's in multiple modules
    By samus250 in forum C Programming
    Replies: 8
    Last Post: 03-24-2008, 02:12 PM
  3. Multiple Modules
    By rwmarsh in forum C++ Programming
    Replies: 6
    Last Post: 02-18-2006, 04:34 PM
  4. Header file (multiple inclusions)
    By cjschw in forum C++ Programming
    Replies: 1
    Last Post: 08-10-2004, 10:28 AM
  5. prototypes and multiple modules
    By Bigbio2002 in forum C Programming
    Replies: 6
    Last Post: 11-19-2003, 02:54 PM