preprocessor seems interfering namespace defines?

Discussion in 'C++' started by wenmang@yahoo.com, May 30, 2007.

  1. Guest

    Hi, all:
    I have a question regarding to how to solve following problem:
    I have header called myHeader.h which #define MAX_LEN 100 (legacy
    code).
    Now, I like to put most commonly used in myHeader.h into a namespace,
    e.g.,

    #include <myHeader.h>
    namespace myNamespace
    {
    const int MAX_LEN = 100;
    MyData data[MAX_NUM]; //MyData defined in myHeader.h
    };

    Unfortunately, I have to include myHeader.h and compiler fails me due
    to that MAX_LEN is probably replaced with 100 by preprocessor since it
    complains about syntax error, what is best way to solve this?
    thx
     
    , May 30, 2007
    #1
    1. Advertising

  2. Stefan Naewe Guest

    On 5/30/2007 3:20 PM, wrote:
    > Hi, all:
    > I have a question regarding to how to solve following problem:
    > I have header called myHeader.h which #define MAX_LEN 100 (legacy
    > code).
    > Now, I like to put most commonly used in myHeader.h into a namespace,
    > e.g.,
    >
    > #include <myHeader.h>


    #ifdef MAX_LEN
    #undef MAX_LEN
    #endif

    > namespace myNamespace
    > {
    > const int MAX_LEN = 100;
    > MyData data[MAX_NUM]; //MyData defined in myHeader.h


    You certainly meant:
    MyData data[MAX_LEN];
    > };
    >
    > Unfortunately, I have to include myHeader.h and compiler fails me due
    > to that MAX_LEN is probably replaced with 100 by preprocessor since it
    > complains about syntax error, what is best way to solve this?


    If you can, ditch the preprocessor usage in 'myHeader.h'.


    Regards,
    Stefan
    --
    Stefan Naewe stefan dot naewe at atlas-elektronik dot com
    Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
    Plain text mails only, please http://www.expita.com/nomime.html
     
    Stefan Naewe, May 30, 2007
    #2
    1. Advertising

  3. Pete Becker Guest

    wrote:
    >
    > Unfortunately, I have to include myHeader.h and compiler fails me due
    > to that MAX_LEN is probably replaced with 100 by preprocessor since it
    > complains about syntax error, what is best way to solve this?
    > thx
    >


    Use a different name for your macro.

    --

    -- Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com)
    Author of "The Standard C++ Library Extensions: a Tutorial and
    Reference." (www.petebecker.com/tr1book)
     
    Pete Becker, May 30, 2007
    #3
  4. Pete Becker Guest

    Pete Becker wrote:
    > wrote:
    >>
    >> Unfortunately, I have to include myHeader.h and compiler fails me due
    >> to that MAX_LEN is probably replaced with 100 by preprocessor since it
    >> complains about syntax error, what is best way to solve this?
    >> thx
    >>

    >
    > Use a different name for your macro.
    >


    s/macro/object/.

    --

    -- Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com)
    Author of "The Standard C++ Library Extensions: a Tutorial and
    Reference." (www.petebecker.com/tr1book)
     
    Pete Becker, May 30, 2007
    #4
  5. peter koch Guest

    On 30 Maj, 15:20, "" <> wrote:
    > Hi, all:
    > I have a question regarding to how to solve following problem:
    > I have header called myHeader.h which #define MAX_LEN 100 (legacy
    > code).
    > Now, I like to put most commonly used in myHeader.h into a namespace,
    > e.g.,
    >
    > #include <myHeader.h>
    > namespace myNamespace
    > {
    > const int MAX_LEN = 100;
    > MyData data[MAX_NUM]; //MyData defined in myHeader.h
    >
    > };
    >
    > Unfortunately, I have to include myHeader.h and compiler fails me due
    > to that MAX_LEN is probably replaced with 100 by preprocessor since it
    > complains about syntax error, what is best way to solve this?
    > thx


    Your problem would never have occured had you followed the good advice
    to reserve names all in uppercase for macroes. Rename your constant to
    max_len.

    /Peter
     
    peter koch, May 30, 2007
    #5
  6. Guest

    Thanks all for replying to my question.

    I have other problem which is not caused by our code, instead from
    Linux/system headers.

    I have defined a file scope var, e.g., in my.C:

    #include "my.h"

    const int MAX_INT = std::numeric_limits<int>::max();
    :
    :

    When I compile, max is replaced with a macro defined in /usr/include/
    LiS/sys/LiS/share.h
    #define max(a,b) (((a)>(b))?(a):(b))

    And compiler complains:
    `max' is not a member of type `
    std::numeric_limits<int>'

    how am I going to use soemthing like
    "std::numeric_limits<int>::max();"?

    My platform is:
    Linux server 2.4.21-15.ELsmp #1 SMP Thu Apr 22 00:18:24 EDT 2004 i686
    i686 i386 GNU/Linux
     
    , May 31, 2007
    #6
  7. BobR Guest

    <> wrote in message ...
    >
    > I have other problem which is not caused by our code, instead from
    > Linux/system headers.
    >
    > I have defined a file scope var, e.g., in my.C:
    >
    > #include "my.h"
    > const int MAX_INT = std::numeric_limits<int>::max();
    > :
    > When I compile, max is replaced with a macro defined in /usr/include/
    > LiS/sys/LiS/share.h
    > #define max(a,b) (((a)>(b))?(a):(b))
    >
    > And compiler complains:
    > `max' is not a member of type `
    > std::numeric_limits<int>'


    Did you:
    #include <limits>


    #include <limits>
    #include <iostream>
    #include <iomanip>
    int main(){
    std::cout <<" 0x"<<std::hex
    <<std::numeric_limits<int>::max()<<std::endl;
    return 0;
    }

    --
    Bob R
    POVrookie
     
    BobR, May 31, 2007
    #7
  8. Guest

    On May 31, 5:38 pm, "BobR" <> wrote:
    > <> wrote in message ...
    >
    > > I have other problem which is not caused by our code, instead from
    > > Linux/system headers.

    >
    > > I have defined a file scope var, e.g., in my.C:

    >
    > > #include "my.h"
    > > const int MAX_INT = std::numeric_limits<int>::max();
    > > :
    > > When I compile, max is replaced with a macro defined in /usr/include/
    > > LiS/sys/LiS/share.h
    > > #define max(a,b) (((a)>(b))?(a):(b))

    >
    > > And compiler complains:
    > > `max' is not a member of type `
    > > std::numeric_limits<int>'

    >
    > Did you:
    > #include <limits>
    >
    > #include <limits>
    > #include <iostream>
    > #include <iomanip>
    > int main(){
    > std::cout <<" 0x"<<std::hex
    > <<std::numeric_limits<int>::max()<<std::endl;
    > return 0;
    > }
    >
    > --
    > Bob R
    > POVrookie


    yes, I did. For a simple test, it compiles/works fine without
    including share.h. share.h is indirectly included by other legacy
    code, preprocessor seems failing the includes.
     
    , Jun 1, 2007
    #8
  9. Pete Becker Guest

    wrote:
    >
    > yes, I did. For a simple test, it compiles/works fine without
    > including share.h. share.h is indirectly included by other legacy
    > code, preprocessor seems failing the includes.
    >


    Right. the problem is the macro max(), which conflicts with the member
    function with the same name (the algorithm max has the same problem, but
    it sounds like you haven't hit that one yet).

    Under Windows, the solution is to define _NO_MINMAX (or something like
    that, it's been a while) before including the offending files. If there
    isn't a mechanism like that for the file that's messing up your code,
    one approach would be to start every list of include files with:

    #include "share.h"
    #undef max

    That way you'll blow away the macro before it does any damage to headers
    that aren't prepared for it. On the other hand, it might cause problems
    for other headers from the same package that assume that the macro
    definition is still there. If that's the case, one possibility (NOT
    TESTED) would be:

    #include "share.h"
    #undef max
    #include <algorithm>
    using std::max;

    That kills the macro, but puts the C++ algorithm named max in the global
    namespace, where subsequent headers will see it. I wouldn't do this
    automatically, only if it's needed to solve actual problems. It may well
    be that the macro max is only used in the library's source files, so all
    you need to do is get rid of it.

    Another approach, if you don't mind doing a little surgery on your
    compiler's headers, is to find all their uses of max and replace them
    with (max) (i.e. put parentheses around them). The preprocessor won't
    treat a name as a function-like macro if it's not followed by a left
    parenthesis, so it won't mess with those uses of max. You'll have to do
    the same in your source code if you use max:

    return (max)(a, b);

    --

    -- Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com)
    Author of "The Standard C++ Library Extensions: a Tutorial and
    Reference." (www.petebecker.com/tr1book)
     
    Pete Becker, Jun 1, 2007
    #9
  10. Guest

    On Jun 1, 10:12 am, Pete Becker <> wrote:
    > wrote:
    >
    > > yes, I did. For a simple test, it compiles/works fine without
    > > including share.h. share.h is indirectly included by other legacy
    > > code, preprocessor seems failing the includes.

    >
    > Right. the problem is the macro max(), which conflicts with the member
    > function with the same name (the algorithm max has the same problem, but
    > it sounds like you haven't hit that one yet).
    >
    > Under Windows, the solution is to define _NO_MINMAX (or something like
    > that, it's been a while) before including the offending files. If there
    > isn't a mechanism like that for the file that's messing up your code,
    > one approach would be to start every list of include files with:
    >
    > #include "share.h"
    > #undef max
    >
    > That way you'll blow away the macro before it does any damage to headers
    > that aren't prepared for it. On the other hand, it might cause problems
    > for other headers from the same package that assume that the macro
    > definition is still there. If that's the case, one possibility (NOT
    > TESTED) would be:
    >
    > #include "share.h"
    > #undef max
    > #include <algorithm>
    > using std::max;
    >
    > That kills the macro, but puts the C++ algorithm named max in the global
    > namespace, where subsequent headers will see it. I wouldn't do this
    > automatically, only if it's needed to solve actual problems. It may well
    > be that the macro max is only used in the library's source files, so all
    > you need to do is get rid of it.
    >
    > Another approach, if you don't mind doing a little surgery on your
    > compiler's headers, is to find all their uses of max and replace them
    > with (max) (i.e. put parentheses around them). The preprocessor won't
    > treat a name as a function-like macro if it's not followed by a left
    > parenthesis, so it won't mess with those uses of max. You'll have to do
    > the same in your source code if you use max:
    >
    > return (max)(a, b);
    >
    > --
    >
    > -- Pete
    > Roundhouse Consulting, Ltd. (www.versatilecoding.com)
    > Author of "The Standard C++ Library Extensions: a Tutorial and
    > Reference." (www.petebecker.com/tr1book)


    Thanks Pete. I have not traced back where share.h is included in our
    code, but most likely it is include indirectly by other headers. I
    guess that I may end up using #undef to solve the problem.
     
    , Jun 1, 2007
    #10
    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. Pat Deegan
    Replies:
    3
    Views:
    491
    Joe Smith
    Apr 22, 2004
  2. Jakob Simon-Gaarde

    Preprocessor concatination of defines

    Jakob Simon-Gaarde, Jul 1, 2004, in forum: C++
    Replies:
    4
    Views:
    452
    Jack Klein
    Jul 2, 2004
  3. Cronus
    Replies:
    1
    Views:
    698
    Paul Mensonides
    Jul 15, 2004
  4. theotyflos
    Replies:
    3
    Views:
    495
    Thomas Matthews
    Feb 19, 2004
  5. Pelle Beckman

    Preprocessor defines

    Pelle Beckman, Jul 2, 2005, in forum: C++
    Replies:
    2
    Views:
    338
    Alan Johnson
    Jul 2, 2005
Loading...

Share This Page