From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 5291F3948024 for ; Tue, 13 Apr 2021 15:38:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5291F3948024 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-499-r7PFffLiMniftXHVJTCtjw-1; Tue, 13 Apr 2021 11:38:00 -0400 X-MC-Unique: r7PFffLiMniftXHVJTCtjw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8B9F21006C83; Tue, 13 Apr 2021 15:37:59 +0000 (UTC) Received: from localhost (unknown [10.33.36.164]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0EC1719C46; Tue, 13 Apr 2021 15:37:58 +0000 (UTC) Date: Tue, 13 Apr 2021 16:37:58 +0100 From: Jonathan Wakely To: Jonathan Wakely Cc: Gerald Pfeifer , "gcc@gcc.gnu.org" , libstdc++ , gcc-patches@gcc.gnu.org Subject: Re: libstdc++-v3/doc/xml/manual/backwards_compatibility.xml Message-ID: <20210413153758.GM3008@redhat.com> References: <20210413153704.GL3008@redhat.com> MIME-Version: 1.0 In-Reply-To: <20210413153704.GL3008@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spam-Status: No, score=-14.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 15:38:26 -0000 On 13/04/21 16:37 +0100, Jonathan Wakely wrote: >On 13/04/21 16:19 +0100, Jonathan Wakely via Libstdc++ wrote: >>Sorry for the slow reply ... >> >>On Mon, 1 Feb 2021 at 22:59, Gerald Pfeifer wrote: >>> >>>I noticed this section on "Backwards Compatibility" in the libstdc++ >>>docs that talks about >>> >>> - glibc 2.0.x >>> - GCC 3.2 (August 2002) >>> - GCC 4.1 (February 2006) >>> >>>and links to "Migrating to GCC 4.1" and "Migration guide for GCC-3.2" >>>documents. >>> >>>Does this still make sense (and serve real users or developers) or >>>should this be trimmed quite a bit? >> >>Yeah, that (and a lot more) should be trimmed from the libstdc++ >>manual. It's just time consuming to do it. > >It turned out to be pretty easy in this case, as the ancient text was >so obviously useless now that it can just be ripped out. > >The remaining parts of the page should probably be evaluated too, but >at least the truly prehistoric stuff is gone with this patch. > >Pushed to trunk. Oops, I meant to change gcc@ to gcc-patches@ before sending, sorry for the noise on the main list. >commit 989e512f719a44fafca0030d7b8a1f5bf5f1baf7 >Author: Jonathan Wakely >Date: Tue Apr 13 16:30:16 2021 > > libstdc++: Remove outdated docs on libg++ and libstdc++-v2 > > The libstdc++-v3 manual doesn't need to document how to use its > predecessors. > > libstdc++-v3/ChangeLog: > > * doc/xml/manual/backwards_compatibility.xml: Remove porting > notes for libg++ and libstdc++-v2, and bibliography. > * doc/html/*: Regenerated. > >diff --git a/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml >index cce553380e1..6a4a5ccedfb 100644 >--- a/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml >+++ b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml >@@ -22,7 +22,7 @@ dinosaur. > > Some background: libg++ was designed and created when there was no > ISO standard to provide guidance. Classes like linked lists are now >-provided for by list<T> and do not need to be >+provided for by std::list<T> and do not need to be > created by genclass. (For that matter, templates exist > now and are well-supported, whereas genclass (mostly) predates them.) > >@@ -34,41 +34,13 @@ Committee couldn't include everything, and so a lot of those > obvious classes didn't get included. > > >-Known Issues include many of the limitations of its immediate ancestor. >- >-Portability notes and known implementation limitations are as follows. >- >-
No <code>ios_base</code> >- >- >- At least some older implementations don't have std::ios_base, so you should use std::ios::badbit, std::ios::failbit and std::ios::eofbit and std::ios::goodbit. >+That project is no longer maintained or supported, and the sources >+archived. For the desperate, the >+ftp.gnu.org >+server still has the libg++ source. > >
> >-
No <code>cout</code> in <filename class="headerfile"><ostream.h></filename>, no <code>cin</code> in <filename class="headerfile"><istream.h></filename> >- >- >- >- In earlier versions of the standard, >- <fstream.h>, >- <ostream.h> >- and <istream.h> >- used to define >- cout, cin and so on. ISO C++ specifies that one needs to include >- <iostream> >- explicitly to get the required definitions. >- >- Some include adjustment may be required. >- >-This project is no longer maintained or supported, and the sources >-archived. For the desperate, >-the GCC extensions >-page describes where to find the last libg++ source. The code is >-considered replaced and rewritten. >- >-
>- >- >
Second > > >@@ -80,504 +52,14 @@ considered replaced and rewritten. > > > >- The STL portions of this library are based on SGI/HP STL release 3.11. >+ The STL portions of that library are based on SGI/HP STL release 3.11. > > > >- This project is no longer maintained or supported, and the sources >- archived. The code is considered replaced and rewritten. >+ That project is no longer maintained or supported, and the sources >+ archived. The code was replaced and rewritten for libstdc++-v3. > > >- >- Portability notes and known implementation limitations are as follows. >- >- >-
Namespace <code>std::</code> not supported >- >- >- >- Some care is required to support C++ compiler and or library >- implementation that do not have the standard library in >- namespace std. >- >- >- >- The following sections list some possible solutions to support compilers >- that cannot ignore std::-qualified names. >- >- >- >- First, see if the compiler has a flag for this. Namespace >- back-portability-issues are generally not a problem for g++ >- compilers that do not have libstdc++ in std::, as the >- compilers use (ignore >- std::, :: = std::) by default. That is, >- the responsibility for enabling or disabling std:: is >- on the user; the maintainer does not have to care about it. This >- probably applies to some other compilers as well. >- >- >- >- Second, experiment with a variety of pre-processor tricks. >- >- >- >- By defining std as a macro, fully-qualified namespace >- calls become global. Volia. >- >- >- >-#ifdef WICKEDLY_OLD_COMPILER >-# define std >-#endif >- >- >- >- Thanks to Juergen Heinzl who posted this solution on gnu.gcc.help. >- >- >- >- Another pre-processor based approach is to define a macro >- NAMESPACE_STD, which is defined to either >- or std based on a compile-type >- test. On GNU systems, this can be done with autotools by means of >- an autoconf test (see below) for HAVE_NAMESPACE_STD, >- then using that to set a value for the NAMESPACE_STD >- macro. At that point, one is able to use >- NAMESPACE_STD::string, which will evaluate to >- std::string or ::string (i.e., in the >- global namespace on systems that do not put string in >- std::). >- >- >- >-dnl @synopsis AC_CXX_NAMESPACE_STD >-dnl >-dnl If the compiler supports namespace std, define >-dnl HAVE_NAMESPACE_STD. >-dnl >-dnl @category Cxx >-dnl @author Todd Veldhuizen >-dnl @author Luc Maisonobe <luc@spaceroots.org> >-dnl @version 2004-02-04 >-dnl @license AllPermissive >-AC_DEFUN([AC_CXX_NAMESPACE_STD], [ >- AC_CACHE_CHECK(if g++ supports namespace std, >- ac_cv_cxx_have_std_namespace, >- [AC_LANG_SAVE >- AC_LANG_CPLUSPLUS >- AC_TRY_COMPILE([#include <iostream> >- std::istream& is = std::cin;],, >- ac_cv_cxx_have_std_namespace=yes, ac_cv_cxx_have_std_namespace=no) >- AC_LANG_RESTORE >- ]) >- if test "$ac_cv_cxx_have_std_namespace" = yes; then >- AC_DEFINE(HAVE_NAMESPACE_STD,,[Define if g++ supports namespace std. ]) >- fi >-]) >- >-
>- >-
Illegal iterator usage >- >- >- The following illustrate implementation-allowed illegal iterator >- use, and then correct use. >- >- >- >- >- >- you cannot do ostream::operator<<(iterator) >- to print the address of the iterator => use >- operator<< &*iterator instead >- >- >- >- >- you cannot clear an iterator's reference (iterator = >- 0) => use iterator = iterator_type(); >- >- >- >- >- if (iterator) won't work any more => use >- if (iterator != iterator_type()) >- >- >- >-
>- >-
<code>isspace</code> from <filename class="headerfile"><cctype></filename> is a macro >- >- >- >- >- Glibc 2.0.x and 2.1.x define <ctype.h> functionality as macros >- (isspace, isalpha etc.). >- >- >- >- This implementations of libstdc++, however, keep these functions >- as macros, and so it is not back-portable to use fully qualified >- names. For example: >- >- >- >-#include <cctype> >-int main() { std::isspace('X'); } >- >- >- >- Results in something like this: >- >- >- >-std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ; >- >- >- >- A solution is to modify a header-file so that the compiler tells >- <ctype.h> to define functions >- instead of macros: >- >- >- >-// This keeps isalnum, et al from being propagated as macros. >-#if __linux__ >-# define __NO_CTYPE 1 >-#endif >- >- >- >- Then, include <ctype.h> >- >- >- >- Another problem arises if you put a using namespace >- std; declaration at the top, and include >- <ctype.h>. This will >- result in ambiguities between the definitions in the global namespace >- (<ctype.h>) and the >- definitions in namespace std:: >- (<cctype>). >- >-
>- >-
No <code>vector::at</code>, <code>deque::at</code>, <code>string::at</code> >- >- >- >- One solution is to add an autoconf-test for this: >- >- >- >-AC_MSG_CHECKING(for container::at) >-AC_TRY_COMPILE( >-[ >-#include <vector> >-#include <deque> >-#include <string> >- >-using namespace std; >-], >-[ >-deque<int> test_deque(3); >-test_deque.at(2); >-vector<int> test_vector(2); >-test_vector.at(1); >-string test_string(test_string); >-test_string.at(3); >-], >-[AC_MSG_RESULT(yes) >-AC_DEFINE(HAVE_CONTAINER_AT)], >-[AC_MSG_RESULT(no)]) >- >- >- >- If you are using other (non-GNU) compilers it might be a good idea >- to check for string::at separately. >- >- >-
>- >-
No <code>std::char_traits<char>::eof</code> >- >- >- >- Use some kind of autoconf test, plus this: >- >- >- >-#ifdef HAVE_CHAR_TRAITS >-#define CPP_EOF std::char_traits<char>::eof() >-#else >-#define CPP_EOF EOF >-#endif >- >- >-
>- >-
No <code>string::clear</code> >- >- >- >- There are two functions for deleting the contents of a string: >- clear and erase (the latter returns the >- string). >- >- >- >-void >-clear() { _M_mutate(0, this->size(), 0); } >- >- >- >-basic_string& >-erase(size_type __pos = 0, size_type __n = npos) >-{ >- return this->replace(_M_check(__pos), _M_fold(__pos, __n), >- _M_data(), _M_data()); >-} >- >- >- >- Unfortunately, clear is not implemented in this >- version, so you should use erase (which is probably >- faster than operator=(charT*)). >- >-
>- >-
>- Removal of <code>ostream::form</code> and <code>istream::scan</code> >- extensions >- >- >- >- >- These are no longer supported. Please use stringstreams instead. >- >-
>- >-
No <code>basic_stringbuf</code>, <code>basic_stringstream</code> >- >- >- >- Although the ISO standard i/ostringstream-classes are >- provided, (<sstream>), for >- compatibility with older implementations the pre-ISO >- i/ostrstream (<strstream>) interface is also provided, >- with these caveats: >- >- >- >- >- >- strstream is considered to be deprecated >- >- >- >- >- strstream is limited to char >- >- >- >- >- with ostringstream you don't have to take care of >- terminating the string or freeing its memory >- >- >- >- >- istringstream can be re-filled (clear(); >- str(input);) >- >- >- >- >- >- You can then use output-stringstreams like this: >- >- >- >-#ifdef HAVE_SSTREAM >-# include <sstream> >-#else >-# include <strstream> >-#endif >- >-#ifdef HAVE_SSTREAM >- std::ostringstream oss; >-#else >- std::ostrstream oss; >-#endif >- >-oss << "Name=" << m_name << ", number=" << m_number << std::endl; >-... >-#ifndef HAVE_SSTREAM >- oss << std::ends; // terminate the char*-string >-#endif >- >-// str() returns char* for ostrstream and a string for ostringstream >-// this also causes ostrstream to think that the buffer's memory >-// is yours >-m_label.set_text(oss.str()); >-#ifndef HAVE_SSTREAM >- // let the ostrstream take care of freeing the memory >- oss.freeze(false); >-#endif >- >- >- >- Input-stringstreams can be used similarly: >- >- >- >-std::string input; >-... >-#ifdef HAVE_SSTREAM >-std::istringstream iss(input); >-#else >-std::istrstream iss(input.c_str()); >-#endif >- >-int i; >-iss >> i; >- >- >- One (the only?) restriction is that an istrstream cannot be re-filled: >- >- >- >-std::istringstream iss(numerator); >-iss >> m_num; >-// this is not possible with istrstream >-iss.clear(); >-iss.str(denominator); >-iss >> m_den; >- >- >- >-If you don't care about speed, you can put these conversions in >- a template-function: >- >- >-template <class X> >-void fromString(const string& input, X& any) >-{ >-#ifdef HAVE_SSTREAM >-std::istringstream iss(input); >-#else >-std::istrstream iss(input.c_str()); >-#endif >-X temp; >-iss >> temp; >-if (iss.fail()) >-throw runtime_error(..) >-any = temp; >-} >- >- >- >- Another example of using stringstreams is in this howto. >- >- >- There is additional information in the libstdc++-v2 info files, in >-particular info iostream. >- >-
>- >-
Little or no wide character support >- >- >- Classes wstring and >- char_traits<wchar_t> are >- not supported. >- >-
>- >-
No templatized iostreams >- >- >- Classes wfilebuf and >- wstringstream are not supported. >- >-
>- >-
Thread safety issues >- >- >- >- Earlier GCC releases had a somewhat different approach to >- threading configuration and proper compilation. Before GCC 3.0, >- configuration of the threading model was dictated by compiler >- command-line options and macros (both of which were somewhat >- thread-implementation and port-specific). There were no >- guarantees related to being able to link code compiled with one >- set of options and macro setting with another set. >- >- >- >- For GCC 3.0, configuration of the threading model used with >- libraries and user-code is performed when GCC is configured and >- built using the --enable-threads and --disable-threads options. >- The ABI is stable for symbol name-mangling and limited functional >- compatibility exists between code compiled under different >- threading models. >- >- >- >- The libstdc++ library has been designed so that it can be used in >- multithreaded applications (with libstdc++-v2 this was only true >- of the STL parts.) The first problem is finding a >- fast method of implementation portable to >- all platforms. Due to historical reasons, some of the library is >- written against per-CPU-architecture spinlocks and other parts >- against the gthr.h abstraction layer which is provided by gcc. A >- minor problem that pops up every so often is different >- interpretations of what "thread-safe" means for a >- library (not a general program). We currently use the same >- definition that SGI uses for their STL subset. However, >- the exception for read-only containers only applies to the STL >- components. This definition is widely-used and something similar >- will be used in the next version of the C++ standard library. >- >- >- >- Here is a small link farm to threads (no pun) in the mail >- archives that discuss the threading problem. Each link is to the >- first relevant message in the thread; from there you can use >- "Thread Next" to move down the thread. This farm is in >- latest-to-oldest order. >- >- >- >- >- >- Our threading expert Loren gives a breakdown of the >- six situations involving threads for the 3.0 >- release series. >- >- >- >- >- >- This message inspired a recent updating of issues with >- threading and the SGI STL library. It also contains some >- example POSIX-multithreaded STL code. >- >- >- >- >- >- (A large selection of links to older messages has been removed; >- many of the messages from 1999 were lost in a disk crash, and the >- few people with access to the backup tapes have been too swamped >- with work to restore them. Many of the points have been >- superseded anyhow.) >- >-
>- >
> >
Third >@@ -588,7 +70,7 @@ libstdc++-v3. > > > The subset commonly known as the Standard Template Library >- (clauses 23 through 25, mostly) is adapted from the final release >+ (clauses 23 through 25 in C++98, mostly) is adapted from the final release > of the SGI STL (version 3.3), with extensive changes. > > >@@ -1223,40 +705,4 @@ AC_DEFUN([AC_HEADER_UNORDERED_SET], [ > >
> >-Bibliography >- >- >- >- >- <link xmlns:xlink="http://www.w3.org/1999/xlink" >- xlink:href="http://www.kegel.com/gcc/gcc4.html"> >- Migrating to GCC 4.1 >- </link> >- >- >- DanKegel >- >- >- >- >- <link xmlns:xlink="http://www.w3.org/1999/xlink" >- xlink:href="https://lists.debian.org/debian-gcc/2006/03/msg00405.html"> >- Building the Whole Debian Archive with GCC 4.1: A Summary >- </link> >- >- MartinMichlmayr >- >- >- >- >- <link xmlns:xlink="http://www.w3.org/1999/xlink" >- xlink:href="http://annwm.lbl.gov/~leggett/Atlas/gcc-3.2.html"> >- Migration guide for GCC-3.2 >- </link> >- >- >- >- >- >- >