#define

[David White]

Re: #define

Ron Natalie <ron@sensor.com > wrote in message
news:3f0c2841$0 $87915$9a6e19ea @news.newshosti ng.com...[color=blue]
>
> "David White" <no@email.provi ded> wrote in message[/color]
news:KbLOa.8912 $eE.124878@nasa l.pacific.net.a u...[color=blue]
>[color=green]
> >
> > Doesn't this replace the symbol 'X' found anywhere in the source code[/color][/color]
with[color=blue][color=green]
> > the text 'Y'?[/color]
>
> No, it doesn't. Pete is right, you seem not to understand the[/color]
preprocessor.

I do. I just didn't use precise enough language in this pedantic place. I am
aware that the 'X' in 'MAX' would not be replaced by 'Y'.
[color=blue][color=green]
> > Given that macros _do_ replace text, why should an undefined symbol[/color][/color]
become[color=blue][color=green]
> > '0' rather than ''?[/color]
>
> They do not replace text, they replace tokens.[/color]

Okay. Why you didn't correct Stroustrup's loose language as well? :)

Getting off the track.

DW

[David White]

Re: #define

Alexander Terekhov <terekhov@web.d e> wrote in message
news:3F0BEAEE.9 995154E@web.de. ..[color=blue]
>
> David White wrote:
> [...][color=green]
> > This is inherently unsafe. The possibility of no. 2 is the reason that[/color][/color]
C++[color=blue][color=green]
> > insists on all function definitions being present and that there is a
> > suitable match for every argument. Does not one other person here think[/color][/color]
that[color=blue][color=green]
> > this is a problem?[/color]
>
> http://groups.google.com/groups?thre...01%40hsv3.UUCP
> (Subject: Using a define that hasn't been #defined)[/color]

Thanks, Alexander. I am not alone after all.

DW

[Sam Holden]

Re: #define

On Thu, 10 Jul 2003 13:35:24 +1000, David White <no@email.provi ded> wrote:[color=blue]
> Sam Holden <sholden@flexal .cs.usyd.edu.au > wrote in message
> news:slrnbgpln5 .fft.sholden@fl exal.cs.usyd.ed u.au...[color=green]
>> On Thu, 10 Jul 2003 12:31:36 +1000,
>> David White <no@email.provi ded> wrote:[color=darkred]
>> >[/color][/color]
>[color=green]
>> Using #if in anything but a header file is madness in my opinion. I
>> guess using it to give some platform specific optimisation might be OK,
>> but I'd try and find a way to move the #if itself into a header.[/color]
>
> You can't always use C++ itself. How, for example, do you make a declaration
> depend on whether you are compiling a NORMAL or LITE version of the
> software? Suppose you also have EXTRA_LITE and PREMIUM versions. And suppose
> the following constant has a different value for each one:
>
> #if MODEL == EXTRA_LITE
> const int NrWheels = 2;
> #elif MODEL == LITE
> const int NrWheels = 4;
> // etcetera[/color]

By moving those values into the header file, since they are obviously
in some way dependant on the MODEL and hence having them in one place
rather than scattered throughout many source files is nice (even
if they are in fact only used once - it unifies the location of all
such data).

#define MODEL_NRWHEELS 2
or
#define MODEL_NRWHEELS 4

which get set by the appropriate model specific header.

and then

const int NrWheels = MODEL_NRWHEELS;

Has the disadvantage that when the code is changed, sometimes
the model header files will have to be modified as well. But
has the advantage that when adding another model you will
hopefully just have to add the appropriate header file set
a the appropriate define and all the code now works - as opposed
to finding all those #ifs and adding #elif MODEL == NEW_MODEL.
Of course in practice things never work out and you have
to modify a bit of the code.

But I'd personally be using the C++ type system rather than
#defines to tell things apart. I've been bitten by inconsistant
settings in #defines in different compile runs or files in C
too many times.

--
Sam Holden

[Paul Mensonides]

Re: #define

David White wrote:[color=blue][color=green]
>> It's not going to change. No matter how much you complain about it.[/color]
>
> Yes, I realized that very quickly. I can't even get anyone here to
> agree that anything needs to be fixed.[/color]

It isn't that I don't agree that the kind of danger you refer to doesn't exist.
Instead, its that I don't consider it a big enough problem to prohibit the
utility of the implicit conversion to 0. IMO, the benefits outweigh the costs.

Regards,
Paul Mensonides

[Ron Natalie]

Re: #define


"David White" <no@email.provi ded> wrote in message news:%G1Pa.1$sI .2864@nasal.pac ific.net.au...[color=blue]
> Ron Natalie <ron@sensor.com > wrote in message[/color]
[color=blue]
> I do. I just didn't use precise enough language in this pedantic place. I am
> aware that the 'X' in 'MAX' would not be replaced by 'Y'.[/color]

There's much more to it than that.
[color=blue][color=green]
> > They do not replace text, they replace tokens.[/color]
>
> Okay. Why you didn't correct Stroustrup's loose language as well? :)[/color]

Because Stroustrup wasn't wrong. You were. The only reference to text
on the page you reference says "the preprocessor rearranges the text ..."
He doesn't say anything specific about macro replacment
[color=blue]
> Getting off the track.[/color]

You're the one driving us there.

[David White]

Re: #define

"Ron Natalie" <ron@sensor.com > wrote in message
news:3f0d771d$0 $87855$9a6e19ea @news.newshosti ng.com...[color=blue]
>
> "David White" <no@email.provi ded> wrote in message[/color]
news:%G1Pa.1$sI .2864@nasal.pac ific.net.au...[color=blue][color=green]
> > Ron Natalie <ron@sensor.com > wrote in message[/color]
>[color=green]
> > I do. I just didn't use precise enough language in this pedantic place.[/color][/color]
I am[color=blue][color=green]
> > aware that the 'X' in 'MAX' would not be replaced by 'Y'.[/color]
>
> There's much more to it than that.[/color]

No kidding? I called the preprocessor a "text" replacer while discussing its
replacement of an undefined symbol with "0" instead of with nothing at all.
This was a correct statement. A token is composed of text. Therefore if you
replace a token you are replacing text. Then I gave an example in which my
language was not precise enough and was corrected. I accepted the correction
to the more precise term 'token' and added an example. And now I get,
completely unnecessarily, but perhaps predictably, "There's much more to it
than that". Really? What a revelation. I've just looked up "The C++
Programming Language", and (my God!), the preprocessor also has #include,
which lets you include a whole other file! And it even has macros with
parameters! And a macro can even use another macro! And there are other
things as well!
[color=blue][color=green]
> > Getting off the track.[/color]
>
> You're the one driving us there.[/color]

No, you are, with this ridiculous waste of time.

DW