Did you also set up a [url=http://boost-log.sourceforge.net/libs/log/doc/html/log/detailed/expressions.html#log.detailed.expressions.formatters.named_scope]formatter[/url] for your sink?.
2013-05-21 04:07:19 PDT in Boost.Log
Yes, the library requires Boost 1.53. I don't think there is much use in BOOST_LOG_VERSION macro since the library will be released with Boost from now on. You can test for Boost version if you target your code for multiple Boost releases.
2013-05-13 02:35:04 PDT in Boost.Log
[quote]1. OK. What's the downside of keeping phoenix::if_?[/quote] Well, it does a bit different thing. It extracts the value and then checks that it is present instead of just checking that the attribute is in the record. Also, if you ever want to extend your formatter so that it has a fixed part in addition to the conditional expression you will find out that it is not possible with...
2013-04-25 10:09:41 PDT in Boost.Log
1. This is probably because there's missing streaming expression in the formatter. Try this: [code] return expr::stream << expr::if_(expr::has_attr<posix_time::ptime>(name_)) [ ... [/code] 2. But you can't use this operator either, can you? You have to do using declarations in order to make this operator visible for the compiler from the point where you're calling it.
2013-04-25 07:40:09 PDT in Boost.Log
[quote]I tried expr::if_, it didn't work.[/quote] Why? What was the problem? [quote]The point is that right now not everything that compiles for std::ostream compiles for boost::log::_xxx_stream_xxx_[/quote] Could you give an example of such code? If it works for std::ostream without any hassle on your side, it should also work for log::formatting_ostream.
2013-04-24 20:21:26 PDT in Boost.Log
Oh, I also forgot to mention. It is typically a bad idea to bind member functions of third party libraries, like time_duration::total_microseconds or value_ref::get, because their signatures may change and break your code. A better approach is to create your own function that takes the value_ref and performs the needed calculations normally. This would also simplify code.
2013-04-24 14:28:46 PDT in Boost.Log
[code]phx::if_(expr::attr<posix_time::ptime>(name_))[/code] I guess, this should be [code]expr::if_(expr::has_attr<posix_time::ptime>(name_))[/code] and name_ should be used instead of log_attibutes::timestamp in the format_date_time call. [quote]Another problem we ran into while porting is that the boost log formatting stream intercepts all operator << calls and...
2013-04-24 14:24:56 PDT in Boost.Log
[quote]I am referring to this[/quote] This is a part of the internal library interface, I wouldn't recommend using it unless there is no other way. [quote]Do you have an example on how to bind a new formatter?[/quote] Sure, just see how point_formatter_factory is implemented on the...
2013-04-23 13:52:18 PDT in Boost.Log
I think the best way to handle this "raw" format in config files is to detect it in the formatter factory and create different formatters for different cases. As I mentioned, you can bind your own raw formatter with phoenix::bind. I'm not sure what placeholders (on_placholder) you're referring to.
2013-04-23 13:34:53 PDT in Boost.Log
Sorry, there is no dedicated migration guide, although I probably should have written one. The list of changes is available in the [url=http://boost-log.sourceforge.net/libs/log/doc/html/log/changelog.html]changelog[/url], there are also links to other relevant sections of the docs. I'll be glad to answer your questions if you have any. Regarding the custom formatter, the principle stayed the...
2013-04-23 11:54:14 PDT in Boost.Log