144c144
<    a size overhead for each allocation to store bookeeping information and a
---
>    a size overhead for each allocation to store bookkeeping information and a
163c163
<    In some situation intrusives containers offer a no-throw guarantee that can't be 
---
>    In some situations intrusive containers offer a no-throw guarantee that can't be 
171c171
<    memory managed is done with intrusive containers. Memory management usually is not a predicable
---
>    memory management is done with intrusive containers. Memory management usually is not a predicable
178c178
<    maintenance information needed by the container. Hence, whenever a certain type shall
---
>    maintenance information needed by the container. Hence, whenever a certain type will
183c183
< *  In intrusive containers you don't store a copy of an object, [*but they rather the original object
---
> *  In intrusive containers you don't store a copy of an object, [*but rather the original object
197,198c197,198
<    containers don't have allocation capabilities, these operations have no sense. However,
<    swapping can be used to implement move-capabilities. To ease the implementation of
---
>    containers don't have allocation capabilities, these operations make no sense. However,
>    swapping can be used to implement move capabilities. To ease the implementation of
203,204c203,204
< *  Analyzing thread-safety of a program that uses containers is harder with intrusive containers, becuase
<    the container might be modified indirectly without an explicitly call to a container member.
---
> *  Analyzing the thread safety of a program that uses containers is harder with intrusive containers, because
>    the container might be modified indirectly without an explicit call to a container member.
236,237c236,237
< container. We will take a simple intrusive container, like an intrusive list
< ([classref boost::intrusive::list boost::intrusive::list]) for the following
---
> container. We will take a simple intrusive container, the intrusive list
> ([classref boost::intrusive::list boost::intrusive::list]), for the following
315c315
<    Some options configured for the hook (the type of the pointers, link mode...)
---
>    Some options configured for the hook (the type of the pointers, link mode, etc.)
329c329
<    (for example, STL-like containers, use the `size_type` defined by their allocator).
---
>    (for example, STL-like containers use the `size_type` defined by their allocator).
431,432c431,432
< You can insert the same object in several intrusive containers at the same time, just
< using one hook for each container. This is a full example using base and member hooks:
---
> You can insert the same object in several intrusive containers at the same time, 
> using one hook per container. This is a full example using base and member hooks:
459c459
< issue and...
---
> issue and:
470c470
< you have a vector of objects (say, `std::vector<Object>`) and you also have a list
---
> you have a vector of objects (say, `std::vector<Object>`), and you also have a list
472c472
< from the list iterator (`std::list<Object*>::iterator`) needs two steps:
---
> from the list iterator (`std::list<Object*>::iterator`) requires two steps:
478,481c478,481
< (vector's memory is guaranteed to be contiguous), and form something
< like a data block, list nodes can stay dispersed in the heap memory.
< Hence depending on your system you can get a lot of cache misses. The same doesn't hold
< for an intrusive list. Indeed, dereferencing an an iterator from an intrusive list is performed in
---
> (a vector's memory is guaranteed to be contiguous), and form something
> like a data block, list nodes may be dispersed in the heap memory.
> Hence depending on your system you might get a lot of cache misses. The same doesn't hold
> for an intrusive list. Indeed, dereferencing an iterator from an intrusive list is performed in
487c487
< in the same container as shown in the following example: 
---
> in the same container, as shown in the following example: 
496c496
< posible or desirable.
---
> possible or desirable.
507,508c507,508
<    basic operations that can be applied to a groups of nodes. It's independent
<    from the node definition, and it's configured taking a NodeTraits template
---
>    basic operations that can be applied to a group of nodes. It's independent
>    from the node definition and configured using a NodeTraits template
510c510
< [[Node Traits][A class that stores basic information and operations to insert a node in a group of nodes.]]
---
> [[Node Traits][A class that stores basic information and operations to insert a node into a group of nodes.]]
531c531
< *  [*set/multiset/rbtree]: A `std::set/std::multiset` like intrusive associative containers
---
> *  [*set/multiset/rbtree]: `std::set/std::multiset` like intrusive associative containers
541c541
< *  [*splay_set/splay_multiset/splaytree]: A `std::set/std::multiset` like intrusive associative
---
> *  [*splay_set/splay_multiset/splaytree]: `std::set/std::multiset` like intrusive associative
549c549
<    balance factor to achieve the desised rebalancing frequency/search time compromise.
---
>    balance factor to achieve the desired rebalancing frequency/search time compromise.
555c555
< *  [*unordered_set/unordered_multiset]: A `std::tr1::unordered_set/std::tr1::unordered_multiset`
---
> *  [*unordered_set/unordered_multiset]: `std::tr1::unordered_set/std::tr1::unordered_multiset`
558c558
<    Many operations have an amortized constant time complexity.
---
>    Many operations have amortized constant time complexity.
563,564c563,564
< *  [*Linear time size]: The intrusive container doesn't hold a size member that it's
< updated with every insertion/erasure. This implies that the `size()` function has not constant
---
> *  [*Linear time size]: The intrusive container doesn't hold a size member that is
> updated with every insertion/erasure. This implies that the `size()` function doesn't have constant
566c566
< `splice()` taking a range of iterators in linked lists have constant time complexity
---
> `splice()` taking a range of iterators in linked lists, have constant time complexity
569c569
< *  [*Constant time size]: The intrusive container holds a size member that it's updated
---
> *  [*Constant time size]: The intrusive container holds a size member that is updated
588c588
<    and can convert some constant time operations in linear time operations.
---
>    and can convert some constant time operations to linear time operations.
592c592
<    having any reference to the container.
---
>    referring to the container.
596c596
<    be configured to use any type of pointers. This configuration information is also
---
>    be configured to use any type of pointer. This configuration information is also
614c614
<    //Configuring explicity the safe mode
---
>    //Configuring the safe mode explicitly
618,619c618,619
< Thanks to the safe-mode the user can detect without any external reference, if the object
< is actually inserted in a container. Let's review the basic features of the safe-mode:
---
> With the safe mode the user can detect if the object
> is actually inserted in a container without any external reference. Let's review the basic features of the safe mode:
621c621
< *  Hooks' constructor puts the hook in a well-known default state.
---
> *  Hook's constructor puts the hook in a well-known default state.
623c623
< *  Hooks' destructor checks if the hook is in the well-known default state. If not,
---
> *  Hook's destructor checks if the hook is in the well-known default state. If not,
626c626
< *  Every time an object is being inserted in the intrusive container, the container
---
> *  Every time an object is inserted in the intrusive container, the container
634c634
< has been inserted in a container calling the `is_linked()` member function.
---
> has been inserted in a container by calling the `is_linked()` member function.
636c636
< in a container, the hook is in the default state and if it's inserted in a container, the
---
> in a container, the hook is in the default state, and if it is inserted in a container, the
658c658
< If any of these macros is not redefined, the assertion will be defaul to `BOOST_ASSERT`.
---
> If any of these macros is not redefined, the assertion will default to `BOOST_ASSERT`.
673,674c673,674
<    node from the container at any moment, without having any reference to the container,
<    if the user want to do so.
---
>    node from the container at any time, without having any reference to the container,
>    if the user wants to do so.
676c676
< These hooks have exactly the same size overhead as their analogue non auto-unlinking
---
> These hooks have exactly the same size overhead as their analog non auto-unlinking
683c683
<   without using any reference to the container. 
---
>   without referring to the container. 
699,700c699,700
< *  Every time an object is being inserted in the intrusive container, the container
<    checks if the hook is the well-known default state. If not,
---
> *  Every time an object is inserted in the intrusive container, the container
>    checks if the hook is in the well-known default state. If not,
703c703
< *  Every time an object is being erased from the intrusive container, the container
---
> *  Every time an object is erased from an intrusive container, the container
766,768c766,768
< that imposes is 1 pointer per node. The size of an empty, non constant-time size 
< [classref boost::intrusive::slist slist], is the size of 1 pointer. This
< lightweight memory overhead comes with its drawbacks, though: many operations have
---
> it imposes is 1 pointer per node. The size of an empty, non constant-time size 
> [classref boost::intrusive::slist slist] is the size of 1 pointer. This
> lightweight memory overhead comes with drawbacks, though: many operations have
776c776
< constructing more elaborated containers, singly linked lists are essential
---
> constructing more elaborate containers, singly linked lists are essential
834,835c834,835
<    to configure the container (to know about value traits go to the section
<    titled [link intrusive.value_traits Containers with custom ValueTraits].
---
>    to configure the container. (To learn about value traits go to the section
>    [link intrusive.value_traits Containers with custom ValueTraits].)
875,876c875,876
< that imposes is 2 pointers per node. An empty, non constant-time size [classref boost::intrusive::list list]
< has also the size of 2 pointers. [classref boost::intrusive::list list]
---
> it imposes is 2 pointers per node. An empty, non constant-time size [classref boost::intrusive::list list]
> also has the size of 2 pointers. [classref boost::intrusive::list list]
878c878
< and provides bidirectional iterator. It's recommendable to use use
---
> and provides a bidirectional iterator. It is recommended to use
936,937c936,937
<    to configure the container (to know about value traits go to the section
<    titled [link intrusive.value_traits Containers with custom ValueTraits].
---
>    to configure the container. (To learn about value traits go to the section
>    [link intrusive.value_traits Containers with custom ValueTraits].)
977c977
< searches, insertions, erasures, etc... [classref boost::intrusive::set set] and
---
> searches, insertions, erasures, etc. [classref boost::intrusive::set set] and
1059,1060c1059,1060
<    to configure the container (to know about value traits go to the section
<    titled [link intrusive.value_traits Containers with custom ValueTraits].
---
>    to configure the container. (To learn about value traits go to the section
>    [link intrusive.value_traits Containers with custom ValueTraits].)
1244,1245c1244,1245
<    to configure the container (to know about value traits go to the section
<    titled [link intrusive.value_traits Containers with custom ValueTraits].
---
>    to configure the container. (To learn about value traits go to the section
>    [link intrusive.value_traits Containers with custom ValueTraits].)
1327c1327
< Splay trees are self-adjusting binary search trees used tipically in caches, memory
---
> Splay trees are self-adjusting binary search trees used typically in caches, memory
1329c1329
< accessed elements have better access times that elements accessed less frequently.
---
> accessed elements have better access times than elements accessed less frequently.
1341c1341
< An empty, non constant-time size splay container has also the size of 3 pointers.
---
> An empty, non constant-time size splay container has also a size of 3 pointers.
1346c1346
< operations like searches, insertions, erasures, etc... but if some elements are
---
> operations like searches, insertions, erasures, etc., but if some elements are
1353c1353
< `count()`...
---
> `count()`, etc.
1426,1427c1426,1427
<    to configure the container (to know about value traits go to the section
<    titled [link intrusive.value_traits Containers with custom ValueTraits].
---
>    to configure the container.  (To learn about value traits go to the section
>    [link intrusive.value_traits Containers with custom ValueTraits].)
1451c1451
< [classref boost::intrusive::sg_multiset sg_multiset] so a programmer
---
> [classref boost::intrusive::sg_multiset sg_multiset]. A programmer
1453,1454c1453,1454
< can be introduced in some situations in an splay container but that
< can also be introduced in other compatible containers as well when
---
> can be inserted in some situations in an splay container but
> also inserted in other compatible containers when
1482c1482
< and because red-black trees also take O(log n) time for the basic operations. 
---
> and because both take O(log n) time for basic operations. 
1503c1503
< has also the size of 3 pointers and an integer (3 pointers when optimized for size).
---
> also has a size of 3 pointers and an integer (3 pointers when optimized for size).
1574,1575c1574,1575
<    to configure the container (to know about value traits go to the section
<    titled [link intrusive.value_traits Containers with custom ValueTraits].
---
>    to configure the container. (To learn about value traits go to the section
>    [link intrusive.value_traits Containers with custom ValueTraits].)
1725,1726c1725,1726
<    to configure the container (to know about value traits go to the section
<    titled [link intrusive.value_traits Containers with custom ValueTraits].
---
>    to configure the container. (To learn about value traits go to the section
>    [link intrusive.value_traits Containers with custom ValueTraits].)
1789c1789
< like `equal_range`, `lower_bound`, `upper_bound`...
---
> like `equal_range`, `lower_bound`, `upper_bound`, etc.
1791c1791
< However, sometimes the object to be searched it's quite expensive to construct:
---
> However, sometimes the object to be searched is quite expensive to construct:
1808c1808
< [*have enough information to find the object]. In this case, a name it's enough
---
> [*have enough information to find the object]. In this case, a name is enough
1865c1865
< *  if the insertion is possible (there is no equivalent value) collects all the needed information
---
> *  if the insertion is possible (there is no equivalent value) `insert_check` collects all the needed information
1874c1874
< `insert_check` and `insert_commit` will come handy
---
> `insert_check` and `insert_commit` will come in handy
1920c1920
< will call "disposer" function object for every removed element. [classref boost::intrusive::list list] offers
---
> will call the "disposer" function object for every removed element. [classref boost::intrusive::list list] offers
1922c1922
< `remove_and_dispose`... 
---
> `remove_and_dispose`, etc. 
1949c1949
< Apart from the container to be cloned, `clone_from` takes two function objects as arguments. For example, the
---
> Apart from the container to be cloned, `clone_from` takes two function objects as arguments. For example, consider the
1968,1969c1968,1969
< *   First clears and disposes all the elements from *this using the disposer function object.
< *   After that starts cloning all the elements of the source container using the cloner function object.
---
> *   First it clears and disposes all the elements from *this using the disposer function object.
> *   After that it starts cloning all the elements of the source container using the cloner function object.
2001c2001
< Not every smart pointer is compatible with [*Boost.Intrusive], the smart pointer must
---
> Not every smart pointer is compatible with [*Boost.Intrusive]; the smart pointer must
2011c2011
< ADL. For example, for `boost::interprocess::offset_ptr` `detail::get_pointer` is defined
---
> ADL. For example, for `boost::interprocess::offset_ptr`, `detail::get_pointer` is defined
2059,2060c2059,2060
< explained in the [link intrusive.value_traits.stateful_value_traits Stateful value traits] section,
< but the programmer uses hooks provided by [*Boost.Intrusive], those functions
---
> explained in the [link intrusive.value_traits.stateful_value_traits Stateful value traits] section;
> if the programmer uses hooks provided by [*Boost.Intrusive], those functions
2078c2078
<    unlink a node from another group of nodes... For example, a circular
---
>    unlink a node from another group of nodes, etc. For example, a circular
2082c2082
<    the needed interface. As an example, here is a class that implements algorithms
---
>    the needed interface. As an example, here is a class that implements operations7'
2119,2123c2119,2123
<    operations on a node that forms a group of nodes:
<    the type of the node, a function to obtain the pointer to the next node... 
<    [*Node Traits] are the configuration information [*Node Algorithms]
<    need. Each type of [*Node Algorithms] expects an interface that compatible
<    [*Node Traits] must implement.
---
>    operations on a node within a group of nodes:
>    the type of the node, a function to obtain the pointer to the next node, etc. 
>    [*Node Traits] specify the configuration information [*Node Algorithms]
>    need. Each type of [*Node Algorithm] expects an interface that compatible
>    [*Node Traits] classes must implement.
2152c2152
<    contains a node object, that will be used to form the group of nodes:
---
>    contains a node object that will be used to form the group of nodes:
2192c2192
<    value types that use different hooks. An intrusive container is also more elaborated
---
>    value types that use different hooks. An intrusive container is also more elaborate
2194c2194
<    size information, it can offer debugging facilities...
---
>    size information, it can offer debugging facilities, etc.
2386c2386
< the pointers to the left and right nodes to itself and whose color is red.
---
> the left and right node pointers point to itself, and whose color is red.
2457c2457
< the pointers to the left and right nodes to itself.
---
> and whose left and right nodes pointers point to itself.
2641c2641
< `ValueTraits` also store information about the link policy of the values to be inserted.
---
> `ValueTraits` also stores information about the link policy of the values to be inserted.
2655c2655
< `ValueTraits` have the following interface:
---
> `ValueTraits` has the following interface:
2681c2681
< *  [*['node_traits]]: The node configuration that it's needed by node algorithms.
---
> *  [*['node_traits]]: The node configuration that is needed by node algorithms.
2683c2683
<    described in the previous chapter: [link intrusive.node_algorithms Nodes Algorithms].
---
>    described in the previous chapter: [link intrusive.node_algorithms Node Algorithms].
2711c2711
<    as `node_ptr`: If `node_ptr` is `node *` `pointer` must be `value_type*`. If
---
>    as `node_ptr`: If `node_ptr` is `node*`, `pointer` must be `value_type*`. If
2717c2717
<    as `node_ptr`: If `node_ptr` is `node *` `const_pointer` must be `const value_type*`. If
---
>    as `node_ptr`: If `node_ptr` is `node*`, `const_pointer` must be `const value_type*`. If
2727c2727
<       as the link, containers
---
>       as the link mode, containers
2731d2730
<       normal_link,
2733,2735c2732,2734
<    *  [*`safe_link`]: If this linking policy is specified in a `ValueTraits` class
<       as the link, containers
<       configured with such `ValueTraits` will set the hooks
---
>    *  [*`safe_link`]: If this linking policy is specified as the link mode 
>       in a `ValueTraits` class, containers
>       configured with this `ValueTraits` will set the hooks
2742c2741
<       Containers also know that the a value can be silently erased from
---
>       Containers also know that a value can be silently erased from
2747c2746
<    These function take a reference to a value_type and return a pointer to the node
---
>    These functions take a reference to a value_type and return a pointer to the node
2752c2751
<    These function take a pointer to a node and return a pointer to the value
---
>    These functions take a pointer to a node and return a pointer to the value
2764c2763
< the object in a singly and doubly linked list at the same time. 
---
> the object in both a singly and a doubly linked list at the same time. 
2776c2775
< Defining a value traits class that just defines `value_type` as 
---
> Defining a value traits class that simply defines `value_type` as 
2797c2796
< if the user does not want to use provided [*Boost.Intrusive] facilities.
---
> if the user does not want to use the provided [*Boost.Intrusive] facilities.
2817c2816
< we'll define a templatized `ValueTraits` that will work for both types:
---
> a templatized `ValueTraits` that will work for both types:
2828c2827
< all the possible [classref boost::intrusive::list list] containers
---
> all possible [classref boost::intrusive::list list] containers
2836c2835
< The previous example can be further simplified using
---
> The previous example can be further simplified using the
2872,2873c2871,2872
< so that we can even separate nodes and values and [*avoid modifying types to insert nodes].
< [*Boost.Intrusive] differentiates between stateful and stateless value traits checking if the ValueTraits
---
> so that we can separate nodes and values and [*avoid modifying types to insert nodes].
> [*Boost.Intrusive] differentiates between stateful and stateless value traits by checking if the ValueTraits
2883c2882
< (stateless value traits could use global variables to achieve the same property), so:
---
> (stateless value traits could use global variables to achieve the same goal), so:
2886,2887c2885,2886
<    value traits, since accessing to global resources might require syncronization primitives that
<    can be avoided when using the internal state.
---
>    value traits, since accessing global resources might require syncronization primitives that
>    can be avoided when using internal state.
2889c2888
< *  [*Run-time polimorphism]: A value traits might implement node <-> value
---
> *  [*Run-time polymorphism]: A value traits might implement node <-> value
2896c2895
<    [*A heavy node <-> value transformation can downgrade intrusive containers' performance].
---
>    [*A heavy node <-> value transformation will hurt intrusive containers' performance].
2917c2916
< Intrusive containers have similar same thread-safety guarantees than STL containers.
---
> Intrusive containers have thread safety guarantees similar to STL containers.
2919c2918
< *  Several threads can have read or write access to different instances is safe as long as inserted
---
> *  Several threads having read or write access to different instances is safe as long as inserted
2926,2927c2925,2926
< Other functions, like checking if an objects is already inserted in a containers using the `is_linked()`
< member of safe hooks is a read-access to the container without having a reference to them, so no other
---
> Other functions, like checking if an object is already inserted in a container using the `is_linked()`
> member of safe hooks, constitute read access on the container without having a reference to it, so no other
2931c2930
< the thread safety of [*Boost.Intrusive] is related to the containers and also the object whose lifetime
---
> the thread safety of [*Boost.Intrusive] is related to the containers and also to the object whose lifetime
2937c2936
< To analyze the thread-safety, take in care the following points:
---
> To analyze the thread safety, consider the following points:
2939,2941c2938,2940
< *  Auto-unlink hook's destructor and `unlink()` functions modify the container indirectly.
< *  Safe mode and auto-unlink hook's `is_linked()` function is a read access to the container.
< *  Inserting an object in several containers that will be modified by different threads has no thread-safety
---
> *  The auto-unlink hook's destructor and `unlink()` functions modify the container indirectly.
> *  The safe mode and auto-unlink hooks' `is_linked()` functions are a read access to the container.
> *  Inserting an object in containers that will be modified by different threads has no thread safety
2949c2948
< has also a couple of downsides:
---
> has a couple of downsides:
2951,2954c2950,2953
< *  If a user specifies the same options in different order or specifies some options and lefts the
<    rest as defaults the type of the created container/hook will be different. Sometimes
<    this is annoying, because two programmers specifying the same options might end with incompatible
<    types. For example, the following two lists, although they're using the same options, have not
---
> *  If a user specifies the same options in different order or specifies some options and leaves the
>    rest as defaults, the type of the created container/hook will be different. Sometimes
>    this is annoying, because two programmers specifying the same options might end up with incompatible
>    types. For example, the following two lists, although using the same options, do not have
2972c2971
<    might suffer a bit if long names are produced.
---
>    may suffer if long names are produced.
2974,2977c2973,2976
< To solve these issues [*Boost.Intrusive] offers some helper metafunctions that that reduce symbol lengths
< and create the same type if the same options (either explicitly or implicitly) are used. This also
< improves compilation times. All containers and hooks have their respective `make_xxx` versions.
< Previous shown example can be rewritten like this to obtain the same list type:
---
> To solve these issues [*Boost.Intrusive] offers some helper metafunctions that reduce symbol lengths
> and create the same type if the same options (either explicitly or implicitly) are used. These also
> improve compilation times. All containers and hooks have their respective `make_xxx` versions.
> The previously shown example can be rewritten like this to obtain the same list type:
2995,2996c2994,2995
< Produced symbol lengths and compilation times are usually shorter and object/debug files are smaller.
< If you are a programmer concerned with file sizes and compilation times, this option is your choice.
---
> Produced symbol lengths and compilation times will usually be shorter and object/debug files smaller.
> If you are concerned with file sizes and compilation times, this option is your best choice.
3025c3024
< [*Boost.Intrusive] wants to avoid any code size overhead associated with templates.
---
> [*Boost.Intrusive] seeks to avoid any code size overhead associated with templates.
3029,3030c3028,3029
< are two-byte aligned. The possibility to avoid constant-time size operations can
< save some size on containers, and this extra size optimization is noticeable
---
> are two-byte aligned. The option to forgo constant-time size operations can
> reduce container size, and this extra size optimization is noticeable
3035c3034
< [section: Boost.Intrusive as basic building block]
---
> [section: Boost.Intrusive as a basic building block]
3037,3039c3036,3038
< [*Boost.Intrusive] should be a basic building block to build more complex containers
< and this guideline has motivated many design decisions. For example, the possibility
< to have more than one hook per user type opens the possibility to implement multi-index
---
> [*Boost.Intrusive] can be a basic building block to build more complex containers
> and this potential has motivated many design decisions. For example, the ability
> to have more than one hook per user type opens the opportunity to implement multi-index
3043,3044c3042,3043
< as arguments (`clone_from`, `erase_and_dispose`, `insert_check`...). These
< functions come handy when implementing non-intrusive containers
---
> as arguments (`clone_from`, `erase_and_dispose`, `insert_check`, etc.). These
> functions come in handy when implementing non-intrusive containers
3054c3053
< build special hooks that take advantage of its application environment.
---
> build special hooks that take advantage of an application environment.
3056c3055
< For example, the programmer can use can customize parts of [*Boost.Intrusive]
---
> For example, the programmer can customize parts of [*Boost.Intrusive]
3065,3066c3064,3065
< [*Boost.Intrusive] containers offer speed improvements comparing to non-intrusive containers,
< basically because:
---
> [*Boost.Intrusive] containers offer speed improvements compared to non-intrusive containers
> primarily because:
3068,3069c3067,3068
< *  We can minimize memory allocation/deallocation calls.
< *  We obtain better memory locality.
---
> *  They minimize memory allocation/deallocation calls.
> *  They obtain better memory locality.
3071c3070
< This section will show some performance tests comparing some operations on 
---
> This section will show performance tests comparing some operations on 
3076c3075
< *  `reverse` member function will show the advantages of the compact
---
> *  The `reverse` member function will show the advantages of the compact
3078,3079c3077,3078
< *  `sort` and `write access` tests will show the advantage of intrusive containers
<    minimizing the memory accesses when comparing them with containers of pointers.
---
> *  The `sort` and `write access` tests will show the advantage of intrusive containers
>    minimizing memory accesses compared to containers of pointers.
3083c3082
< or it can replace `std::list<T*>` when the user wants to obtain containers with
---
> or it can replace `std::list<T*>` when the user wants containers with
3115c3114
< `test_list` objects to funtion objects taking pointers to them.
---
> `test_list` objects to function objects taking pointers to them.
3123c3122
< avoiding memory allocations and deallocations . All the objects to be
---
> avoiding memory allocations and deallocations. All the objects to be
3125c3124
< whereas `std::list` will need to allocate memory for every and deallocate it
---
> whereas `std::list` will need to allocate memory for each object and deallocate it
3183,3184c3182,3183
< whereas `safe_link` and `auto_unlink` intrusive containers need to put the hook of
< erased values' in the default state (complexity: `O(NumElements)`). That's why
---
> whereas `safe_link` and `auto_unlink` intrusive containers need to put the hooks of
> erased values in the default state (complexity: `O(NumElements)`). That's why
3187,3188c3186,3187
< Non-intrusive containers need to make much more allocations and that's why they are
< lagging behind. The `disperse pointer list` needs to make `NumElements*2` allocations,
---
> Non-intrusive containers need to make many more allocations and that's why they
> lag behind. The `disperse pointer list` needs to make `NumElements*2` allocations,
3191,3193c3190,3192
< Linux test shows that standard containers perform very well against intrusive containers
< with big objects. Nearly the same GCC version in MinGW performs worse, so maybe the
< a good memory allocator is the reason for these excelent results.
---
> The Linux test shows that standard containers perform very well against intrusive containers
> with big objects. Nearly the same GCC version in MinGW performs worse, so maybe
> a good memory allocator is the reason for these excellent results.
3200c3199
< Values (`test_class` and `itest_class`) and lists are created like explained in the
---
> Values (`test_class` and `itest_class`) and lists are created as explained in the
3205c3204
< since this function just needs to adjust internal pointers, so in theory, all tested
---
> since this function just needs to adjust internal pointers, so in theory all tested
3263,3265c3262,3264
< For big values the compact pointer list wins because when reversing doesn't need access
< to the values stored in another container. Since all the allocations for nodes of
< this pointer list are likely to be near (since there is no other allocation in the
---
> For big objects the compact pointer list wins because the reversal test doesn't need access
> to values stored in another container. Since all the allocations for nodes of
> this pointer list are likely to be close (since there is no other allocation in the
3267c3266
< containers. The dispersed pointer list, like with small values, has poor locality.
---
> containers. The dispersed pointer list, as with small values, has poor locality.
3273,3274c3272,3273
< The next test measures the time needed to complete calls the member function
< `sort(Pred pred)`. Values (`test_class` and `itest_class`) and lists are created like explained in the
---
> The next test measures the time needed to complete calls to the member function
> `sort(Pred pred)`. Values (`test_class` and `itest_class`) and lists are created as explained in the
3301c3300
< another container to compare to elements.
---
> another container to compare two elements.
3338,3341c3337,3340
< indirection that needs to access the value is minimized because all the values
< are tightly stored, improving cache. The disperse list, on the other hand, is
< slower because the indirection to access to values stored in the object list is
< more expensive than the access to values stored in a vector.
---
> indirection that is needed to access the value is minimized because all the values
> are tightly stored, improving caching. The disperse list, on the other hand, is
> slower because the indirection to access values stored in the object list is
> more expensive than accessing values stored in a vector.
3347c3346
< The next test measures the time needed to iterate all the elements of a list, and
---
> The next test measures the time needed to iterate through all the elements of a list, and
3356c3355
< Values (`test_class` and `itest_class`) and lists are created like explained in
---
> Values (`test_class` and `itest_class`) and lists are created as explained in
3399c3398
< Like with the read access test, the results show that intrusive containers outperform
---
> As with the read access test, the results show that intrusive containers outperform
3401c3400
< The disperse list is again the slowest one.
---
> The disperse list is again the slowest.
3409c3408
< when objects to be inserted are small. Minimizing memory allocation/deallocation calls is also
---
> when the objects to be inserted are small. Minimizing memory allocation/deallocation calls is also
3434c3433
< [*Boost.Intrusive] has been tested in the following compilers/platforms:
---
> [*Boost.Intrusive] has been tested on the following compilers/platforms:
3451c3450
<    [*Boost.Intrusive] is based on STL concepts and interface.
---
>    [*Boost.Intrusive] is based on STL concepts and interfaces.
3485c3484
< *  Thanks to of [*Julienne Walker] and [*The EC Team] ([@http://eternallyconfuzzled.com])
---
> *  Thanks to [*Julienne Walker] and [*The EC Team] ([@http://eternallyconfuzzled.com])