const debug variable optimized away if false?

[Markus Dehmann]

I have a
static const bool debug = false;
variable in my class. Debug output goes like this, trivially:
if(debug) cerr << "debug message";

Is it guaranteed that this if/then clause is always optimized away if the
debug variable is false?

Thanks!
Markus

[Victor Bazarov]

"Markus Dehmann" <ma************@gmail.com> wrote...

I have a
static const bool debug = false;
variable in my class. Debug output goes like this, trivially:
if(debug) cerr << "debug message";

Is it guaranteed that this if/then clause is always optimized away if the
debug variable is false?

Nope. Nothing is guaranteed when it comes to optimisation. Unless
you remove it yourself somehow, it may still be there.

The more generically guaranteed approach is to use a macro that would
expand to nothing if NDEBUG is defined:

#ifndef NDEBUG
#define PRINTDEBUGMESSAGE(a) cerr << (a)
#else
#define PRINTDEBUGMESSAGE(a)
#endif

Now, when you use

PRINTDEBUGMESSAGE("debug message");

in your code, it will be an empty statement if NDEBUG is defined (usually
so in release builds).

Similar approach can be taken to output more than one item at a time.

V

[Evan]

Nope.

For instance, if you compile debugging information into your
executable, many compilers will not optimize because a lot of
optimizations (e.g. inlining) screw with the debugger.

If you want to be 100% positive it's not there, I'm pretty sure you
have to use the preprocessor. I would do something like this:

#ifdef DEBUG
#define DEBUG_PRINT(string) cerr << (string)
#elseif
#else
#define DEBUG_PRINT(string)
#endif

(Probably there are a couple subtle errors there. I don't know whether
to put the ; in the macro or not either.)

Then you just do DEBUG_PRINT("debug message");
That said, if you compile with optimizations the compiler almost
certainly will do it.

You could always look at the assembly output and see too be sure.

(There are things you could do to increase the chance nothing would be
there, but I don't think it's worth it.)

[rajkumar]

most commercial grade compilers will optimize it away. But the standard
doesn't guarantee it

Check the assembly generated and see it actually happens for your
compiler. Also most compilers dont perform optimizations by default for
a DEBUG build

Raj

[Evan]

Wow, I swear I didn't see your post before making mine...

(Also I noted an extranious #elseif in mine; get rid of that. That's me
being really tired.)

[Andre Kostur]

Markus Dehmann <ma************@gmail.com> wrote in news:3a0ipdF66migkU1
@individual.net:

I have a
static const bool debug = false;
variable in my class. Debug output goes like this, trivially:
if(debug) cerr << "debug message";

Is it guaranteed that this if/then clause is always optimized away if the
debug variable is false?

No. Quality of Implementation issue. Depends on your compiler.

[Pete Becker]

ra******@hotmail.com wrote:

most commercial grade compilers will optimize it away. But the standard
doesn't guarantee it

On the other hand, a well-formed program can't tell whether that code
has been optimized away, because it has no observable behavior.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Just that]

Pete Becker <pe********@acm.org> wrote in message news:<pP********************@giganews.com>...

ra******@hotmail.com wrote:

most commercial grade compilers will optimize it away. But the standard
doesn't guarantee it

On the other hand, a well-formed program can't tell whether that code
has been optimized away, because it has no observable behavior.

When will I be able to observe my program's behavior ?
What is a well-formed program ? may i ask you, a member of acm ????

Thank you

[Pete Becker]

Just that wrote:

When will I be able to observe my program's behavior ?
What is a well-formed program ?

A well-formed program is one that conforms to the requirements of the
C++ Standard. Observable behavior is printed output, etc. If that code
is never executed, the output you see won't depend on whether the code
is left in the executable or removed.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Markus Dehmann]

Just that wrote:

Pete Becker <pe********@acm.org> wrote in message
news:<pP********************@giganews.com>...

ra******@hotmail.com wrote:

> most commercial grade compilers will optimize it away. But the standard
> doesn't guarantee it
>

On the other hand, a well-formed program can't tell whether that code
has been optimized away, because it has no observable behavior.

When will I be able to observe my program's behavior ?
What is a well-formed program ? may i ask you, a member of acm ????

A certain slowdown might be measurable, though. Execution speed is a form of
"observable behavior," I'd say.

Markus

[Jonathan Turkanis]

Markus Dehmann wrote:

Just that wrote:

Pete Becker <pe********@acm.org> wrote in message
news:<pP********************@giganews.com>...

ra******@hotmail.com wrote:
most commercial grade compilers will optimize it away. But the
standard doesn't guarantee it
On the other hand, a well-formed program can't tell whether that
code has been optimized away, because it has no observable behavior.

When will I be able to observe my program's behavior ?
What is a well-formed program ? may i ask you, a member of acm ????

A certain slowdown might be measurable, though. Execution speed is a
form of "observable behavior," I'd say.

I believe Pete was summarizing the standard's notion of observable behavior --
assuming that his "etc" includes something about volatile data. ;-)

Jonathan

[Pete Becker]

Markus Dehmann wrote:

A certain slowdown might be measurable, though. Execution speed is a form of
"observable behavior," I'd say.

Not according to the language definition.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)