«

I have defined some variables using #define preprocessor instruction.
And then later I checked whether I had defined a variable. Sometimes
even though a variable have been defined, #if !defined(var) construct
is returning true. I am using gcc3.0.1 on SunOS8. I would appreciate
if any body can tell me whether this is a bug or I am doing something
wrong.

tia,
Srinivas

srinivas reddy <> wrote in message
news: om...
> I have defined some variables using #define preprocessor instruction.
> And then later I checked whether I had defined a variable. Sometimes
> even though a variable have been defined, #if !defined(var) construct
> is returning true. I am using gcc3.0.1 on SunOS8. I would appreciate
> if any body can tell me whether this is a bug or I am doing something
> wrong.

I would have said that this surely is a bug, but I wouldn't put anything
past the C++ preprocessor.

Incomprehensibly, #if var1 == var2 simply converts var1 and var2 to "0"
(yes, "0", even though the preprocessor is a _text_ replacer) if it hasn't
come across definitions of them (something like Basic assuming that any
undefined variable it comes across must be an int; and I thought C++ got rid
of implicit this and implicit that because they are thought unsafe). 0 == 0
is true, of course.

I can only assume that those with influence who wish to see the end of the
preprocessor altogether are trying to accelerate its death by ensuring that
it works as badly as possible.

DW

David White wrote:
>
> I can only assume that those with influence who wish to see the end of the
> preprocessor altogether are trying to accelerate its death by ensuring that
> it works as badly as possible.
>

Then it must be that the folks who originally came up with the idea of
the preprocessor thirty years ago tried to accelerate its death, because
replacing undefined symbols with 0 in arithmetic expressions has been
the rule since the beginning.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

"srinivas reddy" <> wrote in message
news: om...
> I have defined some variables using #define preprocessor instruction.
> And then later I checked whether I had defined a variable. Sometimes
> even though a variable have been defined, #if !defined(var) construct
> is returning true. I am using gcc3.0.1 on SunOS8. I would appreciate
> if any body can tell me whether this is a bug or I am doing something
> wrong.
>
> tia,
> Srinivas

Perhaps you have defined the variable, but not in the compilation unit in
which your #if statement is written? In other words, if you #define the
variable in unit1.h, and make your check in unit2.cpp, then you need to add
#include "unit1.h" in unit2.cpp before checking if the variable exists.

(I usually put my #define's in a precompiled header if they're going to be
widely used in my projects. But that's with CodeWarrior...I don't know how
to use gcc so it may be different.)

Just a thought...

-Howard

David White wrote:
> srinivas reddy <> wrote in message
> news: om...
>> I have defined some variables using #define preprocessor instruction.
>> And then later I checked whether I had defined a variable. Sometimes
>> even though a variable have been defined, #if !defined(var) construct
>> is returning true. I am using gcc3.0.1 on SunOS8. I would appreciate
>> if any body can tell me whether this is a bug or I am doing something
>> wrong.
>
> I would have said that this surely is a bug, but I wouldn't put
> anything past the C++ preprocessor.
>
> Incomprehensibly, #if var1 == var2 simply converts var1 and var2 to
> "0" (yes, "0", even though the preprocessor is a _text_ replacer) if
> it hasn't come across definitions of them (something like Basic
> assuming that any undefined variable it comes across must be an int;
> and I thought C++ got rid of implicit this and implicit that because
> they are thought unsafe). 0 == 0 is true, of course.
>
> I can only assume that those with influence who wish to see the end
> of the preprocessor altogether are trying to accelerate its death by
> ensuring that it works as badly as possible.

It isn't the preprocessor that is bad--even the conversion to 0 that you mention
here. It is *misuse* of the preprocessor that is bad. The preprocessor is
actually a critical component of the C and C++ compilation process. It makes it
possible to write code that works on multiple platforms, as well as write code
that works on various current compilers (as opposed to the idealistic perfect
C++ implementation).

Regards,
Paul Mensonides

Pete Becker <> wrote in message
news:...
> David White wrote:
> >
> > I can only assume that those with influence who wish to see the end of
the
> > preprocessor altogether are trying to accelerate its death by ensuring
that
> > it works as badly as possible.
> >
>
> Then it must be that the folks who originally came up with the idea of
> the preprocessor thirty years ago tried to accelerate its death, because
> replacing undefined symbols with 0 in arithmetic expressions has been
> the rule since the beginning.

I accept that, but why hasn't it been fixed along with everything else?
Implicit int, matching of function argument types, insistence that function
definitions be present, etc. have been some of the many improvements to C++
since C. I don't think anyone disputes that these are all good things. The
more prgrammer errors you can detect at compile time the better. Why leave
something there that's so obviously bad?

DW

David White wrote:
>
> Pete Becker <> wrote in message
> news:...
> > David White wrote:
> > >
> > > I can only assume that those with influence who wish to see the end of
> the
> > > preprocessor altogether are trying to accelerate its death by ensuring
> that
> > > it works as badly as possible.
> > >
> >
> > Then it must be that the folks who originally came up with the idea of
> > the preprocessor thirty years ago tried to accelerate its death, because
> > replacing undefined symbols with 0 in arithmetic expressions has been
> > the rule since the beginning.
>
> I accept that, but why hasn't it been fixed along with everything else?

Because it's not broken.

> Implicit int, matching of function argument types, insistence that function
> definitions be present, etc. have been some of the many improvements to C++
> since C. I don't think anyone disputes that these are all good things. The
> more prgrammer errors you can detect at compile time the better. Why leave
> something there that's so obviously bad?
>

The fact that you don't understand it doesn't make it bad.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Pete Becker <> wrote in message
news:...
> David White wrote:
> >
> >
> > I accept that, but why hasn't it been fixed along with everything else?
>
> Because it's not broken.
>
> > Implicit int, matching of function argument types, insistence that
function
> > definitions be present, etc. have been some of the many improvements to
C++
> > since C. I don't think anyone disputes that these are all good things.
The
> > more prgrammer errors you can detect at compile time the better. Why
leave
> > something there that's so obviously bad?
> >
> The fact that you don't understand it doesn't make it bad.

What have I said that indicates that I don't understand it? Did I describe
it wrongly?

I'm interested to know: do you think that assuming that an undefined
preprocessor symbol is "0" is a good thing, or something that wouldn't be
improved by a compiler error saying that the symbol is undefined? If so, why
not extend the principle to assuming that any symbol in a C++ expression is
an 'int'?

myVariable = 7;
// myVariable not defined anywhere: so it must be an 'int'.

Okay?

myVariable = myFunction(3, "abc", 2.65);
// myFunction not defined anywhere: so it must be int myFunction(int, char
*, double);

Okay?

DW

David White wrote:
>
> Pete Becker <> wrote in message
> news:...
> > David White wrote:
> > >
> > >
> > > I accept that, but why hasn't it been fixed along with everything else?
> >
> > Because it's not broken.
> >
> > > Implicit int, matching of function argument types, insistence that
> function
> > > definitions be present, etc. have been some of the many improvements to
> C++
> > > since C. I don't think anyone disputes that these are all good things.
> The
> > > more prgrammer errors you can detect at compile time the better. Why
> leave
> > > something there that's so obviously bad?
> > >
> > The fact that you don't understand it doesn't make it bad.
>
> What have I said that indicates that I don't understand it? Did I describe
> it wrongly?

You said earlier that the preprocessor is "a _text_ replacer."

>
> I'm interested to know: do you think that assuming that an undefined
> preprocessor symbol is "0" is a good thing, or something that wouldn't be
> improved by a compiler error saying that the symbol is undefined?

No. It would make some things much more verbose, and would only help
beginners.

> If so, why
> not extend the principle to assuming that any symbol in a C++ expression is
> an 'int'?

Non sequitur.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Pete Becker <> wrote in message
news:...
> David White wrote:
> >
> > What have I said that indicates that I don't understand it? Did I
describe
> > it wrongly?
>
> You said earlier that the preprocessor is "a _text_ replacer."

Yes, and that statement was _clearly_ made in the context of #define and
#if.

#define X Y

Doesn't this replace the symbol 'X' found anywhere in the source code with
the text 'Y'?

Also: "Because they rearrange the program text before the compiler proper
sees it, macros are..." - The C++ Programming Language (3rd ed.), page 160.

Given that macros _do_ replace text, why should an undefined symbol become
'0' rather than ''?

> > I'm interested to know: do you think that assuming that an undefined
> > preprocessor symbol is "0" is a good thing, or something that wouldn't
be
> > improved by a compiler error saying that the symbol is undefined?
>
> No. It would make some things much more verbose,

Such as?

And is the increased verbosity worse than no message from the compiler when
a symbol is used without having been defined?

Speaking of verbosity, the way to ensure that preprocessor symbols are not
silently converted to 0 is:

#if !defined(REACTOR_TYPE) || !defined(REACTOR_NEW_MODEL)
#error REACTOR_TYPE or REACTOR_NEW_MODEL not defined
#endif

Apart from the fact that if one remembers to do this then one would have
ensured that the symbols were defined, is it not verbose to place this in
every source file in which these symbols are used?

> and would only help
> beginners.

I see. So, only beginners would ever forget to ensure that both of these are
#defined somewhere?

#if REACTOR_TYPE == REACTOR_NEW_MODEL

> > If so, why
> > not extend the principle to assuming that any symbol in a C++ expression
is
> > an 'int'?
>
> Non sequitur.

void f(int reactorType)
{
// No definition of REACTOR_NEW_MODEL given
if(reactorType == REACTOR_NEW_MODEL)
{
// ...
}
}

Why should this be an error, but not the preprocessor version?

DW