AMDG John Torjo wrote:
See http://torjo.com/log2/doc/html/caching.html for the rationale. However, for a named_logger, we might be able to avoid caching - that is, initialize it in one step.
I see.
Note that in the future I want to make caching a policy - I just didn't have time to do it before the review.
Ok.
Concepts as Namespaces: I strongly dislike this way of expressing it. What you mean is that you put implementations of that concept in a specific namespace. The concept, per se, has no relation to the namespace. This description is very misleading, IMO.
Actually I think this is way too cool. First of all, it's very easy to find everything that is related to a concept: - in the documentation - just click on that namespace - when using code completion
In fact once you get used to the library, you'll see that gets easier and easier to read the code/docs. I don't know if any other lib has done this before - but please give it a shot first ;)
That's fine, but a concept is not a namespace. A concept is a set of requirements. I have no problem with putting everything associated with a particular concept in a single namespace. What I object to is your terminology.
Is there a way to have destination specific formatters?
Yes. When using a custom route (msg_route::with_route). If you make optimize::cache_string_several_str<> your msg formatter. See http://torjo.com/log2/doc/html/no__levels__with__route_8cpp-example.html
Great.
Second, is there any particular reason not to use shared_ptr directly?
Yes, see this : http://torjo.com/log2/doc/html/namespaceboost_1_1logging_1_1manipulator.html...
That doesn't answer my question.
Level: I can't figure out from the documentation what I would need to do to model this concept.
http://torjo.com/log2/doc/html/namespaceboost_1_1logging_1_1level.html
(also, see scenario below)
What if I want to write my own level holder? All that gives is a list of level holders and levels that you provide.
Gather: What exactly are the requirements? The docs say "a function that will gather the data - called .out()" What are the requirements on the return type? Further in scenarios_code.html#scenarios_code_mon there is the definition void *out(const char* msg) { m_msg = msg; return this; } Is out() called implicitly or not? Why is "this" returned as a void*? Confused...
The requirements are to return a void* pointer. This is needed when http://torjo.com/log2/doc/html/caching.html and you want to cache the filter as well.
Then, are there two cases? The version of out returning an ostream and the version that processes the results directly and returns void*?
If I remove the usage of http://torjo.com/log2/doc/html/caching.html#caching_BOOST_LOG_BEFORE_INIT_CA... then you can return anything you like. For more details, please take a look at cache_before_init_macros.hpp, line 50
Tag: The only requirement on a tag is that it must be CopyConstructable (Is it Assignable, too?). tag::holder is a effectively a fusion::set of tags.
Not really - theres'a bit of logic in that class.
Ok. That was the best guess I could come up with from namespaceboost_1_1logging_1_1tag.html. (structboost_1_1logging_1_1tag_1_1holder.html is completely useless)
It's not clear from either the tag or holder documentation how to extract tags in a formatter.
Not sure what you mean.
Suppose I write my own tag. struct my_tag { const char* data; }; Now, I also need a formatter capable of processing it, right? a) what should the argument type to the formatter be? b) How do I get the value of my_tag?
One final comment about the Concepts:
Manipulators: I think this framework is overly complex. It would be
Why?
If manipulators are effectively function objects, I would like to be able to just plug in existing function objects like those created by bind. If there isn't anything more to specialize then you should re-use existing concepts.
better to make manipulators Equality Comparable Unary Function Objects. In the case of destinations the return type is ignored, for for formatters, the result type should be the same as the argument type. For both the argument type is determined from the
"for formatters the result should be the same as the argument type" - why?
Because the result may have to be passed on to other formatters, of the same static type right? Or am I completely misunderstanding how formatters work?
logger. You can use type erasure to allow them to be treated polymorphically at runtime.
Isn't this what I'm doing?
Maybe so, but I don't understand the need to use inheritance at all. In Christ, Steven Watanabe