From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17817 invoked by alias); 23 Mar 2008 19:21:15 -0000 Received: (qmail 17794 invoked by uid 22791); 23 Mar 2008 19:21:13 -0000 X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 23 Mar 2008 19:20:43 +0000 Received: from Relay1.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 7EEA53E1DD; Sun, 23 Mar 2008 20:20:40 +0100 (CET) Message-ID: <47E6AD83.3090904@suse.de> Date: Sun, 23 Mar 2008 20:59:00 -0000 From: Paolo Carlini User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Gerald Pfeifer Cc: libstdc++@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: http://gcc.gnu.org/onlinedocs/libstdc++/ needs a bit of help References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------050605070303040904090207" X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2008-03/txt/msg00933.txt.bz2 This is a multi-part message in MIME format. --------------050605070303040904090207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 354 Hi Gerald, > Working on the link consistency of the http://gcc.gnu.org, I ran into > a couple of links on the libstdc++ side that are in need of a bit love. > It would be great could one of you libstdc++ guys look into those. > Should be all fixed with the below, applied mainline and 4_3-branch. Thanks for the heads up! Paolo. /////////////////// --------------050605070303040904090207 Content-Type: text/plain; name="CL_doc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="CL_doc" Content-length: 280 2008-03-23 Paolo Carlini * doc/xml/faq.xml: Fix various links. * doc/xml/api.xml: Likewise. * doc/xml/manual/parallel_mode.xml: Likewise. * doc/html/faq.html: Regenerate. * doc/html/api.html: Likewise. * doc/html/manual/bk01pt12ch31s03.html: Likewise. --------------050605070303040904090207 Content-Type: text/plain; name="patch_doc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch_doc" Content-length: 5587 Index: doc/xml/faq.xml =================================================================== --- doc/xml/faq.xml (revision 133462) +++ doc/xml/faq.xml (working copy) @@ -130,8 +130,8 @@ - Here is a page devoted to - this topic. Subscribing to the mailing list (see above, or + Here is a page devoted to + this topic. Subscribing to the mailing list (see above, or the homepage) is a very good idea if you have something to contribute, or if you have spare time and want to help. Contributions don't have to be in the form of source code; @@ -400,7 +400,7 @@ If the only functions from libstdc++.a which you need are language support functions (those listed in - clause 18 of the + clause 18 of the standard, e.g., new and delete), then try linking against libsupc++.a, which is a subset of @@ -785,13 +785,13 @@ reason is that the state flags are not cleared on a successful call to open(). The standard unfortunately did not specify behavior in this case, and to everybody's great sorrow, - the proposed LWG resolution in - DR #22 is to leave the flags unchanged. You must insert a call + the proposed LWG resolution in + DR #22 is to leave the flags unchanged. You must insert a call to fs.clear() between the calls to close() and open(), and then everything will work like we all expect it to work. Update: for GCC 4.0 we implemented the resolution - of DR #409 and open() now calls - clear() on success! + of DR #409 and open() + now calls clear() on success! @@ -895,7 +895,7 @@ More information, including how to optionally enable/disable the checks, is available - here. + here. @@ -940,13 +940,13 @@ A few people have reported that the standard containers appear to leak memory when tested with memory checkers such as - valgrind. + valgrind. The library's default allocators keep free memory in a pool for later reuse, rather than returning it to the OS. Although this memory is always reachable by the library and is never lost, memory debugging tools can report it as a leak. If you want to test the library for memory leaks please read - Tips for memory leak hunting + Tips for memory leak hunting first. @@ -961,7 +961,7 @@ See - the Containers + the Containers chapter. @@ -981,7 +981,7 @@ patches that covers the procedure, but for libstdc++ you should also send the patch to our mailing list in addition to the GCC patches mailing list. The libstdc++ - contributors' page + contributors' page also talks about how to submit patches. @@ -1237,8 +1237,8 @@ The copy will take O(n) time and the swap is constant time. - See Shrink-to-fit - strings for a similar solution for strings. + See Shrink-to-fit + strings for a similar solution for strings. Index: doc/xml/api.xml =================================================================== --- doc/xml/api.xml (revision 133462) +++ doc/xml/api.xml (working copy) @@ -15,7 +15,7 @@ 2008 - FSF + FSF Index: doc/xml/manual/parallel_mode.xml =================================================================== --- doc/xml/manual/parallel_mode.xml (revision 133462) +++ doc/xml/manual/parallel_mode.xml (working copy) @@ -116,7 +116,7 @@ To use the libstdc++ parallel mode, compile your application with the compiler flag -D_GLIBCXX_PARALLEL -fopenmp. This - will link in libgomp, the GNU OpenMP implementation, + will link in libgomp, the GNU OpenMP implementation, whose presence is mandatory. In addition, hardware capable of atomic operations is mandatory. Actually activating these atomic operations may require explicit compiler flags on some targets --------------050605070303040904090207--