On 03/16/2010 06:57 PM, Steven Watanabe wrote:
AMDG
Andrey Semashev wrote:
On 03/16/2010 02:02 AM, Steven Watanabe wrote:
Andrey Semashev wrote:
but with extract it doesn't have the copyability restriction.
Why does this require System to be copyable? Can't you return a reference?
Returning a reference looks like an unsafe interface design to me. Remember that double dispatch is taken place here, so that the caller's visitor is invoked by the attribute value, with a reference to the actual value. In order to return this reference from get_nothrow, it has to be saved by the visitor and restored after returning from the attribute value dispatch method. At this point the reference may potentially be broken.
Then I consider your dispatcher interface to be the unsafe thing.
Why? In what way is it unsafe?
Is there a good reason to allow the attribute value to be constructed on the fly every time it's needed?
I tried not to introduce such restriction since it cannot be verified during the compilation.
The only built-in attribute that does this is the current_thread_id attribute, and I don't see a problem with saving the current thread id when getting the attribute's value.
The current_thread_id attribute also exposes itself as the attribute value and thus cannot save the id. Also, attributes, as well as attribute values, may be accessed concurrently, so modifying their state would require locking.