Re: Ada.Execution_Time

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

"BrianG" <briang000@gmail.com> wrote in message 
news:ie91co$cko$1@news.eternal-september.org...
...
> My problem is that what is provided in the package in question does not 
> provide any "values suitable for arithmetic" or provide "an object 
> suitable for print" (unless all you care about is the number of whole 
> seconds with no information about the (required) fraction, which seems 
> rather limiting).

Having missed your original question, I'm confused as to where you are 
finding the quoted text above. I don't see anything like that in the 
Standard. Since it is not in the standard, there is no reason to expect 
those statements to be true. (Even the standard is wrong occassionally, 
other materials are wrong a whole lot more often.)

>  Time_Span is a private type, defined in another package.  If all I want 
> is CPU_Time (in some form), why do I need Ada.Real_Time?  Also, why are 
> "+" and "-" provided as they are defined? (And why Time_Span?  I thought 
> that was the difference between two times, not the fractional part of 
> time.)

I think you are missing the point of CPU_Time. It is an abstract 
representation of some underlying counter. There is no requirement that this 
counter have any particular value -- in particular it is not necessarily 
zero when a task is created. So the only operations that are meaningful on a 
value of type CPU_Time are comparisons and differences. Arguably, CPU_Time 
is misnamed, because it is *not* some sort of time type.

The package uses Ada.Real_Time because no one wanted to invent a new kind of 
time. The only alternative would have been to use Calendar, which does not 
have to be as accurate. (Of course, the real accuracy depends on the 
underlying target; CPU_Time has to be fairly inaccurate on Windows simply 
because the underlying counters are not very accurate, at least in the 
default configuration.)

My guess is that no one thought about the fact that Time_Span is only an 
alias for Duration; it's definitely something that I didn't know until you 
complained. (I know I've confused Time and Time_Span before, must have done 
that here, too). So there probably was no good reason that Time_Span was 
used instead of Duration in the package. But that seems to indicate a flaw 
in Ada.Real_Time, not one for execution time.

In any case, the presumption is that interesting CPU_Time differences are 
relatively short, so that Time_Span is sufficient (as it will hold at least 
one day).

> Given the rest of this thread, I would guess my answer is "No, no one 
> actually uses Ada.Execution_Time".

Can't answer that. I intended to use it to replace some hacked debugging 
code, but I've never gotten around to actually implementing it (I did do a 
design, but there is of course a difference...).

                                  Randy.