On Mon, Jan 23, 2012 at 5:07 PM, Thomas Heller <thom.heller@googlemail.com> wrote:
On Mon, Jan 23, 2012 at 1:57 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Mon, Jan 23, 2012 at 2:37 PM, TONGARI <tongari95@gmail.com> wrote:
I wrote the sample code that conforms these requirements, full code attached.
Thanks a lot, this will greatly help me to get started.
So, as I understand, the env argument to the actor contains arguments provided for evaluation. In case of filtering expression, this is fine as there is only one argument - the set of attributes. But in case of formatter there are two arguments - the stream and the log record. Does Phoenix pass both arguments to the actor in this case?
Yes, the environment is a fusion tuple.
Ok, so it seems the attribute actor will have to be an unary function and always expect either a log record or a set of attribute values as the first argument. It's fine, as long as the argument can be rebound with phoenix::bind. A few more questions, if I may. 1. I would like to cache some data in the actor at the point of AST construction. For instance, I'd like to cache the attribute name (in the actual code it's not really a string but rather an adapter constructible from a string; I'd like to avoid its construction at the expression evaluation time) and, possibly, a default value for the attribute. Is this possible? The attribute keyword should still be a POD (or at least, be safely constructible at the namespace scope), so the cached data can only be provided only by a function call. 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? Also, what should be the template argument for the phoenix::actor specialization? Here's the code example to illustrate what I'm talking about: template< typename DescriptorT > struct attribute_keyword : public phoenix::actor< what_should_be_here? > { // extracts the attribute value template< typename ContextT > DescriptorT::value_type operator() (ContextT const& ctx) const; // adds a default value attribute_keyword_with_default< DescriptorT > or_default(DescriptorT::value_type) const; }; // assume there are specializations of custom_terminal and // is_custom_terminal for attribute_keyword // This is generated by BOOST_LOG_REGISTER_ATTRIBUTE namespace tag { struct severity { typedef my_severity value_type; typedef attribute_name name_type; // returns an equivalent for "Severity" // I want to cache its result in the AST static name_type get_name(); }; } const attribute_keyword< tag::severity > severity; // is this safe?
I have to admit the docs are very unclear about that specifc part ... needs some loving.
Right, the docs are lacking a good tutorial for library extenders. Its internals are rather complicated to gather this information from.