feedc0de/boost_container
1
0
Fork 0
forked from boostorg/container
Code Pull Requests Activity

Trailing whitespaces

Browse Source 
[SVN r78519]
This commit is contained in:
Ion Gaztañaga
2012-05-20 10:03:06 +00:00
parent 9460e03224
commit 082c47b721
27 changed files with 371 additions and 151 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/Jamfile.v2
+9 -9
View File
@@ -36,8 +36,8 @@ doxygen autodoc
<xsl:param>"boost.doxygen.reftitle=Boost.Container Header Reference"
;
xml container : container.qbk
:
xml container : container.qbk
:
<include>../../../tools/auto_index/include
;
@@ -54,26 +54,26 @@ boostbook standalone
<format>pdf:<xsl:param>boost.url.prefix=http://www.boost.org/doc/libs/release/doc/html
# Build requirements go here:
# <auto-index>on (or off) one turns on (or off) indexing:
<auto-index>on
# Turns on (or off) auto-index-verbose for diagnostic info.
# This is highly recommended until you have got all the many details correct!
<auto-index-verbose>on
<auto-index-verbose>on
# Choose the indexing method (separately for html and PDF) - see manual.
# Choose indexing method for PDFs:
<format>pdf:<auto-index-internal>off
# Choose indexing method for html:
<format>html:<auto-index-internal>on
# Set the name of the script file to use (index.idx is popular):
<auto-index-script>index.idx
# Commands in the script file should all use RELATIVE PATHS
# otherwise the script will not be portable to other machines.
# Relative paths are normally taken as relative to the location
# Relative paths are normally taken as relative to the location
# of the script file, but we can add a prefix to all
# those relative paths using the <auto-index-prefix> feature.
# The path specified by <auto-index-prefix> may be either relative or
doc/container.qbk
+22 -22
View File
@@ -225,7 +225,7 @@ want to advance it by n positions, we simply do:
it.p = *(it.p->up+n);
That is, we go "up" to the pointer array, add n there and then go "down" to the resulting node.
That is, we go "up" to the pointer array, add n there and then go "down" to the resulting node.
[*General properties]. `stable_vector` satisfies all the requirements of a container, a reversible container and a sequence
and provides all the optional operations present in vector. Like vector, iterators are random access. `stable_vector`
@@ -291,8 +291,8 @@ C++ world. Matt Austern's classic article
["['Red-black trees aren't the only way to organize data that permits lookup in logarithmic time. One of the basic
algorithms of computer science is binary search, which works by successively dividing a range in half. Binary
search is log N and it doesn't require any fancy data structures, just a sorted collection of elements.
(...) You can use whatever data structure is convenient, so long as it provides STL iterator;
search is log N and it doesn't require any fancy data structures, just a sorted collection of elements.
(...) You can use whatever data structure is convenient, so long as it provides STL iterator;
usually it's easiest to use a C array, or a vector.]]
["['Both std::lower_bound and set::find take time proportional to log N, but the constants of proportionality
@@ -317,12 +317,12 @@ showed `AssocVector`, a `std::map` drop-in
replacement designed in his [@http://loki-lib.sourceforge.net/ Loki] library:
["['It seems as if we're better off with a sorted vector. The disadvantages of a sorted
vector are linear-time insertions and linear-time deletions (...). In exchange, a vector
offers about twice the lookup speed and a much smaller working set (...).
Loki saves the trouble of maintaining a sorted vector by hand by defining an AssocVector class
template. AssocVector is a drop-in replacement for std::map (it supports the same set of member
functions), implemented on top of std::vector. AssocVector differs from a map in the behavior of
its erase functions (AssocVector::erase invalidates all iterators into the object) and in the
vector are linear-time insertions and linear-time deletions (...). In exchange, a vector
offers about twice the lookup speed and a much smaller working set (...).
Loki saves the trouble of maintaining a sorted vector by hand by defining an AssocVector class
template. AssocVector is a drop-in replacement for std::map (it supports the same set of member
functions), implemented on top of std::vector. AssocVector differs from a map in the behavior of
its erase functions (AssocVector::erase invalidates all iterators into the object) and in the
complexity guarantees of insert and erase (linear as opposed to constant). ]]
[*Boost.Container] `flat_[multi]map/set` containers are ordered-vector based associative containers
@@ -380,7 +380,7 @@ should probably use list instead of slist.]]
[*Boost.Container] updates the classic `slist` container with C++11 features like move semantics and placement
insertion and implements it a bit differently than the standard C++ `forward_list`. `forward_list` has no `size()`
method, so it's been designed to allow (or in practice, encourage) implementations without tracking list size
with every insertion/erasure, allowing constant-time
with every insertion/erasure, allowing constant-time
`splice_after(iterator, forward_list &, iterator, iterator)`-based list merging. On the other hand `slist` offers
constant-time `size()` for those that don't care about linear-time `splice_after(iterator, slist &, iterator, iterator)`
`size()` and offers an additional `splice_after(iterator, slist &, iterator, iterator, size_type)` method that
@@ -422,16 +422,16 @@ to suppose two allocators of the same type always compare equal (that means that
by one allocator object could be deallocated by another instance of the same type) and
allocators were not swapped when the container was swapped.
C++11 further improves stateful allocator support through
C++11 further improves stateful allocator support through
[@http://en.cppreference.com/w/cpp/memory/allocator_traits `std::allocator_traits`].
`std::allocator_traits` is the protocol between a container and an allocator, and
an allocator writer can customize its behaviour (should the container propagate it in
move constructor, swap, etc.?) following `allocator_traits` requirements. [*Boost.Container]
not only supports this model with C++11 but also [*backports it to C++03].
not only supports this model with C++11 but also [*backports it to C++03].
If possible, a single allocator is hold to construct `value_type`. If the container needs an auxiliary
allocator (e.g. a array allocator used by `deque` or `stable_vector`), that allocator is also
constructed from the user-supplied allocator when the container is constructed (i.e. it's
If possible, a single allocator is hold to construct `value_type`. If the container needs an auxiliary
allocator (e.g. a array allocator used by `deque` or `stable_vector`), that allocator is also
constructed from the user-supplied allocator when the container is constructed (i.e. it's
not constructed on the fly when auxiliary memory is needed).
[endsect]
@@ -453,14 +453,14 @@ container's elements, and, if the elements themselves are containers, the third
elements' elements, and so on.
[*Boost.Container] implements its own `scoped_allocator_adaptor` class and [*backports this feature also
to C++03 compilers]. Due to C++03 limitations, in those compilers
to C++03 compilers]. Due to C++03 limitations, in those compilers
the allocator propagation implemented by `scoped_allocator_adaptor::construct` functions
will be based on traits([classref boost::container::constructible_with_allocator_suffix constructible_with_allocator_suffix]
and [classref boost::container::constructible_with_allocator_prefix constructible_with_allocator_prefix])
proposed in [@http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2008/n2554.pdf
proposed in [@http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2008/n2554.pdf
N2554: The Scoped Allocator Model (Rev 2) proposal]. In conforming C++11 compilers or compilers supporting SFINAE
expressions (when `BOOST_NO_SFINAE_EXPR` is NOT defined), traits are ignored and C++11 rules
(`is_constructible<T, Args..., inner_allocator_type>::value` and
expressions (when `BOOST_NO_SFINAE_EXPR` is NOT defined), traits are ignored and C++11 rules
(`is_constructible<T, Args..., inner_allocator_type>::value` and
`is_constructible<T, allocator_arg_t, inner_allocator_type, Args...>::value`)
will be used to detect if the allocator must be propagated with suffix or prefix allocator arguments.
@@ -487,7 +487,7 @@ versions.
unsuccessful tries to deprecate or remove it from the standard. [*Boost.Container] does not implement it
as there is a superior [@http://www.boost.org/libs/dynamic_bitset/ Boost.DynamicBitset]
solution. For issues with `vector<bool>` see papers
[@http://www.gotw.ca/publications/N1211.pdf vector<bool>: N1211: More Problems, Better Solutions],
[@http://www.gotw.ca/publications/N1211.pdf vector<bool>: N1211: More Problems, Better Solutions],
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html N2160: Library Issue 96: Fixing vector<bool>],
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2204.html N2204 A Specification to deprecate vector<bool>].
@@ -539,7 +539,7 @@ code tweaked to support non-raw `allocator::pointer` types and stateful allocato
Shmem was accepted as [@http://www.boost.org/libs/interprocess/ Boost.Interprocess] and this library
continued to refine and improve those containers.
In 2007, container code from node containers (`map`, `list`, `slist`) was rewritten, refactored
In 2007, container code from node containers (`map`, `list`, `slist`) was rewritten, refactored
and expanded to build the intrusive container library [@http://www.boost.org/libs/intrusive/ Boost.Intrusive].
[*Boost.Interprocess] containers were refactored to take advantage of [*Boost.Intrusive] containers and
code duplication was minimized. Both libraries continued to gain support and bug fixes for years.
@@ -603,7 +603,7 @@ use [*Boost.Container]? There are several reasons for that:
[@http://bannalia.blogspot.com/2008/09/introducing-stablevector.html Joaqu\u00EDn M. L\u00F3pez Mu\u00F1oz],
then adapted for [*Boost.Interprocess]. Thanks for such a great container.
* Howard Hinnant's help and advices were essential when implementing move semantics,
* Howard Hinnant's help and advices were essential when implementing move semantics,
improving allocator support or implementing small string optimization. Thanks Howard
for your wonderful standard library implementations.
doc/index.idx
+1 -1
View File
@@ -1 +1 @@
!scan-path "boost/container" ".*.hpp" false
!scan-path "boost/container" ".*.hpp" false