Re: [boost] [log] Comments

Subject: Re: [boost] [log] Comments
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-16 14:13:17

On 03/16/2010 08:41 PM, Steven Watanabe wrote:
> 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.

I described unsafe assumption that would have to be taken to implement 
the suggested interface. There's nothing unsafe in dispatchers.

>>> 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.

If it had a dispatching (visitation) interface, similar to what I've 
implemented in Boost.Log, I would have used Boost.Any.

>>> 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.

You mean, to save it into a TLS? Sure, it could. But why bother, since 
with my interface it's not required.

>> 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.

You lost me here.