Menu

Can log::record or sink_list reuse

helingen
2013-03-18
2013-06-03
  • helingen

    helingen - 2013-03-18

                    Can log::record or sink_list reuse

    While Using boost-log, I browsed partial code of boost-log-1.1 and boost-log-2.0-RC1, and have some questions to seek advice. The questions are as follows:
    一、The record returned from (logger).open_record() can reuse——In fact, just want to know is, relative to BOOST_LOG_STREAM_WITH_PARAMS_INTERNAL, I can record log in the following style:
    ::boost::log::record rec_var;
    fun1()
    {
    ::boost::log::record rec_var = (logger).open_record((BOOST_PP_SEQ_ENUM(params_seq)));
    }
    fun2()
    {
    if (rec_var)
    {
    rec_var.message() = "Hello, world!";
            core->push_record(rec_var);
    }
    }

    二、Why do you want to use it like this
    Like this, When writing log, need not to speed time on apply_sink_filter. For the same "log source", the target/sink backends which used by the first time to write log and subsequent write, is almost same, in application; Sink list, the first filter is the future need. Write log, severity_level may a difference, but that is handled in push_record do.

    三、The feeling of browsing code
    I Feeling, version 1.1 and version 1.1 boost-log can't record log in the above way, although the function mode and class implementation of version 2.0 code have done more modification:
    1、In version 1.1, "intrusive_ptr< public_data > m_pData" which is a member of basic_record, as a record, is a intrusive_ptr;
    2、In version 2.0, the record information is temporarily stored in public_data* record::m_impl; Previous "string_type m_Message" now is as the attribute value stored, know which position is the log messages, to replace in order to realize the reuse, seemed less convenient operation.
    3、As to get the the record's sink_list in returned open_record, then construct a record, due to the presence of the "private: struct private_data", class limit, without changing the source code, it seems to only feel powerless and frustrated!

    四、Why
    Why such a design? Or source I see is not detailed enough, cognitive error, a worrier?

    Based on the above condition, then send this post to boost-log authors and the wise men saw this post, please comment.

    Endless Words English expression, so attach the Chinese expression, hoping can understand what I want to express the meaning of.

    ////////////////////////////////////////////////////////////////////////////////////////
                   log::record 或者 private_data's sink_list可以复用吗

    使用boost-log的过程中,我翻阅了boost-log-1.1和boost-log-2.0-RC1的部分源码,有几个疑问想要请教下:
    一、(logger).open_record()返回的record可以重复使用吗——其实也就是想知道,相对于BOOST_LOG_STREAM_WITH_PARAMS_INTERNAL,我可以以如下的方式记录log吗?
    ::boost::log::record rec_var;
    fun1()
    {
    ::boost::log::record rec_var = (logger).open_record((BOOST_PP_SEQ_ENUM(params_seq)));
    }
    fun2()
    {
    if (rec_var)
    {
    rec_var.message() = "Hello, world!";
            core->push_record(rec_var);
    }
    }

    二、为什么想这样使用
    这样使用,记录日志时不用每次open_record将时间花费在apply_sink_filter上;对于同一个“log source”,程序中使用它第一次写日志与后续的写,目标/sink backends基本上是一样的,第一次filter后的sink list,就是以后需要的sink;写日志时,severity_level可能有差别,但那是在push_record中做的处理的。

    三、浏览代码的感觉
    感觉1.1版与2.0版的“boost-log”,都不能像上面方式记录日志,尽管2.0版的代码功能分配与类的实现做了较多改动:
    1、1.1版中record暂存在basic_record中的intrusive_ptr< public_data > m_pData,是个intrusive_ptr;
    2、2.0版中record暂存在public_data* record::m_impl,而以前的string_type m_Message现在是当作attribute value存储的,获知哪一个位置是日志消息,从而替换以实现复用,似乎不那么方便操作。
    3、至于取出open_record返回的record中的sink_list,再构造一个record,有了private:struct private_data的类限制,在不改动源码的情况下,似乎也只能望洋兴叹!

    四、疑问
    为什么这样设计?还是源码我看的不够细、认知有误、杞人忧天了?

    基于以上情况,遂发个这个帖子,向boost-log作者及看见该贴的明白人讨教,恳请赐教。

     
  • Andrey Semashev

    Andrey Semashev - 2013-03-18

    I'm sorry, I didn't understand most of your post. From what I gathered, you're trying to reuse log records, and this is not possible with Boost.Log. You should not try this with v1 and this is explicitly prohibited in v2. The reason is that the formatters and the sinks may use the record (more precisely, its attributes) after push_record returns. Also, conceptually every record you generate may have different attribute values (such as timestamps, line counters, etc.) which may alter records processing (filtering and ordering in sinks). You should always create new records and never try to cache them.

     
  • helingen

    helingen - 2013-03-19

    Think you very much for your answer and explanation——“conceptually every record you generate may have different attribute values (such as timestamps, line counters, etc.) which may alter records processing (filtering and ordering in sinks).”

     

Log in to post a comment.