Name collision with 'nil'

[adam]

ACE+TAO-1.5a
gcc3.4.4
linux

I'm trying to compile an app which pulls in some TAO code. However, I
get lots of name collisions on methods called 'nil' in TAO, e.g. the
following error is one of thousands just like it:

<blah blah>/ACE_wrappers/TAO/tao/Objref_VarOut_T.cpp:12: error:
expected unqualified-id before numeric constant

Here's the code it refers to:

10: template <typename T>
11: TAO_Objref_Var_T<T>::TAO_Objref_Var_T (void)
12: : ptr_ (TAO::Objref_Traits<T>::nil ())
13: {
14: }

nil must be a #define'd constant somewhere or similar. Anybody know
where this collision is coming from and how this may be worked around?

Thanks,
Adam

 

[Victor Bazarov]

ACE+TAO-1.5a
gcc3.4.4
linux

I'm trying to compile an app which pulls in some TAO code. However, I
get lots of name collisions on methods called 'nil' in TAO, e.g. the
following error is one of thousands just like it:

<blah blah>/ACE_wrappers/TAO/tao/Objref_VarOut_T.cpp:12: error:
expected unqualified-id before numeric constant

Here's the code it refers to:

10: template <typename T>
11: TAO_Objref_Var_T<T>::TAO_Objref_Var_T (void)
12: : ptr_ (TAO::Objref_Traits<T>::nil ())
13: {
14: }

nil must be a #define'd constant somewhere or similar. Anybody know
where this collision is coming from and how this may be worked around?

Apparently 'nil' is something like

#define nil 0

(or some such) because otherwise you'd not have a complaint about
an expected unqualified id before numeric constant (IOW the compiler
wanted to see an ide right after the last '::').

I don't have a solution for you except to print out the preprocessor
output and scan it for the define in question. Hopefully you can find
where the compiler gets the symbol from.

V

 

[David Harmon]

On 23 Apr 2007 10:32:03 -0700 in comp.lang.c++, (e-mail address removed)
wrote,

nil must be a #define'd constant somewhere or similar. Anybody know
where this collision is coming from and how this may be worked around?

You are using linux; I would expect that you could find a working grep.

 

[James Kanze]

Apparently 'nil' is something like

#define nil 0

(or some such) because otherwise you'd not have a complaint about
an expected unqualified id before numeric constant (IOW the compiler
wanted to see an ide right after the last '::').

I don't have a solution for you except to print out the preprocessor
output and scan it for the define in question. Hopefully you can find
where the compiler gets the symbol from.

V

 

[James Kanze]

Apparently 'nil' is something like

#define nil 0

(or some such) because otherwise you'd not have a complaint about
an expected unqualified id before numeric constant (IOW the compiler
wanted to see an ide right after the last '::').

I don't have a solution for you except to print out the preprocessor
output and scan it for the define in question. Hopefully you can find
where the compiler gets the symbol from.

Well, he won't find many #define's in the preprocessor
output. But that's where I'd start as well. First, just to
verify that the error is the result of a preprocessing
substitution (although in this case, I can't see what else it
could be), by looking at the line in question after the
preprocessor has finished. And after that, in order to do
something like:
g++ -E lswap.cc |
sed -n 's/^# [0-9][0-9]* "\(.*\)".*/\1/p' |
sort -u |
xargs egrep '# *define *nil'
in order to find the culprit.

 

[James Kanze]

Apparently 'nil' is something like

#define nil 0

(or some such) because otherwise you'd not have a complaint about
an expected unqualified id before numeric constant (IOW the compiler
wanted to see an ide right after the last '::').

I don't have a solution for you except to print out the preprocessor
output and scan it for the define in question. Hopefully you can find
where the compiler gets the symbol from.

I doubt he'll find any #define's, or even any references to nil,
in the preprocessor output (typically the -E or /E option). On
the other hand, looking at the appropriate line in it will allow
him to confirm whether this really is the problem (although I
can't think of any other explination in this case), and piping
it through something like:
g++ -E lswap.cc |
sed -n 's/^# [0-9][0-9]* "\(.*\)".*/\1/p' |
sort -u |
xargs egrep '# *define *nil'
should allow him to find the guilty party.

 

[adam]

Resolved this issue by changing #define nil 0 in local library code to
something else.

Thanks for all your help