Boost logo

Boost :

From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-02-05 15:25:51


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#manipulator_manipulate
>

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk