Corrected link to "More about CAPs" in note.

Author:halw
Date:2010-05-27T01:55:27.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@619 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2010-05-27 01:55:27 +00:00
parent ed8aed5b0c
commit 7e70a8ff08

View File

@@ -69,7 +69,7 @@ Here a check is made to ensure <code>x</code> is not void. Then as long as no as
It is important to understand that in this example (and with other CAPs), <code>x</code> is allowed to be a local variable or formal argument only. That is, <code>x</code> may not be an attribute or general expression (with one exception which we will see [[#Stable attributes|below]]). Direct access to class attribute references cannot be allowed via a CAP due to the fact that they could be set to void by a routine call in some execution path invoked by the intervening instructions or possibly even different process thread. In a later [[Void-safety: Background, definition, and tools#Types as "attached" or "detachable"|section]], we well see that this is not quite such a limitations as it may appear at this point.
{{note|You will find more useful information about CAPs in [[Void-safe programming in Eiffel#More about CAPs|More about CAPs]]. Learn how certain code patterns are determined to be CAPs in [[What makes a Certified Attachment Pattern]]. }}
{{note|You will find more useful information about CAPs in [[Creating a new void-safe project#More about CAPs|More about CAPs]]. Learn how certain code patterns are determined to be CAPs in [[What makes a Certified Attachment Pattern]]. }}
===The ''attached syntax'' (object test)===