Jerome, Bishnupriya, John,
some comments on the constness issue from my side below.
On 31/03/10 17:07, Jerome CORNET wrote:
> why does the norm mandate the *argument* of wait() (be it in sc_module,
> sc_prim_channel or whatever) be a const reference on sc_event?
I think, the user should only get a grip on const event references,
unless he/she owns them explicitly. IMHO, events returned from e.g.
default_event() functions of a channel should NOT be modifiable.
Otherwise, the user could notify() such internal events from the
outside of the channel. This is a Bad Thing...
> This does not seem logical, as waiting for an event can in many cases
> require to modify the event. For instance, one may
> want to instrument the event to record that a process has called wait()
> on it.
Whether or not an implementation needs to modify an event internally
should be kept out of the interface. Changes to this would at least
require to return non-const references for all event retrieving
functions, which severely breaks encapsulation (see above).
[snip]
> On 3/30/2010 10:07 PM, Bishnupriya Bhattacharya wrote:
>> I do not recollect the original discussion on this topic, but I agree
>> in principle with the rationale you proivide below on why wait() is
>> not declared const.
At the end of the day, this is more or less no issue. As I said
before, the user can always call the global sc_core::wait() variant
explicitly, if needed.
Maybe it's really good to disable this by default, since blocking
calls can in fact modify the observed state of the object from the
calling process' point of view.
So let's keep them non-const and let advanced users call the global
functions if they know what they are doing. :-)
Greetings from Oldenburg,
Philipp
[snip]
-- Philipp A. Hartmann Hardware/Software Design Methodology Group OFFIS R&D Division Transportation | FuE-Bereich Verkehr Escherweg 2 · 26121 Oldenburg · Germany Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Mar 31 09:33:55 2010
This archive was generated by hypermail 2.1.8 : Wed Mar 31 2010 - 09:33:55 PDT