RE: Proposed change to IEEE 1666-2005 5.18.8 (Member functions for attributes)

Tor-

My memory on this is a bit fuzzy but as I recall when we were writing the initial LRM many years
ago we did not think sc_attr* was very clean, but it was already widely used and thus we needed
to document it "as-is" in the LRM.

I have not really thought about it in detail since, but one option would be to deprecate sc_attr* entirely and
have an alternative attribute annotation API with cleaner semantics as you propose. This at least would
not introduce any backward incompatibility, which I think maybe is a showstopper with your proposal.

Thanks
Stuart

From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Jeremiassen, Tor
Sent: Friday, February 26, 2010 3:23 PM
To: systemc-p1666-technical@eda.org
Subject: Proposed change to IEEE 1666-2005 5.18.8 (Member functions for attributes)

All,

The current IEEE standard reads (with respect to adding attributes to an sc_object):

The lifetime of an attribute shall extend until the attribute has been completely removed from all
objects. If an application deletes an attribute that is still attached to an object, the behavior of the
implementation shall be undefined.

In one sense, an sc_object acts as a container class for sc_attribute objects. In fact, sc_object may return an sc_attr_coltn reference (reference to an attribute collection). However, while the STL collections create copies of the objects that are inserted, and therefore decouple the lifetime of the object inserted into the collection from what exists in the collection, the sc_attributes are handled differently. In fact, it is necessary to allocate sc_attributes in a way such that their lifetimes exceed that of the sc_objects to which they are attached. Thus, a loop that is inserting sc_attributes (not the same sc_attribute object) into multiple sc_objects will have to be written to dynamically allocate (new) a separate sc_attribute object for each such insertion, and the programmer has to ensure that those dynamically allocated attributes are not deleted until after the sc_object(s) they have been inserted into are deleted. If instead the programmer was inserting the same objects into an STL container, the same sc_attribute object could be reused for each insertion, as a copy of the object would be inserted into the container itself.

I cannot really see any rational reason for doing it this way. If the desire is to be able to insert the same attribute object into multiple sc_objects and have them all point to the same "value", a pointer can be inserted as the value of the sc_attribute. This is how one would address it with STL containers.

My opinion is that this behavior is inconsistent from the behavior a C++ programmer would expect and should be changed accordingly. There may be side-effects of this change on the sc_attribute and sc_attr_coltn class definitions.

A related possible change that I will suggest is the use of boost::any for the value type of the attribute. This will remove the template parameter from the sc_attribute<T> class while re-using a well tested container used for heterogeneous type collections. This would simplify handling of the classes and avoids the programmer having to:

NOTE-A pointer returned from function get_attribute needs to be cast to type sc_attribute<T>* in order to
access data member value of class sc_attribute.

as the boost::any container manages this.

In fact this change would eliminate the need to maintain the base class sc_attr_base, as it is solely used to provide a type neutral handle for attributes.

Best regards,

Tor Jeremiassen

---
Tor Jeremiassen, Ph.D.
Simulation and Modeling CTO
SDO Foundational Tools
Texas Instruments                    Ph:    281 274 3483
P.O. Box 1443, MS 730                Fax:   281 274 2703
Houston, TX 77251-1443               Email: tor@ti.com<mailto:tor@ti.com>
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.