Re: [boost] [log] Comments

Subject: Re: [boost] [log] Comments
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-03-16 13:41:30

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