Re: [boost] [log][phoenix] Questions on porting to phoenix

Subject: Re: [boost] [log][phoenix] Questions on porting to phoenix
From: Eric Niebler (eric_at_[hidden])
Date: 2012-01-24 11:30:16

On 1/24/2012 1:54 AM, TONGARI wrote:
> 2012/1/24 Andrey Semashev <andrey.semashev_at_[hidden]>
>> 2. I would like the keyword have additional methods, in particular,
>> for default attribute value provision. Extending my initial syntax,
>> this would be:
>>
>>  BOOST_LOG_REGISTER_ATTRIBUTE("Severity", severity, my_severity)
>>
>>   attribute_values_view attrs;
>>
>>  severity(attrs); // returns optional<my_severity>
>>  severity.or_default(info)(attrs); // returns my_severity, which is
>> info by default
>>
>> As I understand, the only way I can do that, except for reimplementing
>> phoenix::actor, is to derive my actor from phoenix::actor. This makes
>> the attribute keyword non-POD in C++03 but is it still safe to be
>> constructed in the namespace scope, provided that the keyword does not
>> have its own data members?
> 
> I'm not sure as well, that's what I always want to ask Eric:
> http://www.boost.org/doc/libs/1_48_0/doc/html/proto/appendices.html#boost_proto.appendices.rationale.static_initialization

Proto doesn't force you to use inheritance to extend and expression with
additional member (see BOOST_PROTO_EXTENDS). But Phoenix may, I don't
know. Thomas?

> Anyway, I played a trick while not knowing if it's available.
> The idea is:
> 
>     struct Pod {...you could have some data...};
>     struct Derived : Pod {}; // non-POD in C++03
>     Pod p_base = {...some data...}; // statically initialized
>     Derived& p = static_cast<Derived&>(p_base); // statically initialized,
> not?

Aside from the fact that this is non-standard, not all compilers
statically initialize references, though they should.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com