fixed relative links in docs

Author: joaquintides

doc/modules/ROOT/pages/changes.adoc

@@ -406,7 +406,7 @@ future version.
 
 == Release 1.38.0
 
-* Use link:../../../core/swap.html[`boost::swap`^].
+* Use link:../../../../core/swap.html[`boost::swap`^].
 * {svn-ticket-url}/2237[Ticket 2237^]:
   Document that the equality and inequality operators are undefined for two
   objects if their equality predicates aren't equivalent. Thanks to Daniel
@@ -415,7 +415,7 @@ future version.
   Use a larger prime number list. Thanks to Thorsten Ottosen and Hervé
   Brönnimann.
 * Use
-  link:../../../type_traits/index.html[aligned storage^] to store the types.
+  link:../../../../type_traits/index.html[aligned storage^] to store the types.
   This changes the way the allocator is used to construct nodes. It used to
   construct the node with two calls to the allocator's `construct`
   method - once for the pointers and once for the value. It now constructs

doc/modules/ROOT/pages/hash_equality.adoc

@@ -27,7 +27,7 @@ boost::unordered_map<std::string, int, hash::fnv_1a>
     dictionary;
 ```
 
-There is an link:../../examples/fnv1.hpp[implementation of FNV-1a^] in the examples directory.
+There is an link:../../../examples/fnv1.hpp[implementation of FNV-1a^] in the examples directory.
 
 If you wish to use a different equality function, you will also need to use a matching hash function. For example, to implement a case insensitive dictionary you need to define a case insensitive equality predicate and hash function:
 
@@ -66,7 +66,7 @@ boost::unordered_map<std::string, int, ihash, iequal_to>
 ```
 
 This is a simplified version of the example at
-link:../../examples/case_insensitive.hpp[/libs/unordered/examples/case_insensitive.hpp^] which supports other locales and string types.
+link:../../../examples/case_insensitive.hpp[/libs/unordered/examples/case_insensitive.hpp^] which supports other locales and string types.
 
 CAUTION: Be careful when using the equality (`==`) operator with custom equality
 predicates, especially if you're using a function pointer. If you compare two
@@ -105,7 +105,7 @@ struct point_hash
 boost::unordered_multiset<point, point_hash> points;
 ```
 
-Since the default hash function is link:../../../container_hash/index.html[Boost.Hash^],
+Since the default hash function is link:../../../../container_hash/index.html[Boost.Hash^],
 we can extend it to support the type so that the hash function doesn't need to be explicitly given:
 
 ```cpp
