![]() |
|
|
|
#1 |
|
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 Angus |
|
|
|
|
#2 |
|
Posts: n/a
|
Angus wrote:
> 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. Rolf Magnus |
|
|
|
#3 |
|
Posts: n/a
|
[Please do not mail me a copy of your followup]
Angus <> spake the secret code <14518834-6abe-462a-b76d-> thusly: >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. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com> Richard |
|
|
|
#4 |
|
Posts: n/a
|
On Nov 1, 11:02 am, Angus <anguscom...@gmail.com> wrote:
> 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. -- James Kanze James Kanze |
|
|
|
#5 |
|
Posts: n/a
|
On Nov 2, 4:08*am, James Kanze <james.ka...@gmail.com> wrote:
> On Nov 1, 11:02 am, Angus <anguscom...@gmail.com> wrote: > > > 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. 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. robertwessel2@yahoo.com |
|
|
|
#6 |
|
Posts: n/a
|
On Nov 2, 12:04 pm, Pete Becker <p...@versatilecoding.com> wrote:
> James Kanze wrote: > > 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. > 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.) -- James Kanze James Kanze |
|
|
|
#7 |
|
Posts: n/a
|
On Nov 1, 9:40*am, legalize+jee...@mail.xmission.com (Richard) wrote:
> [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. Anand Hariharan |
|
![]() |
| Thread Tools | Search this Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Re: Israel IS the problem | Dan C | Computer Support | 8 | 06-01-2009 01:45 PM |
| French And CERN Build Massive Particle Accelerator (Black Hole Generator) Unknown Planetary Risk To Create BIG BANG | Doomsday Machine | Computer Support | 1 | 05-01-2008 06:36 PM |
| Technical Analysis programs 2006-2004 of stocks/commodities/futures markets, other Financial software | kashumoto_tokugawa | Computer Information | 0 | 11-07-2006 04:33 PM |
| My Network Places ... Question | Boy Meets Web | Computer Support | 1 | 08-11-2005 04:05 PM |
| SWsoft Acronis Disk Director Suite 9.0 Build 508, Acronis OS Selector 8.0 Build 917, Acronis Partition Expert 2003 Build 292, Acronis Power Utilities 2004 Build 502, F-SECURE.ANTI vIRUS.PROXY v1.10.17.WINALL, F-SECURE.ANTI vIRUS v5.50.10260 for CITRI | vvcd | Computer Support | 0 | 09-25-2004 02:38 AM |