mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2025-12-08 15:52:26 +01:00
edd0fe209f
Date:2009-09-16T23:27:03.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@301 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
47 lines
2.8 KiB
Plaintext
47 lines
2.8 KiB
Plaintext
[[Property:title|What makes a Certified Attachment Pattern]]
|
|
[[Property:weight|8]]
|
|
[[Property:uuid|1a20197d-5a88-59c3-9a04-512399125661]]
|
|
{{underconstruction}}
|
|
|
|
|
|
|
|
==A little background on CAPs==
|
|
|
|
Certified Attachment Patterns (CAPs) were described in the section on [[Void-safety: Background, definition, and tools#Certified attachment patterns (CAPs)|void-safety tools]]. To review, a CAP is a code pattern for a certain expression, say <code>exp</code> of a detachable type that ensures that <code>exp</code> will never have a void run-time value within the covered scope.
|
|
|
|
A simple example is the familiar test for void reference:
|
|
<code>
|
|
if l_x /= Void then
|
|
l_x.do_something
|
|
end
|
|
</code>
|
|
We know that after the explicit check to make sure <code>l_x</code> is not <code>Void</code>, that the feature application <code>l_x.do_something</code> is void-safe.
|
|
Of course, you should remember from previous discussions that <code>l_x</code> must be a local variable, a formal argument, or a [[Void-safety: Background, definition, and tools#Stable attributes|stable attribute]].
|
|
|
|
When void-safety was first envisioned for Eiffel, it was intended that individual CAPs would be proven or certified and documented. This would produce a "catalog" of CAPs.
|
|
|
|
What happened instead is that the members of the Eiffel standards committee have been able to produce and publish as part of the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard] a definition of the nature of a CAP from which a determination can be made as to whether a particular code pattern is or is not a CAP.
|
|
|
|
The definition in the standard document is not easily readable by most developers. So, in this documentation, you will see various examples of CAPs and the rationale behind them.
|
|
|
|
|
|
==The standard CAP definition==
|
|
|
|
The Eiffel standard (2nd edition, June 2006) defines a CAP as follows:
|
|
----
|
|
'''''A Certified Attachment Pattern (or CAP) for an expression <code>exp</code> whose type is detachable is an occurrence of <code>exp</code> in one of the following contexts: '''''
|
|
|
|
|
|
'''''1. <code>exp</code> is an Object-Test Local and the occurrence is in its scope. '''''
|
|
|
|
'''''2. <code>exp</code> is a read-only entity and the occurrence is in the scope of a void test involving <code>exp</code>.'''''
|
|
----
|
|
|
|
The terminology used in the definition is precise. For example, terms like "read-only entity" and "scope of a void test" have specific meanings that are supported by their own definitions in the standard.
|
|
|
|
Here we will consider the CAP definition only, but our discussion will be supported by the ancillary definitions. Of course, the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard document] is available for download if you need to review the specific details.
|
|
|
|
|
|
|
|
|