C Coding Styles and the use of Macros

Discussion in 'C Programming' started by davej, Nov 21, 2003.

  1. davej

    davej Guest

    Hi,

    I've been working on an opensource project for most of this year. The
    group has adopted the use of macros in place of function calls when
    wanting to simplify a function.
    #define get_sensor_values(s1, s2, s3) \
    do { \
    if(s1>s2) { \
    if(s->e != NULL { \
    id = s3->id; \ OID defined\n"); \
    } \
    } \
    ..... this continues for many lines

    if(error)\
    return(-1);
    } while(0)




    int process_sensor_data(n, p, s1, s2, s3)
    {
    ..
    ..
    get_sensor_values(s1, s2, s3);
    ..
    ..
    return(OK);
    }


    I consider this obfuscation. For starters the macro hides one of the
    return paths from the function. Second the use of macros has become
    pervasive in replacing function calls.

    I'd like to hear opinions on this. Are there any web references I
    can use?

    Thanks Much

    DaveJ
     
    davej, Nov 21, 2003
    #1
    1. Advertising

  2. davej

    Mike Wahler Guest

    "davej" <> wrote in message
    news:1Wevb.118538$...
    > Hi,
    >
    > I've been working on an opensource project for most of this year. The
    > group has adopted the use of macros in place of function calls when
    > wanting to simplify a function.
    > #define get_sensor_values(s1, s2, s3) \
    > do { \
    > if(s1>s2) { \
    > if(s->e != NULL { \
    > id = s3->id; \ OID defined\n"); \
    > } \
    > } \
    > .... this continues for many lines
    >
    > if(error)\
    > return(-1);
    > } while(0)
    >
    >
    >
    >
    > int process_sensor_data(n, p, s1, s2, s3)
    > {
    > .
    > .
    > get_sensor_values(s1, s2, s3);
    > .
    > .
    > return(OK);
    > }
    >
    >
    > I consider this obfuscation. For starters the macro hides one of the
    > return paths from the function. Second the use of macros has become
    > pervasive in replacing function calls.
    >
    > I'd like to hear opinions on this.


    I prefer to default to functions, where type checking
    can be done. I'd only use a macro if there were compelling
    reasons (e.g. performance, which I'd first prove by profiling).

    -Mike
     
    Mike Wahler, Nov 21, 2003
    #2
    1. Advertising

  3. davej

    Ed Morton Guest

    davej wrote:

    > Hi,
    >
    > I've been working on an opensource project for most of this year. The
    > group has adopted the use of macros in place of function calls when
    > wanting to simplify a function.
    > #define get_sensor_values(s1, s2, s3) \
    > do { \
    > if(s1>s2) { \


    See below for macro argument feedback "a)".

    > if(s->e != NULL { \
    > id = s3->id;


    See below for local variable feedback "b)". I'm assuming id is declared
    within the macro and you just didn't show it - if not, that's even worse!

    <snip>

    > I consider this obfuscation. For starters the macro hides one of the
    > return paths from the function. Second the use of macros has become
    > pervasive in replacing function calls.
    >
    > I'd like to hear opinions on this. Are there any web references I
    > can use?


    Macros are fine for small, simple, often-repeated, run-to-completion
    code segments. They shouldn't be longer than half a dozen or so lines
    and they should never contain a return statment or otherwise directly
    affect control flow of the calling function. Your group is creating a
    maintenance headache with hard-to-understand and hard-to-debug code.

    By the way:

    a) Within a macro you should surround its arguments in "(...)" to avoid
    unexpected expansions.
    b) Make sure that any variables declared within a macro follow a strict
    naming convention (e.g. start them with an underscore) to avoid clashes
    with variables in calling functions.

    Ed.
     
    Ed Morton, Nov 21, 2003
    #3
  4. davej wrote:
    >
    > Hi,
    >
    > I've been working on an opensource project for most of this year. The
    > group has adopted the use of macros in place of function calls when
    > wanting to simplify a function.
    > #define get_sensor_values(s1, s2, s3) \


    If its an open source project there is a good chance the compiler
    being used is GCC which does support inline functions.

    Inline functions have the advantage of much better type checking
    than macros.

    Erik

    --
    +-----------------------------------------------------------+
    Erik de Castro Lopo (Yes it's valid)
    +-----------------------------------------------------------+
    "What lawyers call 'intellectual property' is -- as every Latin student
    knows -- no more than theft from the public domain."
    -- Andy Mueller-Maguhn, newly elected ICANN board member for Europe.
     
    Erik de Castro Lopo, Nov 21, 2003
    #4
  5. In article <1Wevb.118538$>,
    "davej" <> wrote:

    > Hi,
    >
    > I've been working on an opensource project for most of this year. The
    > group has adopted the use of macros in place of function calls when
    > wanting to simplify a function.
    > #define get_sensor_values(s1, s2, s3) \
    > do { \
    > if(s1>s2) { \
    > if(s->e != NULL { \
    > id = s3->id; \ OID defined\n"); \
    > } \
    > } \
    > .... this continues for many lines
    >
    > if(error)\
    > return(-1);
    > } while(0)
    >
    >
    >
    >
    > int process_sensor_data(n, p, s1, s2, s3)
    > {
    > .
    > .
    > get_sensor_values(s1, s2, s3);
    > .
    > .
    > return(OK);
    > }
    >
    >
    > I consider this obfuscation. For starters the macro hides one of the
    > return paths from the function. Second the use of macros has become
    > pervasive in replacing function calls.


    I don't mind using function-like macros in a way similar to functions.
    Of course, a "return" statement inside a function-like macro means it
    does NOT behave similar to a function, so this should better be very
    well documented both where the macro is defined and wherever it is used.
     
    Christian Bau, Nov 21, 2003
    #5
  6. davej

    CBFalconer Guest

    davej wrote:
    >
    > I've been working on an opensource project for most of this year.
    > The group has adopted the use of macros in place of function calls
    > when wanting to simplify a function.
    > #define get_sensor_values(s1, s2, s3) \
    > do { \
    > if(s1>s2) { \
    > if(s->e != NULL { \
    > id = s3->id; \ OID defined\n"); \
    > } \
    > } \
    > .... this continues for many lines
    >
    > if(error)\
    > return(-1);
    > } while(0)
    >
    > int process_sensor_data(n, p, s1, s2, s3)
    > {
    > .
    > .
    > get_sensor_values(s1, s2, s3);
    > .
    > .
    > return(OK);
    > }
    >
    > I consider this obfuscation. For starters the macro hides one
    > of the return paths from the function. Second the use of macros
    > has become pervasive in replacing function calls.
    >
    > I'd like to hear opinions on this. Are there any web references
    > I can use?


    I agree with you. Disassociate yourself from that bunch as
    rapidly as possible.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Nov 21, 2003
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    80
    Views:
    2,536
    Stephen J. Bevan
    Nov 7, 2003
  2. Replies:
    1
    Views:
    497
    Marco Antoniotti
    Oct 7, 2003
  3. Replies:
    5
    Views:
    516
  4. Michael T. Babcock

    Re: Explanation of macros; Haskell macros

    Michael T. Babcock, Nov 3, 2003, in forum: Python
    Replies:
    0
    Views:
    544
    Michael T. Babcock
    Nov 3, 2003
  5. Andrew Arro

    macros-loop? calling macros X times?

    Andrew Arro, Jul 23, 2004, in forum: C Programming
    Replies:
    2
    Views:
    520
    S.Tobias
    Jul 24, 2004
Loading...

Share This Page