Replace all www.sgi.com/tech/stl URLs with www.boost.org/sgi/stl

Also switch http:// to https:// to avoid redirects.

Author: jwakely

xml/issue0498.xml

@@ -16,9 +16,9 @@ The iterator requirements for partition() and stable_partition() [25.2.12]
 are listed as BidirectionalIterator, however, there are efficient algorithms
 for these functions that only require ForwardIterator that have been known
 since before the standard existed. The SGI implementation includes these (see
-<a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
+<a href="https://www.boost.org/sgi/stl/partition.html">https://www.boost.org/sgi/stl/partition.html</a>
 and
-<a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
+<a href="https://www.boost.org/sgi/stl/stable_partition.html">https://www.boost.org/sgi/stl/stable_partition.html</a>).
 </p>
 
 <note>

xml/issue1213.xml

@@ -43,7 +43,7 @@ First, issue <iref ref="208"/> intentionally removed the earlier constraint that
 values are always non-singular. The reason for this was to support null
 pointers as past-the-end iterators of e.g. empty sequences. But there
 seem to exist different views on what a singular (iterator) value is. E.g.
-according to the <a href="http://www.sgi.com/tech/stl/trivial.html">SGI definition</a>
+according to the <a href="https://www.boost.org/sgi/stl/trivial.html">SGI definition</a>
 a null pointer is <em>not</em> a singular value:
 </p>
 
@@ -55,7 +55,7 @@ involving null pointers) even thought it is not dereferenceable.
 </p></blockquote>
 
 <p>
-and <a href="http://www.sgi.com/tech/stl/InputIterator.html">proceeds</a>:
+and <a href="https://www.boost.org/sgi/stl/InputIterator.html">proceeds</a>:
 </p>
 
 <blockquote><p>

xml/issue1290.xml

@@ -43,10 +43,10 @@ struct binary_function {
 which <i>may</i> be used as base classes (similarly to the iterator template),
 but were originally <i>not</i> intended as a customization point. The SGI
 documentation introduced the concept 
-<a href="http://www.sgi.com/tech/stl/AdaptableUnaryFunction.html">Adaptable Unary
+<a href="https://www.boost.org/sgi/stl/AdaptableUnaryFunction.html">Adaptable Unary
 Function</a> as function objects "with nested typedefs that define its argument
 type and result type" and a similar definition for 
-<a href="http://www.sgi.com/tech/stl/AdaptableBinaryFunction.html">Adaptable Binary
+<a href="https://www.boost.org/sgi/stl/AdaptableBinaryFunction.html">Adaptable Binary
 Function</a> related to <tt>binary_function</tt>. But as of TR1 a protocol was
 introduced that relies on inheritance relations based on these types. <sref
 ref="[refwrap]"/>/3 b. 3 requires that a specialization of

xml/issue1332.xml

@@ -63,7 +63,7 @@ The new definition goes beyond the original hash requirements as specified
 by SGI library in regard to the exception requirement:
 </p>
 <blockquote><p>
-<a href="http://www.sgi.com/tech/stl/HashFunction.html">http://www.sgi.com/tech/stl/HashFunction.html</a>
+<a href="https://www.boost.org/sgi/stl/HashFunction.html">https://www.boost.org/sgi/stl/HashFunction.html</a>
 </p></blockquote>
 </li>
 

xml/issue2035.xml

@@ -41,7 +41,7 @@ ones without semantics:
 *r++ = o // output iterator
 *r--     // bidirectional iterator
 </pre></blockquote><p>
-According to the <a href="http://www.sgi.com/tech/stl/OutputIterator.html">SGI specification</a>
+According to the <a href="https://www.boost.org/sgi/stl/OutputIterator.html">SGI specification</a>
 these correspond to
 </p><blockquote><pre>
 { *r = o; ++r; }                         // output iterator
@@ -280,7 +280,7 @@ that are not associated with any sequence. [&hellip;]
 <sref ref="[input.iterators]"/>, as indicated [<i>Rationale</i>: The wording changes attempt
 to define a minimal "independent" set of operations, namely <tt>*a</tt> and <tt>++r</tt>, and 
 to specify the semantics of the remaining ones. This approach seems to be in agreement with the 
-original <a href="http://www.sgi.com/tech/stl/InputIterator.html">SGI specification</a> 
+original <a href="https://www.boost.org/sgi/stl/InputIterator.html">SGI specification</a>
 &mdash; <i>end rationale</i>]:</p>
 
 <blockquote>
@@ -366,7 +366,7 @@ return tmp; }
 <sref ref="[output.iterators]"/>, as indicated [<i>Rationale</i>: The wording changes attempt
 to define a minimal "independent" set of operations, namely <tt>*r = o</tt> and <tt>++r</tt>,
 and to specify the semantics of the remaining ones. This approach seems to be in agreement with
-the original <a href="http://www.sgi.com/tech/stl/OutputIterator.html">SGI specification</a> 
+the original <a href="https://www.boost.org/sgi/stl/OutputIterator.html">SGI specification</a>
 &mdash; <i>end rationale</i>]:</p>
 
 <blockquote>

xml/issue2072.xml

@@ -29,7 +29,7 @@ or a pair of 0 values if no storage can be obtained or if <tt>n &lt;= 0</tt>.
 I read this as prohibiting to return a buffer of which capacity is less than <tt>n</tt>, because 
 such a buffer is not sufficient to store <tt>n</tt> objects.
 <p/>
-The corresponding description in <a href="http://www.sgi.com/tech/stl/get_temporary_buffer.html">SGI STL</a> 
+The corresponding description in <a href="https://www.boost.org/sgi/stl/get_temporary_buffer.html">SGI STL</a>
 is clear on this point, but I think it is a bit too verbose:
 </p>
 

xml/issue2114.xml

@@ -94,7 +94,7 @@ e.g. <sref ref="[alg.find]"/> p2, which talks about "<tt>pred(*i) != false</tt>"
 While we could simply fix all these places by proper wording to be considered in a "contextual conversion to
 <tt>bool</tt>", I think that this is not the correct solution: Many third-party libraries already refer to
 the previous C++03 <tt>Predicate</tt> definition &mdash; it actually predates C++98 and is as old as the 
-<a href="http://www.sgi.com/tech/stl/Predicate.html">SGI specification</a>. It seems to be a high price to
+<a href="https://www.boost.org/sgi/stl/Predicate.html">SGI specification</a>. It seems to be a high price to
 pay to switch to direct initialization here instead of fixing a completely different specification problem.
 <p/>
 A final observation is that we have another definition for a <tt>Predicate</tt> in <sref ref="[thread.req.paramname]"/> p2:

xml/issue2417.xml

@@ -28,7 +28,7 @@ requirements (see <iref ref="2114"/>) for the result type of <tt>T</tt>'s <tt>op
 <p/>
 Arguably, corresponding operators for <tt>pair</tt> and <tt>tuple</tt> do not impose <tt>LessThanComparable</tt> (nor
 <tt>EqualityComparable</tt>), albeit the definition of the "derived" relation functions depend on properties ensured by
-<tt>LessThanComparable</tt>. According to the <a href="https://www.sgi.com/tech/stl/pair.html">SGI definition</a>, the intention was
+<tt>LessThanComparable</tt>. According to the <a href="https://www.boost.org/sgi/stl/pair.html">SGI definition</a>, the intention was
 to imposed both <tt>EqualityComparable</tt> and <tt>LessThanComparable</tt>. If this is not intended, the standard should clarify
 this position.
 </p>

xml/issue2448.xml

@@ -23,7 +23,7 @@ The initial "note:" can be read as if that part of the specification would not b
 differs from footnotes in tables, which have normative meaning).
 <p/>
 It seems that this initial part of the specification exists since C++98. But comparing with
-the similar <a href="https://www.sgi.com/tech/stl/Container.html">SGI Container specification</a> there is no evidence
+the similar <a href="https://www.boost.org/sgi/stl/Container.html">SGI Container specification</a> there is no evidence
 for that being intended to be non-normative.
 </p>