From patchwork Fri Dec 30 13:46:20 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jonathan Wakely X-Patchwork-Id: 133644 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 785F2B6FBE for ; Sat, 31 Dec 2011 00:46:51 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1325857612; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:Date:Message-ID:Subject:From:To: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=BJGizV8 MhyGCKiIwKYkBAs+C+uc=; b=cLhgmU2q3hDEyHpp97WADL857ue59MsMywJfr1r w78zBcC95L66uxktR18Eo71LmwDN9UO2wSpRQOU8nmKNMg1jA7NjhIetD79VnhHJ ezvHaAshDyB3V2ggadZJCeqryLjmqVYbOJ3Ar9fLroi1KcPpJf9VEv0viYNvojsq cdh8= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:MIME-Version:Received:Received:Date:Message-ID:Subject:From:To:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=jvDQU5bePuPdZRWKPAI0ehi6CFjpixWBhNGj5LsupzIdW52Iy77B3hY+4tX0Z/ hZK554H+Zgnq07Ecu4xsDstVsmJqgACAgDWVmUwWHfddwSv12wMSfCMllspVbN9k yVxADeKO77/SXYzz77aH0ILZRem3pQeyWa9bLudowU/O4=; Received: (qmail 28579 invoked by alias); 30 Dec 2011 13:46:41 -0000 Received: (qmail 28558 invoked by uid 22791); 30 Dec 2011 13:46:38 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Dec 2011 13:46:22 +0000 Received: by wgbdr1 with SMTP id dr1so21276356wgb.8 for ; Fri, 30 Dec 2011 05:46:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.60.82 with SMTP id o18mr30239096wbh.0.1325252780566; Fri, 30 Dec 2011 05:46:20 -0800 (PST) Received: by 10.216.28.194 with HTTP; Fri, 30 Dec 2011 05:46:20 -0800 (PST) Date: Fri, 30 Dec 2011 13:46:20 +0000 Message-ID: Subject: [v3] doc updates From: Jonathan Wakely To: "libstdc++" , gcc-patches Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org * doc/xml/manual/extensions.xml: Improve markup and note that some extensions are included in C++11. * doc/xml/manual/concurrency_extensions.xml: Likewise. Tested with 'make doc-xml-validate-docbook doc-html-docbook' Committed to trunk Index: doc/xml/manual/extensions.xml =================================================================== --- doc/xml/manual/extensions.xml (revision 182724) +++ doc/xml/manual/extensions.xml (working copy) @@ -160,7 +160,7 @@ extensions, be aware of two things: There are versions of single-bit test, set, reset, and flip member functions which do no range-checking. If we call them member functions of an instantiation - of "bitset<N>," then their names and signatures are: + of bitset<N>, then their names and signatures are: bitset<N>& _Unchecked_set (size_t pos); @@ -173,14 +173,10 @@ extensions, be aware of two things: no present plans to do so (and there doesn't seem to be any immediate reason to). -The semantics of member function operator[] are not specified - in the C++ standard. A long-standing defect report calls for sensible - obvious semantics, which are already implemented here: op[] - on a const bitset returns a bool, and for a non-const bitset returns a - reference (a nested type). However, this implementation does - no range-checking on the index argument, which is in keeping with other - containers' op[] requirements. The defect report's proposed - resolution calls for range-checking to be done. We'll just wait and see... +The member function operator[] on a const bitset returns + a bool, and for a non-const bitset returns a reference (a + nested type). No range-checking is done on the index argument, in keeping + with other containers' operator[] requirements. Finally, two additional searching functions have been added. They return the index of the first "on" bit, and the index of the first @@ -214,16 +210,20 @@ extensions, be aware of two things: <rb_tree> are all here; - <hash_map> and <hash_set> + <backwards/hash_map> and + <backwards/hash_set> are deprecated but available as backwards-compatible extensions, - as discussed further below. <rope> is the - SGI specialization for large strings ("rope," - "large strings," get it? Love that geeky humor.) - <slist> is a singly-linked list, for when the - doubly-linked list<> is too much space - overhead, and <rb_tree> exposes the red-black - tree classes used in the implementation of the standard maps and - sets. + as discussed further below. + <ext/rope> is the SGI + specialization for large strings ("rope," "large strings," get it? Love + that geeky humor.) + <ext/slist> (superseded in + C++11 by <forward_list>) + is a singly-linked list, for when the doubly-linked list<> + is too much space overhead, and + <ext/rb_tree> exposes the + red-black tree classes used in the implementation of the standard maps + and sets. Each of the associative containers map, multimap, set, and multiset have a counterpart which uses a @@ -256,6 +256,13 @@ extensions, be aware of two things: + + The deprecated hash tables are superseded by the standard unordered + associative containers defined in the ISO C++ 2011 standard in the + headers <unordered_map> + and <unordered_set>. + + @@ -264,36 +271,37 @@ extensions, be aware of two things: - The <functional> header contains many additional functors + The <functional> header + contains many additional functors and helper functions, extending section 20.3. They are implemented in the file stl_function.h: - identity_element for addition and multiplication. * + identity_element for addition and multiplication. The functor identity, whose operator() - returns the argument unchanged. * + returns the argument unchanged. Composition functors unary_function and binary_function, and their helpers compose1 - and compose2. * + and compose2. - select1st and select2nd, to strip pairs. * + select1st and select2nd, to strip pairs. - project1st and project2nd. * + project1st and project2nd. A set of functors/functions which always return the same result. They are constant_void_fun, constant_binary_fun, constant_unary_fun, constant0, - constant1, and constant2. * - The class subtractive_rng. * + constant1, and constant2. + The class subtractive_rng. mem_fun adaptor helpers mem_fun1 and mem_fun1_ref are provided for backwards compatibility. @@ -320,11 +328,11 @@ you can also use get_temporary_buffer(5, (int*)0); - A class temporary_buffer is given in stl_tempbuf.h. * + A class temporary_buffer is given in stl_tempbuf.h. The specialized algorithms of section 20.4.4 are extended with - uninitialized_copy_n. * + uninitialized_copy_n. @@ -371,25 +379,30 @@ get_temporary_buffer(5, (int*)0); Numerics -26.4, the generalized numeric operations such as accumulate, are extended - with the following functions: +26.4, the generalized numeric operations such as accumulate, + are extended with the following functions: power (x, n); - power (x, n, moniod_operation); -Returns, in FORTRAN syntax, "x ** n" where n>=0. In the - case of n == 0, returns the identity element for the + power (x, n, monoid_operation); +Returns, in FORTRAN syntax, "x ** n" where + n >= 0. In the + case of n == 0, returns the identity element for the monoid operation. The two-argument signature uses multiplication (for a true "power" implementation), but addition is supported as well. The operation functor must be associative. The iota function wins the award for Extension With the - Coolest Name. It "assigns sequentially increasing values to a range. - That is, it assigns value to *first, value + 1 to *(first + 1) and so - on." Quoted from SGI documentation. + Coolest Name (the name comes from Ken Iverson's APL language.) As + described in the SGI + documentation, it "assigns sequentially increasing values to a range. + That is, it assigns value to *first, + value + 1 to *(first + 1) and so on." void iota(_ForwardIter first, _ForwardIter last, _Tp value); +The iota function is included in the ISO C++ 2011 standard. + Index: doc/xml/manual/concurrency_extensions.xml =================================================================== --- doc/xml/manual/concurrency_extensions.xml (revision 182661) +++ doc/xml/manual/concurrency_extensions.xml (working copy) @@ -21,7 +21,8 @@
Interface to Locks and Mutexes -The file <ext/concurrence.h> contains all the higher-level +The file <ext/concurrence.h> +contains all the higher-level constructs for playing with threads. In contrast to the atomics layer, the concurrence layer consists largely of types. All types are defined within namespace __gnu_cxx. @@ -65,14 +66,14 @@ host environment and the current compila interface: __mutex, and __scoped_lock. - - - The scoped lock idiom is well-discussed within the C++ community. This version takes a __mutex reference, and -locks it during construction of __scoped_locke and +locks it during construction of __scoped_lock and unlocks it during destruction. This is an efficient way of locking critical sections, while retaining exception-safety. +These types have been superseded in the ISO C++ 2011 standard by the +mutex and lock types defined in the header +<mutex>.