The easy way, use Named Formatters and Destinations

You use a string to specify Formatters, and a string to specify Destinations. Thus, you use the writer::named_write.

First, the examples: example 1, example 2

step 1: (optional) Specify your format message class and/or destination message class. By default, it's std::(w)string. You'll use this when you want a optimize string class. Or, when using tags
step 2: Specify your logging and filter classes
- step 2A: Typedef your logger as typedef boost::logging::named_logger<>::type logger_type; and typedef your filter class
- step 2B: Declare the filters and loggers you'll use (in a header file)
- step 2C: Define the filters and loggers you'll use (in a source file). We need this separation (into declaring and defining the logs/filters), in order to make compilation times fast.
step 3: Define the macros through which you'll do logging
step 4: Initialize the logger.
- step 4A: Set the formatters and destinations, as strings.
- step 4B: Mark the logger as initialized

The manual way

First, the examples: example 1, example 2

step 1: (optional) Specify your format message class and/or destination message class. By default, it's std::(w)string. You'll use this when you want a optimize string class. Or, when using tags
step 2: (optional) Specify your formatter & destination base classes
step 3: Specify your logging and filter classes
- step 3A: Typedef your filter class(es) and Typedef your logger class(es)
- step 3B: Declare the filters and loggers you'll use (in a header file)
- step 3C: Define the filters and loggers you'll use (in a source file). We need this separation (into declaring and defining the logs/filters), in order to make compilation times fast.
step 4: Define the macros through which you'll do logging
step 5: Initialize the logger
- step 5A: Add formatters and destinations. That is, how the message is to be formatted...
- step 5B: Mark the logger as initialized

Scenario 1, Common usage: Multiple levels, One logging class, Multiple destinations.

Scenario 1 should be the most common.

This usage:

you have multiple levels (in this example: debug < info < error)
you want to format the message before it's written (in this example: prefix it by time, by index, and append newline to it)
you have one log, which writes to several log destinations (in this example: the console, the debug output window, and a file)

In this example, all output will be written to the console, debug output window, and "out.txt" file. It will look similar to this one:

21:03.17.243 [1] this is so cool 1
21:03.17.243 [2] first error 2
21:03.17.243 [3] hello, world
21:03.17.243 [4] second error 3
21:03.17.243 [5] good to be back ;) 4
21:03.17.243 [6] third error 5

Click to see the code

Scenario 2: No levels, One Logger, One Filter

This usage:

you have one logger
you have one filter, which can be turned on or off
you want to format the message before it's written
the logger has several log destinations
- the output goes to console, debug output window, and a file called out.txt
- formatting - prefix each message by its index, and append newline

Optimizations:

use a cache string (from boost::logging::optimize namespace), in order to make formatting the message faster

In this example, all output will be written to the console, debug window, and "out.txt" file. It will be:

[1] this is so cool 1
[2] this is so cool again 2
[3] hello, world
[4] good to be back ;) 3

Click to see the code

Scenario 3: Fastest: Multiple Loggers, One Filter, Not using Formatters/Destinations, Not using <<

This usage:

fastest. It does not use formatters and destinations (thus, the flexibility that comes with formatters/destinations) is gone
you have one filter, which can be turned on or off
you have 2 loggers: app and err
the app writes to console, the err writes to "err.txt" file
the output is "dump" - no usage of << operator

Here's what the output will be:

The console:

this is so cool
hello, world
good to be back ;)

The err.txt file:

first error 
second error

Click to see the code

Your Scenario : Find out logger and filter, based on your application's needs

This usage:

you have several loggers
you have one filter, which can be turned on or off
you want to format the message before it's written
each logger has several log destinations
the logger and filter are specified using the boost::logging::scenario namespace
- the filter is always accurate (but slow)
- the filter does not use levels
- the logger favors speed (on a dedicated thread)
- the logger is initialized once, when only one thread is running

Optimizations:

use a cache string (from boost::logging::optimize namespace), in order to make formatting the message faster

Logs:

error messages go into err.txt file
- formatting - prefix each message by time, index, and append newline
info output goes to console, and a file called out.txt
- formatting - prefix each message by time and append newline
debug messages go to the debug output window, and the console
- formatting - prefix each message by time, and append newline

Here's how the output will look like:

The debug output window:

18:59.24 this is so cool 1
18:59.24 this is so cool again 2

The console:

18:59.24 this is so cool 1
18:59.24 this is so cool again 2
18:59.24 hello, world
18:59.24 good to be back ;) 4

The out.txt file:

18:59.24 hello, world
18:59.24 good to be back ;) 4

The err.txt file

18:59.24 [1] first error 3
18:59.24 [2] second error 5

Click to see the code

Usage Scenarios (together with code)

Scenario 1, Common usage: Multiple levels, One logging class, Multiple destinations.

Scenario 2: No levels, One Logger, One Filter

Scenario 3: Fastest: Multiple Loggers, One Filter, Not using Formatters/Destinations, Not using <<

Your Scenario : Find out logger and filter, based on your application's needs