Index: boost/multi_index/detail/auto_space.hpp =================================================================== --- boost/multi_index/detail/auto_space.hpp (revision 86199) +++ boost/multi_index/detail/auto_space.hpp (working copy) @@ -39,7 +39,7 @@ namespace detail{ * "of zero length", http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14176 * C++ Standard Library Defect Report List (Revision 28), issue 199 * "What does allocate(0) return?", - * http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#199 + * http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199 */ template > Index: boost/program_options/options_description.hpp =================================================================== --- boost/program_options/options_description.hpp (revision 86199) +++ boost/program_options/options_description.hpp (working copy) @@ -61,8 +61,8 @@ namespace program_options { Alas, derived->base conversion for auto_ptr does not really work, see - http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2000/n1232.pdf - http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#84 + http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2000/n1232.pdf + http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#84 So, we have to use plain old pointers. Besides, users are not expected to use the constructor directly. Index: boost/ptr_container/detail/static_move_ptr.hpp =================================================================== --- boost/ptr_container/detail/static_move_ptr.hpp (revision 86199) +++ boost/ptr_container/detail/static_move_ptr.hpp (working copy) @@ -5,7 +5,7 @@ // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt.) // Implementation of the move_ptr from the "Move Proposal" -// (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm) +// (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm) // enhanced to support custom deleters and safe boolean conversions. // // The implementation is based on an implementation by Daniel Wallin, at Index: boost/type_traits/is_abstract.hpp =================================================================== --- boost/type_traits/is_abstract.hpp (revision 86199) +++ boost/type_traits/is_abstract.hpp (working copy) @@ -19,7 +19,7 @@ // Compile type discovery whether given type is abstract class or not. // // Requires DR 337 to be supported by compiler -// (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#337). +// (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#337). // // // Believed (Jan 2004) to work on: Index: libs/array/doc/array.xml =================================================================== --- libs/array/doc/array.xml (revision 86199) +++ libs/array/doc/array.xml (working copy) @@ -77,7 +77,7 @@ Note that this class is suggested to be part of the next Technical Report, which will extend the C++ Standard (see - http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1548.htm). + http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1548.htm). Update: std::array is (as of C++11) part of the C++ standard. The differences between boost::array and std::array are minimal. Index: libs/assign/doc/index.html =================================================================== --- libs/assign/doc/index.html (revision 86199) +++ libs/assign/doc/index.html (working copy) @@ -1407,7 +1407,7 @@ support better initialization (see http://www.oonumerics.org/blitz/
  • Gabriel Dos Reis and Bjarne Stroustrup, - "Generalized Initializer + "Generalized Initializer Lists", 2003

    Index: libs/bimap/doc/bimap.qbk =================================================================== --- libs/bimap/doc/bimap.qbk (revision 86199) +++ libs/bimap/doc/bimap.qbk (working copy) @@ -121,7 +121,7 @@ Distributed under the Boost Software Lic [def __ORDER_STATISTICS_TREE__ [@http://pine.cs.yale.edu/pinewiki/OrderStatisticsTree ['order-statistics trees]]] [def __GENERIC_PROGRAMMING_MOVE_CONSTRUCTORS__ [@http://www.ddj.com/dept/cpp/184403855 "Generic: Move Constructors]] -[def __CLARIFICATION_OF_INITIALIZATION__ [@http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1610.html "Clarification of Initialization of Class Objects by rvalues"]] +[def __CLARIFICATION_OF_INITIALIZATION__ [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1610.html "Clarification of Initialization of Class Objects by rvalues"]] [/ Code snippets ] Index: libs/bind/bind.html =================================================================== --- libs/bind/bind.html (revision 86199) +++ libs/bind/bind.html (working copy) @@ -390,7 +390,7 @@ void connect()

    As a general rule, the function objects generated by bind take their arguments by reference and cannot, therefore, accept non-const temporaries or literal constants. This is an inherent limitation of the C++ language in its - current (2003) incarnation, known as + current (2003) incarnation, known as the forwarding problem. (It will be fixed in the next standard, usually called C++0x.)

    The library uses signatures of the form Index: libs/function_types/example/fast_mem_fn.hpp =================================================================== --- libs/function_types/example/fast_mem_fn.hpp (revision 86199) +++ libs/function_types/example/fast_mem_fn.hpp (working copy) @@ -62,7 +62,7 @@ // ============ // // [Dimov1] Dimov, P., Hinnant H., Abrahams, D. The Forwarding Problem -// http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm +// http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm // // [Dimov2] Dimov, P. Documentation of boost::mem_fn // http://www.boost.org/libs/bind/mem_fn.html Index: libs/function_types/example/result_of.hpp =================================================================== --- libs/function_types/example/result_of.hpp (revision 86199) +++ libs/function_types/example/result_of.hpp (working copy) @@ -26,7 +26,7 @@ // // [Gregor02] Gregor, D. A uniform method for computing function object return // types (revision 1) -// http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1454.html +// http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1454.html #include #include Index: libs/functional/binders.html =================================================================== --- libs/functional/binders.html (revision 86199) +++ libs/functional/binders.html (working copy) @@ -121,7 +121,7 @@ public: be std::ostream&&. Since you cannot have a reference to a reference, at this point we should get a compilation error because references to references are illegal in C++ (but see C++ + "http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#106">C++ Standard core language active issues list).

    The binders in this library avoid this problem by using the Boost Index: libs/functional/index.html =================================================================== --- libs/functional/index.html (revision 86199) +++ libs/functional/index.html (working copy) @@ -228,7 +228,7 @@ std::for_each(c.begin(), c.end(),

  • The Standard Committee has recognised the problem of references to references occurring during template instantiation and has moved to fix the standard (see the C++ + "http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#106">C++ standard core language active issues list).
    • Index: libs/functional/mem_fun.html =================================================================== --- libs/functional/mem_fun.html (revision 86199) +++ libs/functional/mem_fun.html (working copy) @@ -151,7 +151,7 @@ public: declaring the argument as const A&, then if A were a reference type, we would have a reference to a reference, which is currently illegal (but see C++ core + "http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#106">C++ core language issue number 106)

    So the way in which we want to declare the second argument for Index: libs/functional/negators.html =================================================================== --- libs/functional/negators.html (revision 86199) +++ libs/functional/negators.html (working copy) @@ -99,7 +99,7 @@ public:

    Note that if the Predicate's argument_type is a reference, the type of operator()'s argument would be a reference to a reference. Currently this is illegal in C++ (but see the C++ + "http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#106">C++ standard core language active issues list).

    However, if we instead defined operator() to accept Predicate's Index: libs/functional/ptr_fun.html =================================================================== --- libs/functional/ptr_fun.html (revision 86199) +++ libs/functional/ptr_fun.html (working copy) @@ -108,7 +108,7 @@ public: declaring the argument as const Arg&, then if Arg were a reference type, we would have a reference to a reference, which is currently illegal (but see C++ core + "http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#106">C++ core language issue number 106)

    So the way in which we want to declare the argument for Index: libs/fusion/doc/fusion.qbk =================================================================== --- libs/fusion/doc/fusion.qbk (revision 86199) +++ libs/fusion/doc/fusion.qbk (working copy) @@ -30,7 +30,7 @@ [def __mpl__ [@http://www.boost.org/libs/mpl/index.html MPL]] [def __stl__ [@http://en.wikipedia.org/wiki/Standard_Template_Library STL]] [def __tuple__ [@http://www.boost.org/libs/tuple/doc/tuple_users_guide.html Boost.Tuple]] -[def __tr1__tuple__ [@http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1403.pdf TR1 Tuple]] +[def __tr1__tuple__ [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1403.pdf TR1 Tuple]] [def __boost_tools__ [@http://www.boost.org/tools/index.html Boost Tools]] [def __spirit_list__ [@https://lists.sourceforge.net/lists/listinfo/spirit-general Spirit Mailing List]] [def __spirit_general__ [@news://news.gmane.org/gmane.comp.spirit.general Spirit General NNTP news portal]] Index: libs/iostreams/doc/bibliography.html =================================================================== --- libs/iostreams/doc/bibliography.html (revision 86199) +++ libs/iostreams/doc/bibliography.html (working copy) @@ -45,7 +45,7 @@ [Dimov] - Dimov, P., Hinnant, H. and Abrahams, A. The Forwarding Problem: Arguments. C++ standards committe document N1385=02-0043, September, 2002. See http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm. + Dimov, P., Hinnant, H. and Abrahams, A. The Forwarding Problem: Arguments. C++ standards committe document N1385=02-0043, September, 2002. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm. [Egorushkin] Index: libs/iterator/doc/facade-and-adaptor.html =================================================================== --- libs/iterator/doc/facade-and-adaptor.html (revision 86199) +++ libs/iterator/doc/facade-and-adaptor.html (working copy) @@ -26,7 +26,7 @@ Lab, Zephyr Associates, Inc. Date: 2006-09-11 -Number:This is a revised version of N1530=03-0113, which was +Number:This is a revised version of N1530=03-0113, which was accepted for Technical Report 1 by the C++ standard committee's library working group. @@ -239,29 +239,29 @@ Iterator Concepts.

    Iterator Concepts

    This proposal is formulated in terms of the new iterator concepts -as proposed in n1550, since user-defined and especially adapted +as proposed in n1550, since user-defined and especially adapted iterators suffer from the well known categorization problems that are inherent to the current iterator categories.

    -

    This proposal does not strictly depend on proposal n1550, as there +

    This proposal does not strictly depend on proposal n1550, as there is a direct mapping between new and old categories. This proposal -could be reformulated using this mapping if n1550 was not accepted.

    +could be reformulated using this mapping if n1550 was not accepted.

    Interoperability

    The question of iterator interoperability is poorly addressed in the current standard. There are currently two defect reports that are concerned with interoperability issues.

    -

    Issue 179 concerns the fact that mutable container iterator types +

    Issue 179 concerns the fact that mutable container iterator types are only required to be convertible to the corresponding constant iterator types, but objects of these types are not required to interoperate in comparison or subtraction expressions. This situation is tedious in practice and out of line with the way built in types work. This proposal implements the proposed resolution to issue -179, as most standard library implementations do nowadays. In other +179, as most standard library implementations do nowadays. In other words, if an iterator type A has an implicit or user defined conversion to an iterator type B, the iterator types are interoperable and the usual set of operators are available.

    -

    Issue 280 concerns the current lack of interoperability between +

    Issue 280 concerns the current lack of interoperability between reverse iterator types. The proposed new reverse_iterator template fixes the issues raised in 280. It provides the desired interoperability without introducing unwanted overloads.

    @@ -422,8 +422,8 @@ member (e.g. p+n, which is destroyed when operator[] returns.

    Writable iterators built with iterator_facade implement the -semantics required by the preferred resolution to issue 299 and -adopted by proposal n1550: the result of p[n] is an object +semantics required by the preferred resolution to issue 299 and +adopted by proposal n1550: the result of p[n] is an object convertible to the iterator's value_type, and p[n] = x is equivalent to *(p + n) = x (Note: This result object may be implemented as a proxy containing a copy of p+n). This approach Index: libs/iterator/doc/facade-and-adaptor.pdf =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/pdf Index: libs/iterator/doc/facade-and-adaptor.rst =================================================================== --- libs/iterator/doc/facade-and-adaptor.rst (revision 86199) +++ libs/iterator/doc/facade-and-adaptor.rst (working copy) @@ -19,7 +19,7 @@ .. Version 1.9 of this ReStructuredText document corresponds to n1530_, the paper accepted by the LWG. -.. _n1530: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1530.html +.. _n1530: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1530.html :copyright: Copyright David Abrahams, Jeremy Siek, and Thomas Witt 2003. @@ -140,7 +140,7 @@ as proposed in n1550_, since user-define iterators suffer from the well known categorization problems that are inherent to the current iterator categories. -.. _n1550: http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1550.html +.. _n1550: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1550.htm This proposal does not strictly depend on proposal n1550_, as there is a direct mapping between new and old categories. This proposal @@ -169,8 +169,8 @@ reverse iterator types. The proposed new fixes the issues raised in 280. It provides the desired interoperability without introducing unwanted overloads. -.. _179: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#179 -.. _280: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#280 +.. _179: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179 +.. _280: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#280 Iterator Facade Index: libs/iterator/doc/issues.rst =================================================================== --- libs/iterator/doc/issues.rst (revision 86199) +++ libs/iterator/doc/issues.rst (working copy) @@ -3,7 +3,7 @@ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. _N1550: http://www.boost-consulting.com/writing/n1550.html -.. _N1530: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1530.html +.. _N1530: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1530.html :Author: David Abrahams and Jeremy Siek :Contact: dave@boost-consulting.com, jsiek@osl.iu.edu Index: libs/iterator/doc/iterator_facade.html =================================================================== --- libs/iterator/doc/iterator_facade.html (revision 86199) +++ libs/iterator/doc/iterator_facade.html (working copy) @@ -242,8 +242,8 @@ member (e.g. p+n, which is destroyed when operator[] returns.

    Writable iterators built with iterator_facade implement the -semantics required by the preferred resolution to issue 299 and -adopted by proposal n1550: the result of p[n] is an object +semantics required by the preferred resolution to issue 299 and +adopted by proposal n1550: the result of p[n] is an object convertible to the iterator's value_type, and p[n] = x is equivalent to *(p + n) = x (Note: This result object may be implemented as a proxy containing a copy of p+n). This approach Index: libs/iterator/doc/iterator_facade.pdf =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/pdf Index: libs/iterator/doc/iterator_facade_body.rst =================================================================== --- libs/iterator/doc/iterator_facade_body.rst (revision 86199) +++ libs/iterator/doc/iterator_facade_body.rst (working copy) @@ -167,9 +167,9 @@ the implementation of her iterator is fr class; it will hide the one supplied by ``iterator_facade`` from clients of her iterator. -.. _n1550: http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1550.html +.. _n1550: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1550.htm -.. _`issue 299`: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#299 +.. _`issue 299`: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299 .. _`operator arrow`: Index: libs/iterator/doc/new-iter-concepts.html =================================================================== --- libs/iterator/doc/new-iter-concepts.html (revision 86199) +++ libs/iterator/doc/new-iter-concepts.html (working copy) @@ -27,10 +27,10 @@ Lab, Zephyr Associates, Inc. Date: 2006-09-11 -Number:This is a revised version of n1550=03-0133, which was +Number:This is a revised version of n1550=03-0133, which was accepted for Technical Report 1 by the C++ standard committee's library working group. This proposal is a -revision of paper n1297, n1477, and n1531. +revision of paper n1297, n1477, and n1531. Copyright: Copyright David Abrahams, Jeremy Siek, and Thomas Witt @@ -127,12 +127,12 @@ requirements in the iterator categories. *i is convertible to T Forward Iterator -*i is T& (or const T& once issue 200 +*i is T& (or const T& once issue 200 is resolved) Random Access Iterator i[n] is convertible to T (also i[n] = t -is required for mutable iterators once issue 299 +is required for mutable iterators once issue 299 is resolved) @@ -141,7 +141,7 @@ is resolved) single hierarchy, many useful iterators can not be appropriately categorized. For example, vector<bool>::iterator is almost a random access iterator, but the return type is not bool& (see -issue 96 and Herb Sutter's paper J16/99-0008 = WG21 +issue 96 and Herb Sutter's paper J16/99-0008 = WG21 N1185). Therefore, the iterators of vector<bool> only meet the requirements of input iterator and output iterator. This is so nonintuitive that the C++ standard contradicts itself on this point. @@ -344,7 +344,7 @@ approach for specifying issue 299: operator[] is +matches the preferred resolution of issue 299: operator[] is only required to return something convertible to the value_type (for a Readable Iterator), and is required to support assignment i[n] = t (for a Writable Iterator).

    @@ -976,7 +976,7 @@ struct random_access_traversal_tag : bid

    Addition to [lib.iterator.traits]

    The is_readable_iterator class -template satisfies the UnaryTypeTrait requirements.

    +template satisfies the UnaryTypeTrait requirements.

    Given an iterator type X, is_readable_iterator<X>::value yields true if, for an object a of type X, *a is convertible to iterator_traits<X>::value_type, and false @@ -1007,7 +1007,7 @@ otherwise.

    Footnotes

    -

    The UnaryTypeTrait concept is defined in n1519; the LWG is +

    The UnaryTypeTrait concept is defined in n1519; the LWG is considering adding the requirement that specializations are derived from their nested ::type.

    int main() {}''') --> -

    Note that because of the forwarding problem, parameter::parameters::operator() +

    Note that because of the forwarding problem, parameter::parameters::operator() can't accept non-const rvalues.

    Index: libs/parameter/doc/index.rst =================================================================== --- libs/parameter/doc/index.rst (revision 86199) +++ libs/parameter/doc/index.rst (working copy) @@ -783,7 +783,7 @@ signatures. isolate ``depth_first_search`` in a namespace containing no types [#using]_, but suppose we *want* it to found via ADL? -__ http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#225 +__ http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225 It's usually a good idea to prevent functions from being considered for overload resolution when the passed argument types aren't @@ -1800,7 +1800,7 @@ its function call operator: Note that because of the `forwarding problem`_, ``parameter::parameters::operator()`` can't accept non-const rvalues. -.. _`forwarding problem`: http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm +.. _`forwarding problem`: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm Extracting Parameter Types ========================== Index: libs/ptr_container/doc/ptr_container.html =================================================================== --- libs/ptr_container/doc/ptr_container.html (revision 86199) +++ libs/ptr_container/doc/ptr_container.html (working copy) @@ -595,7 +595,7 @@ As of this writing both libraries are no [8]C++ Standard Library Closed Issues List (Revision 27), -Item 218, Algorithms do not use binary predicate objects for default comparisons. +Item 218, Algorithms do not use binary predicate objects for default comparisons. Index: libs/ptr_container/doc/ptr_container.rst =================================================================== --- libs/ptr_container/doc/ptr_container.rst (revision 86199) +++ libs/ptr_container/doc/ptr_container.rst (working copy) @@ -320,7 +320,7 @@ __ http://www.cuj.com/documents/s=7986/c .. [8] C++ Standard Library Closed Issues List (Revision 27), Item 218, `Algorithms do not use binary predicate objects for default comparisons`__. -__ http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#218 +__ http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#218 .. [9] C++ Standard Library Active Issues List (Revision 27), Item 226, `User supplied specializations or overloads of namespace std function templates`__. Index: libs/range/doc/boost_range.qbk =================================================================== --- libs/range/doc/boost_range.qbk (revision 86199) +++ libs/range/doc/boost_range.qbk (working copy) @@ -171,7 +171,7 @@ [def __metafunctions__ [@boost:/libs/mpl/doc/refmanual/metafunction.html metafunctions]] [def __concept_check__ [@boost:/libs/concept_check/index.html Boost Concept Check library]] [def __boost_array__ [@boost:/libs/array/index.html boost::array]] -[def __the_forwarding_problem__ [@http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm The Forwarding Problem]] +[def __the_forwarding_problem__ [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm The Forwarding Problem]] [def __sgi_inner_product__ [@http://www.sgi.com/tech/stl/inner_product.html inner_product]] [def __sgi_partial_sum__ [@http://www.sgi.com/tech/stl/partial_sum.html partial_sum]] Index: libs/smart_ptr/smart_ptr.htm =================================================================== --- libs/smart_ptr/smart_ptr.htm (revision 86199) +++ libs/smart_ptr/smart_ptr.htm (working copy) @@ -190,7 +190,7 @@ the full committee, counted_ptr was rejected and surprising transfer-of-ownership semantics were added to auto_ptr.

    References

    -

    [Col-94] Gregory Colvin, +

    [Col-94] Gregory Colvin, Exception Safe Smart Pointers, C++ committee document 94-168/N0555, July, 1994.

    [E&D-94] John R. Ellis & David L. Detlefs, Index: libs/utility/utility.htm =================================================================== --- libs/utility/utility.htm (revision 86199) +++ libs/utility/utility.htm (working copy) @@ -313,7 +313,7 @@ typedef boost::result_of< Technical Report, N1836, or, for motivation and design rationale, - the result_of proposal.

    + the result_ofproposal.

    Usage guidelines for boost::result_of

    Index: libs/utility/value_init.htm =================================================================== --- libs/utility/value_init.htm (revision 86199) +++ libs/utility/value_init.htm (working copy) @@ -159,10 +159,10 @@ the object shall be value-initialized (

    value-initialization

    The first Technical + href="http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html">Technical Corrigendum for the C++ Standard (TC1), whose draft was released to the public in November 2001, introduced Core + href="http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#178">Core Issue 178 (among many other issues, of course).

    That issue introduced the new concept of value-initialization Index: tools/boostbook/test/more/tests/libs/array.gold =================================================================== --- tools/boostbook/test/more/tests/libs/array.gold (revision 86199) +++ tools/boostbook/test/more/tests/libs/array.gold (working copy) @@ -54,7 +54,7 @@ Note that this class is suggested to be part of the next Technical Report, which will extend the C++ Standard (see - http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1548.htm). + http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1548.htm). Class array fulfills most but not all of the requirements of "reversible containers" (see Index: tools/boostbook/test/more/tests/libs/array.xml =================================================================== --- tools/boostbook/test/more/tests/libs/array.xml (revision 86199) +++ tools/boostbook/test/more/tests/libs/array.xml (working copy) @@ -75,7 +75,7 @@ Note that this class is suggested to be part of the next Technical Report, which will extend the C++ Standard (see - http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1548.htm). + http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1548.htm). Class array fulfills most but not all of the requirements of "reversible containers" (see