|
|
Boost-Commit : |
From: john.groups_at_[hidden]
Date: 2007-10-30 03:46:53
Author: jtorjo
Date: 2007-10-30 03:46:51 EDT (Tue, 30 Oct 2007)
New Revision: 40600
URL: http://svn.boost.org/trac/boost/changeset/40600
Log:
[logging]
v0.9.3, 30 oct 2007
- updated documentation
- updated workflow/most of the pages in the table of contents
- removed most of references to @c process_msg class
Properties modified:
sandbox/logging/lib/logging/samples/basic_usage/ (props changed)
Text files modified:
sandbox/logging/boost/logging/changelog.hpp | 5 +
sandbox/logging/boost/logging/detail/logger.hpp | 14 ++-
sandbox/logging/boost/logging/detail/manipulator.hpp | 72 ++++++++++++++----
sandbox/logging/boost/logging/detail/raw_doc/fixme.hpp | 4
sandbox/logging/boost/logging/detail/raw_doc/namespace_concepts.hpp | 4
sandbox/logging/boost/logging/detail/raw_doc/table_of_contents.hpp | 4
sandbox/logging/boost/logging/detail/raw_doc/workflow.hpp | 155 +++++++++++++++++++--------------------
sandbox/logging/boost/logging/macros.hpp | 8 +
sandbox/logging/boost/logging/process_msg/ostream_like.hpp | 107 ++++++++-------------------
sandbox/logging/boost/logging/writer/format_write.hpp | 21 ++--
10 files changed, 201 insertions(+), 193 deletions(-)
Modified: sandbox/logging/boost/logging/changelog.hpp
==============================================================================
--- sandbox/logging/boost/logging/changelog.hpp (original)
+++ sandbox/logging/boost/logging/changelog.hpp 2007-10-30 03:46:51 EDT (Tue, 30 Oct 2007)
@@ -1,6 +1,11 @@
/**
@page page_changelog Changelog
+v0.9.3, 30 oct 2007
+- updated documentation
+ - updated workflow/most of the pages in the table of contents
+ - removed most of references to @c process_msg class
+
v0.9.2, 30 oct 2007
- Breaking chage:
- @c process_msg class has been removed. Now @c logger takes its place
Modified: sandbox/logging/boost/logging/detail/logger.hpp
==============================================================================
--- sandbox/logging/boost/logging/detail/logger.hpp (original)
+++ sandbox/logging/boost/logging/detail/logger.hpp 2007-10-30 03:46:51 EDT (Tue, 30 Oct 2007)
@@ -61,7 +61,7 @@
- @ref workflow_2a "Gathering the message"
- @ref workflow_2b "Processing the message"
- The process_msg class has 2 template parameters:
+ The logger class has 2 template parameters:
@param gather_msg A new gather instance is created each time a message is written.
@@ -82,24 +82,26 @@
\n\n
- The logger forwards all message processing to the @c %process_msg class. The @c %process_msg class forwards
+ The logger forwards
the gathering of the message to the @c gather_msg class. Once all message is gathered, it's passed on to the writer.
This is usually done through a @ref macros "macro".
@code
- logger< process_msg<...> ... > g_log;
+ typedef logger< ... > log_type;
+ BOOST_DECLARE_LOG_FILTER(g_log_filter, filter::no_ts )
+ BOOST_DECLARE_LOG(g_l, log_type)
- #define L_ if ( !g_log) ; else g_log->read_msg().gather().some_function_in_the_gather_class
+ #define L_ BOOST_LOG_USE_LOG_IF_FILTER(g_l, g_log_filter->is_enabled() )
// usage
- L_ << "cool " << "message";
+ L_ << "this is so cool " << i++;
@endcode
\n\n
- To understand more on the workflow that involves process_msg:
+ To understand more on the workflow that involves %logging:
- check out the gather namespace
- check out the writer namespace
Modified: sandbox/logging/boost/logging/detail/manipulator.hpp
==============================================================================
--- sandbox/logging/boost/logging/detail/manipulator.hpp (original)
+++ sandbox/logging/boost/logging/detail/manipulator.hpp 2007-10-30 03:46:51 EDT (Tue, 30 Oct 2007)
@@ -38,6 +38,7 @@
- @ref manipulator_common
- @ref manipulator_base_class
+- @ref manipulator_default_base_class
- @ref manipulator_generic
- @ref manipulator_create
- @ref manipulator_share_data
@@ -63,18 +64,20 @@
+
+
\n\n\n
@section manipulator_base_class Specifying the base class
-As said @ref manipulator_common "above", formatters and destinations need a %base class.
-You do this through a typedef - one for the formatters, and one for the destinations:
+You can use a typedef - one for the formatters, and one for the destinations:
@code
// ptr_type - optional ; usualy you don't need to worry about this
-typedef formatter::base<arg_type [,ptr_type]> formatter_base;
-typedef destination::base<arg_type [,ptr_type]> destination_base;
+typedef formatter::base< arg_type [,ptr_type] > formatter_base;
+typedef destination::base< arg_type [,ptr_type] > destination_base;
@endcode
+
The @c arg_type is the argument you receive in your <tt>operator()</tt>, to process the message. It can be as simple as this:
@code
@@ -100,13 +103,54 @@
+
+\n\n\n
+@section manipulator_default_base_class Default base classes
+
+As shown above, you can do your own typedefs. But there's an easier way, to specify the default base classes:
+use the default formatter %base class and the default destination %base class.
+
+They are: <tt>formatter::base<> </tt> and <tt>destination::base<> </tt>.
+
+The default formatter %base class is computed based on your usage of the @c BOOST_LOG_FORMAT_MSG macro:
+- if you haven't used it, it's <tt>std::(w)string & </tt>
+- if you've used it, it's the type you specified there; see below
+
+@code
+BOOST_LOG_FORMAT_MSG( optimize::cache_string_several_str<> )
+@endcode
+
+In the above case
+@code
+formatter::base<> = formatter::base< optimize::cache_string_several_str<>& >
+@endcode
+
+
+
+The default destination %base class is computed based on your usage of the @c BOOST_LOG_DESTINATION_MSG macro:
+- if you haven't used it, it's <tt>const std::(w)string & </tt>
+- if you've used it, it's the type you specified there; see below
+
+@code
+BOOST_LOG_DESTINATION_MSG( my_cool_string )
+@endcode
+
+In the above case
+@code
+destination::base<> = destination::base< const my_cool_string & >
+@endcode
+
+
+
+
+
\n\n\n
@section manipulator_generic Using manipulators that come with the library
Now, you will define your @ref logger "logger(s)", to use the @ref boost::logging::writer::format_write "format_write" class:
@code
-logger< ... format_write<formatter_base,destination_base> > g_l;
+BOOST_DECLARE_LOG(g_l, logger< ... format_write<formatter_base,destination_base> > );
@endcode
After this, you'll add formatter and/or destination classes to your logger(s):
@@ -158,19 +202,16 @@
@section manipulator_create Creating your own formatter and/or destination class(es)
To create your formatter class, you need to derive from @ref class_ "formatter::class_". You will need to implement
-<tt>operator()(arg_type)</tt> <br> (@c arg_type is the argument you passed in your @ref manipulator_base_class "formatter_base" typedef)
+<tt>operator()(arg_type)</tt> <br> (@c arg_type is the argument from your @ref manipulator_base_class "formatter base class")
@code
-typedef formatter::base< std::string&> formatter_base;
-...
-
// milliseconds since start of the program
-struct ms_since_start : formatter::class_<ms_since_start, formatter_base, op_equal_no_context> {
+struct ms_since_start : formatter::class_<ms_since_start, formatter::implement_op_equal::no_context> {
time_t m_start;
ms_since_start : m_start( time(0) ) {}
// param = std::string&
- // (in other words, it's the parameter you used when you defined formatter_base)
+ // (in other words, it's the arg_type from your formatter base class)
void operator()(param msg) const {
std::ostringstream out;
time_t now = time(0);
@@ -181,20 +222,17 @@
@endcode
To create your destination class, you need to derive from @ref class_ "destination::class_". You will need to implement
-<tt>operator()(arg_type)</tt> <br> (@c arg_type is the argument you passed in your @ref manipulator_base_class "destination_base" typedef)
+<tt>operator()(arg_type)</tt> <br> (@c arg_type is the argument from your @ref manipulator_base_class "destination base class")
@code
-typedef destination::base< const std::string&> destination_base;
-...
-
-struct to_hwnd : destination::class_<to_hwnd, destination_base, op_equal_has_context> {
+struct to_hwnd : destination::class_<to_hwnd, destination::implement_op_equal::has_context> {
HWND h;
to_hwnd(HWND h) : h(h) {}
bool operator==(const to_hwnd& other) { return h == other.h; }
// param = const std::string&
- // (in other words, it's the parameter you used when you defined destination_base)
+ // (in other words, it's the arg_type from your destination base class)
void operator()(param msg) const {
::SetWindowText(h, msg.c_str());
}
Modified: sandbox/logging/boost/logging/detail/raw_doc/fixme.hpp
==============================================================================
--- sandbox/logging/boost/logging/detail/raw_doc/fixme.hpp (original)
+++ sandbox/logging/boost/logging/detail/raw_doc/fixme.hpp 2007-10-30 03:46:51 EDT (Tue, 30 Oct 2007)
@@ -5,8 +5,10 @@
FIXME change the workflow & logger's definition - it doesn't need a filter
all gather classes - they need to typedef the param they take, so that I can create a virtual function.
no more process_msg class -> remove from docs!
+gathering the message - gather class must hold "param" type!
+gather namespace - rewrite docs
-
+tell about logger_format_write <> - in format_write<> as well
------> FIXME after showing scenarios, show customizing?
Modified: sandbox/logging/boost/logging/detail/raw_doc/namespace_concepts.hpp
==============================================================================
--- sandbox/logging/boost/logging/detail/raw_doc/namespace_concepts.hpp (original)
+++ sandbox/logging/boost/logging/detail/raw_doc/namespace_concepts.hpp 2007-10-30 03:46:51 EDT (Tue, 30 Oct 2007)
@@ -9,7 +9,7 @@
This library uses a few concepts.
-Take filter, for instance. It's a very simple concept - it only requires the <tt>bool is_enabled() const;</tt> function to be present.
+Take filter, for instance. It's a very simple concept - it tells you if "it's enabled".
Each concept can be implemented in several ways. To make it easier for you, <b>each concept is a namespace</b>.
In the given namespace, you'll find possible implementations of that concept. Of course, to those implementations, you can add your own ;)
@@ -23,7 +23,7 @@
\n\n
@section namespace_process Processing the message
-(for more info, see process_msg class)
+(for more info, see logger class)
- gather - gathering the message
- writer - %writer objects; they do the actual write of the message
- gather::ostream_like - (related to gathering the message) allows gathering the message using the cool operator<< (@ref workflow_2a)
Modified: sandbox/logging/boost/logging/detail/raw_doc/table_of_contents.hpp
==============================================================================
--- sandbox/logging/boost/logging/detail/raw_doc/table_of_contents.hpp (original)
+++ sandbox/logging/boost/logging/detail/raw_doc/table_of_contents.hpp 2007-10-30 03:46:51 EDT (Tue, 30 Oct 2007)
@@ -34,13 +34,13 @@
- @ref namespace_manipulator
- @ref namespace_write
- @ref logger "The logger class"
-- @ref filter "The filters (namespace)"
-- @ref process_msg "The process message class"
- @ref gather "The gather namespace"
- @ref writer "The writer namespace"
+- @ref filter "The filters (namespace)"
- @ref manipulator "Formatters and/or destinations (manipulators namespace)"
- @ref manipulator_common
- @ref manipulator_base_class
+ - @ref manipulator_default_base_class
- @ref manipulator_generic
- @ref manipulator_create
- @ref manipulator_share_data
Modified: sandbox/logging/boost/logging/detail/raw_doc/workflow.hpp
==============================================================================
--- sandbox/logging/boost/logging/detail/raw_doc/workflow.hpp (original)
+++ sandbox/logging/boost/logging/detail/raw_doc/workflow.hpp 2007-10-30 03:46:51 EDT (Tue, 30 Oct 2007)
@@ -11,94 +11,83 @@
- @ref workflow_2b
-_at_attention
-The filter is not kept in the logger anymore. They are different concepts. Need to update these pages
-Every time, the logger should contains a process_msg<> class. This is the core class.
@section workflow_introduction Introduction
+
What happens when a message is written to the log?
+- the message is filtered : is the filter enabled?
+ - if so (in other words, the log is turned on), process the message:
+ - gather the message
+ - write the message to the destination(s)
+ - if not (in other words, the log is turned off)
+ - completely ignore the message
-First, you have a logger you write to. @b Every logger contains 2 things:
-- a filter, which indicates if the log is turned on or off
-- a processor, which will process the message, in case the log is turned on.
+The part that says "Completely ignore the message" means that <em>if the log is not enabled, no processing takes place</em>.
-Whenever you create a logger, you specify the filter and the processor as template parameters:
+For instance, say you have:
@code
-// filter is optional - there is a default
-logger< the_processor, the_filter> g_l;
+LDBG_ << "user count = " << some_func_taking_a_lot_of_cpu_time();
@endcode
-Example:
+If @c LDBG_ is disabled, everything after "LDBG_" is ignored. Thus, @c some_func_taking_a_lot_of_cpu_time() will not be called.
-_at_code
-using namespace boost::logging;
-logger<write_to_cout, filter::no_ts> g_log;
-_at_endcode
+First of all, we have 2 concepts:
+- logger : a "logical" log - something you write to; it kwnows its destination(s), that is, where to write to
+- filter : this provides a way to say if a logger is enabled or not. Whatever that "way to say a logger is enabled or not" means,
+ is up to the designer of the filter class.
+Note that the logger is a templated class, and the filter is a @ref namespace_concepts "namespace". I've provided
+several implementations of the filter concept - you can use them, or define your own.
@section workflow_filter Step 1: Filtering the message
-First time the message is filtered. The filter class only needs to provide the @c is_enabled function.
-Then, the logger provides 2 helpers:
-- operator bool()
-- operator !
-
-Thus, in your code, you can easily find out if a logger is enabled or not:
+As said above, the filter just provides a way to say if a logger is enabled or not. The %logger and the %filter are completely
+separated concepts. No %logger owns a %filter, or the other way around. You can have a %filter per %logger, but most likely
+you'll have one %filter, and several loggers:
@code
-logger<write_to_cout, filter::no_ts> g_log;
+// Example 1 : 1 filter, 1 logger
+BOOST_DECLARE_LOG_FILTER(g_log_filter, filter::no_ts )
+BOOST_DECLARE_LOG(g_l, log_type)
-// code
-if ( g_log) do_something(g_log);
+#define L_ BOOST_LOG_USE_LOG_IF_FILTER(g_l, g_log_filter->is_enabled() )
-// or
-if ( !g_log) ; else do_something...
-_at_endcode
-
-Usually, you won't write code like above - instead, you'll hide all the above with @ref macros "macros".
-Anyway, the end result is that logging is efficient - processing the message happens <b>only if</b> the filter is enabled.
-Otherwise, processing is @em completely ignored.
+// Example 2 : 1 filter (containing a level), several loggers
+BOOST_DECLARE_LOG_FILTER(g_log_level, level::holder )
+BOOST_DECLARE_LOG(g_log_err, log_type)
+BOOST_DECLARE_LOG(g_log_app, log_type)
+BOOST_DECLARE_LOG(g_log_dbg, log_type)
+#define LDBG_ BOOST_LOG_USE_LOG_IF_LEVEL(g_log_dbg, g_log_level, debug )
+#define LERR_ BOOST_LOG_USE_LOG_IF_LEVEL(g_log_err, g_log_level, error )
+#define LAPP_ BOOST_LOG_USE_LOG_IF_LEVEL(g_log_app, g_log_level, info )
+@endcode
+Every time, before anything gets written to the log, the filter is asked if "it's enabled". If so, the processing of the message takes place
+(gathering the message and then writing it). Otherwise, the log message is completely ignored.
-_at_section workflow_processing Step 2: Processing the message
+What "it's enabled" is depends on the filter class you use:
+- if it's a simple class (filter::no_ts, filter::ts, filter::use_tls_with_cache), it's simply the @c is_enabled function (Example 1, above)
+- if it's a more complex class, it's up to you
+ - for instance, the level::holder_no_ts exposes an <tt>is_enabled(level)</tt>, so you can ask if a certain level is enabled (Example 2, above)
+ Thus, logging takes place only if that certain level is enabled (@c debug for LDBG_, @c info for LAPP_, @c error for LERR_)
-Once we've established that the logger is enabled, we'll @em process the message.
-Processing means whatever your application thinks logging means.
-This can be as simple as dumping the message to cout or whatever.
-Example:
-_at_code
-struct write_to_cout {
- void operator()(const std::string & msg) const {
- std::cout << msg << std::endl ;
- }
-};
-
-using namespace boost::logging;
-logger<write_to_cout> g_single_log;
-
-#define L_(x) if ( g_single_log) g_single_log.process_msg()(x)
-
-// usage
-L_("reading word " + word);
-_at_endcode
-
-As you can see, processing the message means having a functor which implements operator(). You can be happy with something similar to the above. Or...
+\n\n
+@section workflow_processing Step 2: Processing the message
-If you think about it, you can actually divide this step, into 2 smaller steps:
+Once we've established that the logger is enabled, we'll @em process the message. This is divided into 2 smaller steps:
- gathering the message
- writing the message
-\n\n
@section workflow_2a Step 2A: Gathering the message
The meaning of "gathering the message" depends on your application. The message can:
@@ -122,66 +111,72 @@
How you gather your message, depends on how you <tt>\#define L_ ...</tt>.
-In other words, gathering the message means getting all the message in "one piece", so that it can be written.
-
+In other words, gathering the message means getting all the message in "one piece", so that it can be written. \n
+See the
+- the gather namespace - classes for gathering
+- the gather::ostream_like - classes for gathering, using the cool "<<" operator
+- @ref macros_gathering "Macros for gathering" section.
\n\n
@section workflow_2b Step 2B: Writing the message
-Now that you have the message, you're ready to write it. Again, writing is done by calling operator() on the writer object.
+Now that you have the message, you're ready to write it. Writing is done by calling @c operator() on the writer object.
What you choose as the writer object is completely up to you. It can be as simple as this:
@code
// dump message to cout
-
struct write_to_cout {
void operator()(const std::string & msg) const {
std::cout << msg << std::endl ;
}
};
-typedef process_msg< gather::ostream_like::return_str<>, write_to_cout> processor;
-logger<processor, filter::no_ts> g_single_log;
+typedef logger< gather::ostream_like::return_str<>, write_to_cout> log_type;
+BOOST_DECLARE_LOG(g_single_log, log_type)
+BOOST_DECLARE_LOG_FILTER(g_filter, filter::no_ts)
-#define L_ if ( !g_single_log) ; else g_single_log->read_msg().gather().out()
+#define L_ BOOST_LOG_USE_LOG_IF_FILTER(g_single_log, g_filter->is_enabled() )
// usage
-L_ << idx << " : reading word " << word;
+int i = 100;
+L_ << "this is " << i << " times cooler then the average log";
@endcode
You can define your own types of writers. The %writer classes that come with this library are in <tt>namespace writer</tt>.
-At this time, I've defined the concept of writer::format_write - writing using Formatters and Destinations.
+At this time, I've defined the concept of writer::format_write - writing using @ref manipulator "Formatters and Destinations".
Simply put, this means formatting the message, and then writing it to destination(s).
For each log, you decide how messages are formatted and to what destinations they are written. Example:
@code
-typedef process_msg< gather::ostream_like::return_cache_str<> ,
- format_write< format_base, destination_base, format_and_write::simple<cache_string> > > process;
-logger<process, filter::no_ts> g_l;
-
-#define L_ if ( !g_l) ; else g_l->read_msg().gather().out()
-
-// add formatters : [idx] [time] message [enter]
-g_l->writer().add_formatter( write_idx() );
-g_l->writer().add_formatter( write_time() );
-g_l->writer().add_formatter( append_enter() );
-
-// write to cout and file
-g_l->writer().add_destination( write_to_cout() );
-g_l->writer().add_destination( write_to_file("out.txt") );
+typedef logger_format_write< > log_type;
+
+BOOST_DECLARE_LOG_FILTER(g_log_filter, filter::no_ts )
+BOOST_DECLARE_LOG(g_l, log_type)
+
+#define L_ BOOST_LOG_USE_LOG_IF_FILTER(g_l, g_log_filter->is_enabled() )
+// add formatters : [idx] [time] message <enter>
+g_l->writer().add_formatter( formatter::idx() );
+g_l->writer().add_formatter( formatter::time("$hh:$mm.$ss ") );
+g_l->writer().add_formatter( formatter::append_enter() );
+// add destinations : console, output debug window, and a file called "out.txt"
+g_l->writer().add_destination( destination::cout() );
+g_l->writer().add_destination( destination::dbg_window() );
+g_l->writer().add_destination( destination::file("out.txt") );
// usage
int i = 1;
-L_ << "testing " << i++;
+L_ << "this is so cool " << i++;
+L_ << "this is so cool again " << i++;
-// the above message will be formatted like this : "[1] 22:30 testing 1\n",
-// and will be dumped to cout and "out.txt" file.
+// possible output:
+// [1] 12:32:10 this is so cool 1
+// [2] 12:32:10 this is so cool again 2
@endcode
Modified: sandbox/logging/boost/logging/macros.hpp
==============================================================================
--- sandbox/logging/boost/logging/macros.hpp (original)
+++ sandbox/logging/boost/logging/macros.hpp 2007-10-30 03:46:51 EDT (Tue, 30 Oct 2007)
@@ -32,6 +32,8 @@
/**
@page macros Macros - how, what for?
+ The need for macros - creating the object before main.
+
When dealing with logs, you will most likely want to use macros: simply to write less.
To be efficient, you usually want to write to a log only if it's enabled.
@@ -48,6 +50,10 @@
don't want compile fast? then log.h will look easier; but - are you sure you don't want to turn compile fast off?
+ @section macros_gathering
+
+ FIXME
+
Macros
- BOOST_LOG_COMPILE_FAST_ON
- BOOST_LOG_COMPILE_FAST_OFF
@@ -178,7 +184,7 @@
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Format and Destination Macros
-/**
+/** @section BOOST_LOG_FORMAT_MSG BOOST_LOG_FORMAT_MSG
@note
When using BOOST_LOG_FORMAT_MSG or BOOST_LOG_DESTINATION_MSG, you must not be within any namespace scope.
Modified: sandbox/logging/boost/logging/process_msg/ostream_like.hpp
==============================================================================
--- sandbox/logging/boost/logging/process_msg/ostream_like.hpp (original)
+++ sandbox/logging/boost/logging/process_msg/ostream_like.hpp 2007-10-30 03:46:51 EDT (Tue, 30 Oct 2007)
@@ -28,6 +28,15 @@
namespace boost { namespace logging {
+/** @page gather_the_message Gathering the message
+
+A class that implements gathering the message needs 2 things:
+- a function that will gather the data - called <tt>.out()</tt>
+- define a function called <tt>.msg()</tt> that will return the gathered data (once all data has been gathered).
+
+
+*/
+
namespace optimize {
template<class char_type_ > struct cache_string_one_str ;
}
@@ -35,22 +44,9 @@
/**
@brief Classes that implement gathering the message
- A class that implements gathering the message needs 2 things:
- - a function that will gather the data - give it any name you wish, and call that in your @ref macros "macro"
- - define a function called <tt>.msg()</tt> that will return the gathered data.
+ @copydoc gather_the_message
- The gatherer class is used by the process_msg class. When doing %logging, it's usually used like this:
-
- @code
- logger< process_msg<some_gather_class, some_writer_class> ... > g_log;
-
- #define L_ if ( !g_log) ; else g_log->read_msg().gather().gatherer_function...
-
- // usage
- L_ << "cool " << "message";
- @endcode
-
- Implementing that @c gatherer_function is rather easy, here's a simple example:
+ Implementing a gather class is rather easy, here's a simple example:
@code
struct return_str {
@@ -63,44 +59,17 @@
};
@endcode
- In the above case, defining the @ref macros "macro" is easy:
-
- @code
- #define L_ if ( !g_log) ; else g_log->read_msg().gather().out()
-
- // usage
- L_ << "cool " << "message";
- @endcode
-
@sa gather::ostream_like
*/
namespace gather {
/**
- @brief Allows you to write to a log using the cool "<<" operator.
+ @brief Gathering the message: Allows you to write to a log using the cool "<<" operator.
The <tt>.msg()</tt> function returns the gathered message.
- Example:
- @code
- struct dump_to_cout {
- void operator()(const std::stringstream & out) {
- cout << out.str();
- }
- };
-
- // define the logger
- typedef process_msg< gather::ostream_like::return_str<>, dump_to_cout> processor;
- logger<processor, filter::no_ts> g_single_log("out.txt");
-
- #define L_ if ( g_single_log) ; else g_single_log->read_msg().gather().msg()
-
- // code
- i = 100;
- L_ << "this is " << i << " times better that the average bear... ";
-
- @endcode
+ @copydoc gather_the_message
*/
namespace ostream_like {
@@ -108,14 +77,14 @@
/**
@brief Allows you to write to a log using the cool "<<" operator. The @c .msg() returns the stream itself.
- @sa ostream_like
-
Note that this is a very simple class - meant only as an example.
- Just remember:
- 1. you need a function that will gather the data - give it any name you wish, and call that in your macro
- 2. define a function called msg() that will return the gathered data.
- In our case, 1. and 2. are the same
+ @copydoc gather_the_message
+
+ See also:
+ - boost::logging::gather
+ - ostream_like
+
*/
template<class stream_type = std::basic_ostringstream<char_type> > struct return_raw_stream {
// what does the gather_msg class return?
@@ -129,6 +98,7 @@
which could have better access to its buffer/internals
*/
stream_type & msg() { return m_out; }
+ stream_type & out() { return m_out; }
private:
stream_type m_out;
};
@@ -139,29 +109,11 @@
Note that this is a very simple class.
- Just remember:
- 1. you need a function that will gather the data - give it any name you wish, and call that in your macro (in this case, it's called "out()")
- 2. define a function called msg() that will return the gathered data.
-
- Usage:
-
- @code
- struct dump_to_cout {
- void operator()(const std::string & msg) { cout << msg; }
- };
-
- // define the logger
- typedef process_msg< ostream_like<>, dump_to_cout> processor;
- logger<processor, filter::no_ts> g_single_log("out.txt");
-
- #define L_ if ( negate_sink<processor> s = g_single_log) s->read_msg().gather().out()
-
- // code
- i = 100;
- L_ << "this is " << i << " times better that the average bear... ";
-
- @endcode
+ @copydoc gather_the_message
+ See also:
+ - boost::logging::gather
+ - ostream_like
*/
template<class stream_type = std::basic_ostringstream<char_type> > struct return_str {
@@ -172,6 +124,7 @@
return_str(const return_str& other) : m_out(other.m_out.str()) {}
stream_type & out() { return m_out; }
+ /** returns a string */
std::basic_string<char_type> msg() { return m_out.str(); }
private:
stream_type m_out;
@@ -182,9 +135,14 @@
/**
@brief Allows you to write to a log using the cool "<<" operator. The .msg() returns a @ref boost::logging::optimize::cache_string_one_str "cache_string".
- @sa ostream_like
+ Returns a cache string
+
+ @copydoc gather_the_message
+
+ See also:
+ - boost::logging::gather
+ - ostream_like
- returns a cache string
@bug right now prepend_size and append_size are ignored; because we can also return a cache_string_several_str<>. When fixing, watch the find_gather class!
*/
@@ -199,6 +157,7 @@
return_cache_str(const return_cache_str& other) : m_out(other.m_out.str()) {}
stream_type & out() { return m_out; }
+ /** returns a cache_string */
cache_string msg() { return cache_string( m_out.str() ); }
private:
stream_type m_out;
Modified: sandbox/logging/boost/logging/writer/format_write.hpp
==============================================================================
--- sandbox/logging/boost/logging/writer/format_write.hpp (original)
+++ sandbox/logging/boost/logging/writer/format_write.hpp 2007-10-30 03:46:51 EDT (Tue, 30 Oct 2007)
@@ -55,26 +55,27 @@
and then all destinations are called, in the order they were added. You can easily access the router() instance.
@code
-typedef process_msg< gather::ostream_like::return_cache_str<> , format_write<...> > process;
-logger<process, filter::no_ts> g_l;
-#define L_ if ( !g_l) ; else g_l->read_msg().gather().out()
+typedef logger< gather::ostream_like::return_cache_str<> , format_write< ... > > log_type;
+BOOST_DECLARE_LOG(g_l, log_type)
+BOOST_DECLARE_LOG_FILTER(g_log_filter, filter::no_ts )
+#define L_ BOOST_LOG_USE_LOG_IF_FILTER(g_l, g_log_filter->is_enabled() )
// add formatters : [idx] [time] message [enter]
-g_l->writer().add_formatter( write_idx() );
-g_l->writer().add_formatter( write_time() );
-g_l->writer().add_formatter( append_enter() );
+g_l->writer().add_formatter( formatter::idx() );
+g_l->writer().add_formatter( formatter::time("$hh:$mm.$ss ") );
+g_l->writer().add_formatter( formatter::append_enter() );
// write to cout and file
-g_l->writer().add_destination( write_to_cout() );
-g_l->writer().add_destination( write_to_file("out.txt") );
+g_l->writer().add_destination( destination::cout() );
+g_l->writer().add_destination( destination::file("out.txt") );
// usage
int i = 1;
L_ << "testing " << i << i+1 << i+2;
@endcode
-In the above case, @c write_idx() is called, then @c write_time(), then @c append_enter(). Now, the destinations are called:
-_at_c write_to_cout(), and then @c write_to_file().
+In the above case, @c formatter::idx() is called, then @c formatter::time(), then @c formatter::append_enter(). Now, the destinations are called:
+@c destinatino::cout(), and then @c destination::file().
Most of the time this is ok, and this is what the @ref msg_route::simple "default router" does. However, there are other routers
in the msg_route namespace. For instance, take a look at msg_route::with_route class.
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk