quote: Original post by Miserable
I could very possibly be wrong, but it occurs to me that the reason why Microsoft''s headers use #defines could be that they are used for C (which, as I recall, does not support const-type constants) as well. I don''t know this, but I do know that DirectX can be invoked in C as well as C++.

Yes, DX can be used from C, too. I never did it, and I assume that it''s a pain in the ars, like all COM stuff you want to use from plain C.

#define are nice to use if you are entering the IOCCC contest :->
Otherwise, they are useful for dynamically chosing portions of your code to compile.

say you have :
...
//very important code
#ifdef DEBUG_MODE
cerr<<"Something to help me debug this program\n";
#endif
...

now all you have to do is to put a #define DEBUG_MODE at the beginning of your file, and all statements such like the one above wont be compiled. The difference between this and something like a command line argument would be that the code wouldnt be COMPILED at all, meaning the program would take less space, and essentially be faster.

similarly, you could have something like
#ifdef DOS_COMPILE
//something for DOS specific system
#elif WIN95_COMPILE
//something else
#elif WIN2K_COMPILE
//and something even different
#endif

you get the idea, depending on what you #define at the beginning of your file, only one portion of code will be compiled.

it's actually pretty cool.

another useful thing (and you'll see that happen often in visual C++ if you have large projects), is to avoid putting the same stuff several times.
namely, you might need a particular header file for some file.
but imagine that you also need that particular header file in one of the other header files called; say you have :

types.h is a file that define a few essential types for your project. and globals.h is a file with a few globals.
now, globals.h has a #include "types.h" in it.
Now, imagine you are coding a new file where you make use of those types and globals.
You could include only types.h knowing that it itself include globals.h , right ?
Yes, but trust me, it's a real bad idea.
The nice way is this.
In your header files you put (after any necessary #include statements)

//TYPES_H is for types.h, but you could put anything else, and you have to put something different for each header file.
#ifndef TYPES_H
#define TYPES_H
//type all your stuff
#endif

That's it. Now when you include types.h in any file of your project, the compiler checks if the #define exists.
If it already exists, it means that all the code inside the #ifndef ...#endif has been processed, hence has already been included
Otherwise, it #define what it needs, and all the code gets compiled.

Nice, hey ?
I wish I had known that when I was in first year...


Sancte Isidore ora pro nobis !

[EDIT] Just fixing the link. Use "< / a >" to close instead of "< / href >"

[edited by - michalson on May 15, 2002 11:25:44 AM]

as for the MFC library windows stuff and directx they dont like namespaces at microsoft. i mean they implemented it but nobody is going to force them to engineer with it. its not at all a standard engineering practice to see namespaces as "good"

whats their downside? none really =)


as for #defines scope. its a .cpp file level scope. which aint so bad.

are consts better. ya but not drastically better. they are a slight improvement.


NOW! the original poster asked should he
= a string
or
= a symbol.

as a good habit. use the symbol. one giant file. if your doing it by hand do the "mysymbols.h" use commented to chunk it up. let every .cpp file #include it. if your using vc++ i say use the string table in the resource. all that is is a global repository of #defines.

why all in one file? its a pain to have to remember where _this_ string literal is at. just use one big consistant file makes it easy to add changes later.

quote: Original post by declspec
its not at all a standard engineering practice to see namespaces as "good"

I don''t know how namespaces have crept into a thread about using the preprocessor for defining constants. Still, the "standard" engineering practice is to view namespaces as "useful". You can''t view any particular construct as "good" or "bad" independently from usage context.

[ C++ FAQ Lite | ACCU | Boost | Python | Agile Manifesto! ]

quote: Original post by ahw
... they are useful for dynamically chosing portions of your code to compile.

say you have :
...
//very important code
#ifdef DEBUG_MODE
cerr<<"Something to help me debug this program\n";
#endif
...

now all you have to do is to put a #define DEBUG_MODE at the beginning of your file, and all statements such like the one above wont be compiled. The difference between this and something like a command line argument would be that the code wouldnt be COMPILED at all, meaning the program would take less space, and essentially be faster.
...

I can understand using #DEFINE in this context, just not in place of a const -- you couldn''t use a const to do the above (obviously). #DEFINEs are very useful for conditional compiling, I''m just not sure of their use as constants.

quote: Original post by Useless Hacker
I can understand using #DEFINE in this context, just not in place of a const -- you couldn''t use a const to do the above (obviously). #DEFINEs are very useful for conditional compiling, I''m just not sure of their use as constants.

Agreed
I was just pointing out some use of the #define command.
As a matter of fact, I think it''s really a matter of personal preferences.
For a beginner (or for my students), I tell them to use ''const'' as it teaches them the importance of types.
But when you are more experienced, I think it''s not really necessary to use ''const'' anymore as they use memory and it''s not really necessary.


Sancte Isidore ora pro nobis !

quote: Original post by SabreMan
I don''t know how namespaces have crept into a thread about using the preprocessor for defining constants. Still, the "standard" engineering practice is to view namespaces as "useful". You can''t view any particular construct as "good" or "bad" independently from usage context.

quote: Original post by SabreMan
The bigger problems with #defines are that they do not respect scope boundaries, thus violate the rule of thumb "define variables in the narrowest applicable scope". Also, since they are preprocessed, they compromise the ability of tools to provide useful information, such as compiler diagnostics.

Not to be provocative - but it looks like you introduced the notion of scope - and namespace followed from there. Maybe you could elaborate more as the topic is an interesting one.

They might be good to use as many pros use them(such as Andre Lamothe in game programming for dummies).But he could just have used them to make it simpler.

quote: Original post by declspec
as for #defines scope. its a .cpp file level scope. which aint so bad.

Uhmm... they would be in scope for the entire compilation unit, not just the .cpp.

Quick note on "M$"

Apparently all their good programmers were working on .NET

The .NET framework abides by every single standard that they have defined, which are all based on quite a few studies of programming practices.

Namespaces, Casing and other common confusions faced by C++ are eleminated by the strict, but simple, standards.

As for the defines vs constants in the DX header files... yes those are indeed not constants to provide compatability with older versions of DX and C.

This backwards compatability is the largest offender for crazy standard unconformities because it is clear that Microsoft''s old code base was formulated by a very, very inexperianced company (as anyone can see just by using the Windows API)

I think that its time to stop bashing Microsoft and start begging them for a complete, from scratch, rewrite of their code bases. However unplausable that sounds :-)

So bottom line, use the "const" instead of "define" for your projects.

-SniperBoB-