RE: Virtual bind operators

Philipp,

initially my use case was the following: being able to overload
one of the many bind()/operator() methods in a class derived from sc_port
without having to re-implement all of them. However, as David Long
pointed out (see technical mailing list archive in March), making
the bind() and operator() virtual does not solve this problem as I though.
Actually, the problem can be solved with a "using" clause in
the derived class (as in the example you give below), so on my side
there is no longer the need to declare bind()/operator() virtual.

If I understand well, with what you propose below, we would avoid
to write the using clause for the operator() and could focus on overloading
the bind() methods only?

Thanks,

Jerome

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Wednesday, October 13, 2010 10:04 PM
To: Jerome CORNET
Cc: systemc-p1666-technical@eda.org; John Aynsley
Subject: Re: Virtual bind operators

Jerome, All,

I'm not sure, if I understand the use-case correctly.
Consider the following example:

template<typename IF>
struct my_port : sc_core::sc_port<IF>
{
  typedef sc_core::sc_port<IF> base_port;

  // override port-interface binding
  virtual void bind( IF& iface )
  {
    // do something special
    // call base function
    base_port::bind( iface );
  }

  // still needed for port-port binding due to name-hiding
  using base_port::bind;

  // inherit operator()
};

Is this the use-case you had in mind?

In that case, I would propose to make only bind() virtual and require
the operators to call exactly this virtual bind function (which is not
required as of now):

template< typename IF >
struct sc_port_b
{
  void operator()( IF& iface); // Effect: this->bind(iface)
  void operator()(sc_port_b<IF> & port); // Effect: this->bind(port)

  virtual void bind(IF &);
  virtual void bind(sc_port_b<IF> &);
};

This would make the above example work, if the operator() functions are
required to call the virtual bind() function. Do I miss something? Is
there a reason, to make the operators virtual as well? We would still
want them to call their virtual bind() siblings, right?

Thanks,
  Philipp

On 13/10/10 16:14, john.aynsley@doulos.com wrote:
> Jerome, All,
>
> The next item on the list is virtual bind operators. I include the text
> from Jerome's original proposal below.
>
> Thoughts?
>
> John A
>
>
> Another area that can be improved with only minor changes is the
> sc_port/sc_export classes:
>
> * The various bind() and operator() methods are not declared virtual. This
> means that when someone wants to overload these methods in a user class
> derived from sc_port or sc_export, he has to declare and provide
> implementation for all the variants. For instance the user could want to
> overload the sc_port binding to an interface, and he has to also declare
> and implement all the other bindings. This is a real pain when
> implementing user protocol classes derived from sc_port or sc_export.
>
> * Similarly, I would propose to declare virtual the various bind() and
> operator() methods in the TLM 2.0 sockets classes
> (tlm_base_initiator_socket and tlm_base_target_socket).
>
> * The class sc_port is template on IF (interface), N (max number of
> connections) and POL (policy), and derives from the sc_port_base class.
>
> * The declaration of sc_port binding on another sc_port does not seems
> consistent:
> void bind(sc_port<IF, N> &);
>
> This means that a sc_port "templatized" with N=2 can only connect to
> another port that is "templatized" with the very same N whereas you can
> logically connect a sc_port with N=2 to 2 sc_port that would have N=1 (for
> instance). In this area, I have seen many implementations (including the
> reference OSCI implementation) that just don't comply with the norm in
> order to allow these logical connections.
>
> So, what is needed is something like this:
> virtual void bind("any_port" &);
> sc_port_base could be a candidate for "any_port" but it is not template on
> IF. Actually, if we look at some implementations, we see that they do use
> an intermediate class called sc_port_b, that is template on IF.
>
> So the proposal is:
>
> - Standardize the class sc_port_b<IF>, that inherits from sc_port_base and
> that contains the following bind/operator functions:
>
> virtual void operator() (IF &);
> virtual void operator() (sc_port_b<IF> &);
>
> virtual void bind(IF &);
> virtual void bind(sc_port_b<IF> &);
>
> The class sc_port would then inherit from sc_port_b. This is just a
> standardization (+ virtual keyword) of what is already implemented in many
> simulators, including the OSCI reference one. Any user that implements
> class derived from sc_port will need that sc_port_b class for the same
> reason. A perfect example of that are the OSCI TLM 2.0 sockets, that
> explictly make use of sc_port_b (see tlm_base_initiator_socket_b and
> tlm_base_target_socket_b) to allow binding of sockets with different N and
> POL parameters, but with matching BUSWIDTH, FW_IF and BW_IF.
>
>

-- 
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.