Boost logo

Boost :

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


John Torjo wrote:
> See 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.


>> 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
I have no problem with putting everything associated with a particular
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


>> Second, is there any particular reason not to use shared_ptr directly?
> Yes, see this :

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.
> (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 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
> 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
(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, gregod at, cpdaniel at, john at