Description
Definition at line 297 of file OmpAttribute.h.
Public Member Functions | |
| std::string | toOpenMPString () |
| void | print () |
| virtual OwnershipPolicy | getOwnershipPolicy () const override |
| Who owns this attribute. More... | |
| virtual std::string | attribute_class_name () const override |
| Attribute class name. More... | |
| virtual OmpAttributeList * | copy () override |
 Public Member Functions inherited from AstAttribute | |
| virtual AstAttribute * | constructor () const |
| Virtual default constructor. More... | |
| virtual AstAttribute * | copy () const |
| Virtual copy constructor. More... | |
| virtual std::string | toString () |
| Convert an attribute to a string. More... | |
| virtual bool | commentOutNodeInGraph () |
| Eliminate IR nodes in DOT graphs. More... | |
| virtual int | packed_size () |
| Packing support. | |
| virtual char * | packed_data () |
| Packing support. | |
| virtual void | unpacked_data (int size, char *data) |
| Packing support. | |
| virtual std::string | additionalNodeOptions () |
| DOT support. | |
| virtual std::vector< AttributeEdgeInfo > | additionalEdgeInfo () |
| DOT support. | |
| virtual std::vector< AttributeNodeInfo > | additionalNodeInfo () |
| DOT support. | |
Public Attributes | |
| std::vector< OmpAttribute * > | ompAttriList |
Additional Inherited Members | |
| Public Types inherited from AstAttribute | |
| enum | OwnershipPolicy { CONTAINER_OWNERSHIP, NO_OWNERSHIP, CUSTOM_OWNERSHIP, UNKNOWN_OWNERSHIP } |
| Who owns this attribute. More... | |
Member Function Documentation
|
inlineoverridevirtual |
Who owns this attribute.
The original implementation of this class from the early 2000's did not have clear rules about who owned a heap-allocated attribute. The documentation was silent on the issue, and the implementation seemed to imply that container ownership was intended but was then commented out at some point. Any ownership policy should have the following properties:
- Attributes allocated on the heap should not be leaked. For instance, if an AST is deleted, then the attributes that were referenced by the AST nodes should also be eventually deleted.
- The mechanism should not place undue burden on the user. For instance, if a user copies and later deletes an AST to which some analysis has attached attributes, the user should not need to be concerned with deleting attributes stored in the copy.
- The mechanism should be able to support either deep or shallow attribute copies as appropriate for the attribute. The deep vs. shallow copying policy is implemented by the virtual copy method, which must coordinate with the ownership policy to ensure no leaks.
We define four ownership policies, although from the standpoint of an attribute container there are really only two: the container either deletes attributes or doesn't delete attributes. The four ownership policies are:
CONTAINER_OWHERSHIP:The simple approach to ownership, and the one that we recommend for all new attribute subclasses, is that the attribute container owns the attributes. When the container is copied (e.g., as part of copying an AST node) then it invokes the copy methods of its attributes, and when the container is deleted (e.g., as part of deleting an AST node) then it explicitly deletes its attributes. This policy is an "allocate and forget" approach: once the creator inserts an attribute into the container it transfers/moves ownership to the container and the creator never needs to invokedelete. This policy also means that users never need to explicitly delete attributes if they copy and then delete an AST. Newly designed attribute subclasses should use this policy unless they have a very good reason to use another policy.
NO_OWNERSHIP:Another simple approach is that ownership is transfered to the operating system. In other words, the attribute is never deleted by the program and its memory is reclaimed only when the program terminates. Attribute containers that are incorporated into objects that are frequently allocated and/or copied and then deleted will result in a large number of leaked attributes. This approach is not recommended and is present only for laziness.
CUSTOM_OWNERSHIP:A third approach is that the attribute subclass implements its own ownership policy, which ideally should have the properties listed above. An attribute using this policy will never be deleted by an attribute container; the class must implement some other mechanism for tracking which attributes are allocated and whether they can be safely deleted.
UNKNOWN_OWNERSHIP:This final policy is for subclasses implemented before clear attribute ownership rules were defined. Due to the ambiguity in the original AstAttributeMechanism implementation and the fact that attributes are used by code outside the ROSE library, this must be the default implementation.
Regardless of the ownership policy, an attribute must not be deleted while it is a member of an AstAttributeMechanism container. This is because in order for the container to decide whether it should delete the attribute, it must first ask the attribute for its ownership policy. In other words, the following code will likely result in a segmentation fault:
Reimplemented from AstAttribute.
Definition at line 311 of file OmpAttribute.h.
|
overridevirtual |
Attribute class name.
Returns the name of the dynamic type. All subclasses must implement this in order to return the correct type name, although many don't. If a subclass fails to implement this then it will return an incorrect class name.
It would be nice if this could be pure virtual, but unfortunately ROSETTA-generated code fails to compile because it generates an instantiation of this interface (whether or not that code is ever executed is unknown). [Robb Matzke 2015-11-10]
Reimplemented from AstAttribute.
The documentation for this class was generated from the following file:
