Boost logo

Boost :

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:

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at