By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,370 Members | 1,512 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,370 IT Pros & Developers. It's quick & easy.

preprocessor seems interfering namespace defines?

P: n/a
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 '07 #1
Share this Question
Share on Google+
9 Replies


P: n/a
On 5/30/2007 3:20 PM, we*****@yahoo.com 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
May 30 '07 #2

P: n/a
we*****@yahoo.com 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)
May 30 '07 #3

P: n/a
Pete Becker wrote:
we*****@yahoo.com 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)
May 30 '07 #4

P: n/a
On 30 Maj, 15:20, "wenm...@yahoo.com" <wenm...@yahoo.comwrote:
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

May 30 '07 #5

P: n/a
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 '07 #6

P: n/a

<we*****@yahoo.comwrote 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
May 31 '07 #7

P: n/a
On May 31, 5:38 pm, "BobR" <removeBadB...@worldnet.att.netwrote:
<wenm...@yahoo.comwrote 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 '07 #8

P: n/a
we*****@yahoo.com 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)
Jun 1 '07 #9

P: n/a
On Jun 1, 10:12 am, Pete Becker <p...@versatilecoding.comwrote:
wenm...@yahoo.com 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 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.