Ticket #8585: fix_log_typo.patch

File fix_log_typo.patch, 88.7 KB (added by Michel Morin, 9 years ago)

  • boost/log/expressions/keyword.hpp

     
    239239/*!
    240240 * \brief The macro declares an attribute keyword
    241241 *
    242  * The macro provides definitions similar to \c BOOST_LOG_ATTRIBUTE_KEYWORD_TYPE and addidionally
     242 * The macro provides definitions similar to \c BOOST_LOG_ATTRIBUTE_KEYWORD_TYPE and additionally
    243243 * defines the keyword object.
    244244 *
    245245 * \param keyword_ Keyword name

  • boost/log/sources/basic_logger.hpp

     
    306306 * The user's logger class is expected to derive from the composite logger class, instantiated with
    307307 * the character type, the user's logger class, the threading model and the list of the required features.
    308308 * The former three parameters are passed to the \c basic_logger class template. The feature list
    309  * must be a MPL type sequence, where each element is an unary MPL metafunction class, that upon
     309 * must be an MPL type sequence, where each element is a unary MPL metafunction class, that upon
    310310 * applying on its argument results in a logging feature class that derives from the argument.
    311311 * Every logger feature provided by the library can participate in the feature list.
    312312 */

  • boost/log/attributes/constant.hpp

     
    3838/*!
    3939 * \brief A class of an attribute that holds a single constant value
    4040 *
    41  * The constant is a simpliest and one of the most frequently used types of attributes.
     41 * The constant is a simplest and one of the most frequently used types of attributes.
    4242 * It stores a constant value, which it eventually returns as its value each time
    4343 * requested.
    4444 */

  • boost/log/attributes/clock.hpp

     
    4141 * The time traits provided by the library use \c boost::posix_time::ptime as the time type.
    4242 *
    4343 * Time traits also determine the way time is acquired. There are two types of time traits
    44  * provided by th library: \c utc_time_traits and \c local_time_traits. The first returns UTC time,
     44 * provided by the library: \c utc_time_traits and \c local_time_traits. The first returns UTC time,
    4545 * the second returns local time.
    4646 */
    4747template< typename TimeTraitsT >

  • boost/log/attributes/attribute_value.hpp

     
    3939 * \brief An attribute value class
    4040 *
    4141 * An attribute value is an object that contains a piece of data that represents an attribute state
    42  * at the point of the value acquision. All major operations with log records, such as filtering and
     42 * at the point of the value acquisition. All major operations with log records, such as filtering and
    4343 * formatting, involve attribute values contained in a single view. Most likely an attribute value is
    4444 * implemented as a simple holder of some typed value. This holder implements the
    4545 * \c attribute_value::implementation interface and acts as a pimpl for the \c attribute_value
    … …  
    213213
    214214    /*!
    215215     * The method attempts to extract the stored value, assuming the value has the specified type.
    216      * One can specify either a single type or a MPL type sequence, in which case the stored value
     216     * One can specify either a single type or an MPL type sequence, in which case the stored value
    217217     * is checked against every type in the sequence.
    218218     *
    219219     * \note Include <tt>value_extraction.hpp</tt> prior to using this method.
    … …  
    227227
    228228    /*!
    229229     * The method attempts to extract the stored value, assuming the value has the specified type.
    230      * One can specify either a single type or a MPL type sequence, in which case the stored value
     230     * One can specify either a single type or an MPL type sequence, in which case the stored value
    231231     * is checked against every type in the sequence.
    232232     *
    233233     * \note Include <tt>value_extraction.hpp</tt> prior to using this method.
    … …  
    241241
    242242    /*!
    243243     * The method attempts to extract the stored value, assuming the value has the specified type.
    244      * One can specify either a single type or a MPL type sequence, in which case the stored value
     244     * One can specify either a single type or an MPL type sequence, in which case the stored value
    245245     * is checked against every type in the sequence. If extraction fails, the default value is returned.
    246246     *
    247247     * \note Include <tt>value_extraction.hpp</tt> prior to using this method.
    … …  
    257257
    258258    /*!
    259259     * The method attempts to extract the stored value, assuming the value has the specified type.
    260      * One can specify either a single type or a MPL type sequence, in which case the stored value
     260     * One can specify either a single type or an MPL type sequence, in which case the stored value
    261261     * is checked against every type in the sequence. If extraction fails, the default value is returned.
    262262     *
    263263     * \note Include <tt>value_extraction.hpp</tt> prior to using this method.
    … …  
    274274#if defined(BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS)
    275275    /*!
    276276     * The method attempts to extract the stored value, assuming the value has the specified type.
    277      * One can specify either a single type or a MPL type sequence, in which case the stored value
     277     * One can specify either a single type or an MPL type sequence, in which case the stored value
    278278     * is checked against every type in the sequence.
    279279     *
    280280     * \note Include <tt>value_extraction.hpp</tt> prior to using this method.
    … …  
    288288
    289289    /*!
    290290     * The method attempts to extract the stored value, assuming the value has the specified type.
    291      * One can specify either a single type or a MPL type sequence, in which case the stored value
     291     * One can specify either a single type or an MPL type sequence, in which case the stored value
    292292     * is checked against every type in the sequence.
    293293     *
    294294     * \note Include <tt>value_extraction.hpp</tt> prior to using this method.
    … …  
    302302
    303303    /*!
    304304     * The method attempts to extract the stored value, assuming the value has the specified type.
    305      * One can specify either a single type or a MPL type sequence, in which case the stored value
     305     * One can specify either a single type or an MPL type sequence, in which case the stored value
    306306     * is checked against every type in the sequence. If extraction fails, the default value is returned.
    307307     *
    308308     * \note Include <tt>value_extraction.hpp</tt> prior to using this method.
    … …  
    318318
    319319    /*!
    320320     * The method attempts to extract the stored value, assuming the value has the specified type.
    321      * One can specify either a single type or a MPL type sequence, in which case the stored value
     321     * One can specify either a single type or an MPL type sequence, in which case the stored value
    322322     * is checked against every type in the sequence. If extraction fails, the default value is returned.
    323323     *
    324324     * \note Include <tt>value_extraction.hpp</tt> prior to using this method.
    … …  
    338338    /*!
    339339     * The method attempts to extract the stored value, assuming the value has the specified type,
    340340     * and pass it to the \a visitor function object.
    341      * One can specify either a single type or a MPL type sequence, in which case the stored value
     341     * One can specify either a single type or an MPL type sequence, in which case the stored value
    342342     * is checked against every type in the sequence.
    343343     *
    344344     * \note Include <tt>value_visitation.hpp</tt> prior to using this method.

  • boost/log/attributes/mutable_constant.hpp

     
    4545 * The mutable_constant attribute stores a single value of type, specified as the first template argument.
    4646 * This value is returned on each attribute value acquisition.
    4747 *
    48  * The attribute also allows to modify the stored value, even if the attibute is registered in an attribute set.
     48 * The attribute also allows to modify the stored value, even if the attribute is registered in an attribute set.
    4949 * In order to ensure thread safety of such modifications the \c mutable_constant class is also parametrized
    5050 * with three additional template arguments: mutex type, scoped write and scoped read lock types. If not specified,
    5151 * the lock types are automatically deduced based on the mutex type.

  • boost/log/attributes/attribute.hpp

     
    5050 * Every attribute is represented with a factory that is basically an attribute value generator.
    5151 * The sole purpose of an attribute is to return an actual value when requested. A simplest attribute
    5252 * can always return the same value that it stores internally, but more complex ones can
    53  * perform a considirable amount of work to return a value, and the returned values may differ
     53 * perform a considerable amount of work to return a value, and the returned values may differ
    5454 * each time requested.
    5555 *
    5656 * A word about thread safety. An attribute should be prepared to be requested a value from

  • boost/log/attributes/attribute_name.hpp

     
    3939 * lighter in terms of memory footprint and operations complexity. This is done
    4040 * transparently by this class, on object construction. Passing objects of this class
    4141 * to other library methods, such as attribute lookup functions, will not require
    42  * this thanslation and/or string copying and thus will result in a more efficient code.
     42 * this translation and/or string copying and thus will result in a more efficient code.
    4343 */
    4444class attribute_name
    4545{

  • boost/log/attributes/value_extraction.hpp

     
    5454 * \brief A metafunction that allows to acquire the result of the value extraction
    5555 *
    5656 * The metafunction results in a type that is in form of <tt>T const&</tt>, if \c T is
    57  * not a MPL type sequence and <tt>DefaultT</tt> is the same as <tt>T</tt>,
     57 * not an MPL type sequence and <tt>DefaultT</tt> is the same as <tt>T</tt>,
    5858 * or <tt>value_ref< TypesT, TagT ></tt> otherwise, with
    5959 * \c TypesT being a type sequence comprising the types from sequence \c T and \c DefaultT,
    6060 * if it is not present in \c T already.
    … …  
    8787 * \brief A metafunction that allows to acquire the result of the value extraction
    8888 *
    8989 * The metafunction results in a type that is in form of <tt>T const&</tt>, if \c T is
    90  * not a MPL type sequence, or <tt>value_ref< T, TagT ></tt> otherwise. In the latter
     90 * not an MPL type sequence, or <tt>value_ref< T, TagT ></tt> otherwise. In the latter
    9191 * case the value reference shall never be empty.
    9292 */
    9393template< typename T, typename TagT >
    … …  
    414414 * The function extracts an attribute value from the view. The user has to explicitly specify the
    415415 * type or set of possible types of the attribute value to be extracted.
    416416 *
    417  * \note Caution must be excercised if the default value is a temporary object. Because the function returns
    418  *       a reference, if the temporary object is destroued, the reference may become dangling.
     417 * \note Caution must be exercised if the default value is a temporary object. Because the function returns
     418 *       a reference, if the temporary object is destroyed, the reference may become dangling.
    419419 *
    420420 * \param name The name of the attribute value to extract.
    421421 * \param attrs A set of attribute values in which to look for the specified attribute value.
    … …  
    435435 * The function extracts an attribute value from the view. The user has to explicitly specify the
    436436 * type or set of possible types of the attribute value to be visited.
    437437 *
    438  * \note Caution must be excercised if the default value is a temporary object. Because the function returns
    439  *       a reference, if the temporary object is destroued, the reference may become dangling.
     438 * \note Caution must be exercised if the default value is a temporary object. Because the function returns
     439 *       a reference, if the temporary object is destroyed, the reference may become dangling.
    440440 *
    441441 * \param name The name of the attribute value to extract.
    442442 * \param rec A log record. The attribute value will be sought among those associated with the record.
    … …  
    456456 * The function extracts an attribute value from the view. The user has to explicitly specify the
    457457 * type or set of possible types of the attribute value to be visited.
    458458 *
    459  * \note Caution must be excercised if the default value is a temporary object. Because the function returns
    460  *       a reference, if the temporary object is destroued, the reference may become dangling.
     459 * \note Caution must be exercised if the default value is a temporary object. Because the function returns
     460 *       a reference, if the temporary object is destroyed, the reference may become dangling.
    461461 *
    462462 * \param name The name of the attribute value to extract.
    463463 * \param rec A log record view. The attribute value will be sought among those associated with the record.
    … …  
    477477 * The function extracts an attribute value from the view. The user has to explicitly specify the
    478478 * type or set of possible types of the attribute value to be visited.
    479479 *
    480  * \note Caution must be excercised if the default value is a temporary object. Because the function returns
    481  *       a reference, if the temporary object is destroued, the reference may become dangling.
     480 * \note Caution must be exercised if the default value is a temporary object. Because the function returns
     481 *       a reference, if the temporary object is destroyed, the reference may become dangling.
    482482 *
    483483 * \param value Attribute value.
    484484 * \param def_val The default value
    … …  
    690690 * The function extracts an attribute value from the view. The user has to explicitly specify the
    691691 * type or set of possible types of the attribute value to be extracted.
    692692 *
    693  * \note Caution must be excercised if the default value is a temporary object. Because the function returns
    694  *       a reference, if the temporary object is destroued, the reference may become dangling.
     693 * \note Caution must be exercised if the default value is a temporary object. Because the function returns
     694 *       a reference, if the temporary object is destroyed, the reference may become dangling.
    695695 *
    696696 * \param keyword The keyword of the attribute value to extract.
    697697 * \param attrs A set of attribute values in which to look for the specified attribute value.
    … …  
    711711 * The function extracts an attribute value from the view. The user has to explicitly specify the
    712712 * type or set of possible types of the attribute value to be visited.
    713713 *
    714  * \note Caution must be excercised if the default value is a temporary object. Because the function returns
    715  *       a reference, if the temporary object is destroued, the reference may become dangling.
     714 * \note Caution must be exercised if the default value is a temporary object. Because the function returns
     715 *       a reference, if the temporary object is destroyed, the reference may become dangling.
    716716 *
    717717 * \param keyword The keyword of the attribute value to extract.
    718718 * \param rec A log record. The attribute value will be sought among those associated with the record.
    … …  
    732732 * The function extracts an attribute value from the view. The user has to explicitly specify the
    733733 * type or set of possible types of the attribute value to be visited.
    734734 *
    735  * \note Caution must be excercised if the default value is a temporary object. Because the function returns
    736  *       a reference, if the temporary object is destroued, the reference may become dangling.
     735 * \note Caution must be exercised if the default value is a temporary object. Because the function returns
     736 *       a reference, if the temporary object is destroyed, the reference may become dangling.
    737737 *
    738738 * \param keyword The keyword of the attribute value to extract.
    739739 * \param rec A log record view. The attribute value will be sought among those associated with the record.

  • boost/log/attributes/timer.hpp

     
    3434/*!
    3535 * \brief A class of an attribute that makes an attribute value of the time interval since construction
    3636 *
    37  * The timer attribute calculates the time passed since its construction and returns it on value acquision.
     37 * The timer attribute calculates the time passed since its construction and returns it on value acquisition.
    3838 * The attribute value type is <tt>boost::posix_time::time_duration</tt>.
    3939 *
    4040 * On Windows platform there are two implementations of the attribute. The default one is more precise but
    … …  
    4242 * to calculate elapsed time.
    4343 *
    4444 * There are known problems with these functions when used with some CPUs, notably AMD Athlon with
    45  * Cool'n'Quiet technology enabled. See the following links for for more information and possible resolutions:
     45 * Cool'n'Quiet technology enabled. See the following links for more information and possible resolutions:
    4646 *
    4747 * http://support.microsoft.com/?scid=kb;en-us;895980
    4848 * http://support.microsoft.com/?id=896256

  • boost/log/attributes/function.hpp

     
    7777
    7878    public:
    7979        /*!
    80          * Constructor with the stored delegate imitialization
     80         * Constructor with the stored delegate initialization
    8181         */
    8282        explicit impl_template(T const& fun) : m_Functor(fun) {}
    8383

  • boost/log/attributes/value_visitation.hpp

     
    5353    {
    5454        ok,                     //!< The attribute value has been visited successfully
    5555        value_not_found,        //!< The attribute value is not present in the view
    56         value_has_invalid_type  //!< The attribute value is present in the vew, but has an unexpected type
     56        value_has_invalid_type  //!< The attribute value is present in the view, but has an unexpected type
    5757    };
    5858
    5959private:
    … …  
    9090 *
    9191 * Attribute value invoker is a functional object that attempts to find and extract the stored
    9292 * attribute value from the attribute value view or a log record. The extracted value is passed to
    93  * an unary function object (the visitor) provided by user.
     93 * a unary function object (the visitor) provided by user.
    9494 *
    9595 * The invoker can be specialized on one or several attribute value types that should be
    9696 * specified in the second template argument.

  • boost/log/sinks/event_log_backend.hpp

     
    304304    private:
    305305        //! The mapper that will extract the event identifier
    306306        event_id_mapper_type m_EventIDMapper;
    307         //! The map of event identifiers and and their insertion composers
     307        //! The map of event identifiers and their insertion composers
    308308        event_map m_EventMap;
    309309
    310310    public:

  • boost/log/sinks/unlocked_frontend.hpp

     
    100100    /*!
    101101     * Locking accessor to the attached backend.
    102102     *
    103      * \note Does not do any actual locking, provided only for intarface consistency
     103     * \note Does not do any actual locking, provided only for interface consistency
    104104     *       with other frontends.
    105105     */
    106106    locked_backend_ptr locked_backend()

  • boost/log/sinks/async_frontend.hpp

     
    9595private:
    9696    //! Backend synchronization mutex type
    9797    typedef boost::mutex backend_mutex_type;
    98     //! Frontend syncronization mutex type
     98    //! Frontend synchronization mutex type
    9999    typedef typename base_type::mutex_type frontend_mutex_type;
    100100
    101101    //! A scope guard that implements thread ID management

  • boost/log/sinks/attribute_mapping.hpp

     
    251251     * the native value.
    252252     *
    253253     * \param rec A log record to extract value from
    254      * \return A mapped value, if mapping was successfull, or the default value if
     254     * \return A mapped value, if mapping was successful, or the default value if
    255255     *         mapping did not succeed.
    256256     */
    257257    mapped_type operator() (record_view const& rec) const

  • boost/log/sinks/frontend_requirements.hpp

     
    4646/*!
    4747 * The sink backend expects pre-synchronized calls, all needed synchronization is implemented
    4848 * in the frontend (IOW, only one thread is feeding records to the backend concurrently, but
    49  * is is possible for several threads to write sequentially). Note that if a frontend supports
     49 * it is possible for several threads to write sequentially). Note that if a frontend supports
    5050 * synchronized record feeding, it will also report capable of concurrent record feeding.
    5151 */
    5252struct synchronized_feeding {};

  • boost/log/core/record.hpp

     
    3636/*!
    3737 * \brief Logging record class
    3838 *
    39  * The logging record incapsulates all information related to a single logging statement,
     39 * The logging record encapsulates all information related to a single logging statement,
    4040 * in particular, attribute values view and the log message string. The record can be updated before pushing
    4141 * for further processing to the logging core.
    4242 */

  • boost/log/core/core.hpp

     
    188188     * every log record made in the current thread.
    189189     *
    190190     * \note In single-threaded build the effect is the same as adding the attribute globally. This, however, does
    191      *       not imply that iterators to thread-specific and global attributes are interchangable.
     191     *       not imply that iterators to thread-specific and global attributes are interchangeable.
    192192     *
    193193     * \param name The attribute name.
    194194     * \param attr The attribute factory.

  • boost/log/core/record_view.hpp

     
    4242/*!
    4343 * \brief Logging record view class
    4444 *
    45  * The logging record incapsulates all information related to a single logging statement,
     45 * The logging record encapsulates all information related to a single logging statement,
    4646 * in particular, attribute values view and the log message string. The view is immutable,
    4747 * it is implemented as a wrapper around a reference-counted implementation.
    4848 */

  • boost/log/trivial.hpp

     
    4848    fatal
    4949};
    5050
    51 //! Returns stringified enumeration value or \c NULL, if the value is not valid
     51//! Returns stringized enumeration value or \c NULL, if the value is not valid
    5252BOOST_LOG_API const char* to_string(severity_level lvl);
    5353
    5454template< typename CharT, typename TraitsT >

  • boost/log/detail/unary_function_terminal.hpp

     
    3939namespace aux {
    4040
    4141/*!
    42  * \brief An adapter for an unary function to be used as a terminal in a Boost.Phoenix expression
     42 * \brief An adapter for a unary function to be used as a terminal in a Boost.Phoenix expression
    4343 *
    44  * This class is an adapter between Boost.Phoenix expression invokation protocol and
    45  * an unary function. It forwards the call to the base function, passing only the first argument
    46  * from the original call. This allows to to embed value extractors in template expressions.
     44 * This class is an adapter between Boost.Phoenix expression invocation protocol and
     45 * a unary function. It forwards the call to the base function, passing only the first argument
     46 * from the original call. This allows to embed value extractors in template expressions.
    4747 */
    4848template< typename FunT >
    4949class unary_function_terminal

  • boost/log/utility/explicit_operator_bool.hpp

     
    1010 * \date   08.03.2009
    1111 *
    1212 * This header defines a compatibility macro that implements an unspecified
    13  * \c bool operator idiom, which is superceded with explicit conversion operators in
     13 * \c bool operator idiom, which is superseded with explicit conversion operators in
    1414 * C++0x.
    1515 */
    1616

  • boost/log/utility/record_ordering.hpp

     
    7878    result_type operator() (record_view const& left, record_view const& right) const
    7979    {
    8080        // We rely on the fact that the attribute_values() method returns a reference to the object in the record implementation,
    81         // so we can comare pointers.
     81        // so we can compare pointers.
    8282        return FunT::operator() (static_cast< const void* >(&left.attribute_values()), static_cast< const void* >(&right.attribute_values()));
    8383    }
    8484};
    … …  
    8686/*!
    8787 * \brief Ordering predicate, based on attribute values associated with records
    8888 *
    89  * This predicate allows to order log records based on values of a specificly named attribute
     89 * This predicate allows to order log records based on values of a specifically named attribute
    9090 * associated with them. Two given log records being compared should both have the specified
    9191 * attribute value of the specified type to be able to be ordered properly. As a special case,
    9292 * if neither of the records have the value, these records are considered equivalent. Otherwise,

  • boost/log/utility/value_ref.hpp

     
    404404 * since it may be empty (i.e. refer to no value at all) and it can also refer to values of different types. Therefore its
    405405 * interface and behavior combines features of Boost.Ref, Boost.Optional and Boost.Variant, depending on the use case.
    406406 *
    407  * The template parameter \c T can be a single type or an MPL seqence of possible types being referred. The reference wrapper
     407 * The template parameter \c T can be a single type or an MPL sequence of possible types being referred. The reference wrapper
    408408 * will act as either an optional reference or an optional variant of references to the specified types. In any case, the
    409409 * referred values will not be modifiable (i.e. \c value_ref always models a const reference).
    410410 *

  • boost/log/utility/setup/filter_parser.hpp

     
    137137 * The base class for filter factories. The class defines default implementations for most
    138138 * filter expressions. In order to be able to construct filters, the attribute value type must
    139139 * support reading from a stream. Also, the default filters will rely on relational operators for
    140  * the type, so these optrators must also be defined.
     140 * the type, so these operators must also be defined.
    141141 */
    142142template< typename CharT, typename AttributeValueT >
    143143class basic_filter_factory :

  • boost/log/utility/setup/console.hpp

     
    168168 *                           or a filter lambda expression.
    169169 *             \li \c format Specifies a formatter to install into the sink. May be a string that represents a formatter,
    170170 *                           or a formatter lambda expression (either streaming or Boost.Format-like notation).
    171  *             \li \c auto_flush A boolean flag that shows whether the sink should automaticallu flush the stream
     171 *             \li \c auto_flush A boolean flag that shows whether the sink should automatically flush the stream
    172172 *                               after each written record.
    173173 * \return Pointer to the constructed sink.
    174174 */

  • boost/log/utility/functional/logical.hpp

     
    1414 * header are not templates and therefore do not require a fixed argument type. Furthermore, both arguments
    1515 * may have different types, in which case the comparison is performed without type conversion.
    1616 *
    17  * \note In case if arguments are intergal, the conversion is performed according to the standard C++ rules
     17 * \note In case if arguments are integral, the conversion is performed according to the standard C++ rules
    1818 *       in order to avoid warnings from the compiler.
    1919 */
    2020

  • libs/log/test/run/attr_attribute_value_impl.cpp

     
    126126    BOOST_CHECK(!p4.dispatch(disp));
    127127}
    128128
    129 // The test verifies that value extracition works
     129// The test verifies that value extraction works
    130130BOOST_AUTO_TEST_CASE(value_extraction)
    131131{
    132132    logging::attribute_value p1(attrs::make_attribute_value< int >(10));

  • libs/log/test/run/util_string_literal.cpp

     
    192192    BOOST_CHECK_EQUAL(lit1, "yo-ho-ho");
    193193}
    194194
    195 // STL strings acquision tests
     195// STL strings acquisition tests
    196196BOOST_AUTO_TEST_CASE(string_literal_str)
    197197{
    198198    logging::string_literal lit = "yo-ho-ho";

  • libs/log/doc/tutorial.qbk

     
    5757
    5858[heading File logging unleashed]
    5959
    60 As a starting point, here is how you would initialize logginig to a file:
     60As a starting point, here is how you would initialize logging to a file:
    6161
    6262[example_tutorial_file_simple]
    6363
    … …  
    117117
    118118Regardless of the thread safety, all loggers provided by the library are default and copy-constructible and support swapping, so there should be no problem in making a logger a member of your class. As you will see later, such approach can give you additional benefits.
    119119
    120 The library provides a number of loggers with different features, such as severity and channel support. These features can be combined with each other in order to construct more complex loggers. See [link log.detailed.sources here] for more datails.
     120The library provides a number of loggers with different features, such as severity and channel support. These features can be combined with each other in order to construct more complex loggers. See [link log.detailed.sources here] for more details.
    121121
    122122[heading Global logger objects]
    123123
    … …  
    155155
    156156In previous sections we mentioned attributes and attribute values several times. Here we will discover how attributes can be used to add more data to log records.
    157157
    158 Each log record can have a number of named attribute values attached. Attributes can represent any essental information about the conditions in which the log record occurred, such as position in the code, executable module name, current date and time, or any piece of data relevant to your particular application and execution environment. An attribute may behave as a value generator, in which case it would return a different value for each log record it's involved in. As soon as the attribute generates the value, the latter becomes independent from the creator and can be used by filters, formatters and sinks. But in order to use the attribute value one has to know its name and type, or at least a set of types it may have. There are a number of commonly used attributes implemented in the library, you can find the types of their values in the documentation.
     158Each log record can have a number of named attribute values attached. Attributes can represent any essential information about the conditions in which the log record occurred, such as position in the code, executable module name, current date and time, or any piece of data relevant to your particular application and execution environment. An attribute may behave as a value generator, in which case it would return a different value for each log record it's involved in. As soon as the attribute generates the value, the latter becomes independent from the creator and can be used by filters, formatters and sinks. But in order to use the attribute value one has to know its name and type, or at least a set of types it may have. There are a number of commonly used attributes implemented in the library, you can find the types of their values in the documentation.
    159159
    160160Aside from that, as described in the [link log.design Design overview] section, there are three possible scopes of attributes: source-specific, thread-specific and global. When a log record is made, attribute values from these three sets are joined into a single set and passed to sinks. This implies that the origin of the attribute makes no difference for sinks. Any attribute can be registered in any scope. When registered, an attribute is given a unique name in order to make it possible to search for it. If it happens that the same named attribute is found in several scopes, the attribute from the most specific scope is taken into consideration in any further processing, including filtering and formatting. Such behavior makes it possible to override global or thread-scoped attributes with the ones registered in your local logger, thus reducing thread interference.
    161161
    … …  
    175175
    176176The [funcref boost::log::add_common_attributes `add_common_attributes`] function is one of the several convenience helpers described [link log.detailed.utilities.setup.convenience here].
    177177
    178 Some attrubutes are registered automatically on loggers construction. For example, [link log.detailed.sources.severity_level_logger `severity_logger`] registers a source-specific attribute "Severity" which can be used to add a level of emphasis for different log records. For example:
     178Some attributes are registered automatically on loggers construction. For example, [link log.detailed.sources.severity_level_logger `severity_logger`] registers a source-specific attribute "Severity" which can be used to add a level of emphasis for different log records. For example:
    179179
    180180[example_sources_severity]
    181181
    … …  
    200200        // other attributes skipped for brevity
    201201    }
    202202
    203 Here the [link log.detailed.attributes.counter `counter`] and [link log.detailed.attributes.clock `local_clock`] components are attribute classes, they derive from the common attribute interface [class_log_attribute]. The library provides a number of other [link log.detailed.attributes attribute classes], including the [link log.detailed.attributes.function `function`] attribute that calls some function object on value acquisition. For example, we can in a similar way register a [link log.detailed.attributes.named_scope `named_scope`] attrubute:
     203Here the [link log.detailed.attributes.counter `counter`] and [link log.detailed.attributes.clock `local_clock`] components are attribute classes, they derive from the common attribute interface [class_log_attribute]. The library provides a number of other [link log.detailed.attributes attribute classes], including the [link log.detailed.attributes.function `function`] attribute that calls some function object on value acquisition. For example, we can in a similar way register a [link log.detailed.attributes.named_scope `named_scope`] attribute:
    204204
    205205    core->add_global_attribute("Scope", attrs::named_scope());
    206206
    … …  
    260260
    261261    expr::attr< logging::trivial::severity_level >("Severity")
    262262
    263 [tip As shown in the previous section, it is possible to define placeholders like `severity` for user's attributes. As an additional benefit to the simpler syntax in the template expressions such placeholders allow to concentrate all the information about the attribute (the name and the value type) in the placeholder definition. This makes coding less error-prone (you won't misspel the attribute name or specify incorrect value type) and therefore is the recommended way of defining new attributes and using them in template expressions.]
     263[tip As shown in the previous section, it is possible to define placeholders like `severity` for user's attributes. As an additional benefit to the simpler syntax in the template expressions such placeholders allow to concentrate all the information about the attribute (the name and the value type) in the placeholder definition. This makes coding less error-prone (you won't misspell the attribute name or specify incorrect value type) and therefore is the recommended way of defining new attributes and using them in template expressions.]
    264264
    265265There are other [link log.detailed.expressions.formatters formatter manipulators] that provide advanced support for date, time and other types. Some manipulators accept additional arguments that customize their behavior. Most of these arguments are named and can be passed in __boost_parameter__ style.
    266266
    … …  
    274274
    275275[heading Boost.Format-style formatters]
    276276
    277 As an alternative, you can define formatters with with a syntax similar to __boost_format__. The same formatter as described above can be written as follows:
     277As an alternative, you can define formatters with a syntax similar to __boost_format__. The same formatter as described above can be written as follows:
    278278
    279279[example_tutorial_formatters_format]
    280280
    … …  
    304304
    305305[note Textual format templates are not accepted by sink backends in the `set_formatter` method. In order to parse textual template into a formatter function one has to call `parse_formatter` function. See [link log.detailed.utilities.setup.filter_formatter here] for more details.]
    306306
    307 [heading Custom formatting functons]
     307[heading Custom formatting functions]
    308308
    309309You can add a custom formatter to a sink backend that supports formatting. The formatter is actually a function object that supports the following signature:
    310310
    … …  
    332332
    333333In this sample we initialize two sinks - one for the complete log file and the other for important messages only. Both sinks will be writing to text files with the same log record format, which we initialize first and save to the `fmt` variable. The [classref boost::log::basic_formatter formatter] type is a type-erased function object with the formatter calling signature; in many respects it can be viewed similar to `boost::function` or `std::function` except that it is never empty. There is also [classref boost::log::filter a similar function object] for filters.
    334334
    335 Notably, the formatter itself contains a filter here. As you can see, the format contains a conditional part that is only present when log records contain the "Tag" attribute. The [link log.detailed.expressions.predicates.has_attr `has_attr`] predicate checks whether the record containts the "Tag" attribute value and conrtols whether it is put into the file or not. We used the attribute keyword to specify the name and type of the attribute for the predicate, but it is also possible to specify them in the [link log.detailed.expressions.predicates.has_attr `has_attr`] call site. Conditional formatters are explained in more details [link log.detailed.expressions.formatters.conditional here].
     335Notably, the formatter itself contains a filter here. As you can see, the format contains a conditional part that is only present when log records contain the "Tag" attribute. The [link log.detailed.expressions.predicates.has_attr `has_attr`] predicate checks whether the record contains the "Tag" attribute value and controls whether it is put into the file or not. We used the attribute keyword to specify the name and type of the attribute for the predicate, but it is also possible to specify them in the [link log.detailed.expressions.predicates.has_attr `has_attr`] call site. Conditional formatters are explained in more details [link log.detailed.expressions.formatters.conditional here].
    336336
    337337Further goes the initialization of the two sinks. The first sink does not have any filter, which means it will save every log record to the file. We call `set_filter` on the second sink to only save log records with severity no less than `warning` or having a "Tag" attribute with value "IMPORTANT_MESSAGE". As you can see, the filter syntax resembles usual C++ very much, especially when attribute keywords are used.
    338338

  • libs/log/doc/utilities.qbk

     
    5858
    5959    #include <``[boost_log_utility_type_dispatch_static_type_dispatcher_hpp]``>
    6060
    61 Static type dispatchers are used when the set of types that needs to be supported for extraction is known at compile time. The [class_log_static_type_dispatcher] class template is parametrized with a MPL type sequence of types that need to be supported. The dispatcher inherits from the [class_log_type_dispatcher] interface which provides the `get_callback` method for aquiring the function object to invoke on the stored value. All you need to do is provide a visitor function object to the dispatcher at construction point and invoke the callback when dispatching the stored value:
     61Static type dispatchers are used when the set of types that needs to be supported for extraction is known at compile time. The [class_log_static_type_dispatcher] class template is parametrized with an MPL type sequence of types that need to be supported. The dispatcher inherits from the [class_log_type_dispatcher] interface which provides the `get_callback` method for acquiring the function object to invoke on the stored value. All you need to do is provide a visitor function object to the dispatcher at construction point and invoke the callback when dispatching the stored value:
    6262
    6363[example_util_static_type_dispatcher]
    6464
    … …  
    149149
    150150[heading Abstract record ordering]
    151151
    152 The [class_log_abstract_ordering] class allows application of a quick opaque ordering. The result of this ordering is not stable between different runs of the application and in generag cannot be predicted before the predicate is applied, however it provides the best performance. The [class_log_abstract_ordering] class is a template that is specialized with an optional predicate function that will be able to compare `const void*` pointers. By default an `std::less` equivalent is used.
     152The [class_log_abstract_ordering] class allows application of a quick opaque ordering. The result of this ordering is not stable between different runs of the application and in general cannot be predicted before the predicate is applied, however it provides the best performance. The [class_log_abstract_ordering] class is a template that is specialized with an optional predicate function that will be able to compare `const void*` pointers. By default an `std::less` equivalent is used.
    153153
    154154    // A set of unique records
    155155    std::set< logging::record_view, logging::abstract_ordering< > > m_Records;
    … …  
    184184
    185185The library provides exception handling hooks in different places. Tools, defined in this header, provide an easy way of implementing function objects suitable for such hooks.
    186186
    187 An exception handler is a function object that accepts no arguments. The result of the exception handler is ignored and thus should generally be `void`. Exception handlers are called from within `catch` sections by the library, therefore in order to reacquire the exception object it has to rethrow it. The header defines an [class_log_exception_handler] template functor that does just that and then forwards the exception object to an unary user-defined functional object. The [funcref boost::log::make_exception_handler `make_exception_handler`] function can be used to simplify the handler construction. All expected exception types should be specified explicitly in the call, in the order they would appear in the `catch` sections (i.e. from most specific ones to the most general ones).
     187An exception handler is a function object that accepts no arguments. The result of the exception handler is ignored and thus should generally be `void`. Exception handlers are called from within `catch` sections by the library, therefore in order to reacquire the exception object it has to rethrow it. The header defines an [class_log_exception_handler] template functor that does just that and then forwards the exception object to a unary user-defined functional object. The [funcref boost::log::make_exception_handler `make_exception_handler`] function can be used to simplify the handler construction. All expected exception types should be specified explicitly in the call, in the order they would appear in the `catch` sections (i.e. from most specific ones to the most general ones).
    188188
    189189[example_utility_exception_handler]
    190190
    … …  
    465465
    466466Sink settings are divided into separate subsections within the common top-level section "Sinks" - one subsection for each sink. The subsection names should denote a user-defined sink name. For example, "MyFile".
    467467
    468 [note Previous versions of the library also supported top-level sections starting with the "Sink:" prefix to describe sink parameters. This syntax is deprecated now, although it still works when parsing a settings file for backward compatibility. The parser will automatically put these sections under the "Sinks" top-level section in the resulting settings contsiner. Support for this syntax will be removed in future releases.]
     468[note Previous versions of the library also supported top-level sections starting with the "Sink:" prefix to describe sink parameters. This syntax is deprecated now, although it still works when parsing a settings file for backward compatibility. The parser will automatically put these sections under the "Sinks" top-level section in the resulting settings container. Support for this syntax will be removed in future releases.]
    469469
    470470[table Sections under the "Sinks" section. Common sink settings.
    471471[[Parameter]             [Format]                                                               [Description]]

  • libs/log/doc/extension.qbk

     
    2828* [class_sinks_formatted_records]. The backend expects formatted log records. The frontend implements formatting to a string with character type defined by the `char_type` typedef within the backend. The formatted string will be passed along with the log record to the backend. The [class_sinks_basic_formatted_sink_backend] base class automatically adds this requirement to the `frontend_requirements` type.
    2929* [class_sinks_flushing]. The backend supports flushing its internal buffers. If the backend indicates this requirement it has to implement the `flush` method taking no arguments; this method will be called by the frontend when flushed.
    3030
    31 [tip By chosing either of the thread synchronization requirements you effectively allow or prohibit certain [link log.detailed.sink_frontends sink frontends] from being used with your backend.]
     31[tip By choosing either of the thread synchronization requirements you effectively allow or prohibit certain [link log.detailed.sink_frontends sink frontends] from being used with your backend.]
    3232
    3333Multiple requirements can be combined into `frontend_requirements` type with the [class_sinks_combine_requirements] metafunction:
    3434
    … …  
    7474
    7575The second notable difference from the previous examples is that `consume` method takes an additional string parameter besides the log record. This is the result of formatting. The `string_type` type is defined by the [class_sinks_basic_formatted_sink_backend] base class and it corresponds to the requested character type.
    7676
    77 We don't need to flush any buffers in this example, so we didn't specify the [class_sinks_flushing] requirement and omitted the `flush` method in the backens. Although we don't need any synchronization in our backend, we specified [class_sinks_synchronized_feeding] requirement so that we don't spawn multiple instances of `notify-send` program and cause a "fork bomb".
     77We don't need to flush any buffers in this example, so we didn't specify the [class_sinks_flushing] requirement and omitted the `flush` method in the backend. Although we don't need any synchronization in our backend, we specified [class_sinks_synchronized_feeding] requirement so that we don't spawn multiple instances of `notify-send` program and cause a "fork bomb".
    7878
    7979Now, the `consume` implementation is trivial:
    8080
    … …  
    283283
    284284You can extend filter parser in the similar way you can extend the formatter parser - by registering filter factories for your attribute values into the library. However, since it takes a considerably more complex syntax to describe filters, a filter factory typically implements several generator functions.
    285285
    286 Like with formatter parser extension, you can avoid spelling out the filter factory and register a simple factlry provided by the library:
     286Like with formatter parser extension, you can avoid spelling out the filter factory and register a simple factory provided by the library:
    287287
    288288[example_extension_simple_filter_factory]
    289289
    290 In order this to work the user's type should fullfill these requirements:
     290In order this to work the user's type should fulfill these requirements:
    291291
    292292# Support reading from an input stream with `operator>>`.
    293293# Support the complete set of comparison and ordering operators.
    294294
    295295Naturally, all these operators must be visible from the point of the [funcref boost::log::register_simple_filter_factory `register_simple_filter_factory`] call. Note that unlike the simple formatter factory, the filter factory requires the user's type to support reading from a stream. This is so because the filter factory would have to parse the argument of the filter relation from a string.
    296296
    297 But we won't get away with a simple filter factory, because our `point` class doesn't have a sensible ordering semantics and thus we cannot define the complete set of operators. We'll have to implement our own filter factory instead. Filter factories derive from the [class_log_filter_factory] interface. This base class declares a number of virtual functions that will be called in order to create filters, according to the filter expression. If some functions are not overriden by the factory, the corresponding operations are considered to be not supported by the attribute value. But before we define the filter factory we have to improve our `point` class slightly:
     297But we won't get away with a simple filter factory, because our `point` class doesn't have a sensible ordering semantics and thus we cannot define the complete set of operators. We'll have to implement our own filter factory instead. Filter factories derive from the [class_log_filter_factory] interface. This base class declares a number of virtual functions that will be called in order to create filters, according to the filter expression. If some functions are not overridden by the factory, the corresponding operations are considered to be not supported by the attribute value. But before we define the filter factory we have to improve our `point` class slightly:
    298298
    299299[example_extension_filter_parser_point_definition]
    300300
    … …  
    343343
    344344As you can see, we read parameters from settings and simply create our sink with them as a result of `create_sink` method. Generally, users are free to name parameters of their sinks the way they like, as long as [link log.detailed.utilities.setup.settings_file settings file format] is adhered. However, it is a good idea to follow the pattern established by the library and reuse parameter names with the same meaning. That is, it should be obvious that the parameter "Filter" means the same for both the library-provided "TextFile" sink and out custom "StatCollector" sink.
    345345
    346 After defining the factory we only have to register it with the [funcref boost::log::register_sink_factory `register_sink_factory`] call. The first argument is the new value of the "Destination" parameter in the settings. Whenever the library finds sink description with destination "StatCollector", our factory will be invoked to create the sink. It is also possible to override library-provided destination types with user-defined factories, however it is not possble to restore the default factories afterwards.
     346After defining the factory we only have to register it with the [funcref boost::log::register_sink_factory `register_sink_factory`] call. The first argument is the new value of the "Destination" parameter in the settings. Whenever the library finds sink description with destination "StatCollector", our factory will be invoked to create the sink. It is also possible to override library-provided destination types with user-defined factories, however it is not possible to restore the default factories afterwards.
    347347
    348348[note As the "Destination" parameter is used to determine the sink factory, this parameter is reserved and cannot be used by sink factories for their own purposes.]
    349349

  • libs/log/doc/rationale.qbk

     
    105105
    106106[section:why_attribute_manips_dont_affect_filters Why attributes set with stream manipulators do not participate in filtering?]
    107107
    108 One can add attributes to log records in the followinf way:
     108One can add attributes to log records in the following way:
    109109
    110110    BOOST_LOG(logger) << logging::add_value("MyInt", 10) << logging::add_value("MyString", "string attribute value")
    111111        << "Some log message";
    … …  
    181181
    182182As a couple quick examples, `v2s_st` corresponds to v2 static single-threaded build of the library and `v2_mt_posix` - to v2 dynamic multi-threaded build for POSIX system API.
    183183
    184 Namespace mangling may lead to linkinkg errors if the application is misconfigured. One common mistake is to build dynamic version of the library and not define `BOOST_LOG_DYN_LINK` or `BOOST_ALL_DYN_LINK` when building the application, so that the library assumes static linking by default. Whenever such linking errors appear, one can decode the namespace name in the missing symbols and the exported symbols of Boost.Log library and adjust library or application [link log.installation.config configuration] accordingly.
     184Namespace mangling may lead to linking errors if the application is misconfigured. One common mistake is to build dynamic version of the library and not define `BOOST_LOG_DYN_LINK` or `BOOST_ALL_DYN_LINK` when building the application, so that the library assumes static linking by default. Whenever such linking errors appear, one can decode the namespace name in the missing symbols and the exported symbols of Boost.Log library and adjust library or application [link log.installation.config configuration] accordingly.
    185185
    186186[endsect]
    187187

  • libs/log/doc/expressions.qbk

     
    1818    #include <``[boost_log_expressions_attr_fwd_hpp]``>
    1919    #include <``[boost_log_expressions_attr_hpp]``>
    2020
    21 The [funcref boost::log::expressions::attr attr] placeholder represents an attribute value in template expressions. Given the record view or a set of attribute values, the placeholder will attempt to extract the specified attribute value from the argument upon invokation. This can be roughly described with the following pseudo-code:
     21The [funcref boost::log::expressions::attr attr] placeholder represents an attribute value in template expressions. Given the record view or a set of attribute values, the placeholder will attempt to extract the specified attribute value from the argument upon invocation. This can be roughly described with the following pseudo-code:
    2222
    2323    logging::value_ref< T, TagT > val = expr::attr< T, TagT >(name)(rec);
    2424
    … …  
    156156
    157157[@boost:/libs/log/example/doc/expressions_has_attr_stat_accum.cpp See the complete code].
    158158
    159 In this example, log records emitted with the `PUT_STAT` macto will be directed to the `my_stat_accumulator` sink backend, which will accumulate the changes passed in the "Change" attribute values. All other records (even those made through the same logger) will be passed to the filte sink. This is achieved with the mutually exclusive filters set for the two sinks.
     159In this example, log records emitted with the `PUT_STAT` macro will be directed to the `my_stat_accumulator` sink backend, which will accumulate the changes passed in the "Change" attribute values. All other records (even those made through the same logger) will be passed to the filter sink. This is achieved with the mutually exclusive filters set for the two sinks.
    160160
    161161Please note that in the example above we extended the library in two ways: we defined a new sink backend `my_stat_accumulator` and a new macro `PUT_STAT`. Also note that `has_attr` can accept attribute keywords to identify the attribute to check.
    162162
    … …  
    509509
    510510    #include <``[boost_log_expressions_formatters_c_decorator_hpp]``>
    511511
    512 The header defines two character decorators: `c_decor` and `c_ascii_decor`. The first one replaces the following characters with their escaped counerparts: \\ (backslash, 0x5c), \\a (bell character, 0x07), \\b (backspace, 0x08), \\f (formfeed, 0x0c), \\n (newline, 0x0a), \\r (carriage return, 0x0d), \\t (horizontal tabulation, 0x09), \\v (vertical tabulation, 0x0b), \' (apostroph, 0x27), \" (quote, 0x22), ? (question mark, 0x3f). The `c_ascii_decor` decorator does the same but also replaces all other non-printable and non-ASCII characters with escaped hexadecimal character codes in C notation (e.g. "\\x8c"). The usage is similar to other character decorators:
     512The header defines two character decorators: `c_decor` and `c_ascii_decor`. The first one replaces the following characters with their escaped counterparts: \\ (backslash, 0x5c), \\a (bell character, 0x07), \\b (backspace, 0x08), \\f (formfeed, 0x0c), \\n (newline, 0x0a), \\r (carriage return, 0x0d), \\t (horizontal tabulation, 0x09), \\v (vertical tabulation, 0x0b), \' (apostroph, 0x27), \" (quote, 0x22), ? (question mark, 0x3f). The `c_ascii_decor` decorator does the same but also replaces all other non-printable and non-ASCII characters with escaped hexadecimal character codes in C notation (e.g. "\\x8c"). The usage is similar to other character decorators:
    513513
    514514    sink->set_formatter
    515515    (

  • libs/log/doc/sources.qbk

     
    5252
    5353[example_sources_network_connection_channels]
    5454
    55 It is also possible to set the channel name of individual log records. This can be uesful when a [link log.detailed.sources.global_storage global logger] is used instead of an object-specific one. The channel name can be set by calling the `channel` modifier on the logger or by using a special macro for logging. For example:
     55It is also possible to set the channel name of individual log records. This can be useful when a [link log.detailed.sources.global_storage global logger] is used instead of an object-specific one. The channel name can be set by calling the `channel` modifier on the logger or by using a special macro for logging. For example:
    5656
    5757[example_sources_network_connection_dynamic_channels]
    5858

  • libs/log/doc/attributes.qbk

     
    380380
    381381Working with identifiers is much more efficient than with strings. For example, copying does not involve dynamic memory allocation and comparison operators are very lightweight. On the other hand, it is easy to get a human-readable attribute name for presentation, if needed.
    382382
    383 The [class_log_attribute_name] class supports an empty (uninitialized) state when default constructed. In this state the name object is not equal to any other initialized name object. Unitnitialized attribute names should not be passed to the library but can be useful in some contexts (e.g. when a delayed initialization is desired).
     383The [class_log_attribute_name] class supports an empty (uninitialized) state when default constructed. In this state the name object is not equal to any other initialized name object. Uninitialized attribute names should not be passed to the library but can be useful in some contexts (e.g. when a delayed initialization is desired).
    384384
    385385[endsect]
    386386
    … …  
    396396
    397397    #include <``[boost_log_attributes_attribute_value_set_hpp]``>
    398398
    399 Attribute value set is an unordered assocoative container that maps [link log.detailed.attributes.related_components.attribute_name attribute names] to [link log.detailed.attributes attribute values]. This container is used in log [link log.detailed.core.record records] to represent attribute values. Unlike conventional containers, [class_log_attribute_value_set] does not support removing or modifying elements after being inserted. This warrants that the attribute values that participated filtering will not disappear from the log record in the middle of the processing.
     399Attribute value set is an unordered associative container that maps [link log.detailed.attributes.related_components.attribute_name attribute names] to [link log.detailed.attributes attribute values]. This container is used in log [link log.detailed.core.record records] to represent attribute values. Unlike conventional containers, [class_log_attribute_value_set] does not support removing or modifying elements after being inserted. This warrants that the attribute values that participated filtering will not disappear from the log record in the middle of the processing.
    400400
    401 Additionally, the set can be constructed from three [link log.detailed.attributes.related_components.attribute_set attribute sets], which are interpreted as the sets of source-specific, thread-specific and global attributes. The constructor adopts attribute values from the three attribute sets into a single set of attribute values. After construction, [class_log_attribute_value_set] is considered to be in an unfrozen state. This means that the container may keep references to the elements of the attribute sets used as the source for the value set construction. While in this state, neither the attribute sets nor the value set must not be modified in any way as this may make the value set corrupted. The value set can be used for reading in this state, its lookup operations will perform as usual. The value set can be frozen by calling the `freeze` method; the set will no longer be attached to the original attribute sets and will be available for further insertions after this call. The library will ensure that the value set is always frosen when a log record is returned from the logging core; the set is [_not] frozen during filtering though.
     401Additionally, the set can be constructed from three [link log.detailed.attributes.related_components.attribute_set attribute sets], which are interpreted as the sets of source-specific, thread-specific and global attributes. The constructor adopts attribute values from the three attribute sets into a single set of attribute values. After construction, [class_log_attribute_value_set] is considered to be in an unfrozen state. This means that the container may keep references to the elements of the attribute sets used as the source for the value set construction. While in this state, neither the attribute sets nor the value set must not be modified in any way as this may make the value set corrupted. The value set can be used for reading in this state, its lookup operations will perform as usual. The value set can be frozen by calling the `freeze` method; the set will no longer be attached to the original attribute sets and will be available for further insertions after this call. The library will ensure that the value set is always frozen when a log record is returned from the logging core; the set is [_not] frozen during filtering though.
    402402
    403403[tip In the unfrozen state the value set may not have all attribute values acquired from the attributes. It will only acquire the values as requested by filters. After freezing the container has all attribute values. This transition allows to optimize the library so that attribute values are only acquired when needed.]
    404404
    405 For futher details on the container interface please consult the [class_log_attribute_value_set] reference.
     405For further details on the container interface please consult the [class_log_attribute_value_set] reference.
    406406
    407407[endsect]
    408408
    … …  
    415415    #include <``[boost_log_attributes_value_visitation_fwd_hpp]``>
    416416    #include <``[boost_log_attributes_value_visitation_hpp]``>
    417417
    418 Attribute value visitation implements the visitor design pattern, hence the naming. The user has to provide an unary function object (a visitor) which will be invoked on the stored attribute value. The caller also has to provide the expected type or set of possible types of the stored value. Obviously, the visitor must be capable of receiving an argument of the expected type. Visitation will only succeed if the stored type matches the expectation.
     418Attribute value visitation implements the visitor design pattern, hence the naming. The user has to provide a unary function object (a visitor) which will be invoked on the stored attribute value. The caller also has to provide the expected type or set of possible types of the stored value. Obviously, the visitor must be capable of receiving an argument of the expected type. Visitation will only succeed if the stored type matches the expectation.
    419419
    420420In order to apply the visitor, one should call the [funcref boost::log::visit `visit`] function on the attribute value. Let's see an example:
    421421
    … …  
    426426In this example we print the stored attribute value in our `print_visitor`. We expect the attribute value to have either `int` or `std::string` stored type; only in this case the visitor will be invoked and the visitation result will be positive. In case of failure the [class_log_visitation_result] class provides additional information on the failure reason. The class has the method named `code` which returns visitation error code. The following error codes are possible:
    427427
    428428* `ok` - visitation succeeded, the visitor has been invoked; visitation result is positive when this code is used
    429 * `value_not_found` - visitation failed because the requested value was not found; this code is used when visitation is applied to a log record or a set of attrinute values rather than a single value
     429* `value_not_found` - visitation failed because the requested value was not found; this code is used when visitation is applied to a log record or a set of attribute values rather than a single value
    430430* `value_has_invalid_type` - visitation failed because the value has type differing from any of the expected types
    431431
    432432By default the visitor function result is ignored but it is possible to obtain it. To do this one should use a special [funcref boost::log::save_result `save_result`] wrapper for the visitor; the wrapper will save the visitor resulting value into an external variable captured by reference. The visitor result is initialized when the returned [class_log_visitation_result] is positive. See the following example where we compute the hash value on the stored value.
    … …  
    458458
    459459In this example we expect the attribute value to have the stored type `int`. The [funcref boost::log::extract `extract`] function attempts to extract a reference to the stored value and returns the filled [link log.detailed.utilities.value_ref `value_ref`] object if succeeded.
    460460
    461 Value extraction can also be used with a set of expected stored types. The follwoing code snippet demonstrates this:
     461Value extraction can also be used with a set of expected stored types. The following code snippet demonstrates this:
    462462
    463463[example_attr_value_extraction_multiple_types]
    464464

  • libs/log/doc/sink_frontends.qbk

     
    3939
    4040[tip [link log.detailed.core.core.exception_handling Logging core] and [link log.detailed.sources.exception_handling loggers] also support installing exception handlers.]
    4141
    42 The library provides a [link log.detailed.utilities.exception_handlers convenient tool] for dispatching exceptions into an unary polymorphic function object.
     42The library provides a [link log.detailed.utilities.exception_handlers convenient tool] for dispatching exceptions into a unary polymorphic function object.
    4343
    4444[note An exception handler is not allowed to return a value. This means you are not able to alter the filtering result once an exception occurs, and thus filtering will always fail.]
    4545

  • libs/log/doc/changelog.qbk

     
    5151* Attribute sets and attribute value sets no longer maintain order of elements. Although it wasn't stated explicitly, the containers used to be ordered associative containers. Now the order of elements is unspecified. The implementation has been reworked to speed up insertion/removal of attributes, as well as attribute lookup and values set construction. The drawback is that memory footprint may get increased in some cases.
    5252* Attribute sets now use small memory pools to speed up element insertion/removal.
    5353* The header `scoped_attribute.hpp` moved from `utility` to the `attributes` directory. The header `attribute_value_extractor.hpp` in `utility` has been replaced with headers [boost_log_attributes_value_extraction_hpp] and [boost_log_attributes_value_visitation_hpp] in the `attributes` directory. The two new headers define the revised API of attribute value extraction and visitation, respectively. See [link log.detailed.attributes.related_components.value_processing here] for more details.
    54 * [link log.detailed.attributes.related_components.scoped_attributes Scoped attibute] macros simplified. The attribute constructor arguments are specified next to the attribute type and tag type is no longer required.
     54* [link log.detailed.attributes.related_components.scoped_attributes Scoped attribute] macros simplified. The attribute constructor arguments are specified next to the attribute type and tag type is no longer required.
    5555* The [link log.detailed.attributes.thread_id `current_thread_id`] attribute no longer uses `boost::thread::id` type for thread identification. An internal type is used instead, the type is accessible as `current_thread_id::value_type`. The new thread ids are taken from the underlying OS API and thus more closely correlate to what may be displayed by debuggers and system diagnostic tools.
    5656* Added [link log.detailed.attributes.process_name `current_process_name`] attribute. The attribute generates a string with the executable name of the current process.
    5757* The `functor` attribute has been renamed to [class_attributes_function]. The generator function has been renamed from `make_functor_attr` to `make_function`. The header has been renamed from `functor.hpp` to `function.hpp`.
    … …  
    6969* Formatting functionality moved to sink frontends. Sink backends that support record formatting derive from the `basic_formatting_sink_backend` class template, which indicates to the frontend that record formatting is required. This breaks user-side API of the library: the formatter and locale has to be set to the frontend rather than backend.
    7070* Formatting support no longer makes frontend thread synchronization mandatory. Formatting is done prior to locking for processing the record in the backend and can be performed concurrently in multiple threads.
    7171* Added support for flushing sinks. A sink backend that supports flushing has to define public method with the following signature: `void flush()`.
    72 * Asynchronous sink frontend reworkerd, ordering asynchronous sink removed. The [class_sinks_asynchronous_sink] class template now allows to specify record queueing strategy. Several strategies provided, including [class_sinks_unbounded_fifo_queue] (the default) and [class_sinks_unbounded_ordering_queue] which cover the functionality of asynchronous sink frontends in 1.x releases. See the [link log.detailed.sink_frontends.async asynchronous sink frontend] docs for more details.
     72* Asynchronous sink frontend reworked, ordering asynchronous sink removed. The [class_sinks_asynchronous_sink] class template now allows to specify record queueing strategy. Several strategies provided, including [class_sinks_unbounded_fifo_queue] (the default) and [class_sinks_unbounded_ordering_queue] which cover the functionality of asynchronous sink frontends in 1.x releases. See the [link log.detailed.sink_frontends.async asynchronous sink frontend] docs for more details.
    7373* Lock-free FIFO record queueing in asynchronous sinks reworked to reduce log record processing stalls.
    7474* Added `Append` configuration file parameter for text file sinks. If this parameter is set to `true`, the sink will append log records to the existing log file instead of overwriting it.
    7575* Added bounded variants of asynchronous sink frontends. Implemented two strategies to handle queue overflows: either log records are dropped or logging threads are blocked until there is space in the queue.
    … …  
    129129* Added a new ordering asynchronous sink frontend.
    130130* The [link log.detailed.sink_backends.syslog syslog] sink backend is now supported on Windows, too. The sink no longer requires native support for POSIX API for syslog, but is able to send syslog packets to a remote server over UDP.
    131131* Loggers implementation has been improved. Feature composition mechanism has been cleaned up.
    132 * Added support for scoped logging. There is now a distinct [link log.detailed.core.record log record entity], which is returned by the core as a result of filtering. It is possible to fill in the record message in any way the user wants, not necessarilly with a streaming expression. The record object is now processed by sinks and formatters.
     132* Added support for scoped logging. There is now a distinct [link log.detailed.core.record log record entity], which is returned by the core as a result of filtering. It is possible to fill in the record message in any way the user wants, not necessarily with a streaming expression. The record object is now processed by sinks and formatters.
    133133* Added support for exception control. User can register exception handlers at one of the three layers: for a particular sink, at the core layer, and for a particular logger (given that it has the appropriate feature). Sinks and core will not suppress exceptions by default. Filter and formatters will throw if the requested attribute value is not found.
    134134* Added a few new formatters, called character decorators. These can be useful to post-process the formatted output before passing it on to the sink.
    135135* Added attributes for thread and process identifiers. These identifiers are automatically added after the call to `add_common_attributes`.
    136136* Helper initialization functions, such as `init_log_to_file` now accept more customization options as named arguments.
    137137* A new [link log.detailed.utilities.setup.settings initialization interface] has been exposed. One can fill a settings container and use it to initialize the library.
    138 * The library setup support code has beed extracted into a separate binary. Further on, this binary will be made optional to build.
     138* The library setup support code has been extracted into a separate binary. Further on, this binary will be made optional to build.
    139139* Added a new mode of logging, called trivial logging. In this mode the library requires no initialization at all, however it does not offer many ways of customization.
    140140* A number of bugs fixed.
    141141* A few optimizations added to improve multithreaded applications performance.
    … …  
    153153
    154154[heading Release Candidate 2]
    155155
    156 Noone really remembers these dark ages...
     156No one really remembers these dark ages...
    157157
    158158[endsect]

  • libs/log/doc/core.qbk

     
    116116        // ...
    117117    }
    118118
    119 The core also provides another way to disable logging. By calling the `set_logging_enabled` with a boolean argument one may completely disable or reenable logging, including applying filtering. Disabling logging with this method may be more benefical in terms of application performance than setting a global filter that always fails.
     119The core also provides another way to disable logging. By calling the `set_logging_enabled` with a boolean argument one may completely disable or re-enable logging, including applying filtering. Disabling logging with this method may be more beneficial in terms of application performance than setting a global filter that always fails.
    120120
    121121[endsect]
    122122

  • libs/log/doc/sink_backends.qbk

     
    162162
    163163    #include <``[boost_log_sinks_syslog_backend_hpp]``>
    164164
    165 The syslog backend, as comes from its name, provides support for the syslog API that is available on virtually any UNIX-like platform. On Windows there exists at least [@http://syslog-win32.sourceforge.net one] public implementation of the syslog client API. However, in order to provide maximum flexibibity and better portability the library offers built-in support for the syslog protocol described in [@http://tools.ietf.org/html/rfc3164 RFC 3164]. Thus on Windows only the built-in implementation is supported, while on UNIX-like systems both built-in and system API based implementations are supported.
     165The syslog backend, as comes from its name, provides support for the syslog API that is available on virtually any UNIX-like platform. On Windows there exists at least [@http://syslog-win32.sourceforge.net one] public implementation of the syslog client API. However, in order to provide maximum flexibility and better portability the library offers built-in support for the syslog protocol described in [@http://tools.ietf.org/html/rfc3164 RFC 3164]. Thus on Windows only the built-in implementation is supported, while on UNIX-like systems both built-in and system API based implementations are supported.
    166166
    167167The backend is implemented in the [class_sinks_syslog_backend] class. The backend supports formatting log records, and therefore requires thread synchronization in the frontend. The backend also supports severity level translation from the application-specific values to the syslog-defined values. This is achieved with an additional function object, level mapper, that receives a set of attribute values of each log record and returns the appropriate syslog level value. This value is used by the backend to construct the final priority value of the syslog record. The other component of the syslog priority value, the facility, is constant for each backend object and can be specified in the backend constructor arguments.
    168168
    … …  
    176176
    177177Also note that the backend will default to the built-in implementation and `user` logging facility, if the corresponding constructor parameters are not specified.
    178178
    179 [tip The `set_target_address` method will also accept DNS names, which it will resolve to the actual IP address. This featue, however, is not available in single threaded builds.]
     179[tip The `set_target_address` method will also accept DNS names, which it will resolve to the actual IP address. This feature, however, is not available in single threaded builds.]
    180180
    181181[endsect]
    182182

  • libs/log/src/process_id.cpp

     
    9696    if (strm.good())
    9797    {
    9898        io::ios_flags_saver flags_saver(strm, std::ios_base::hex | std::ios_base::showbase);
    99         // The width is set calculated to accomodate pid in hex + "0x" prefix
     99        // The width is set calculated to accommodate pid in hex + "0x" prefix
    100100        io::ios_width_saver width_saver(strm, static_cast< std::streamsize >(pid_size * 2 + 2));
    101101        io::basic_ios_fill_saver< CharT, TraitsT > fill_saver(strm, static_cast< CharT >('0'));
    102102        strm << static_cast< uint_t< pid_size * 8 >::least >(pid.native_id());

  • libs/log/src/filter_parser.cpp

     
    198198        operand =
    199199        (
    200200            quoted_string_operand |
    201             // A single word, enclosed with white spaces. It cannot contain parenthesis, since is is used by the filter parser.
     201            // A single word, enclosed with white spaces. It cannot contain parenthesis, since it is used by the filter parser.
    202202            qi::raw[ qi::lexeme[ +(encoding_specific::graph - qi::lit(constants::char_paren_bracket_left) - qi::lit(constants::char_paren_bracket_right)) ] ]
    203203                [boost::bind(&filter_grammar::on_operand, this, _1)]
    204204        );
    … …  
    242242        );
    243243    }
    244244
    245     //! The method returns the cinstructed filter
     245    //! The method returns the constructed filter
    246246    filter get_filter()
    247247    {
    248248        BOOST_ASSERT(!m_Subexpressions.empty());

  • libs/log/src/attribute_name.cpp

     
    122122
    123123    //! The container that provides storage for nodes
    124124    typedef std::deque< node > node_list;
    125     //! The conainer that provides name-based lookup
     125    //! The container that provides name-based lookup
    126126    typedef intrusive::set<
    127127        node,
    128128        intrusive::base_hook< node_by_name_hook >,

  • libs/log/src/event_log_registry.hpp

     
    7171            std::string source_name(buf, buf + size);
    7272            if (source_name.empty())
    7373            {
    74                 // In case of error we provide artifical application name
     74                // In case of error we provide artificial application name
    7575                std::ostringstream strm;
    7676                strm << "Boost.Log "
    7777                    << static_cast< unsigned int >(BOOST_VERSION / 100000)
    … …  
    187187            std::wstring source_name(buf, buf + size);
    188188            if (source_name.empty())
    189189            {
    190                 // In case of error we provide artifical application name
     190                // In case of error we provide artificial application name
    191191                std::wostringstream strm;
    192192                strm << L"Boost.Log "
    193193                    << static_cast< unsigned int >(BOOST_VERSION / 100000)

  • libs/log/src/syslog_backend.cpp

     
    528528    }
    529529#else
    530530    // Boost.ASIO requires threads for the host name resolver,
    531     // so without threads wi simply assume the string already contains IP address
     531    // so without threads we simply assume the string already contains IP address
    532532    set_local_address(boost::asio::ip::address::from_string(addr), port);
    533533#endif // !defined(BOOST_LOG_NO_THREADS)
    534534}
    … …  
    564564    }
    565565#else
    566566    // Boost.ASIO requires threads for the host name resolver,
    567     // so without threads wi simply assume the string already contains IP address
     567    // so without threads we simply assume the string already contains IP address
    568568    set_target_address(boost::asio::ip::address::from_string(addr), port);
    569569#endif // !defined(BOOST_LOG_NO_THREADS)
    570570}

  • libs/log/example/advanced_usage/main.cpp

     
    9898    // Here synchronous_sink is a sink frontend that performs thread synchronization
    9999    // before passing log records to the backend (the text_ostream_backend class).
    100100    // The backend formats each record and outputs it to one or several streams.
    101     // This approach makes implementing backends a lot simplier, because you don't
     101    // This approach makes implementing backends a lot simpler, because you don't
    102102    // need to worry about multithreading.
    103103
    104104    {

  • libs/log/example/doc/core_record.cpp

     
    9494//[ example_core_record_subscript
    9595BOOST_LOG_ATTRIBUTE_KEYWORD(severity, "Severity", severity_level)
    9696
    97 // Prints severity level by using the subscript opereator
     97// Prints severity level by using the subscript operator
    9898void print_severity_subscript(logging::record const& rec)
    9999{
    100100    // Use the attribute keyword to communicate the name and type of the value

  • libs/log/example/bounded_async_log/main.cpp

     
    5757    // Wait until all threads are created
    5858    bar.wait();
    5959
    60     // Here we go. First, identfy the thread.
     60    // Here we go. First, identify the thread.
    6161    BOOST_LOG_SCOPED_THREAD_TAG("ThreadID", boost::this_thread::get_id());
    6262
    6363    // Now, do some logging

  • libs/log/example/async_log/main.cpp

     
    5757    // Wait until all threads are created
    5858    bar.wait();
    5959
    60     // Here we go. First, identfy the thread.
     60    // Here we go. First, identify the thread.
    6161    BOOST_LOG_SCOPED_THREAD_TAG("ThreadID", boost::this_thread::get_id());
    6262
    6363    // Now, do some logging