Opened 17 years ago
Closed 16 years ago
#82 closed enhancement (fixed)
Doc review needed for time_measure.h and counter.h
Reported by: | Alpar Juttner | Owned by: | Peter Kovacs |
---|---|---|---|
Priority: | major | Milestone: | LEMON 1.0 release |
Component: | documentation | Version: | hg main |
Keywords: | Cc: | ||
Revision id: |
Description
See ticket:52 for a longish discussion on it.
Attachments (2)
Change History (10)
comment:1 Changed 17 years ago by
Status: | new → assigned |
---|
Changed 16 years ago by
Attachment: | counter.patch added |
---|
comment:2 follow-ups: 3 4 Changed 16 years ago by
comment:3 follow-up: 5 Changed 16 years ago by
Replying to kpeter:
What do you think about it? It could be fixed using an implementation like SubCounter for NoSubCounter (but without printing report)
I don't like this idea.
What about just removing the reset()
functions from the subcounters? Or even from the main counters? (I would expect that reset()
also resets the sub-counters, but I can't see any reasonable implementation for that.)
Alternatively, we can leave it as is, but also write a documentation note about when will the reset()
do what the user might expect.
comment:4 Changed 16 years ago by
Replying to kpeter:
I uploaded a patch with improved documentation for counters.
The patch went to the main branch, see [b1bd0c2a7f57].
comment:5 follow-up: 6 Changed 16 years ago by
I support removing reset() from subcounters.
For Counter we have two options:
- Remove the reset() functuion to keep the current concpet that the subcounters can be used exactly the same way as Counter and to avoid the following confusing meaning.
- Add a note to the doc of reset() that it does not resets the values of SubCounters but it do resets NoSubCounters.
comment:6 Changed 16 years ago by
Replying to kpeter:
I support removing reset() from subcounters.
Let's do that.
For Counter we have two options:
- Remove the reset() functuion to keep the current concpet that the subcounters can be used exactly the same way as Counter and to avoid the following confusing meaning.
- Add a note to the doc of reset() that it does not resets the values of SubCounters but it do resets NoSubCounters.
I prefer the latter one.
Changed 16 years ago by
Attachment: | counter-reset.patch added |
---|
comment:7 follow-up: 8 Changed 16 years ago by
I attached a patch about the reset() functions. As it goes to the main branch, this ticket can be closed.
comment:8 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Replying to kpeter:
I attached a patch about the reset() functions. As it goes to the main branch, this ticket can be closed.
It went there, see [8ceb318224b1].
I uploaded a patch with improved documentation for counters.
I see only one problem with the current counter-nocounter concept. The following code
prints out
However if the SubCounter is replaced with NoSubCounter it prints out
What do you think about it? It could be fixed using an implementation like SubCounter for NoSubCounter (but without printing report), however then NoSubCounters would generate code even if they are used for a NoCounter.