Re: Any Suggestion How To Accomplish A Debug Macro?

["Randy Brukardt" <randy@rrsoftware.com>]

"Brad Moore" <brad.moore@shaw.ca> wrote in message 
news:gCDow.832901$No4.618024@fx19.iad...
> On 14-12-30 04:14 AM, Simon Wright wrote:
>> Hubert <herrdoktor@fumanchu.com> writes:
>>
>>> I know there is no such thing as C #define's in Ada, but isn't there a
>>> way to make some sort of debug macro?
>>> In my C++ code I use a lot of statements like
>>>
>>> PRINT(DEBUG_CHANNEL, "TEXT" );
>>>
>>> to print out debug messages and in release code, these defines aren't
>>> compiled. Is there any way to achieve something like this in Ada
>>> without surrounding it with an IF statement and a boolean flag?

That's of course the Ada way. What's the point of avoiding the Ada way here? 
Everything in Ada is more verbose than C -- some of us think that's the 
advantage of Ada (more for readability than writability).


...
> Another more portable solution would be to declare a static constant 
> somewhere, and use the value of that constant to decide if logging should 
> occur.

He said he didn't want to do that.

I usually make these flags more complex (like an array of constants) so that 
various sets of tracing can be enabled in order to track whatever is wrong.

Indeed, in most of my programs, I use a flag set at runtime (controlled 
either through the GUI or through command-line switches. In that case, the 
code is always there (but a Boolean test is cheap), but that means I don't 
have to waste time with a compile-link-test-repeat cycle to trace a problem. 
(I admit, it's often necessary to add additional tracing to actually find 
the root cause, but the initial tracing at least can narrow it down 
quickly.)

...
> This works in GNAT, and might work in other compilers as well. Worst case 
> is that the Debug_Enabled boolean get evaluated in multiple places, but 
> that overhead of evaluating a Boolean might still be acceptable for a 
> compiler that doesn't do dead code elimination.

I think that the set of compilers that don't do dead code elimination is 
close to the empty set. (That was pretty much the first optimization we did 
in Janus/Ada, even before we had packages or floating point.) Whether the 
dead code elimination can get rid of everything (it won't get rid of string 
literals in Janus/Ada, for instance) is a different question.

But I don't think there is much reason (outside of the memory-constrained 
embedded system, or the system that has to be formally proved or validated) 
to ever removing the tracing. It's important to be able to turn it off, of 
course, but the runtime cost of it being off is so minimal (primarily 
caching/paging effects) that removing it isn't worth the effort. (And if you 
plan to keep it around forever, you'll spend more time making the traces 
make sense in the future -- which typically pays off very quickly.)

                                     Randy.