@@ -130,7 +130,7 @@ std::size_t hash_value(point const& p) {
 boost::unordered_multiset<point> points;
 ```
 
-See the link:../../../container_hash/index.html[Boost.Hash documentation^] for more detail on how to
+See the link:../../../../container_hash/index.html[Boost.Hash documentation^] for more detail on how to
 do this. Remember that it relies on extensions to the standard - so it
 won't work for other implementations of the unordered associative containers,
 you'll need to explicitly use Boost.Hash.

doc/modules/ROOT/pages/hash_quality.adoc

@@ -13,7 +13,7 @@ Closed-addressing containers in Boost.Unordered are fairly robust against
 hash functions with less-than-ideal quality, but open-addressing and concurrent
 containers are much more sensitive to this factor, and their performance can
 degrade dramatically if the hash function is not appropriate. In general, if
-you're using functions provided by or generated with link:../../../container_hash/index.html[Boost.Hash^],
+you're using functions provided by or generated with link:../../../../container_hash/index.html[Boost.Hash^],
 the quality will be adequate, but you have to be careful when using alternative
 hash algorithms.
 
@@ -116,7 +116,7 @@ If the hash function behaves properly:
 just the element found is checked).
 * The average number of comparisons per unsuccessful lookup should be close to 0.0.
 
-An link:../../benchmark/string_stats.cpp[example^] is provided that displays container
+An link:../../../benchmark/string_stats.cpp[example^] is provided that displays container
 statistics for `boost::hash<std::string>`, an implementation of the
 https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#FNV-1a_hash[FNV-1a hash^]
 and two ill-behaved custom hash functions that have been incorrectly marked as avalanching:

doc/modules/ROOT/pages/intro.adoc

@@ -92,7 +92,7 @@ Storing an object in an unordered associative container requires both a
 key equality function and a hash function. The default function objects in
 the standard containers support a few basic types including integer types,
 floating point types, pointer types, and the standard strings. Since
-Boost.Unordered uses link:../../../container_hash/index.html[boost::hash^] it also supports some other types,
+Boost.Unordered uses link:../../../../container_hash/index.html[boost::hash^] it also supports some other types,
 including standard containers. To use any types not supported by these methods
 you have to extend Boost.Hash to support the type or use
 your own custom equality predicates and hash functions. See the

doc/modules/ROOT/pages/reference/concurrent_flat_map.adoc

@@ -419,7 +419,7 @@ if concurrent outstanding operations on `y` do not access `x` directly or indire
 ==== `BOOST_UNORDERED_DISABLE_REENTRANCY_CHECK`
 
 In debug builds (more precisely, when
-link:../../../assert/doc/html/assert.html#boost_assert_is_void[`BOOST_ASSERT_IS_VOID`^]
+link:../../../../../assert/doc/html/assert.html#boost_assert_is_void[`BOOST_ASSERT_IS_VOID`^]
 is not defined), __container reentrancies__ (illegaly invoking an operation on `m` from within
 a function visiting elements of `m`) are detected and signalled through `BOOST_ASSERT_MSG`.
 When run-time speed is a concern, the feature can be disabled by globally defining
@@ -1805,7 +1805,7 @@ c.xref:#concurrent_flat_map_erase_if[erase_if](pred);
 === Serialization
 
 ``concurrent_flat_map``s can be archived/retrieved by means of
-link:../../../serialization/index.html[Boost.Serialization^] using the API provided
+link:../../../../../serialization/index.html[Boost.Serialization^] using the API provided
 by this library. Both regular and XML archives are supported.
 
 ==== Saving an concurrent_flat_map to an archive

doc/modules/ROOT/pages/reference/concurrent_flat_set.adoc

@@ -366,7 +366,7 @@ if concurrent outstanding operations on `y` do not access `x` directly or indire
 ==== `BOOST_UNORDERED_DISABLE_REENTRANCY_CHECK`
 
 In debug builds (more precisely, when
-link:../../../assert/doc/html/assert.html#boost_assert_is_void[`BOOST_ASSERT_IS_VOID`^]
+link:../../../../../assert/doc/html/assert.html#boost_assert_is_void[`BOOST_ASSERT_IS_VOID`^]
 is not defined), __container reentrancies__ (illegaly invoking an operation on `m` from within
 a function visiting elements of `m`) are detected and signalled through `BOOST_ASSERT_MSG`.
 When run-time speed is a concern, the feature can be disabled by globally defining
@@ -1581,7 +1581,7 @@ c.xref:#concurrent_flat_set_erase_if[erase_if](pred);
 === Serialization
 
 ``concurrent_flat_set``s can be archived/retrieved by means of
-link:../../../serialization/index.html[Boost.Serialization^] using the API provided
+link:../../../../../serialization/index.html[Boost.Serialization^] using the API provided
 by this library. Both regular and XML archives are supported.
 
 ==== Saving an concurrent_flat_set to an archive

doc/modules/ROOT/pages/reference/concurrent_node_map.adoc

@@ -436,7 +436,7 @@ if concurrent outstanding operations on `y` do not access `x` directly or indire
 ==== `BOOST_UNORDERED_DISABLE_REENTRANCY_CHECK`
 
 In debug builds (more precisely, when
-link:../../../assert/doc/html/assert.html#boost_assert_is_void[`BOOST_ASSERT_IS_VOID`^]
+link:../../../../../assert/doc/html/assert.html#boost_assert_is_void[`BOOST_ASSERT_IS_VOID`^]
 is not defined), __container reentrancies__ (illegaly invoking an operation on `m` from within
 a function visiting elements of `m`) are detected and signalled through `BOOST_ASSERT_MSG`.
 When run-time speed is a concern, the feature can be disabled by globally defining
@@ -1921,7 +1921,7 @@ c.xref:#concurrent_node_map_erase_if[erase_if](pred);
 === Serialization
 
 ``concurrent_node_map``s can be archived/retrieved by means of
-link:../../../serialization/index.html[Boost.Serialization^] using the API provided
+link:../../../../../serialization/index.html[Boost.Serialization^] using the API provided
 by this library. Both regular and XML archives are supported.
 
 ==== Saving an concurrent_node_map to an archive

doc/modules/ROOT/pages/reference/concurrent_node_set.adoc

@@ -383,7 +383,7 @@ if concurrent outstanding operations on `y` do not access `x` directly or indire
 ==== `BOOST_UNORDERED_DISABLE_REENTRANCY_CHECK`
 
 In debug builds (more precisely, when
-link:../../../assert/doc/html/assert.html#boost_assert_is_void[`BOOST_ASSERT_IS_VOID`^]
+link:../../../../../assert/doc/html/assert.html#boost_assert_is_void[`BOOST_ASSERT_IS_VOID`^]
 is not defined), __container reentrancies__ (illegaly invoking an operation on `m` from within
 a function visiting elements of `m`) are detected and signalled through `BOOST_ASSERT_MSG`.
 When run-time speed is a concern, the feature can be disabled by globally defining
@@ -1704,7 +1704,7 @@ c.xref:#concurrent_node_set_erase_if[erase_if](pred);
 === Serialization
 
 ``concurrent_node_set``s can be archived/retrieved by means of
-link:../../../serialization/index.html[Boost.Serialization^] using the API provided
+link:../../../../../serialization/index.html[Boost.Serialization^] using the API provided
 by this library. Both regular and XML archives are supported.
 
 ==== Saving an concurrent_node_set to an archive

doc/modules/ROOT/pages/reference/unordered_flat_map.adoc

@@ -1507,7 +1507,7 @@ return original_size - c.size();
 === Serialization
 
 ``unordered_flat_map``s can be archived/retrieved by means of
-link:../../../serialization/index.html[Boost.Serialization^] using the API provided
+link:../../../../../serialization/index.html[Boost.Serialization^] using the API provided
 by this library. Both regular and XML archives are supported.
 
 ==== Saving an unordered_flat_map to an archive

doc/modules/ROOT/pages/reference/unordered_flat_set.adoc

@@ -1256,7 +1256,7 @@ return original_size - c.size();
 === Serialization
 
 ``unordered_flat_set``s can be archived/retrieved by means of
-link:../../../serialization/index.html[Boost.Serialization^] using the API provided
+link:../../../../../serialization/index.html[Boost.Serialization^] using the API provided
 by this library. Both regular and XML archives are supported.
 
 ==== Saving an unordered_flat_set to an archive