|
|
Boost-Commit : |
Subject: [Boost-commit] svn:boost r84351 - in trunk: boost/log boost/log/attributes boost/log/core boost/log/detail boost/log/expressions boost/log/sinks boost/log/sources boost/log/utility boost/log/utility/functional boost/log/utility/setup libs/log/doc libs/log/example/advanced_usage libs/log/example/async_log libs/log/example/bounded_async_log libs/log/example/doc libs/log/src libs/log/test/run
From: andrey.semashev_at_[hidden]
Date: 2013-05-18 09:00:24
Author: andysem
Date: 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
New Revision: 84351
URL: http://svn.boost.org/trac/boost/changeset/84351
Log:
Refs #8585. Fixed typos in docs and comments.
Text files modified:
trunk/boost/log/attributes/attribute.hpp | 2 +-
trunk/boost/log/attributes/attribute_name.hpp | 2 +-
trunk/boost/log/attributes/attribute_value.hpp | 20 ++++++++++----------
trunk/boost/log/attributes/clock.hpp | 2 +-
trunk/boost/log/attributes/constant.hpp | 2 +-
trunk/boost/log/attributes/function.hpp | 2 +-
trunk/boost/log/attributes/mutable_constant.hpp | 2 +-
trunk/boost/log/attributes/timer.hpp | 4 ++--
trunk/boost/log/attributes/value_extraction.hpp | 32 ++++++++++++++++----------------
trunk/boost/log/attributes/value_visitation.hpp | 4 ++--
trunk/boost/log/core/core.hpp | 2 +-
trunk/boost/log/core/record.hpp | 2 +-
trunk/boost/log/core/record_view.hpp | 2 +-
trunk/boost/log/detail/unary_function_terminal.hpp | 8 ++++----
trunk/boost/log/expressions/keyword.hpp | 2 +-
trunk/boost/log/sinks/async_frontend.hpp | 2 +-
trunk/boost/log/sinks/attribute_mapping.hpp | 2 +-
trunk/boost/log/sinks/event_log_backend.hpp | 2 +-
trunk/boost/log/sinks/frontend_requirements.hpp | 2 +-
trunk/boost/log/sinks/unlocked_frontend.hpp | 2 +-
trunk/boost/log/sources/basic_logger.hpp | 2 +-
trunk/boost/log/trivial.hpp | 2 +-
trunk/boost/log/utility/explicit_operator_bool.hpp | 2 +-
trunk/boost/log/utility/functional/logical.hpp | 2 +-
trunk/boost/log/utility/record_ordering.hpp | 4 ++--
trunk/boost/log/utility/setup/console.hpp | 2 +-
trunk/boost/log/utility/setup/filter_parser.hpp | 2 +-
trunk/boost/log/utility/value_ref.hpp | 2 +-
trunk/libs/log/doc/attributes.qbk | 14 +++++++-------
trunk/libs/log/doc/changelog.qbk | 10 +++++-----
trunk/libs/log/doc/core.qbk | 2 +-
trunk/libs/log/doc/expressions.qbk | 6 +++---
trunk/libs/log/doc/extension.qbk | 12 ++++++------
trunk/libs/log/doc/rationale.qbk | 4 ++--
trunk/libs/log/doc/sink_backends.qbk | 4 ++--
trunk/libs/log/doc/sink_frontends.qbk | 2 +-
trunk/libs/log/doc/sources.qbk | 2 +-
trunk/libs/log/doc/tutorial.qbk | 18 +++++++++---------
trunk/libs/log/doc/utilities.qbk | 8 ++++----
trunk/libs/log/example/advanced_usage/main.cpp | 2 +-
trunk/libs/log/example/async_log/main.cpp | 2 +-
trunk/libs/log/example/bounded_async_log/main.cpp | 2 +-
trunk/libs/log/example/doc/core_record.cpp | 2 +-
trunk/libs/log/src/attribute_name.cpp | 2 +-
trunk/libs/log/src/event_log_registry.hpp | 4 ++--
trunk/libs/log/src/filter_parser.cpp | 4 ++--
trunk/libs/log/src/process_id.cpp | 2 +-
trunk/libs/log/src/syslog_backend.cpp | 4 ++--
trunk/libs/log/test/run/attr_attribute_value_impl.cpp | 2 +-
trunk/libs/log/test/run/util_string_literal.cpp | 2 +-
50 files changed, 113 insertions(+), 113 deletions(-)
Modified: trunk/boost/log/attributes/attribute.hpp
==============================================================================
--- trunk/boost/log/attributes/attribute.hpp (original)
+++ trunk/boost/log/attributes/attribute.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -50,7 +50,7 @@
* Every attribute is represented with a factory that is basically an attribute value generator.
* The sole purpose of an attribute is to return an actual value when requested. A simplest attribute
* can always return the same value that it stores internally, but more complex ones can
- * perform a considirable amount of work to return a value, and the returned values may differ
+ * perform a considerable amount of work to return a value, and the returned values may differ
* each time requested.
*
* A word about thread safety. An attribute should be prepared to be requested a value from
Modified: trunk/boost/log/attributes/attribute_name.hpp
==============================================================================
--- trunk/boost/log/attributes/attribute_name.hpp (original)
+++ trunk/boost/log/attributes/attribute_name.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -39,7 +39,7 @@
* lighter in terms of memory footprint and operations complexity. This is done
* transparently by this class, on object construction. Passing objects of this class
* to other library methods, such as attribute lookup functions, will not require
- * this thanslation and/or string copying and thus will result in a more efficient code.
+ * this translation and/or string copying and thus will result in a more efficient code.
*/
class attribute_name
{
Modified: trunk/boost/log/attributes/attribute_value.hpp
==============================================================================
--- trunk/boost/log/attributes/attribute_value.hpp (original)
+++ trunk/boost/log/attributes/attribute_value.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -39,7 +39,7 @@
* \brief An attribute value class
*
* An attribute value is an object that contains a piece of data that represents an attribute state
- * at the point of the value acquision. All major operations with log records, such as filtering and
+ * at the point of the value acquisition. All major operations with log records, such as filtering and
* formatting, involve attribute values contained in a single view. Most likely an attribute value is
* implemented as a simple holder of some typed value. This holder implements the
* \c attribute_value::implementation interface and acts as a pimpl for the \c attribute_value
@@ -213,7 +213,7 @@
/*!
* The method attempts to extract the stored value, assuming the value has the specified type.
- * One can specify either a single type or a MPL type sequence, in which case the stored value
+ * One can specify either a single type or an MPL type sequence, in which case the stored value
* is checked against every type in the sequence.
*
* \note Include <tt>value_extraction.hpp</tt> prior to using this method.
@@ -227,7 +227,7 @@
/*!
* The method attempts to extract the stored value, assuming the value has the specified type.
- * One can specify either a single type or a MPL type sequence, in which case the stored value
+ * One can specify either a single type or an MPL type sequence, in which case the stored value
* is checked against every type in the sequence.
*
* \note Include <tt>value_extraction.hpp</tt> prior to using this method.
@@ -241,7 +241,7 @@
/*!
* The method attempts to extract the stored value, assuming the value has the specified type.
- * One can specify either a single type or a MPL type sequence, in which case the stored value
+ * One can specify either a single type or an MPL type sequence, in which case the stored value
* is checked against every type in the sequence. If extraction fails, the default value is returned.
*
* \note Include <tt>value_extraction.hpp</tt> prior to using this method.
@@ -257,7 +257,7 @@
/*!
* The method attempts to extract the stored value, assuming the value has the specified type.
- * One can specify either a single type or a MPL type sequence, in which case the stored value
+ * One can specify either a single type or an MPL type sequence, in which case the stored value
* is checked against every type in the sequence. If extraction fails, the default value is returned.
*
* \note Include <tt>value_extraction.hpp</tt> prior to using this method.
@@ -274,7 +274,7 @@
#if defined(BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS)
/*!
* The method attempts to extract the stored value, assuming the value has the specified type.
- * One can specify either a single type or a MPL type sequence, in which case the stored value
+ * One can specify either a single type or an MPL type sequence, in which case the stored value
* is checked against every type in the sequence.
*
* \note Include <tt>value_extraction.hpp</tt> prior to using this method.
@@ -288,7 +288,7 @@
/*!
* The method attempts to extract the stored value, assuming the value has the specified type.
- * One can specify either a single type or a MPL type sequence, in which case the stored value
+ * One can specify either a single type or an MPL type sequence, in which case the stored value
* is checked against every type in the sequence.
*
* \note Include <tt>value_extraction.hpp</tt> prior to using this method.
@@ -302,7 +302,7 @@
/*!
* The method attempts to extract the stored value, assuming the value has the specified type.
- * One can specify either a single type or a MPL type sequence, in which case the stored value
+ * One can specify either a single type or an MPL type sequence, in which case the stored value
* is checked against every type in the sequence. If extraction fails, the default value is returned.
*
* \note Include <tt>value_extraction.hpp</tt> prior to using this method.
@@ -318,7 +318,7 @@
/*!
* The method attempts to extract the stored value, assuming the value has the specified type.
- * One can specify either a single type or a MPL type sequence, in which case the stored value
+ * One can specify either a single type or an MPL type sequence, in which case the stored value
* is checked against every type in the sequence. If extraction fails, the default value is returned.
*
* \note Include <tt>value_extraction.hpp</tt> prior to using this method.
@@ -338,7 +338,7 @@
/*!
* The method attempts to extract the stored value, assuming the value has the specified type,
* and pass it to the \a visitor function object.
- * One can specify either a single type or a MPL type sequence, in which case the stored value
+ * One can specify either a single type or an MPL type sequence, in which case the stored value
* is checked against every type in the sequence.
*
* \note Include <tt>value_visitation.hpp</tt> prior to using this method.
Modified: trunk/boost/log/attributes/clock.hpp
==============================================================================
--- trunk/boost/log/attributes/clock.hpp (original)
+++ trunk/boost/log/attributes/clock.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -41,7 +41,7 @@
* The time traits provided by the library use \c boost::posix_time::ptime as the time type.
*
* Time traits also determine the way time is acquired. There are two types of time traits
- * provided by th library: \c utc_time_traits and \c local_time_traits. The first returns UTC time,
+ * provided by the library: \c utc_time_traits and \c local_time_traits. The first returns UTC time,
* the second returns local time.
*/
template< typename TimeTraitsT >
Modified: trunk/boost/log/attributes/constant.hpp
==============================================================================
--- trunk/boost/log/attributes/constant.hpp (original)
+++ trunk/boost/log/attributes/constant.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -38,7 +38,7 @@
/*!
* \brief A class of an attribute that holds a single constant value
*
- * The constant is a simpliest and one of the most frequently used types of attributes.
+ * The constant is a simplest and one of the most frequently used types of attributes.
* It stores a constant value, which it eventually returns as its value each time
* requested.
*/
Modified: trunk/boost/log/attributes/function.hpp
==============================================================================
--- trunk/boost/log/attributes/function.hpp (original)
+++ trunk/boost/log/attributes/function.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -77,7 +77,7 @@
public:
/*!
- * Constructor with the stored delegate imitialization
+ * Constructor with the stored delegate initialization
*/
explicit impl_template(T const& fun) : m_Functor(fun) {}
Modified: trunk/boost/log/attributes/mutable_constant.hpp
==============================================================================
--- trunk/boost/log/attributes/mutable_constant.hpp (original)
+++ trunk/boost/log/attributes/mutable_constant.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -45,7 +45,7 @@
* The mutable_constant attribute stores a single value of type, specified as the first template argument.
* This value is returned on each attribute value acquisition.
*
- * The attribute also allows to modify the stored value, even if the attibute is registered in an attribute set.
+ * The attribute also allows to modify the stored value, even if the attribute is registered in an attribute set.
* In order to ensure thread safety of such modifications the \c mutable_constant class is also parametrized
* with three additional template arguments: mutex type, scoped write and scoped read lock types. If not specified,
* the lock types are automatically deduced based on the mutex type.
Modified: trunk/boost/log/attributes/timer.hpp
==============================================================================
--- trunk/boost/log/attributes/timer.hpp (original)
+++ trunk/boost/log/attributes/timer.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -34,7 +34,7 @@
/*!
* \brief A class of an attribute that makes an attribute value of the time interval since construction
*
- * The timer attribute calculates the time passed since its construction and returns it on value acquision.
+ * The timer attribute calculates the time passed since its construction and returns it on value acquisition.
* The attribute value type is <tt>boost::posix_time::time_duration</tt>.
*
* On Windows platform there are two implementations of the attribute. The default one is more precise but
@@ -42,7 +42,7 @@
* to calculate elapsed time.
*
* There are known problems with these functions when used with some CPUs, notably AMD Athlon with
- * Cool'n'Quiet technology enabled. See the following links for for more information and possible resolutions:
+ * Cool'n'Quiet technology enabled. See the following links for more information and possible resolutions:
*
* http://support.microsoft.com/?scid=kb;en-us;895980
* http://support.microsoft.com/?id=896256
Modified: trunk/boost/log/attributes/value_extraction.hpp
==============================================================================
--- trunk/boost/log/attributes/value_extraction.hpp (original)
+++ trunk/boost/log/attributes/value_extraction.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -54,7 +54,7 @@
* \brief A metafunction that allows to acquire the result of the value extraction
*
* The metafunction results in a type that is in form of <tt>T const&</tt>, if \c T is
- * not a MPL type sequence and <tt>DefaultT</tt> is the same as <tt>T</tt>,
+ * not an MPL type sequence and <tt>DefaultT</tt> is the same as <tt>T</tt>,
* or <tt>value_ref< TypesT, TagT ></tt> otherwise, with
* \c TypesT being a type sequence comprising the types from sequence \c T and \c DefaultT,
* if it is not present in \c T already.
@@ -87,7 +87,7 @@
* \brief A metafunction that allows to acquire the result of the value extraction
*
* The metafunction results in a type that is in form of <tt>T const&</tt>, if \c T is
- * not a MPL type sequence, or <tt>value_ref< T, TagT ></tt> otherwise. In the latter
+ * not an MPL type sequence, or <tt>value_ref< T, TagT ></tt> otherwise. In the latter
* case the value reference shall never be empty.
*/
template< typename T, typename TagT >
@@ -414,8 +414,8 @@
* The function extracts an attribute value from the view. The user has to explicitly specify the
* type or set of possible types of the attribute value to be extracted.
*
- * \note Caution must be excercised if the default value is a temporary object. Because the function returns
- * a reference, if the temporary object is destroued, the reference may become dangling.
+ * \note Caution must be exercised if the default value is a temporary object. Because the function returns
+ * a reference, if the temporary object is destroyed, the reference may become dangling.
*
* \param name The name of the attribute value to extract.
* \param attrs A set of attribute values in which to look for the specified attribute value.
@@ -435,8 +435,8 @@
* The function extracts an attribute value from the view. The user has to explicitly specify the
* type or set of possible types of the attribute value to be visited.
*
- * \note Caution must be excercised if the default value is a temporary object. Because the function returns
- * a reference, if the temporary object is destroued, the reference may become dangling.
+ * \note Caution must be exercised if the default value is a temporary object. Because the function returns
+ * a reference, if the temporary object is destroyed, the reference may become dangling.
*
* \param name The name of the attribute value to extract.
* \param rec A log record. The attribute value will be sought among those associated with the record.
@@ -456,8 +456,8 @@
* The function extracts an attribute value from the view. The user has to explicitly specify the
* type or set of possible types of the attribute value to be visited.
*
- * \note Caution must be excercised if the default value is a temporary object. Because the function returns
- * a reference, if the temporary object is destroued, the reference may become dangling.
+ * \note Caution must be exercised if the default value is a temporary object. Because the function returns
+ * a reference, if the temporary object is destroyed, the reference may become dangling.
*
* \param name The name of the attribute value to extract.
* \param rec A log record view. The attribute value will be sought among those associated with the record.
@@ -477,8 +477,8 @@
* The function extracts an attribute value from the view. The user has to explicitly specify the
* type or set of possible types of the attribute value to be visited.
*
- * \note Caution must be excercised if the default value is a temporary object. Because the function returns
- * a reference, if the temporary object is destroued, the reference may become dangling.
+ * \note Caution must be exercised if the default value is a temporary object. Because the function returns
+ * a reference, if the temporary object is destroyed, the reference may become dangling.
*
* \param value Attribute value.
* \param def_val The default value
@@ -690,8 +690,8 @@
* The function extracts an attribute value from the view. The user has to explicitly specify the
* type or set of possible types of the attribute value to be extracted.
*
- * \note Caution must be excercised if the default value is a temporary object. Because the function returns
- * a reference, if the temporary object is destroued, the reference may become dangling.
+ * \note Caution must be exercised if the default value is a temporary object. Because the function returns
+ * a reference, if the temporary object is destroyed, the reference may become dangling.
*
* \param keyword The keyword of the attribute value to extract.
* \param attrs A set of attribute values in which to look for the specified attribute value.
@@ -711,8 +711,8 @@
* The function extracts an attribute value from the view. The user has to explicitly specify the
* type or set of possible types of the attribute value to be visited.
*
- * \note Caution must be excercised if the default value is a temporary object. Because the function returns
- * a reference, if the temporary object is destroued, the reference may become dangling.
+ * \note Caution must be exercised if the default value is a temporary object. Because the function returns
+ * a reference, if the temporary object is destroyed, the reference may become dangling.
*
* \param keyword The keyword of the attribute value to extract.
* \param rec A log record. The attribute value will be sought among those associated with the record.
@@ -732,8 +732,8 @@
* The function extracts an attribute value from the view. The user has to explicitly specify the
* type or set of possible types of the attribute value to be visited.
*
- * \note Caution must be excercised if the default value is a temporary object. Because the function returns
- * a reference, if the temporary object is destroued, the reference may become dangling.
+ * \note Caution must be exercised if the default value is a temporary object. Because the function returns
+ * a reference, if the temporary object is destroyed, the reference may become dangling.
*
* \param keyword The keyword of the attribute value to extract.
* \param rec A log record view. The attribute value will be sought among those associated with the record.
Modified: trunk/boost/log/attributes/value_visitation.hpp
==============================================================================
--- trunk/boost/log/attributes/value_visitation.hpp (original)
+++ trunk/boost/log/attributes/value_visitation.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -53,7 +53,7 @@
{
ok, //!< The attribute value has been visited successfully
value_not_found, //!< The attribute value is not present in the view
- value_has_invalid_type //!< The attribute value is present in the vew, but has an unexpected type
+ value_has_invalid_type //!< The attribute value is present in the view, but has an unexpected type
};
private:
@@ -90,7 +90,7 @@
*
* Attribute value invoker is a functional object that attempts to find and extract the stored
* attribute value from the attribute value view or a log record. The extracted value is passed to
- * an unary function object (the visitor) provided by user.
+ * a unary function object (the visitor) provided by user.
*
* The invoker can be specialized on one or several attribute value types that should be
* specified in the second template argument.
Modified: trunk/boost/log/core/core.hpp
==============================================================================
--- trunk/boost/log/core/core.hpp (original)
+++ trunk/boost/log/core/core.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -188,7 +188,7 @@
* every log record made in the current thread.
*
* \note In single-threaded build the effect is the same as adding the attribute globally. This, however, does
- * not imply that iterators to thread-specific and global attributes are interchangable.
+ * not imply that iterators to thread-specific and global attributes are interchangeable.
*
* \param name The attribute name.
* \param attr The attribute factory.
Modified: trunk/boost/log/core/record.hpp
==============================================================================
--- trunk/boost/log/core/record.hpp (original)
+++ trunk/boost/log/core/record.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -36,7 +36,7 @@
/*!
* \brief Logging record class
*
- * The logging record incapsulates all information related to a single logging statement,
+ * The logging record encapsulates all information related to a single logging statement,
* in particular, attribute values view and the log message string. The record can be updated before pushing
* for further processing to the logging core.
*/
Modified: trunk/boost/log/core/record_view.hpp
==============================================================================
--- trunk/boost/log/core/record_view.hpp (original)
+++ trunk/boost/log/core/record_view.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -42,7 +42,7 @@
/*!
* \brief Logging record view class
*
- * The logging record incapsulates all information related to a single logging statement,
+ * The logging record encapsulates all information related to a single logging statement,
* in particular, attribute values view and the log message string. The view is immutable,
* it is implemented as a wrapper around a reference-counted implementation.
*/
Modified: trunk/boost/log/detail/unary_function_terminal.hpp
==============================================================================
--- trunk/boost/log/detail/unary_function_terminal.hpp (original)
+++ trunk/boost/log/detail/unary_function_terminal.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -39,11 +39,11 @@
namespace aux {
/*!
- * \brief An adapter for an unary function to be used as a terminal in a Boost.Phoenix expression
+ * \brief An adapter for a unary function to be used as a terminal in a Boost.Phoenix expression
*
- * This class is an adapter between Boost.Phoenix expression invokation protocol and
- * an unary function. It forwards the call to the base function, passing only the first argument
- * from the original call. This allows to to embed value extractors in template expressions.
+ * This class is an adapter between Boost.Phoenix expression invocation protocol and
+ * a unary function. It forwards the call to the base function, passing only the first argument
+ * from the original call. This allows to embed value extractors in template expressions.
*/
template< typename FunT >
class unary_function_terminal
Modified: trunk/boost/log/expressions/keyword.hpp
==============================================================================
--- trunk/boost/log/expressions/keyword.hpp (original)
+++ trunk/boost/log/expressions/keyword.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -239,7 +239,7 @@
/*!
* \brief The macro declares an attribute keyword
*
- * The macro provides definitions similar to \c BOOST_LOG_ATTRIBUTE_KEYWORD_TYPE and addidionally
+ * The macro provides definitions similar to \c BOOST_LOG_ATTRIBUTE_KEYWORD_TYPE and additionally
* defines the keyword object.
*
* \param keyword_ Keyword name
Modified: trunk/boost/log/sinks/async_frontend.hpp
==============================================================================
--- trunk/boost/log/sinks/async_frontend.hpp (original)
+++ trunk/boost/log/sinks/async_frontend.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -95,7 +95,7 @@
private:
//! Backend synchronization mutex type
typedef boost::mutex backend_mutex_type;
- //! Frontend syncronization mutex type
+ //! Frontend synchronization mutex type
typedef typename base_type::mutex_type frontend_mutex_type;
//! A scope guard that implements thread ID management
Modified: trunk/boost/log/sinks/attribute_mapping.hpp
==============================================================================
--- trunk/boost/log/sinks/attribute_mapping.hpp (original)
+++ trunk/boost/log/sinks/attribute_mapping.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -251,7 +251,7 @@
* the native value.
*
* \param rec A log record to extract value from
- * \return A mapped value, if mapping was successfull, or the default value if
+ * \return A mapped value, if mapping was successful, or the default value if
* mapping did not succeed.
*/
mapped_type operator() (record_view const& rec) const
Modified: trunk/boost/log/sinks/event_log_backend.hpp
==============================================================================
--- trunk/boost/log/sinks/event_log_backend.hpp (original)
+++ trunk/boost/log/sinks/event_log_backend.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -304,7 +304,7 @@
private:
//! The mapper that will extract the event identifier
event_id_mapper_type m_EventIDMapper;
- //! The map of event identifiers and and their insertion composers
+ //! The map of event identifiers and their insertion composers
event_map m_EventMap;
public:
Modified: trunk/boost/log/sinks/frontend_requirements.hpp
==============================================================================
--- trunk/boost/log/sinks/frontend_requirements.hpp (original)
+++ trunk/boost/log/sinks/frontend_requirements.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -46,7 +46,7 @@
/*!
* The sink backend expects pre-synchronized calls, all needed synchronization is implemented
* in the frontend (IOW, only one thread is feeding records to the backend concurrently, but
- * is is possible for several threads to write sequentially). Note that if a frontend supports
+ * it is possible for several threads to write sequentially). Note that if a frontend supports
* synchronized record feeding, it will also report capable of concurrent record feeding.
*/
struct synchronized_feeding {};
Modified: trunk/boost/log/sinks/unlocked_frontend.hpp
==============================================================================
--- trunk/boost/log/sinks/unlocked_frontend.hpp (original)
+++ trunk/boost/log/sinks/unlocked_frontend.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -100,7 +100,7 @@
/*!
* Locking accessor to the attached backend.
*
- * \note Does not do any actual locking, provided only for intarface consistency
+ * \note Does not do any actual locking, provided only for interface consistency
* with other frontends.
*/
locked_backend_ptr locked_backend()
Modified: trunk/boost/log/sources/basic_logger.hpp
==============================================================================
--- trunk/boost/log/sources/basic_logger.hpp (original)
+++ trunk/boost/log/sources/basic_logger.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -306,7 +306,7 @@
* The user's logger class is expected to derive from the composite logger class, instantiated with
* the character type, the user's logger class, the threading model and the list of the required features.
* The former three parameters are passed to the \c basic_logger class template. The feature list
- * must be a MPL type sequence, where each element is an unary MPL metafunction class, that upon
+ * must be an MPL type sequence, where each element is a unary MPL metafunction class, that upon
* applying on its argument results in a logging feature class that derives from the argument.
* Every logger feature provided by the library can participate in the feature list.
*/
Modified: trunk/boost/log/trivial.hpp
==============================================================================
--- trunk/boost/log/trivial.hpp (original)
+++ trunk/boost/log/trivial.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -48,7 +48,7 @@
fatal
};
-//! Returns stringified enumeration value or \c NULL, if the value is not valid
+//! Returns stringized enumeration value or \c NULL, if the value is not valid
BOOST_LOG_API const char* to_string(severity_level lvl);
template< typename CharT, typename TraitsT >
Modified: trunk/boost/log/utility/explicit_operator_bool.hpp
==============================================================================
--- trunk/boost/log/utility/explicit_operator_bool.hpp (original)
+++ trunk/boost/log/utility/explicit_operator_bool.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -10,7 +10,7 @@
* \date 08.03.2009
*
* This header defines a compatibility macro that implements an unspecified
- * \c bool operator idiom, which is superceded with explicit conversion operators in
+ * \c bool operator idiom, which is superseded with explicit conversion operators in
* C++0x.
*/
Modified: trunk/boost/log/utility/functional/logical.hpp
==============================================================================
--- trunk/boost/log/utility/functional/logical.hpp (original)
+++ trunk/boost/log/utility/functional/logical.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -14,7 +14,7 @@
* header are not templates and therefore do not require a fixed argument type. Furthermore, both arguments
* may have different types, in which case the comparison is performed without type conversion.
*
- * \note In case if arguments are intergal, the conversion is performed according to the standard C++ rules
+ * \note In case if arguments are integral, the conversion is performed according to the standard C++ rules
* in order to avoid warnings from the compiler.
*/
Modified: trunk/boost/log/utility/record_ordering.hpp
==============================================================================
--- trunk/boost/log/utility/record_ordering.hpp (original)
+++ trunk/boost/log/utility/record_ordering.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -78,7 +78,7 @@
result_type operator() (record_view const& left, record_view const& right) const
{
// We rely on the fact that the attribute_values() method returns a reference to the object in the record implementation,
- // so we can comare pointers.
+ // so we can compare pointers.
return FunT::operator() (static_cast< const void* >(&left.attribute_values()), static_cast< const void* >(&right.attribute_values()));
}
};
@@ -86,7 +86,7 @@
/*!
* \brief Ordering predicate, based on attribute values associated with records
*
- * This predicate allows to order log records based on values of a specificly named attribute
+ * This predicate allows to order log records based on values of a specifically named attribute
* associated with them. Two given log records being compared should both have the specified
* attribute value of the specified type to be able to be ordered properly. As a special case,
* if neither of the records have the value, these records are considered equivalent. Otherwise,
Modified: trunk/boost/log/utility/setup/console.hpp
==============================================================================
--- trunk/boost/log/utility/setup/console.hpp (original)
+++ trunk/boost/log/utility/setup/console.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -168,7 +168,7 @@
* or a filter lambda expression.
* \li \c format Specifies a formatter to install into the sink. May be a string that represents a formatter,
* or a formatter lambda expression (either streaming or Boost.Format-like notation).
- * \li \c auto_flush A boolean flag that shows whether the sink should automaticallu flush the stream
+ * \li \c auto_flush A boolean flag that shows whether the sink should automatically flush the stream
* after each written record.
* \return Pointer to the constructed sink.
*/
Modified: trunk/boost/log/utility/setup/filter_parser.hpp
==============================================================================
--- trunk/boost/log/utility/setup/filter_parser.hpp (original)
+++ trunk/boost/log/utility/setup/filter_parser.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -137,7 +137,7 @@
* The base class for filter factories. The class defines default implementations for most
* filter expressions. In order to be able to construct filters, the attribute value type must
* support reading from a stream. Also, the default filters will rely on relational operators for
- * the type, so these optrators must also be defined.
+ * the type, so these operators must also be defined.
*/
template< typename CharT, typename AttributeValueT >
class basic_filter_factory :
Modified: trunk/boost/log/utility/value_ref.hpp
==============================================================================
--- trunk/boost/log/utility/value_ref.hpp (original)
+++ trunk/boost/log/utility/value_ref.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -404,7 +404,7 @@
* 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
* interface and behavior combines features of Boost.Ref, Boost.Optional and Boost.Variant, depending on the use case.
*
- * The template parameter \c T can be a single type or an MPL seqence of possible types being referred. The reference wrapper
+ * The template parameter \c T can be a single type or an MPL sequence of possible types being referred. The reference wrapper
* will act as either an optional reference or an optional variant of references to the specified types. In any case, the
* referred values will not be modifiable (i.e. \c value_ref always models a const reference).
*
Modified: trunk/libs/log/doc/attributes.qbk
==============================================================================
--- trunk/libs/log/doc/attributes.qbk (original)
+++ trunk/libs/log/doc/attributes.qbk 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -380,7 +380,7 @@
Working 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.
-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).
+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. 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).
[endsect]
@@ -396,13 +396,13 @@
#include <``[boost_log_attributes_attribute_value_set_hpp]``>
-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.
+Attribute 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.
-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.
+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 frozen when a log record is returned from the logging core; the set is [_not] frozen during filtering though.
[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.]
-For futher details on the container interface please consult the [class_log_attribute_value_set] reference.
+For further details on the container interface please consult the [class_log_attribute_value_set] reference.
[endsect]
@@ -415,7 +415,7 @@
#include <``[boost_log_attributes_value_visitation_fwd_hpp]``>
#include <``[boost_log_attributes_value_visitation_hpp]``>
-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.
+Attribute 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.
In order to apply the visitor, one should call the [funcref boost::log::visit `visit`] function on the attribute value. Let's see an example:
@@ -426,7 +426,7 @@
In 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:
* `ok` - visitation succeeded, the visitor has been invoked; visitation result is positive when this code is used
-* `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
+* `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
* `value_has_invalid_type` - visitation failed because the value has type differing from any of the expected types
By 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.
@@ -458,7 +458,7 @@
In 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.
-Value extraction can also be used with a set of expected stored types. The follwoing code snippet demonstrates this:
+Value extraction can also be used with a set of expected stored types. The following code snippet demonstrates this:
[example_attr_value_extraction_multiple_types]
Modified: trunk/libs/log/doc/changelog.qbk
==============================================================================
--- trunk/libs/log/doc/changelog.qbk (original)
+++ trunk/libs/log/doc/changelog.qbk 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -51,7 +51,7 @@
* 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.
* Attribute sets now use small memory pools to speed up element insertion/removal.
* 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.
-* [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.
+* [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.
* 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.
* Added [link log.detailed.attributes.process_name `current_process_name`] attribute. The attribute generates a string with the executable name of the current process.
* 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`.
@@ -69,7 +69,7 @@
* 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.
* 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.
* Added support for flushing sinks. A sink backend that supports flushing has to define public method with the following signature: `void flush()`.
-* 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.
+* 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.
* Lock-free FIFO record queueing in asynchronous sinks reworked to reduce log record processing stalls.
* 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.
* 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.
@@ -129,13 +129,13 @@
* Added a new ordering asynchronous sink frontend.
* 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.
* Loggers implementation has been improved. Feature composition mechanism has been cleaned up.
-* 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.
+* 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.
* 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.
* 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.
* Added attributes for thread and process identifiers. These identifiers are automatically added after the call to `add_common_attributes`.
* Helper initialization functions, such as `init_log_to_file` now accept more customization options as named arguments.
* 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.
-* The library setup support code has beed extracted into a separate binary. Further on, this binary will be made optional to build.
+* The library setup support code has been extracted into a separate binary. Further on, this binary will be made optional to build.
* 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.
* A number of bugs fixed.
* A few optimizations added to improve multithreaded applications performance.
@@ -153,6 +153,6 @@
[heading Release Candidate 2]
-Noone really remembers these dark ages...
+No one really remembers these dark ages...
[endsect]
Modified: trunk/libs/log/doc/core.qbk
==============================================================================
--- trunk/libs/log/doc/core.qbk (original)
+++ trunk/libs/log/doc/core.qbk 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -116,7 +116,7 @@
// ...
}
-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.
+The 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.
[endsect]
Modified: trunk/libs/log/doc/expressions.qbk
==============================================================================
--- trunk/libs/log/doc/expressions.qbk (original)
+++ trunk/libs/log/doc/expressions.qbk 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -18,7 +18,7 @@
#include <``[boost_log_expressions_attr_fwd_hpp]``>
#include <``[boost_log_expressions_attr_hpp]``>
-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:
+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 invocation. This can be roughly described with the following pseudo-code:
logging::value_ref< T, TagT > val = expr::attr< T, TagT >(name)(rec);
@@ -156,7 +156,7 @@
[@boost:/libs/log/example/doc/expressions_has_attr_stat_accum.cpp See the complete code].
-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.
+In 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.
Please 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.
@@ -509,7 +509,7 @@
#include <``[boost_log_expressions_formatters_c_decorator_hpp]``>
-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:
+The 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:
sink->set_formatter
(
Modified: trunk/libs/log/doc/extension.qbk
==============================================================================
--- trunk/libs/log/doc/extension.qbk (original)
+++ trunk/libs/log/doc/extension.qbk 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -28,7 +28,7 @@
* [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.
* [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.
-[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.]
+[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.]
Multiple requirements can be combined into `frontend_requirements` type with the [class_sinks_combine_requirements] metafunction:
@@ -74,7 +74,7 @@
The 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.
-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".
+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 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".
Now, the `consume` implementation is trivial:
@@ -283,18 +283,18 @@
You 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.
-Like with formatter parser extension, you can avoid spelling out the filter factory and register a simple factlry provided by the library:
+Like with formatter parser extension, you can avoid spelling out the filter factory and register a simple factory provided by the library:
[example_extension_simple_filter_factory]
-In order this to work the user's type should fullfill these requirements:
+In order this to work the user's type should fulfill these requirements:
# Support reading from an input stream with `operator>>`.
# Support the complete set of comparison and ordering operators.
Naturally, 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.
-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:
+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 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:
[example_extension_filter_parser_point_definition]
@@ -343,7 +343,7 @@
As 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.
-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.
+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 possible to restore the default factories afterwards.
[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.]
Modified: trunk/libs/log/doc/rationale.qbk
==============================================================================
--- trunk/libs/log/doc/rationale.qbk (original)
+++ trunk/libs/log/doc/rationale.qbk 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -105,7 +105,7 @@
[section:why_attribute_manips_dont_affect_filters Why attributes set with stream manipulators do not participate in filtering?]
-One can add attributes to log records in the followinf way:
+One can add attributes to log records in the following way:
BOOST_LOG(logger) << logging::add_value("MyInt", 10) << logging::add_value("MyString", "string attribute value")
<< "Some log message";
@@ -181,7 +181,7 @@
As 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.
-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.
+Namespace 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.
[endsect]
Modified: trunk/libs/log/doc/sink_backends.qbk
==============================================================================
--- trunk/libs/log/doc/sink_backends.qbk (original)
+++ trunk/libs/log/doc/sink_backends.qbk 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -162,7 +162,7 @@
#include <``[boost_log_sinks_syslog_backend_hpp]``>
-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.
+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 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.
The 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.
@@ -176,7 +176,7 @@
Also note that the backend will default to the built-in implementation and `user` logging facility, if the corresponding constructor parameters are not specified.
-[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.]
+[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.]
[endsect]
Modified: trunk/libs/log/doc/sink_frontends.qbk
==============================================================================
--- trunk/libs/log/doc/sink_frontends.qbk (original)
+++ trunk/libs/log/doc/sink_frontends.qbk 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -39,7 +39,7 @@
[tip [link log.detailed.core.core.exception_handling Logging core] and [link log.detailed.sources.exception_handling loggers] also support installing exception handlers.]
-The library provides a [link log.detailed.utilities.exception_handlers convenient tool] for dispatching exceptions into an unary polymorphic function object.
+The library provides a [link log.detailed.utilities.exception_handlers convenient tool] for dispatching exceptions into a unary polymorphic function object.
[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.]
Modified: trunk/libs/log/doc/sources.qbk
==============================================================================
--- trunk/libs/log/doc/sources.qbk (original)
+++ trunk/libs/log/doc/sources.qbk 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -52,7 +52,7 @@
[example_sources_network_connection_channels]
-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:
+It 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:
[example_sources_network_connection_dynamic_channels]
Modified: trunk/libs/log/doc/tutorial.qbk
==============================================================================
--- trunk/libs/log/doc/tutorial.qbk (original)
+++ trunk/libs/log/doc/tutorial.qbk 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -57,7 +57,7 @@
[heading File logging unleashed]
-As a starting point, here is how you would initialize logginig to a file:
+As a starting point, here is how you would initialize logging to a file:
[example_tutorial_file_simple]
@@ -117,7 +117,7 @@
Regardless 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.
-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.
+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 details.
[heading Global logger objects]
@@ -155,7 +155,7 @@
In 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.
-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.
+Each 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.
Aside 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.
@@ -175,7 +175,7 @@
The [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].
-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:
+Some 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:
[example_sources_severity]
@@ -200,7 +200,7 @@
// other attributes skipped for brevity
}
-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:
+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`] attribute:
core->add_global_attribute("Scope", attrs::named_scope());
@@ -260,7 +260,7 @@
expr::attr< logging::trivial::severity_level >("Severity")
-[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.]
+[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.]
There 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.
@@ -274,7 +274,7 @@
[heading Boost.Format-style formatters]
-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:
+As an alternative, you can define formatters with a syntax similar to __boost_format__. The same formatter as described above can be written as follows:
[example_tutorial_formatters_format]
@@ -304,7 +304,7 @@
[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.]
-[heading Custom formatting functons]
+[heading Custom formatting functions]
You can add a custom formatter to a sink backend that supports formatting. The formatter is actually a function object that supports the following signature:
@@ -332,7 +332,7 @@
In 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.
-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].
+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 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].
Further 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.
Modified: trunk/libs/log/doc/utilities.qbk
==============================================================================
--- trunk/libs/log/doc/utilities.qbk (original)
+++ trunk/libs/log/doc/utilities.qbk 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -58,7 +58,7 @@
#include <``[boost_log_utility_type_dispatch_static_type_dispatcher_hpp]``>
-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:
+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 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:
[example_util_static_type_dispatcher]
@@ -149,7 +149,7 @@
[heading Abstract record ordering]
-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.
+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 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.
// A set of unique records
std::set< logging::record_view, logging::abstract_ordering< > > m_Records;
@@ -184,7 +184,7 @@
The 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.
-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).
+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 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).
[example_utility_exception_handler]
@@ -465,7 +465,7 @@
Sink 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".
-[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.]
+[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.]
[table Sections under the "Sinks" section. Common sink settings.
[[Parameter] [Format] [Description]]
Modified: trunk/libs/log/example/advanced_usage/main.cpp
==============================================================================
--- trunk/libs/log/example/advanced_usage/main.cpp (original)
+++ trunk/libs/log/example/advanced_usage/main.cpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -98,7 +98,7 @@
// Here synchronous_sink is a sink frontend that performs thread synchronization
// before passing log records to the backend (the text_ostream_backend class).
// The backend formats each record and outputs it to one or several streams.
- // This approach makes implementing backends a lot simplier, because you don't
+ // This approach makes implementing backends a lot simpler, because you don't
// need to worry about multithreading.
{
Modified: trunk/libs/log/example/async_log/main.cpp
==============================================================================
--- trunk/libs/log/example/async_log/main.cpp (original)
+++ trunk/libs/log/example/async_log/main.cpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -57,7 +57,7 @@
// Wait until all threads are created
bar.wait();
- // Here we go. First, identfy the thread.
+ // Here we go. First, identify the thread.
BOOST_LOG_SCOPED_THREAD_TAG("ThreadID", boost::this_thread::get_id());
// Now, do some logging
Modified: trunk/libs/log/example/bounded_async_log/main.cpp
==============================================================================
--- trunk/libs/log/example/bounded_async_log/main.cpp (original)
+++ trunk/libs/log/example/bounded_async_log/main.cpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -57,7 +57,7 @@
// Wait until all threads are created
bar.wait();
- // Here we go. First, identfy the thread.
+ // Here we go. First, identify the thread.
BOOST_LOG_SCOPED_THREAD_TAG("ThreadID", boost::this_thread::get_id());
// Now, do some logging
Modified: trunk/libs/log/example/doc/core_record.cpp
==============================================================================
--- trunk/libs/log/example/doc/core_record.cpp (original)
+++ trunk/libs/log/example/doc/core_record.cpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -94,7 +94,7 @@
//[ example_core_record_subscript
BOOST_LOG_ATTRIBUTE_KEYWORD(severity, "Severity", severity_level)
-// Prints severity level by using the subscript opereator
+// Prints severity level by using the subscript operator
void print_severity_subscript(logging::record const& rec)
{
// Use the attribute keyword to communicate the name and type of the value
Modified: trunk/libs/log/src/attribute_name.cpp
==============================================================================
--- trunk/libs/log/src/attribute_name.cpp (original)
+++ trunk/libs/log/src/attribute_name.cpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -122,7 +122,7 @@
//! The container that provides storage for nodes
typedef std::deque< node > node_list;
- //! The conainer that provides name-based lookup
+ //! The container that provides name-based lookup
typedef intrusive::set<
node,
intrusive::base_hook< node_by_name_hook >,
Modified: trunk/libs/log/src/event_log_registry.hpp
==============================================================================
--- trunk/libs/log/src/event_log_registry.hpp (original)
+++ trunk/libs/log/src/event_log_registry.hpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -71,7 +71,7 @@
std::string source_name(buf, buf + size);
if (source_name.empty())
{
- // In case of error we provide artifical application name
+ // In case of error we provide artificial application name
std::ostringstream strm;
strm << "Boost.Log "
<< static_cast< unsigned int >(BOOST_VERSION / 100000)
@@ -187,7 +187,7 @@
std::wstring source_name(buf, buf + size);
if (source_name.empty())
{
- // In case of error we provide artifical application name
+ // In case of error we provide artificial application name
std::wostringstream strm;
strm << L"Boost.Log "
<< static_cast< unsigned int >(BOOST_VERSION / 100000)
Modified: trunk/libs/log/src/filter_parser.cpp
==============================================================================
--- trunk/libs/log/src/filter_parser.cpp (original)
+++ trunk/libs/log/src/filter_parser.cpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -198,7 +198,7 @@
operand =
(
quoted_string_operand |
- // A single word, enclosed with white spaces. It cannot contain parenthesis, since is is used by the filter parser.
+ // A single word, enclosed with white spaces. It cannot contain parenthesis, since it is used by the filter parser.
qi::raw[ qi::lexeme[ +(encoding_specific::graph - qi::lit(constants::char_paren_bracket_left) - qi::lit(constants::char_paren_bracket_right)) ] ]
[boost::bind(&filter_grammar::on_operand, this, _1)]
);
@@ -242,7 +242,7 @@
);
}
- //! The method returns the cinstructed filter
+ //! The method returns the constructed filter
filter get_filter()
{
BOOST_ASSERT(!m_Subexpressions.empty());
Modified: trunk/libs/log/src/process_id.cpp
==============================================================================
--- trunk/libs/log/src/process_id.cpp (original)
+++ trunk/libs/log/src/process_id.cpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -96,7 +96,7 @@
if (strm.good())
{
io::ios_flags_saver flags_saver(strm, std::ios_base::hex | std::ios_base::showbase);
- // The width is set calculated to accomodate pid in hex + "0x" prefix
+ // The width is set calculated to accommodate pid in hex + "0x" prefix
io::ios_width_saver width_saver(strm, static_cast< std::streamsize >(pid_size * 2 + 2));
io::basic_ios_fill_saver< CharT, TraitsT > fill_saver(strm, static_cast< CharT >('0'));
strm << static_cast< uint_t< pid_size * 8 >::least >(pid.native_id());
Modified: trunk/libs/log/src/syslog_backend.cpp
==============================================================================
--- trunk/libs/log/src/syslog_backend.cpp (original)
+++ trunk/libs/log/src/syslog_backend.cpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -528,7 +528,7 @@
}
#else
// Boost.ASIO requires threads for the host name resolver,
- // so without threads wi simply assume the string already contains IP address
+ // so without threads we simply assume the string already contains IP address
set_local_address(boost::asio::ip::address::from_string(addr), port);
#endif // !defined(BOOST_LOG_NO_THREADS)
}
@@ -564,7 +564,7 @@
}
#else
// Boost.ASIO requires threads for the host name resolver,
- // so without threads wi simply assume the string already contains IP address
+ // so without threads we simply assume the string already contains IP address
set_target_address(boost::asio::ip::address::from_string(addr), port);
#endif // !defined(BOOST_LOG_NO_THREADS)
}
Modified: trunk/libs/log/test/run/attr_attribute_value_impl.cpp
==============================================================================
--- trunk/libs/log/test/run/attr_attribute_value_impl.cpp (original)
+++ trunk/libs/log/test/run/attr_attribute_value_impl.cpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -126,7 +126,7 @@
BOOST_CHECK(!p4.dispatch(disp));
}
-// The test verifies that value extracition works
+// The test verifies that value extraction works
BOOST_AUTO_TEST_CASE(value_extraction)
{
logging::attribute_value p1(attrs::make_attribute_value< int >(10));
Modified: trunk/libs/log/test/run/util_string_literal.cpp
==============================================================================
--- trunk/libs/log/test/run/util_string_literal.cpp (original)
+++ trunk/libs/log/test/run/util_string_literal.cpp 2013-05-18 09:00:19 EDT (Sat, 18 May 2013)
@@ -192,7 +192,7 @@
BOOST_CHECK_EQUAL(lit1, "yo-ho-ho");
}
-// STL strings acquision tests
+// STL strings acquisition tests
BOOST_AUTO_TEST_CASE(string_literal_str)
{
logging::string_literal lit = "yo-ho-ho";
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk