Boost logo

Boost :

From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-02-05 18:06:50


John Torjo wrote:
> I wanted a standard way of implementing a manipulator that holds non
> constant data.
> Users will usually look at existing code and then develop their-own.
> Using shared_ptr<> could easily be overlooked, and people could would
> end up with a badly implemented manipulator.
> Also, non_const_context makes sure the shared_ptr doesn't point to
> null - syntactic sugar.
> To answer your question : you can use shared_ptr, but the recommended
> way is to use non_const_context.

And in addition, non_const_context is a slightly higher level of
The disadvantage I see is that copying such a manipulator may cause
and using shared_ptr directly makes it more obvious that copying doesn't
have normal semantics.
> Depends on what you want - the library is very flexible when it comes
> to filters. The simplest level holders looks like this:
> // the higher the level, the more critical the message
> struct level_filter {
> level_filter(int default_level = 0) : m_level(default_level) {}
> bool is_enabled(int level) const { return level >= m_level; }
> void set_enabled(int level) {
> m_level = level;
> }
> private:
> int m_level;
> };

So the minimum needed to interoperate with LOG_IF_LEVEL is
bool is_enabled(int level)?

>> 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.
> There's more to manipulators than just being a functor:
> - they need to have some inner typedefs, and they provide the
> possibility to be configured.

As far as the logging framework is concerned, is there any particular reason
that you need to support configuration directly? Why can't there just be an
interface for accessing manipulators. Oh. I get it. You've lost the
type information. I'll shut up now until I have time to look at 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?
> They don't work like that. A formatter gets a string as argument to
> its operator(), and it manipulates that string.
> So each manipulator works isolated from the other formatters.

In place manipulation. Doh. (Sounds like I've been doing too much
functional programming recently)

In Christ,
Steven Watanabe

Boost list run by bdawes at, gregod at, cpdaniel at, john at