AMDG Andrey Semashev wrote:
On 03/16/2010 06:57 PM, Steven Watanabe wrote:
Andrey Semashev wrote:
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?
I thought that you just described the dangerous behavior.
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.
It can if you use a different interface. Ideally, I'd like the interface to be like boost::any (or even /be/ boost::any). i.e. having access to the typeid and the ability to cast to a specific type.
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.
Can't it save the thread id in a separate object? It's hard for me to believe that this is a valuable optimization given that none of the other provided attributes behave in this way.
Also, attributes, as well as attribute values, may be accessed concurrently, so modifying their state would require locking.
Then access should be through a reference or a pointer to const. In Christ, Steven Watanabe