Compiler Directives Not Working

[shane.tietjen]

Working in VS 2003.

in a header file:

[test.h]

#ifdef _UNUSED_NAME_3223458 //this is not defined anywhere at anytime
#define TEST123 6789
#endif

[\test.h]

in the implementation file:

[test.cpp]

\\the value of TEST123 will be 6789 or whatever value is assigned to it
even though _UNUSED_NAME_3223458 was never defined and is not present
in any other files.

[\test.cpp]

Also, if you do:
#ifndef _UNUSED_NAME_3223458
#define TEST123 0
#endif

Insert this prior to the other one(so you test for not defined before
defined), TEST123 will have a value of 0 and not 6789.

No errors or warnings.

It is almost as if the variable you testing( _UNUSED_NAME_3223458 which
is never defined at any time) is in an unknown state at the time you
test it.

What is going on here?

 

[Victor Bazarov]

Working in VS 2003.

Perhaps you should ask in 'microsoft.public.vc.language'...

in a header file:

[test.h]

#ifdef _UNUSED_NAME_3223458 //this is not defined anywhere at anytime
#define TEST123 6789
#endif

[\test.h]

in the implementation file:

[test.cpp]

\\the value of TEST123 will be 6789 or whatever value is assigned to it
even though _UNUSED_NAME_3223458 was never defined and is not present
in any other files.

By _definition_ if 'TEST123' has the value 6789 (or whatever), it means
that either 'TEST123' is defined _elsewhere_ *as well* as here, or that
"_UNUSED_NAME_3223458" macro is in fact _defined_ and that's how the C++
preprocessor knows to define 'TEST123".

What you're trying to doubt here is the very basic functionality of the
preprocessor. I am _sure_ it's you who's made the mistake. Are you sure
it's "ifdef" and not "ifndef"?...

[\test.cpp]

Also, if you do:
#ifndef _UNUSED_NAME_3223458
#define TEST123 0
#endif

Insert this prior to the other one(so you test for not defined before
defined), TEST123 will have a value of 0 and not 6789.

No errors or warnings.

It is almost as if the variable you testing( _UNUSED_NAME_3223458 which
is never defined at any time) is in an unknown state at the time you
test it.

What is going on here?

Impossible to say. Your code fragments do not carry enough information.
You're asking for a rather big leap from those fragments to the notion
that everything else is OK, and you didn't screw up somehow. I'd rather
believe the compiler.

V

 

[red floyd]

Working in VS 2003.

in a header file:

[test.h]

#ifdef _UNUSED_NAME_3223458 //this is not defined anywhere at anytime

_UNUSED_NAME_3223458 is reserved to the implementation. You can't use
it in your code.

 

[Jay_Nabonne]

Working in VS 2003.

in a header file:

[test.h]

#ifdef _UNUSED_NAME_3223458 //this is not defined anywhere at anytime
#define TEST123 6789
#endif

[\test.h]

in the implementation file:

[test.cpp]

\\the value of TEST123 will be 6789 or whatever value is assigned to it
even though _UNUSED_NAME_3223458 was never defined and is not present
in any other files.

Put

#undef _UNUSED_NAME_3223458

right before the #ifdef in test.h. If that fixes it, then
_UNUSED_NAME_3223458 is defined *somewhere*. (Preprocessor defines in the
project settings perhaps?)

Also, what if you change it to

#ifdef _UNUSED_NAME_3223458foo

? Does it still behave the same?

- Jay

 

[Howard]

Working in VS 2003.

in a header file:

[test.h]

#ifdef _UNUSED_NAME_3223458 //this is not defined anywhere at anytime
#define TEST123 6789
#endif

[\test.h]

in the implementation file:

[test.cpp]

\\the value of TEST123 will be 6789 or whatever value is assigned to it
even though _UNUSED_NAME_3223458 was never defined and is not present
in any other files.

[\test.cpp]

Also, if you do:
#ifndef _UNUSED_NAME_3223458
#define TEST123 0
#endif

Insert this prior to the other one(so you test for not defined before
defined), TEST123 will have a value of 0 and not 6789.

No errors or warnings.

It is almost as if the variable you testing( _UNUSED_NAME_3223458 which
is never defined at any time) is in an unknown state at the time you
test it.

What is going on here?

