Re: Copy/assignment of sc_object

Hi Philipp,

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.
[attachment "object_copy.cpp" deleted by David Long/doulos] 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.