Re: Copy/assignment of sc_object

David,

Thanks for your feedback.

  I can see the use-cases for copying objects derived from sc_object.
But from the standard's perspective, we need to define the correct
semantics not only for the parent object and the (non-existent)
children, but also for the name and the attributes of an sc_object.

  The crash in my example occurs due to a double delete of the name
member in the destructor, since the compiler-generated copy is only a
shallow one.

  If we make these operations private, a user-defined class can still
define their own copy-semantics as follows (by ignoring/replacing the
base operations):

struct some_object : sc_object
{
  // ...

  some_object( const some_object & that )
    // use a "similar" name in the correct hierarchical position
    : sc_object( that.basename() )
  { /* ... */ }

  some_object& operator=( const some_object& that )
  {
    // do NOT call (as the default operator would)
    // sc_object::operator=( that );
    // ...
    return *this;
  }
};

 OTOH, if we define these operations explicitly in the standard, we need
to ensure more or less the same semantics as in the manual
implementation above. Specifically, the following sc_object invariants
should be guaranteed:

 - all object names in the hierarchy are still unique

 - the hierarchical name correctly reflects the position in the
   hierarchy, and this position depends on the context of (copy)
   creation, not on the position of the source object

 - attributes shall NOT be copied (or replaced during assignment)
   This is debatable, though. But if we want to deep-copy
   attributes, sc_attribute_base needs a clone() function.

 - upon assignment, name and parent object of the destination object
   shall NOT change

  Since we are quite late in the standardisation process, it may be
easier to make these operations private, adding a note with the manual
example as outlined above.

  The attached patch implements protected copy/assignment with the
properties discussed above in the latest OSCI simulator and avoids the
crash in my initial example.

Greetings from Oldenburg,
   Philipp

On 26/10/10 17:54, david.long@doulos.com wrote:
>
> I think that it should be allowed to copy a user-defined class derived
> from sc_object. For example, consider if an application wanted to create
> something like the ovm_object/uvm_object class that is used as a base
> class for transactions and sequence items in those SV methodologies (I am
> not talking about TLM2 generic_payload type transactions here) - why
> should these not be copied? The links to their parent object would still
> be valid.
>
> The 2005 LRM already states that "only module objects and process objects
> can have children" (5.15.1) so I don't think this introduces any
> anomalies.
>
> As you point out, what is currently missing are explicit definitions for
> the sc_object copy constructor and assignment operator, but I think they
> should be protected, not private. The virtual destructor (which is what
> causes the crash in your example) is already declared as protected in the
> LRM.
>
>
> Best Regards,
>
> Dave Long
> Doulos
>
>
>
>
> From:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To:
> John Aynsley <john.aynsley@doulos.com>
> Cc:
> SystemC P1666 Technical <systemc-p1666-technical@eda.org>
> Date:
> 26/10/2010 14:50
> Subject:
> Copy/assignment of sc_object
> Sent by:
> owner-systemc-p1666-technical@eda.org
>
>
>
> John,
>
> since users can derive their own classes from sc_object, but such
> objects still have an explicit identity within the object hierarchy,
> sc_object's copy constructor/copy-assignment operator should probably be
> disabled, right?
>
> Is this an oversight in 1666-2005? I think, in sc_object's class
> definition (6.15.3), we should add
>
> private:
> // disabled
> sc_object( const sc_object& );
> sc_object& operator=( const sc_object& );
>
> The attached test program compiles fine and crashes (after pressing
> <enter>) with OSCI's PoC implementation.
>
> NB: sc_module is missing explicitly disabled copy/assignment as well.
> But these are correctly disabled in the OSCI simulator.
>
> I think, if we would want to support copying and assigning user-defined
> sc_objects, we would need to define the semantics wrt. the object
> hierarchy explicitly.
>
> What do you think?
>
> Greetings from Oldenburg,
> Philipp
>

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