I miss my preprocessor!

java-programmer, I miss my preprocessor! There's one thing I really used the C/C++ preprocessor for, and that is
compile-time control of debugging statements.

in it's simplest form:
----------------------------------------------
// comment out this line to disable debugs
#define DEBUG 1

#ifdef DEBUG
# define dbg(msg) printf(msg)
#else
# define dbg(msg)
#endif

void main(int argc, char argv[][])
{
dbg("Some sorta message\n");
}
----------------------------------------------

This system had evolved to a very powerful mechanism for
enabling/disabling/removing debug statements from my code. The beauty of it
is that debugging code can be removed
entirely from released code, without removing from the source. (I like
leaving it in the source because it provides a sort of ancillary
documentation). The only shortcoming was the lack of variable macro
parameters in C/C++.

The nearest I could come up with in java is:
----------------------------------------------
class xxx
{
private static final boolean DEBUG=true; // set to false to turn
off debugging
void dbg(String msg)
{
if (DEBUG) // this gets optimized out
System.out.print(msg);
}

public static void main( String[] args )
{
if (DEBUG) dbg("Some sorta message\n");
}
} // xxx
----------------------------------------------
While this does seem to work, it relies on the compiler to implicitly
optimize the code out. Not that I don't trust the compiler, but how can I
prove it?
From an aesthetic point of view, the "if (DEBUG)" part seems to clutter up
the source.
And it leaves a stub for dbg() in the code.

My point is, what options are available to reproduce the desired mechanism?
(Don't give me anything from java 1.5/5.0; I can't use it till it is
officially released, and the major ide manufactures endorse it).

regards,
Dar7yl (the 7 is silent)

java-programmer >> I miss my preprocessor! dar7yl wrote:

> My point is, what options are available to reproduce the desired mechanism?

Take a look at aspectj. You should be able to turn debug statements to
no-op or redirect it to any logging listener you will like to.

As a side effect, you might be able to remove large number of your debug
statements, as aspectj can generate them for you in some places.

Artur

java-programmer >> I miss my preprocessor!
"dar7yl" <email***@***.com> wrote in message
news:0jPRc.51443$yT2.44212@clgrps13...
> There's one thing I really used the C/C++ preprocessor for, and that is
> compile-time control of debugging statements.
>
> in it's simplest form:
> ----------------------------------------------
> // comment out this line to disable debugs
> #define DEBUG 1
>
> #ifdef DEBUG
> # define dbg(msg) printf(msg)
> #else
> # define dbg(msg)
> #endif
>
> void main(int argc, char argv[][])
> {
> dbg("Some sorta message\n");
> }
> ----------------------------------------------
>
> This system had evolved to a very powerful mechanism for
> enabling/disabling/removing debug statements from my code. The beauty of
it
> is that debugging code can be removed
> entirely from released code, without removing from the source. (I like
> leaving it in the source because it provides a sort of ancillary
> documentation). The only shortcoming was the lack of variable macro
> parameters in C/C++.
>
> The nearest I could come up with in java is:
> ----------------------------------------------
> class xxx
> {
> private static final boolean DEBUG=true; // set to false to
turn
> off debugging
> void dbg(String msg)
> {
> if (DEBUG) // this gets optimized out
> System.out.print(msg);
> }
>
> public static void main( String[] args )
> {
> if (DEBUG) dbg("Some sorta message\n");
> }
> } // xxx
> ----------------------------------------------
> While this does seem to work, it relies on the compiler to implicitly
> optimize the code out. Not that I don't trust the compiler, but how can I
> prove it?
> From an aesthetic point of view, the "if (DEBUG)" part seems to clutter
up
> the source.
> And it leaves a stub for dbg() in the code.
>
> My point is, what options are available to reproduce the desired
mechanism?
> (Don't give me anything from java 1.5/5.0; I can't use it till it is
> officially released, and the major ide manufactures endorse it).
>
> regards,
> Dar7yl (the 7 is silent)
>

