Re: sc_event_and/or_list

John,

you are right, I've missed to mention those declarations explicitly,
since for the implementation of sc_event_and/or_list, the default
generated copy constructor/copy-assignment operators do fine.
The base class needs explicit ones, but this is implementation-defined.

  I have been under the impression, that 1666-2005 only mentions those
constructors/assignment operators only, if they are somehow different
from their default signature (e.g. private/disabled, or with different
signatures). If that's not the case, we should add them to the class
definitions in the LRM, of course.

Thanks,
  Philipp

On 22/10/10 12:55, john.aynsley@doulos.com wrote:
> Philipp,
>
> Comparing your sc_event-new-interface.h document (attached) with the
> prototype implementation of sc_event.h, I notice that the base class
> sc_event_list has public ctor and assignment operators that you have not
> reproduced in the documented pseudo-classes sc_event_or_list and
> sc_event_and_list. I think we need the copy ctor and assignment operators
> of the event lists to be public and available to the user, yes/no?
>
> Thanks,
>
> John A
>
>
>
>
> From:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To:
> john.aynsley@doulos.com
> Cc:
> systemc-p1666-technical@eda.org, "Jeremiassen, Tor" <tor@ti.com>
> Date:
> 12/10/2010 19:11
> Subject:
> Re: sc_event_and/or_list
>
>
>
> John, All,
>
> I just realized, that the attached files in my previous mail may not be
> concise enough to review the proposed API.
>
> Please find below a stripped-down version of the possible "new" public
> interface of the event list related classes.
>
> Greetings from Oldenburg,
> Philipp
>
> namespace sc_core {
>
> // -------------------------------------------------------------------
> // CLASS : sc_event_(and|or)_expr
> // (implementation defined expression classes, an application shall
> // not use these classes explicitly).
> // -------------------------------------------------------------------
>
> // AND expressions
> class sc_event_and_expr // implementation-defined
> {
> public:
> operator sc_event_and_list const &() const;
> };
>
> sc_event_and_expr
> operator & ( sc_event_and_expr, sc_event const & );
> sc_event_and_expr
> operator & ( sc_event_and_expr, sc_event_and_list const & );
>
> // OR expressions
> class sc_event_or_expr
> {
> public:
> operator sc_event_or_list const &() const;
> };
>
> sc_event_or_expr
> operator | ( sc_event_or_expr, sc_event const & );
> sc_event_or_expr
> operator | ( sc_event_or_expr, sc_event_or_list const & );
>
> // -------------------------------------------------------------------
> // CLASS : sc_event -> new/changed operators
> // -------------------------------------------------------------------
>
> class sc_event
> {
> public:
> // ...
> sc_event_or_expr operator | ( const sc_event& ) const;
> sc_event_or_expr operator | ( const sc_event_or_list& ) const;
>
> sc_event_and_expr operator & ( const sc_event& ) const;
> sc_event_and_expr operator & ( const sc_event_and_list& ) const;
> };
>
> // -------------------------------------------------------------------
> // CLASS : sc_event_or_list
> // -------------------------------------------------------------------
>
> class sc_event_or_list
> {
> public:
> sc_event_or_list(); // default constructible
> sc_event_or_list( const sc_event& ); // single-event list
>
> void swap( sc_event_or_list& ); // optional
> int size() const; // shall be >0 for wait() etc.
>
> // modify in-place
> sc_event_or_list& operator |= ( const sc_event& );
> sc_event_or_list& operator |= ( const sc_event_or_list & );
>
> // non-mutating operators -> return expression
> sc_event_or_expr operator | ( const sc_event& ) const;
> sc_event_or_expr operator | ( const sc_event_or_list& ) const;
> };
>
> // -------------------------------------------------------------------
> // CLASS : sc_event_and_list (see OR list)
> // -------------------------------------------------------------------
>
> class sc_event_and_list
> {
> public:
> sc_event_and_list();
> sc_event_and_list( const sc_event& );
>
> void swap( sc_event_and_list& );
> int size() const;
>
> sc_event_and_list& operator &= ( const sc_event& );
> sc_event_and_list& operator &= ( const sc_event_and_list & );
>
> sc_event_and_expr operator & ( const sc_event& );
> sc_event_and_expr operator & ( const sc_event_and_list& );
> };
>
> } // namespace sc_core
>
> On 12/10/10 19:08, Philipp A. Hartmann wrote:
>> John,
>>
>> sorry for the delay. I finally found some time to look at this.
>> Comments embedded below.
>>
>> On 12/10/10 16:22, john.aynsley@doulos.com wrote:
>> [snip]
>>
>>> Using Philipp's prototype we can do some cool stuff with event lists,
> for
>>> example:
>> [snip some code examples]
>>
>>> sc_event_and_list list3 = list2 & e2; // Caveat - modifies list2
>>> wait( list3 );
>>
>> I agree, that this is an unexpected side-effect. I would suggest to add
>> &= and |= operators to the lists to modify lists in place, though:
>>
>> class sc_event_or_list {
>> // ...
>> sc_event_or_list& operator |= ( const sc_event& );
>> sc_event_or_list& operator |= ( const sc_event_or_list & );
>>
>> sc_event_or_expr operator | ( const sc_event& ) const;
>> sc_event_or_expr operator | ( const sc_event_or_list& ) const;
>> };
>>
>> (sc_event_or_expr is an implementation defined helper class, as you
>> suggested, see below).
>>
>>> However, because the ctor sc_event_and_list(const sc_event&) is
> protected,
>>> we cannot do
>>>
>>> sc_event_and_list list5 = e3;
>>>
>>> I think it would be nice to be able to initialize a list with a single
>>> event, so I propose we make this ctor public (but without putting the
>>> auto_delete argument in the LRM)
>>
>> I'm not sure, if this is really required. With the '&|='-operators, the
>> same could be written as:
>>
>> sc_event_and_list list5;
>> list5 &= e3;
>>
>> Nevertheless it seems not to cause real harm in the usual case. But
>> note, that for your desired syntax these constructors can not be
>> 'explicit', which may lead to ambiguities if some functions are
>> overloaded for sc_event_and_list and sc_event_or_list but not sc_event
>> (not in the kernel, though).
>>
>>> Also, we cannot do
>>>
>>> sc_event_and_list list6 = list3 & list4;
>>>
>>> because we have no sc_event_and_list& operator & ( const
>>> sc_event_and_list& );
>>> I propose we add this operator
>>
>> Indeed, this would be very useful. Implemented in the attached quick'n
>> dirty prototype as well.
>>
>>> Finally, note that
>>>
>>> list2 = list2 & e1;
>>>
>>> is equivalent to
>>>
>>> list2 & e1;
>>>
>>> the latter being permitted because operator& works through a
> side-effect.
>>> Would this be a reason for introducing a separate class for
>>> user-instantiated event lists?
>>
>> Yes, this is a strong reason for adding implementation-defined
>> expression helper classes. They can be implemented fairly easily around
>> a temporary (auto-deleted) sc_event_list, which gives up ownership upon
>> conversion to a list object.
>>
>> I have attached updated sc_event.(h,cpp) classes, which implement nearly
>> all of the proposed extensions:
>>
>> - construction from single events
>> - expression classes (sc_event_and_expr, sc_event_or_expr)
>> - list concatenation ( list1 & list2 )
>> - operator &=, |=
>> - size()
>> - swap()
>> - move-semantics for temporary lists (implementation detail)
>>
>> The implementation is backwards-compatible, even regarding the
>> 'reference hack' and can detect premature deletion (or modification) of
>> busy event lists (i.e. with currently sensitive processes).
>>
>> The new classes should work with the earlier proposed 'const patch',
>> where wait() and next_trigger() take const list-references. This
>> earlier patch (against OSCI PoC version 2.3.10dec09_beta) can be found
>> in the Twiki [1].
>>
>> Greetings from Oldenburg,
>> Philipp
>>
>> [1]
>>
> http://www.eda.org/twiki/pub/Main/PhilippHartmann/0001-make-event-handling-const.patch
>
>>
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
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.