c++ build question

[Angus]

Hello

I hope this is an ok topic for this forum.

When I compile a C++ file I can specify on the command line a macro.
In my compiler it can be eg /D "_DEBUG". But on my command line I can
also specify /Od - which disables optimisations. Are they the same
thing?

I can also use #define _DEBUG in my source file. Does that have the
same effect as the command line /D "DEBUG"?

A

 

[Rolf Magnus]

Hello

I hope this is an ok topic for this forum.

When I compile a C++ file I can specify on the command line a macro.
In my compiler it can be eg /D "_DEBUG". But on my command line I can
also specify /Od - which disables optimisations. Are they the same
thing?

Not sure what you're asking here. Why would you suspect that setting the
compiler optimiziation level is the same as defining a macro?

I can also use #define _DEBUG in my source file. Does that have the
same effect as the command line /D "DEBUG"?

I would expect that. It might depend on the compiler though. The compiler's
manual should tell you more.

 

[Richard]

[Please do not mail me a copy of your followup]

Angus <[email protected]> spake the secret code

When I compile a C++ file I can specify on the command line a macro.
In my compiler it can be eg /D "_DEBUG". But on my command line I can
also specify /Od - which disables optimisations. Are they the same
thing?

Nope. One defines a macro (there is nothing special about "_DEBUG";
it is simply a convention). The other changes how optimizations are
applied to the generated code.

I can also use #define _DEBUG in my source file. Does that have the
same effect as the command line /D "DEBUG"?

Yes, as long as you define the macro at the beginning of the source
file before anything else is included that depends on the macro.
The only difference between the two is that the command-line switch
sets the macro before the file is processed whereas #define defines
the macro at the location of the #define. Things that might depend on
the macro before the #define are not affected by it.

 

[James Kanze]

I hope this is an ok topic for this forum.

When I compile a C++ file I can specify on the command line a
macro.

Formally, the C++ standard doesn't say anything about this.
But in practice, yes; every compiler has some means of
"predefining" preprocessor variables (and every compiler also
has a few that are automatically predefined as well). For that
matter, every compiler I've seen uses the D option (typically
-D, but /D is generally accepted under Windows as well), with
some variation as to whether there can be a space between the D
and the preprocessor symbol. (In other words, "-D_DEBUG" can be
used more or less portably. But since most of the rest of the
command line is totally unportable, it really doesn't matter.)

In my compiler it can be eg /D "_DEBUG". But on my command
line I can also specify /Od - which disables optimisations.
Are they the same thing?

No. The "/O" part and the "/D" part are the same thing:
compiler options (or directives). The first directs the
compiler to pre-define the following symbol; the second directs
it configure optimization according to the following flags.

I can also use #define _DEBUG in my source file. Does that
have the same effect as the command line /D "DEBUG"?

As /D _DEBUG? More or less, provided the #define _DEBUG is the
first line of your program (e.g. before any includes).

Note that _DEBUG is a special symbol, whose effects are defined
by the standard, and that it is not designed to be defined in
the command line or at the top of the code, but rather somewhere
within the code, before including <assert.h> (for a second
time), so that you only turn off assertions around the critical
block, and not everywhere.

 

[robertwessel2]

Formally, the C++ standard doesn't say anything about this.
But in practice, yes; every compiler has some means of
"predefining" preprocessor variables (and every compiler also
has a few that are automatically predefined as well).  For that
matter, every compiler I've seen uses the D option (typically
-D, but /D is generally accepted under Windows as well), with
some variation as to whether there can be a space between the D
and the preprocessor symbol.  (In other words, "-D_DEBUG" can be
used more or less portably.

And to mention everyone's favorite exception to the rules, the
compiler for zOS accepts that option in the form: "DEFINE
(name=value)". And the options are in a comma separated list.

 

[James Kanze]

James Kanze wrote:

Umm, that's NDEBUG. _DEBUG is often used to indicate a debug
build, but that's a convention, not a requirement.

Oops. And the _DEBUG convention is doubtlessly one from the
compiler implementer (or implementers, since it is likely used
by more than one), since the name is in the implementation's
namespace.

In practice, you do want something other than NDEBUG, since what
you want around the time critical parts is something like:

#ifdef _DEBUG
#define NDEBUG
#include <assert.h>
#endif

// Critical function...

#undef NDEBUG
#include <assert.h>

(Although in practice, I find that just having one flag for
debug, in such cases, is awkward. You often want different
levels, rather than an on/off switch, and you often want
different subsystems to use different levels.)

 

[Anand Hariharan]

[Please do not mail me a copy of your followup]
(...)

I can also use #define _DEBUG in my source file.  Does that have the
same effect as the command line /D "DEBUG"?

Yes, as long as you define the macro at the beginning of the source
file before anything else is included that depends on the macro.
The only difference between the two is that the command-line switch
sets the macro before the file is processed whereas #define defines
the macro at the location of the #define.  Things that might depend on
the macro before the #define are not affected by it.

When it is defined in the file, it is no longer an option for the
build process to switch between debug and release.