From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Any Suggestion How To Accomplish A Debug Macro? Date: Tue, 30 Dec 2014 16:11:56 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1419977517 1901 24.196.82.226 (30 Dec 2014 22:11:57 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 30 Dec 2014 22:11:57 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:24298 Date: 2014-12-30T16:11:56-06:00 List-Id: "Brad Moore" wrote in message news:gCDow.832901$No4.618024@fx19.iad... > On 14-12-30 04:14 AM, Simon Wright wrote: >> Hubert 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.