You don't show how you're checking the value of TEST123. How do you know
its value if it hasn't been defined? Testing for a specific value may not
be a valid test if it is never defined in the first place. (I'm not sure if
that's mandated by the standard, or an implementation detail, though.)

-Howard

 

[shane.tietjen]

I thought I was very clear. TEST123 and _UNUSED_NAME_3223458 are not
defined anywhere in my code nor are they present in any file on the
system. This means that there is no possible way they could be
defined. Not defined.

I understand the compiler is smarter than I am. Thats why I use it
instead of writing Assembly.

 

[shane.tietjen]

Could you explain what you mean by "reserved" and by "You can't use it
in your code."?
Thanks

 

[shane.tietjen]

I have tried the #undef solution before and it produced the same
results. But it IS NOT defined anywhere on the local machine in any
file. I know this becaue I just made up the name with a bunch of
random numbers and then searched for it.

And yes, it will behave the same no matter what name you choose.

 

[Ben Pope]

Could you explain what you mean by "reserved" and by "You can't use it
in your code."?

The standard says that identifiers that start with an underscore
followed by a capital alpha character are reserved for the implementation.

As are identifiers prefixed with double underscore.

This means you have undefined behaviour, regardless of how likely that
identifier is likely to appear in the implementation.

Ben Pope

 

[shane.tietjen]

<Quote>
You don't show how you're checking the value of TEST123. How do you
know
its value if it hasn't been defined? Testing for a specific value may
not
be a valid test if it is never defined in the first place. (I'm not
sure if
that's mandated by the standard, or an implementation detail, though.)

-Howard
<\Quote>

I check it using the debugger at runtime. I searched every file on the
local machine and "TEST123" and "_UNUSED_NAME_xxxx" not listed as being
part of any other file other than the lines I showed you in the .h file
and .cpp file we are dealing with.

 

[shane.tietjen]

Could you explain what you mean by "reserved" and by "You can't use it
in your code."?

The standard says that identifiers that start with an underscore
followed by a capital alpha character are reserved for the
implementation.

As are identifiers prefixed with double underscore.


This means you have undefined behaviour, regardless of how likely that
identifier is likely to appear in the implementation.
<quote>

Okay I accept that. I wasn't trying to confuse anyone with the name.
Truth is, the name doesn't matter so assume my original problem without
the "_" at the beginning. Sorry for any confusion.

 

[Victor Bazarov]

The standard says that identifiers that start with an underscore
followed by a capital alpha character are reserved for the implementation.

As are identifiers prefixed with double underscore.

Actually, as are identifiers _containing_ double underscores (17.4.3.1.2).

This means you have undefined behaviour, regardless of how likely that
identifier is likely to appear in the implementation.

V

 

[Victor Bazarov]

I thought I was very clear. TEST123 and _UNUSED_NAME_3223458 are not
defined anywhere in my code nor are they present in any file on the
system. This means that there is no possible way they could be
defined. Not defined.

I understand the compiler is smarter than I am. Thats why I use it
instead of writing Assembly.

No, the compiler is not smarter. It's just more careful at following
the rules imposed on it.

Read the FAQ 5.8, and follow its recommendations. Then we can talk. So
far you're just too frustrated about your problem to hear what others are
telling you.

V

 

[Howard]

<Quote>
You don't show how you're checking the value of TEST123. How do you
know
its value if it hasn't been defined? Testing for a specific value may
not
be a valid test if it is never defined in the first place. (I'm not
sure if
that's mandated by the standard, or an implementation detail, though.)

-Howard
<\Quote>

I check it using the debugger at runtime. I searched every file on the
local machine and "TEST123" and "_UNUSED_NAME_xxxx" not listed as being
part of any other file other than the lines I showed you in the .h file
and .cpp file we are dealing with.

I'd question the debugger, then. Try actually using code or more
preprocessor directives to test if it's defined, and what its value is. I
bet it's simply not defined, which is confusing the debugger. Try something
like this to test:

// in header file:
#ifdef _UNUSED_NAME_3223458 //this is not defined anywhere at anytime
#define TEST123 6789
#endif

// in a function somewhere in a file which includes that header:
#ifdef TEST123
int testInt = TEST123;
#else
int testInt = 0;
#endif
// Now, check or display the value of testInt!

-Howard

 

[Victor Bazarov]

The standard says that identifiers that start with an underscore
followed by a capital alpha character are reserved for the
implementation.

As are identifiers prefixed with double underscore.


This means you have undefined behaviour, regardless of how likely that
identifier is likely to appear in the implementation.
<quote>

Okay I accept that. I wasn't trying to confuse anyone with the name.
Truth is, the name doesn't matter so assume my original problem without
the "_" at the beginning. Sorry for any confusion.

No. We won't assume anything. Assumption is the mother of all f***-ups.

Post complete minimal code that demonstrates your problem.

V

 

[shane.tietjen]

I thought I was very clear. TEST123 and _UNUSED_NAME_3223458 are not
defined anywhere in my code nor are they present in any file on the
system. This means that there is no possible way they could be
defined. Not defined.

I understand the compiler is smarter than I am. Thats why I use it
instead of writing Assembly.

No, the compiler is not smarter. It's just more careful at following
the rules imposed on it.

Read the FAQ 5.8, and follow its recommendations. Then we can talk.
So
far you're just too frustrated about your problem to hear what others
are
telling you.


V
<\quote>

No I am not frustrated. I actually solved the problem a while ago by
modifying other code so I was not required to use the initial #ifdef in
the header file. No frustrations here at all. I just don't know why
the code was behaving the way it was. And it IS "Smarter" than me. LOL.

 

[shane.tietjen]

The way I meant assume: Similar to writing a mathematical proof,
"Assume the problem is the same as it was originally and get rid of the
"_" in the name". Since the name of the variable doesn't matter( as
long as it is a valid name ), it doesn't change the original nature of
the problem which is what I wanted you to "asume".

sorry for any confustion.

 

[Jim Langston]

I'd question the debugger, then. Try actually using code or more
preprocessor directives to test if it's defined, and what its value is. I
bet it's simply not defined, which is confusing the debugger. Try
something like this to test:

// in header file:
#ifdef _UNUSED_NAME_3223458 //this is not defined anywhere at anytime
#define TEST123 6789
#endif

// in a function somewhere in a file which includes that header:
#ifdef TEST123
int testInt = TEST123;
#else
int testInt = 0;
#endif
// Now, check or display the value of testInt!

-Howard

Heck, I think I would just do:

#ifdef UNUSED_NAME_3223458
#slakjfsl;adkjfsal;kdjf
#endif

and see if the compiler barfs or not.