Someone correct me if I'm wrong, but if you do something like this:

public static final boolean DEBUG = true;

...

if(DEBUG) System.out.println("message");

----------

It should do the same thing. To remove the debug code, all you have to do
is change DEBUG to:

public static final boolean DEBUG = false;

---

The Java compiler should remove all debug code in this case, since it can
statically determine at compile time that DEBUG is always false. It is able
to do this because we have declared DEBUG to be 'final'.

l8r, Mike N. Christoff

java-programmer >> I miss my preprocessor!
"Michael N. Christoff" <email***@***.com> wrote in message
news:eVQRc.11067$email***@***.com...
>
> Someone correct me if I'm wrong, but if you do something like this:
>
> public static final boolean DEBUG = true;
> if(DEBUG) System.out.println("message");
>
> It should do the same thing. To remove the debug code, all you have to do
> is change DEBUG to:
>
> public static final boolean DEBUG = false;
>

Didn't I just say that?

>
> The Java compiler should remove all debug code in this case, since it can
> statically determine at compile time that DEBUG is always false. It is
> able
> to do this because we have declared DEBUG to be 'final'.
>

I said that as well, but I also remarked that there is no way to verify that
the compiler will actually do this, now, and in the future. With the C/C++
preprocessor, I am always confident that the code will not be generated.
With java, there is always the possibility that there will still be
reminants in the compiled code.
Btw, is this optimization actually specified in the java standard?

regards,
Dar7yl

java-programmer >> I miss my preprocessor!
"dar7yl" <email***@***.com> wrote in message
news:FDRRc.51235$hw6.17489@edtnps84...
>
> "Michael N. Christoff" <email***@***.com> wrote in
message
> news:eVQRc.11067$email***@***.com...
> >
> > Someone correct me if I'm wrong, but if you do something like this:
> >
> > public static final boolean DEBUG = true;
> > if(DEBUG) System.out.println("message");
> >
> > It should do the same thing. To remove the debug code, all you have to
do
> > is change DEBUG to:
> >
> > public static final boolean DEBUG = false;
> >
>
> Didn't I just say that?
>

Sorry. I wasn't paying enough attention.

> >
> > The Java compiler should remove all debug code in this case, since it
can
> > statically determine at compile time that DEBUG is always false. It is
> > able
> > to do this because we have declared DEBUG to be 'final'.
> >
>
> I said that as well, but I also remarked that there is no way to verify
that
> the compiler will actually do this, now, and in the future. With the
C/C++
> preprocessor, I am always confident that the code will not be generated.
> With java, there is always the possibility that there will still be
> reminants in the compiled code.
> Btw, is this optimization actually specified in the java standard?
>

I don't think so, but I would be surprised if any modern compiler would not
use such an obvious trick. ie: I'm pretty sure the Java 1.4+ compilers from
BEA, IBM, and Sun do this.

l8r, Mike N. Christoff

java-programmer >> I miss my preprocessor! dar7yl wrote:
> "Michael N. Christoff" <email***@***.com> wrote in
message
[snip]
>> The Java compiler should remove all debug code in this case, since it can
>> statically determine at compile time that DEBUG is always false. It is
>> able
>> to do this because we have declared DEBUG to be 'final'.
>>
>
> I said that as well, but I also remarked that there is no way to verify
that
> the compiler will actually do this, now, and in the future. With the
C/C++
> preprocessor, I am always confident that the code will not be generated.
> With java, there is always the possibility that there will still be
> reminants in the compiled code.
> Btw, is this optimization actually specified in the java standard?

it's mentioned, but not mandated. i don't know of a compiler that does not
perform it, though---after all it's quite trivial to do.

jls, section 14.20
http://java.sun.com/docs/books/jls/second_edition/html/statements.doc.html#237366

-- j

java-programmer >> I miss my preprocessor! "dar7yl" <email***@***.com> wrote in
news:0jPRc.51443$yT2.44212@clgrps13:

> There's one thing I really used the C/C++ preprocessor for, and that
> is compile-time control of debugging statements.
>
> in it's simplest form:
> ----------------------------------------------
> // comment out this line to disable debugs
> #define DEBUG 1
>
> #ifdef DEBUG
> # define dbg(msg) printf(msg)
> #else
> # define dbg(msg)
> #endif
>
> void main(int argc, char argv[][])
> {
> dbg("Some sorta message\n");
> }
> ----------------------------------------------
>
> This system had evolved to a very powerful mechanism for
> enabling/disabling/removing debug statements from my code. The beauty
> of it is that debugging code can be removed
> entirely from released code, without removing from the source. (I
> like leaving it in the source because it provides a sort of ancillary
> documentation). The only shortcoming was the lack of variable macro
> parameters in C/C++.
>
> The nearest I could come up with in java is:
> ----------------------------------------------
> class xxx
> {
> private static final boolean DEBUG=true; // set to false to
> turn
> off debugging
> void dbg(String msg)
> {
> if (DEBUG) // this gets optimized out
> System.out.print(msg);
> }
>
> public static void main( String[] args )
> {
> if (DEBUG) dbg("Some sorta message\n");
> }
> } // xxx
> ----------------------------------------------
> While this does seem to work, it relies on the compiler to implicitly
> optimize the code out. Not that I don't trust the compiler, but how
> can I prove it?
> From an aesthetic point of view, the "if (DEBUG)" part seems to
> clutter up the source.
> And it leaves a stub for dbg() in the code.
>
> My point is, what options are available to reproduce the desired
> mechanism? (Don't give me anything from java 1.5/5.0; I can't use it
> till it is officially released, and the major ide manufactures endorse
> it).
>
> regards,
> Dar7yl (the 7 is silent)
>
>

Would it really cost that much to have a class with a static 'Logger'
reference and a static init or method that chooses between a NullLogger and
a DebugLogger. The runtime enviroment should quickly notice that it can
short out the empty implementation. Even if it didn't, what would the cost
be of calling an empty function a couple thousand times? Or using the code
you posted without the local "if(DEBUG)". How much are you really saving by
eliminating the call site? It seems that this is an as yet unjustified
optimization.

A Logging Class would also allow you to turn it on and off with an
eviroment/commandline flag rather than a recompile. For that matter, it
could be toggled inside the program if you wanted to add a way to get to
it.

I've never been fond of the "#ifdef DEBUG #define" trick. It has some uses
but seems too devious. Compile flags changing my code and the execution
path. Now you have to be side effect free. Its not that hard but its
another thing to worry about. And I have caught people messing it up.

Otis

java-programmer >> I miss my preprocessor! Otis Bricker wrote:

> Would it really cost that much to have a class with a static 'Logger'
> reference and a static init or method that chooses between a NullLogger and
> a DebugLogger. The runtime enviroment should quickly notice that it can
> short out the empty implementation. Even if it didn't, what would the cost
> be of calling an empty function a couple thousand times? Or using the code
> you posted without the local "if(DEBUG)". How much are you really saving by
> eliminating the call site? It seems that this is an as yet unjustified
> optimization.

There is a difference in argument handling. Even if implementation is
empty, jvm cannot omit argument creation. So, if you will do

Logger.log("Current value" + compositeObject.toString());

new StringBuffer will be created and compositeObject.toString() method
will be called (which can be possibly quite heavy plus include creation
another StringBuffer/String instance).

On the other hand,
if (DEBUG) Logger.log("Current value" + compositeObject.toString());
will help here - because argument won't be created if DEBUG is false.
But question is how to write it in different way with same
optimalization. My answer is AOP.

Artur

java-programmer >> I miss my preprocessor! dar7yl <email***@***.com> wrote or quoted:

> There's one thing I really used the C/C++ preprocessor for, and that is
> compile-time control of debugging statements.
>
> in it's simplest form:
> ----------------------------------------------
> // comment out this line to disable debugs
> #define DEBUG 1
>
> #ifdef DEBUG
> # define dbg(msg) printf(msg)
> #else
> # define dbg(msg)
> #endif

[...]

> This system had evolved to a very powerful mechanism for
> enabling/disabling/removing debug statements from my code. The beauty of it
> is that debugging code can be removed
> entirely from released code, without removing from the source. [...]

Much the same works in Java.

> The nearest I could come up with in java is:
> ----------------------------------------------
> class xxx
> {
> private static final boolean DEBUG=true; // set to false to turn
> off debugging
> void dbg(String msg)
> {
> if (DEBUG) // this gets optimized out
> System.out.print(msg);
> }
>
> public static void main( String[] args )
> {
> if (DEBUG) dbg("Some sorta message\n");
> }
> } // xxx
> ----------------------------------------------
> While this does seem to work, it relies on the compiler to implicitly
> optimize the code out. Not that I don't trust the compiler, but how can I
> prove it?

Why do you want to prove it. It /does/ normally happen. If you want to
produce brief code you should be using a squeezing tool anyway - and not
relying on the compiler to produce maximally short code.

> From an aesthetic point of view, the "if (DEBUG)" part seems to clutter up
> the source.

Worse than #ifdef DEBUG?

That doesn't just clutter up the source code - it clutters up the whole
language by introducing an unnecessary construct - a second sort of if
statement - making the job of parsers harder.

> And it leaves a stub for dbg() in the code.

So: use a logging class - so your log statement looks like
Log.dbg("msg");

A few extra keystrokes - but a /lot/ neater than putting a dbg(...)
method in every single class.
--
__________
|im |yler http://timtyler.org/ email***@***.com Remove lock to reply.

java-programmer >> I miss my preprocessor!
"Tim Tyler" <email***@***.com> wrote in message news:email***@***.com...
> dar7yl <email***@***.com> wrote or quoted:
>
>> From an aesthetic point of view, the "if (DEBUG)" part seems to clutter
>> up
>> the source.
>
> Worse than #ifdef DEBUG?
>

The "#ifdef DEBUG" is actually not in the source, but is included in the
header, eg:
#include debug.h
(didn't I say that the example I gave was the simplest form? the mechanism
I use is fairly elaborate, with the ability to selectivly turn on/off debugs
by module, level, and other criteria.

The only inclusion within the body of the source (beside the include, and a
few defines to outline the parameters) is the dbg(...) statements. My point
is that the C/C++ preprocessor can control the generation of source with
three letters: 'd' 'b' 'g', while java requires
"if (DEBUG) dbg"... .

>> And it leaves a stub for dbg() in the code.
>
> So: use a logging class - so your log statement looks like
> Log.dbg("msg");
>
> A few extra keystrokes - but a /lot/ neater than putting a dbg(...)
> method in every single class.

didn't I say that the example I gave was the simplest form? I actually have
created a logging class, but I still have the stub:
void dbg( String msg)
{
if (DEBUG)
Logger.dbg(msg);
}

While this does add one level of subroutine call to the debug when it is
enabled, but it avoids a class call when not.

In C/C++, I could have put the stub into a header, and inlined it.

regards,
Dar7yl

java-programmer >> I miss my preprocessor! Thanks for your reply, Artur. I couldn't have said it better. That's the
whole idea behind the "if (DEBUG)...", to bypass the argument evaluation.

>> My answer is AOP.

Care to elaborate?

regards,
Dar7yl

"Artur Biesiadowski" <email***@***.com> wrote in message
news:email***@***.com...
> Otis Bricker wrote:
>
>> Would it really cost that much to have a class with a static 'Logger'
>> reference and a static init or method that chooses between a NullLogger
>> and a DebugLogger. The runtime enviroment should quickly notice that it
>> can short out the empty implementation. Even if it didn't, what would the
>> cost be of calling an empty function a couple thousand times? Or using
>> the code you posted without the local "if(DEBUG)". How much are you
>> really saving by eliminating the call site? It seems that this is an as
>> yet unjustified optimization.
>
> There is a difference in argument handling. Even if implementation is
> empty, jvm cannot omit argument creation. So, if you will do
>
> Logger.log("Current value" + compositeObject.toString());
>
> new StringBuffer will be created and compositeObject.toString() method
> will be called (which can be possibly quite heavy plus include creation
> another StringBuffer/String instance).
>
> On the other hand,
> if (DEBUG) Logger.log("Current value" + compositeObject.toString());
> will help here - because argument won't be created if DEBUG is false. But
> question is how to write it in different way with same optimalization. My
> answer is AOP.
>
> Artur

java-programmer >> I miss my preprocessor! dar7yl <email***@***.com> wrote or quoted:
> "Tim Tyler" <email***@***.com> wrote in message news:email***@***.com...
> > dar7yl <email***@***.com> wrote or quoted:

> >> From an aesthetic point of view, the "if (DEBUG)" part seems to clutter
> >> up the source.
> >
> > Worse than #ifdef DEBUG?
>
> The "#ifdef DEBUG" is actually not in the source, but is included in the
> header, eg:
> #include debug.h
>
> (didn't I say that the example I gave was the simplest form? the mechanism
> I use is fairly elaborate, with the ability to selectivly turn on/off debugs
> by module, level, and other criteria.
>
> The only inclusion within the body of the source (beside the include, and a
> few defines to outline the parameters) is the dbg(...) statements. My point
> is that the C/C++ preprocessor can control the generation of source with
> three letters: 'd' 'b' 'g', while java requires
> "if (DEBUG) dbg"... .

I think you are saying you'd like a tool that takes
dbg("msg"); calls, and strips them out of the code at
compile time if the method they call does nothing.

I'm not certain if any tools currently do this,
but code squeezers do an /awful/ lot of that sort
of thing to reduce code size - so the chances are
probably pretty good that one of them does.

> I actually have created a logging class, but I still have the stub:
> void dbg( String msg)
> {
> if (DEBUG)
> Logger.dbg(msg);
> }

Again, it's the job of code squeezers to eliminate useless calls to
functions that do nothing.

The compiler's job is normally a bit different from that of a code
squeezer - and it should not attempt to squeeze every last bit
of space out of the compiled code.

> While this does add one level of subroutine call to the debug when it is
> enabled, but it avoids a class call when not.
> In C/C++, I could have put the stub into a header, and inlined it.

Probably not a good idea in Java.

There inlining is done automatically by the runtime - depending on whether
the space/time tradeoff on the client looks favourable or not - and as
I recall, some runtimes actually do experiments in real time to evaluate
whether such inlining is actually helping in practice.
--
__________
|im |yler http://timtyler.org/ email***@***.com Remove lock to reply.

java-programmer >> I miss my preprocessor! dar7yl wrote:

>>>My answer is AOP.
>
>
> Care to elaborate?

Aspect oriented programming.
For more details please look at
eclipse.org/aspectj/

At the moment I'm not able to show you an example which will work
exactly as you want - in fact I'm not sure if it is possible in aspectj
to avoid evaluation of parameters in around() advice (or if there is
some other idiom which can be used here). But I hope it can be managed.
If you will find out exact syntax, please let us know :)

Artur

java-programmer >> I miss my preprocessor! Artur Biesiadowski <email***@***.com> wrote in
news:email***@***.com:

> Otis Bricker wrote:
>
>> Would it really cost that much to have a class with a static 'Logger'
>> reference and a static init or method that chooses between a
>> NullLogger and a DebugLogger. The runtime enviroment should quickly
>> notice that it can short out the empty implementation. Even if it
>> didn't, what would the cost be of calling an empty function a couple
>> thousand times? Or using the code you posted without the local
>> "if(DEBUG)". How much are you really saving by eliminating the call
>> site? It seems that this is an as yet unjustified optimization.
>
> There is a difference in argument handling. Even if implementation is
> empty, jvm cannot omit argument creation. So, if you will do
>
> Logger.log("Current value" + compositeObject.toString());
>
> new StringBuffer will be created and compositeObject.toString() method
> will be called (which can be possibly quite heavy plus include
> creation another StringBuffer/String instance).
>
> On the other hand,
> if (DEBUG) Logger.log("Current value" + compositeObject.toString());
> will help here - because argument won't be created if DEBUG is false.
> But question is how to write it in different way with same
> optimalization. My answer is AOP.
>
> Artur

While it may not be done currently, it seems to me that the VM could
determine that the log call could be inlined as well as the call
toString, then it would notice that the argument is never used and has no
side effects and eliminate it all. HotSpot may not do this yet. But is
there a reason it couldn't?

And I still wonder about the amount of time really spent logging this
stuff. Unless you dump a whole lot of debug info, this really looks like
a fraction of a percent of execution time. I was trying to get across the
idea that this may not be worth worrying about except in some rare cases.

java-programmer >> I miss my preprocessor! Otis Bricker wrote:

> While it may not be done currently, it seems to me that the VM could
> determine that the log call could be inlined as well as the call
> toString, then it would notice that the argument is never used and has no
> side effects and eliminate it all. HotSpot may not do this yet. But is
> there a reason it couldn't?

There is a side effect - creation of String/StringBuffer object at
least. I'm not sure if it is legal for jvm to optimize it away.

public void m() {
Integer i = new Integer(5);
}

Could this be optimized by jvm to no-op ? I'm not sure. Maybe it can
have a hardcoded list of objects which have no side effects when created
- discovering it at runtime is probably too hard.

> And I still wonder about the amount of time really spent logging this
> stuff. Unless you dump a whole lot of debug info, this really looks like
> a fraction of a percent of execution time. I was trying to get across the
> idea that this may not be worth worrying about except in some rare cases.

It really depends on domain and on verbosity of logs. If you are doing
anything game-related for example, even such small costs when added
together can kill performance.

Artur

java-programmer >> I miss my preprocessor! "dar7yl" <email***@***.com> wrote in
news:0jPRc.51443$yT2.44212@clgrps13:

> There's one thing I really used the C/C++ preprocessor for, and that is
> compile-time control of debugging statements.
>
> in it's simplest form:
> ----------------------------------------------
> // comment out this line to disable debugs
> #define DEBUG 1
>
> #ifdef DEBUG
> # define dbg(msg) printf(msg)
> #else
> # define dbg(msg)
> #endif
>
> void main(int argc, char argv[][])
> {
> dbg("Some sorta message\n");
> }
> ----------------------------------------------
>
> This system had evolved to a very powerful mechanism for
> enabling/disabling/removing debug statements from my code. The beauty
> of it is that debugging code can be removed
> entirely from released code, without removing from the source. (I like
> leaving it in the source because it provides a sort of ancillary
> documentation). The only shortcoming was the lack of variable macro
> parameters in C/C++.
>
> The nearest I could come up with in java is:
> ----------------------------------------------
> class xxx
> {
> private static final boolean DEBUG=true; // set to false to
> turn
> off debugging
> void dbg(String msg)
> {
> if (DEBUG) // this gets optimized out
> System.out.print(msg);
> }
>
> public static void main( String[] args )
> {
> if (DEBUG) dbg("Some sorta message\n");
> }
> } // xxx
> ----------------------------------------------
> While this does seem to work, it relies on the compiler to implicitly
> optimize the code out. Not that I don't trust the compiler, but how can
> I prove it?
> From an aesthetic point of view, the "if (DEBUG)" part seems to clutter
> up the source.
> And it leaves a stub for dbg() in the code.
>
> My point is, what options are available to reproduce the desired
> mechanism? (Don't give me anything from java 1.5/5.0; I can't use it
> till it is officially released, and the major ide manufactures endorse
> it).
>

Tie him up, remove his upper clothes. Tie him to the pole with his hands
safely tied behind his back properly cinched. Then blindfold him. Take ruber
hose. Open water valve and stream that cold water on him. If he wont come to
senses cuff him and leave him here until morning.

Then again, better would be to strip him and balltie him. Leave him in dark
room for quarter of hour. Then ask him if he came to his senses.

Debug messages cluttering source code. Ouch. And preprocessor syntax
cluttering source code on the top. Crawl 3.3, or so, provided enough warnings
against such behaviour.

Here is some code:

public final boolean shit = false;
public void ug(){
if(shit){System.out.print("shit");}
}

And here is some dissasembly:

public final boolean shit = false;
public void ug() {
}

--
Kizutsuite 'ta ano hi kara

java-programmer >> I miss my preprocessor!
"Artur Biesiadowski" <email***@***.com> wrote in message
news:email***@***.com...
>>>>My answer is AOP.
>> Care to elaborate?
>
> Aspect oriented programming.
> For more details please look at
> eclipse.org/aspectj/
>

I've seen aspectj, and it looks nice from a gee-whiz 2nd year computer
science course point of view. Instead of simplifying things, it seems to
complicate matters.
IMHO, it does not add enough to overcome the steep learning-curve it forces
my poor human-sized brain into.

regards,
Dar7yl

java-programmer >> I miss my preprocessor!
"Raghar" <email***@***.com> wrote in message
news:email***@***.com...

>> ...insults and profanity deleted...

please refrain from exposing your immaturity. If you have a point, state
it.
regards,
Dar7yl.

java-programmer >> I miss my preprocessor! In comp.lang.java.advocacy, dar7yl
<email***@***.com>
wrote
on Wed, 11 Aug 2004 00:22:57 GMT
<BFdSc.995$X12.901@edtnps84>:
>
> "Raghar" <email***@***.com> wrote in message
> news:email***@***.com...
>
>>> ...insults and profanity deleted...
>
> please refrain from exposing your immaturity. If you have a point, state
> it.
> regards,
> Dar7yl.
>

Indeed.

I'd think, though, that explicitly typing in those statements is a PITA. :-)

--
#191, email***@***.com
It's still legal to go .sigless.

java-programmer >> I miss my preprocessor! "dar7yl" <email***@***.com> wrote in news:BFdSc.995$X12.901@edtnps84:

>
> "Raghar" <email***@***.com> wrote in message
> news:email***@***.com...
>
>>> ...insults and profanity deleted...
>
> please refrain from exposing your immaturity. If you have a point, state
> it.

I'm sorry if you are taking it as a insults and profanity. I thought I'm
pretty clear. I consider debug messages cluttering source code in C++ way as
a worse alternative to the above statements.
(Yes I consider a preprocessor a slightly better alternative to the Bush
reelection... doomed or very doomed what's better?)

"> While this does seem to work, it relies on the compiler to implicitly
> optimize the code out. Not that I don't trust the compiler, but how can
> I prove it?"
I proved it in my post.

Alas I didn't find that really ugly part of crawl source code, nor I found a
really effective example of define, undefine, ifdef, ifndef, and so on.
However I found a really nice source codes without defines that were nicely
commented. It's a part of the Java standard library source code, and the Kent
Paul Dolan's Traveller source code. You could easily find answers on your
questions in the former, and you could easily continue with development of
the later.
About what we talked about? Defines and source code?

">Btw, is this optimization actually specified in the java standard?"

Not, and it shouldn't be. Any compiler is able to remove "branch" statement
from the code with exception of experimental and beta versions of compiler.

">My point is, what options are available to reproduce the desired mechanism?
>(Don't give me anything from java 1.5/5.0; I can't use it till it is
>officially released, and the major ide manufactures endorse it)."

IDE manufacturers? O_O

--
Kizutsuite 'ta ano hi kara