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: Fri, 2 Jan 2015 15:52:28 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1420235549 32355 24.196.82.226 (2 Jan 2015 21:52:29 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 2 Jan 2015 21:52:29 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:24319 Date: 2015-01-02T15:52:28-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:fh7u81n706kr.131btl9yj1iz8.dlg@40tude.net... > On Fri, 02 Jan 2015 21:37:47 +0100, J-P. Rosen wrote: ... > However, it would be interesting to consider how tracing could be better > supported. I mean options: > > 1. To have zero-cost turned off tracing, e.g. some code modification > techniques or maybe something else. After all we have zero-cost > exceptions, > why not tracing. But "zero-cost exceptions" aren't really zero-cost, they just shift the cost to handling. And that's already the case; virtually all of the cost of tracing is when the tracing is enabled. (A Boolean compare being about the cheapest operation on most targets.) About all one could do would be to keep the tracing code out of the normal flow, which would decrease paging/caching costs a bit when tracing is off -- but that would not make a noticable difference on the vast majority of programs. It would be unlikely to be worth the work. > 2. Ideas for the compilation units structure modification which would > allow > to have tracing code physically separated from the functional code. We've considered such ideas in the context of assertions, but nothing proposed really looked like a proper part of Ada. For tracing, it would be even harder, because tracing can be inserted anywhere in the flow of a program (not just at particular places like most assertions). Moreover, in both cases, there isn't a clear-cut boundary between them (for tracing, that's primarily human-readable output, which often is needed anyway; for assertions, that's predicate functions that you might want to use to insert pre-tests before operations). I use separate logging and trace management packages, which (combined with my aversion to use clauses) show tracing code pretty well. It's not clear at all that we could do better with syntax mechanisms. Randy.