Jump to content

  • Log In with Google      Sign In   
  • Create Account

Is #ifdef still preferred?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
9 replies to this topic

#1 Nairou   Members   -  Reputation: 418

Like
0Likes
Like

Posted 30 August 2007 - 06:19 AM

Reading "Effective C++" by Scott Meyers, he talks about the disadvantages of #define and how you should almost always use const or inline instead, relying on the compiler to optimize your code for the same result. That got me wondering, what about things like #ifdef? For example, will the compiler optimize the following two examples into the same thing? If so, I wonder if there are any advantages of one over the other. The second seems more friendly to me, less hackish than the first.
#define IS_SERVER 1

// ...
#ifdef IS_SERVER
    // ... server code ...
#endif
// ...
const int isServer = 1;

// ...
if ( isServer ) {
    // .. server code ...
}
// ...


Sponsor:

#2 Sneftel   Senior Moderators   -  Reputation: 1781

Like
0Likes
Like

Posted 30 August 2007 - 06:23 AM

Quote:
Original post by Nairou
For example, will the compiler optimize the following two examples into the same thing?

For most modern compilers, yes. To make sure of it, though, it's a good idea to force internal linkage of constants used in this way (by declaring the variable as static, or putting it in an anonymous namespace). The compiler is much less likely to be able to do this with constants defined in a different translation unit.

However, the code still needs to be syntactically and semantically correct. So using const variables may not be the right approach if you're implementing different functionality for each branch, as you seem to be doing here.

#3 Palidine   Members   -  Reputation: 1279

Like
0Likes
Like

Posted 30 August 2007 - 06:23 AM

The idea of using #define for constants is bad. But using pre-processor things for determining platform and such is what you must do if you want easily configured code.

to explain further, this is often considered "bad":

#define PI 3.14156




it is now generally preferred to be

const FLOAT PI = 3.14159f;





however, your example of using const for isServer is horrible. That's the kind of thing you want to control in your compiler setttings (i.e. you set up a configuration for client, one for server, one for linux, etc). With the const example you have to actually change code every time you want to compile for a different platform.

-me

#4 Josh Petrie   Moderators   -  Reputation: 3115

Like
0Likes
Like

Posted 30 August 2007 - 06:24 AM

Meyers is talking about #define for constants, not for preprocessor control over code generation, which is what your example is. The first method is the correct way to handle the situation.

#5 Bregma   Crossbones+   -  Reputation: 5133

Like
0Likes
Like

Posted 30 August 2007 - 06:53 AM

Quote:
Original post by Nairou
That got me wondering, what about things like #ifdef? For example, will the compiler optimize the following two examples into the same thing? If so, I wonder if there are any advantages of one over the other. The second seems more friendly to me, less hackish than the first.

Most popular compilers will elide the unreachable code, making the two implementations act as if they do the same thing.

There are fundamental differences, however, and most of the advantages go to the preprocessor construct in this case.

(1) A preprocessor value can be set extralingually (usually through a command-line option to the compiler, such as -DIS_SERVER=1). Thus, you can autodetect and set various compile-time options, something you can't do using C++ constants.

(2) Code within an #ifdef block is never even seen by the compiler. That means if you have, say, functions calls that do not exist on some platforms then you can still compile your code. For example,

#ifdef _WIN32
int istat = WSAStartup( ... );
#endif

You can't do that at all using C++ constants. You would have to revert to some kind of wacky template specialization.

Quote:
Original post by SneftelFor most modern compilers, yes. To make sure of it, though, it's a good idea to force internal linkage of constants used in this way (by declaring the variable as static, or putting it in an anonymous namespace).

Simply putting it in an anonymous namespace forces external linkage. If you want internal linkage you will have to make it static, regardless of the namespace in which you put it (don't forget "global" is just a namespace like any other).

--smw

#6 rip-off   Moderators   -  Reputation: 8210

Like
0Likes
Like

Posted 30 August 2007 - 07:09 AM

Quote:

To make sure of it, though, it's a good idea to force internal linkage of constants used in this way (by declaring the variable as static, or putting it in an anonymous namespace).

Quote:

Simply putting it in an anonymous namespace forces external linkage.


Ok. 2 things I thought I knew about C++ questioned in this thread.

1) I thought const variables had internal linkage by default (I thought this is why you can place them in headers).
2) I also thought anything in an anonymous namespace had internal linkage. (how does one refer to something in an anonymous namespace in a different source file anyway?)

I could easily be wrong, but can anyone clarify?

#7 Sneftel   Senior Moderators   -  Reputation: 1781

Like
0Likes
Like

Posted 30 August 2007 - 07:17 AM

It looks like I was partially wrong about anonymous namespaces. Names declared in an anonymous namespace are only visible to the translation unit, but have external linkage. Of course, for this particular purpose name visibility is the important thing, so it'll work fine--as will just declaring it const, since that defaults to internal linkage.

#8 Xai   Crossbones+   -  Reputation: 1450

Like
0Likes
Like

Posted 30 August 2007 - 07:17 AM

To state all the above great things as a general guidline:

In the old days of C / C++, people used the preprocessor to do anything it could do, often doing things with the preprocessor that could be done in code simply to improve compiler performance, or make the generated output more efficient (when compilers weren't as advanced).

Now, the preference is:

Use the preprocessor for anything to do with controlling compilation.

Use the compiler and language constructs for anything to do with controlling program logic and data.

Simple, easy to remember, and correct almost every time.


#9 Iftah   Members   -  Reputation: 409

Like
0Likes
Like

Posted 01 September 2007 - 08:14 PM

If you have certain code for server and other code for client - maybe you can put the code in different files and use the project settings (ie. makefile) to build the right files.
In my project I have "common" files, server files and client files, and several makefiles (one for server and one for client).

But of course, it works if the code is clearly separated and doesn't solve the entire need for ifdef style compilation control.

#10 ToohrVyk   Members   -  Reputation: 1591

Like
0Likes
Like

Posted 01 September 2007 - 08:18 PM

As a side note, Visual C++ 2005 will "grey out" code within #ifdef X #endif whenever X is not defined. It obviously doesn't do this when using if(x).

Also, to expand on what Bregma said, not only do you have problems with platform-specific functions, you'll also have trouble with including platform-specific headers.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS