136ac495dSmrg<?xml version="1.0" encoding="UTF-8" standalone="no"?> 236ac495dSmrg<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Backwards Compatibility</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="ISO C++, backwards" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="appendix_porting.html" title="Appendix B. Porting and Maintenance" /><link rel="prev" href="api.html" title="API Evolution and Deprecation History" /><link rel="next" href="appendix_free.html" title="Appendix C. Free Software Needs Free Documentation" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Backwards Compatibility</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="api.html">Prev</a> </td><th width="60%" align="center">Appendix B. 336ac495dSmrg Porting and Maintenance 436ac495dSmrg 536ac495dSmrg</th><td width="20%" align="right"> <a accesskey="n" href="appendix_free.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.appendix.porting.backwards"></a>Backwards Compatibility</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.first"></a>First</h3></div></div></div><p>The first generation GNU C++ library was called libg++. It was a 636ac495dSmrgseparate GNU project, although reliably paired with GCC. Rumors imply 736ac495dSmrgthat it had a working relationship with at least two kinds of 836ac495dSmrgdinosaur. 936ac495dSmrg</p><p>Some background: libg++ was designed and created when there was no 1036ac495dSmrgISO standard to provide guidance. Classes like linked lists are now 1136ac495dSmrgprovided for by <code class="classname">list<T></code> and do not need to be 1236ac495dSmrgcreated by <code class="function">genclass</code>. (For that matter, templates exist 1336ac495dSmrgnow and are well-supported, whereas genclass (mostly) predates them.) 1436ac495dSmrg</p><p>There are other classes in libg++ that are not specified in the 1536ac495dSmrgISO Standard (e.g., statistical analysis). While there are a lot of 1636ac495dSmrgreally useful things that are used by a lot of people, the Standards 1736ac495dSmrgCommittee couldn't include everything, and so a lot of those 1836ac495dSmrg<span class="quote">“<span class="quote">obvious</span>”</span> classes didn't get included. 1936ac495dSmrg</p><p>Known Issues include many of the limitations of its immediate ancestor.</p><p>Portability notes and known implementation limitations are as follows.</p><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.first.ios_base"></a>No <code class="code">ios_base</code></h4></div></div></div><p> At least some older implementations don't have <code class="code">std::ios_base</code>, so you should use <code class="code">std::ios::badbit</code>, <code class="code">std::ios::failbit</code> and <code class="code">std::ios::eofbit</code> and <code class="code">std::ios::goodbit</code>. 2036ac495dSmrg</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.first.cout_cin"></a>No <code class="code">cout</code> in <code class="filename"><ostream.h></code>, no <code class="code">cin</code> in <code class="filename"><istream.h></code></h4></div></div></div><p> 2136ac495dSmrg In earlier versions of the standard, 2236ac495dSmrg <code class="filename"><fstream.h></code>, 2336ac495dSmrg <code class="filename"><ostream.h></code> 2436ac495dSmrg and <code class="filename"><istream.h></code> 2536ac495dSmrg used to define 2636ac495dSmrg <code class="code">cout</code>, <code class="code">cin</code> and so on. ISO C++ specifies that one needs to include 2736ac495dSmrg <code class="filename"><iostream></code> 2836ac495dSmrg explicitly to get the required definitions. 2936ac495dSmrg </p><p> Some include adjustment may be required.</p><p>This project is no longer maintained or supported, and the sources 3036ac495dSmrgarchived. For the desperate, 3136ac495dSmrgthe <a class="link" href="http://gcc.gnu.org/extensions.html" target="_top">GCC extensions 3236ac495dSmrgpage</a> describes where to find the last libg++ source. The code is 3336ac495dSmrgconsidered replaced and rewritten. 3436ac495dSmrg</p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.second"></a>Second</h3></div></div></div><p> 3536ac495dSmrg The second generation GNU C++ library was called libstdc++, or 3636ac495dSmrg libstdc++-v2. It spans the time between libg++ and pre-ISO C++ 3736ac495dSmrg standardization and is usually associated with the following GCC 3836ac495dSmrg releases: egcs 1.x, gcc 2.95, and gcc 2.96. 3936ac495dSmrg</p><p> 4036ac495dSmrg The STL portions of this library are based on SGI/HP STL release 3.11. 4136ac495dSmrg</p><p> 4236ac495dSmrg This project is no longer maintained or supported, and the sources 4336ac495dSmrg archived. The code is considered replaced and rewritten. 4436ac495dSmrg</p><p> 4536ac495dSmrg Portability notes and known implementation limitations are as follows. 4636ac495dSmrg</p><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.second.std"></a>Namespace <code class="code">std::</code> not supported</h4></div></div></div><p> 4736ac495dSmrg Some care is required to support C++ compiler and or library 4836ac495dSmrg implementation that do not have the standard library in 4936ac495dSmrg <code class="code">namespace std</code>. 5036ac495dSmrg </p><p> 5136ac495dSmrg The following sections list some possible solutions to support compilers 5236ac495dSmrg that cannot ignore <code class="code">std::</code>-qualified names. 5336ac495dSmrg </p><p> 5436ac495dSmrg First, see if the compiler has a flag for this. Namespace 5536ac495dSmrg back-portability-issues are generally not a problem for g++ 5636ac495dSmrg compilers that do not have libstdc++ in <code class="code">std::</code>, as the 5736ac495dSmrg compilers use <code class="option">-fno-honor-std</code> (ignore 5836ac495dSmrg <code class="code">std::</code>, <code class="code">:: = std::</code>) by default. That is, 5936ac495dSmrg the responsibility for enabling or disabling <code class="code">std::</code> is 6036ac495dSmrg on the user; the maintainer does not have to care about it. This 6136ac495dSmrg probably applies to some other compilers as well. 6236ac495dSmrg </p><p> 6336ac495dSmrg Second, experiment with a variety of pre-processor tricks. 6436ac495dSmrg </p><p> 6536ac495dSmrg By defining <code class="code">std</code> as a macro, fully-qualified namespace 6636ac495dSmrg calls become global. Volia. 6736ac495dSmrg </p><pre class="programlisting"> 6836ac495dSmrg#ifdef WICKEDLY_OLD_COMPILER 6936ac495dSmrg# define std 7036ac495dSmrg#endif 7136ac495dSmrg</pre><p> 7236ac495dSmrg Thanks to Juergen Heinzl who posted this solution on gnu.gcc.help. 7336ac495dSmrg </p><p> 7436ac495dSmrg Another pre-processor based approach is to define a macro 7536ac495dSmrg <code class="code">NAMESPACE_STD</code>, which is defined to either 7636ac495dSmrg <span class="quote">“<span class="quote"> </span>”</span> or <span class="quote">“<span class="quote">std</span>”</span> based on a compile-type 7736ac495dSmrg test. On GNU systems, this can be done with autotools by means of 7836ac495dSmrg an autoconf test (see below) for <code class="code">HAVE_NAMESPACE_STD</code>, 7936ac495dSmrg then using that to set a value for the <code class="code">NAMESPACE_STD</code> 8036ac495dSmrg macro. At that point, one is able to use 8136ac495dSmrg <code class="code">NAMESPACE_STD::string</code>, which will evaluate to 8236ac495dSmrg <code class="code">std::string</code> or <code class="code">::string</code> (i.e., in the 8336ac495dSmrg global namespace on systems that do not put <code class="code">string</code> in 8436ac495dSmrg <code class="code">std::</code>). 8536ac495dSmrg </p><pre class="programlisting"> 8636ac495dSmrgdnl @synopsis AC_CXX_NAMESPACE_STD 8736ac495dSmrgdnl 8836ac495dSmrgdnl If the compiler supports namespace std, define 8936ac495dSmrgdnl HAVE_NAMESPACE_STD. 9036ac495dSmrgdnl 9136ac495dSmrgdnl @category Cxx 9236ac495dSmrgdnl @author Todd Veldhuizen 9336ac495dSmrgdnl @author Luc Maisonobe <luc@spaceroots.org> 9436ac495dSmrgdnl @version 2004-02-04 9536ac495dSmrgdnl @license AllPermissive 9636ac495dSmrgAC_DEFUN([AC_CXX_NAMESPACE_STD], [ 9736ac495dSmrg AC_CACHE_CHECK(if g++ supports namespace std, 9836ac495dSmrg ac_cv_cxx_have_std_namespace, 9936ac495dSmrg [AC_LANG_SAVE 10036ac495dSmrg AC_LANG_CPLUSPLUS 10136ac495dSmrg AC_TRY_COMPILE([#include <iostream> 10236ac495dSmrg std::istream& is = std::cin;],, 10336ac495dSmrg ac_cv_cxx_have_std_namespace=yes, ac_cv_cxx_have_std_namespace=no) 10436ac495dSmrg AC_LANG_RESTORE 10536ac495dSmrg ]) 10636ac495dSmrg if test "$ac_cv_cxx_have_std_namespace" = yes; then 10736ac495dSmrg AC_DEFINE(HAVE_NAMESPACE_STD,,[Define if g++ supports namespace std. ]) 10836ac495dSmrg fi 10936ac495dSmrg]) 11036ac495dSmrg</pre></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.second.iterators"></a>Illegal iterator usage</h4></div></div></div><p> 11136ac495dSmrg The following illustrate implementation-allowed illegal iterator 11236ac495dSmrg use, and then correct use. 11336ac495dSmrg</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p> 11436ac495dSmrg you cannot do <code class="code">ostream::operator<<(iterator)</code> 11536ac495dSmrg to print the address of the iterator => use 11636ac495dSmrg <code class="code">operator<< &*iterator</code> instead 11736ac495dSmrg </p></li><li class="listitem"><p> 11836ac495dSmrg you cannot clear an iterator's reference (<code class="code">iterator = 11936ac495dSmrg 0</code>) => use <code class="code">iterator = iterator_type();</code> 12036ac495dSmrg </p></li><li class="listitem"><p> 12136ac495dSmrg <code class="code">if (iterator)</code> won't work any more => use 12236ac495dSmrg <code class="code">if (iterator != iterator_type())</code> 12336ac495dSmrg </p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.second.isspace"></a><code class="code">isspace</code> from <code class="filename"><cctype></code> is a macro 12436ac495dSmrg </h4></div></div></div><p> 12536ac495dSmrg Glibc 2.0.x and 2.1.x define <code class="filename"><ctype.h></code> functionality as macros 12636ac495dSmrg (isspace, isalpha etc.). 12736ac495dSmrg </p><p> 12836ac495dSmrg This implementations of libstdc++, however, keep these functions 12936ac495dSmrg as macros, and so it is not back-portable to use fully qualified 13036ac495dSmrg names. For example: 13136ac495dSmrg </p><pre class="programlisting"> 13236ac495dSmrg#include <cctype> 13336ac495dSmrgint main() { std::isspace('X'); } 13436ac495dSmrg</pre><p> 13536ac495dSmrg Results in something like this: 13636ac495dSmrg</p><pre class="programlisting"> 13736ac495dSmrgstd:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ; 13836ac495dSmrg</pre><p> 13936ac495dSmrg A solution is to modify a header-file so that the compiler tells 14036ac495dSmrg <code class="filename"><ctype.h></code> to define functions 14136ac495dSmrg instead of macros: 14236ac495dSmrg</p><pre class="programlisting"> 14336ac495dSmrg// This keeps isalnum, et al from being propagated as macros. 14436ac495dSmrg#if __linux__ 14536ac495dSmrg# define __NO_CTYPE 1 14636ac495dSmrg#endif 14736ac495dSmrg</pre><p> 14836ac495dSmrg Then, include <code class="filename"><ctype.h></code> 14936ac495dSmrg</p><p> 15036ac495dSmrg Another problem arises if you put a <code class="code">using namespace 15136ac495dSmrg std;</code> declaration at the top, and include 15236ac495dSmrg <code class="filename"><ctype.h></code>. This will 15336ac495dSmrg result in ambiguities between the definitions in the global namespace 15436ac495dSmrg (<code class="filename"><ctype.h></code>) and the 15536ac495dSmrg definitions in namespace <code class="code">std::</code> 15636ac495dSmrg (<code class="code"><cctype></code>). 15736ac495dSmrg</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.second.at"></a>No <code class="code">vector::at</code>, <code class="code">deque::at</code>, <code class="code">string::at</code></h4></div></div></div><p> 15836ac495dSmrg One solution is to add an autoconf-test for this: 15936ac495dSmrg</p><pre class="programlisting"> 16036ac495dSmrgAC_MSG_CHECKING(for container::at) 16136ac495dSmrgAC_TRY_COMPILE( 16236ac495dSmrg[ 16336ac495dSmrg#include <vector> 16436ac495dSmrg#include <deque> 16536ac495dSmrg#include <string> 16636ac495dSmrg 16736ac495dSmrgusing namespace std; 16836ac495dSmrg], 16936ac495dSmrg[ 17036ac495dSmrgdeque<int> test_deque(3); 17136ac495dSmrgtest_deque.at(2); 17236ac495dSmrgvector<int> test_vector(2); 17336ac495dSmrgtest_vector.at(1); 17436ac495dSmrgstring test_string(<span class="quote">“<span class="quote">test_string</span>”</span>); 17536ac495dSmrgtest_string.at(3); 17636ac495dSmrg], 17736ac495dSmrg[AC_MSG_RESULT(yes) 17836ac495dSmrgAC_DEFINE(HAVE_CONTAINER_AT)], 17936ac495dSmrg[AC_MSG_RESULT(no)]) 18036ac495dSmrg</pre><p> 18136ac495dSmrg If you are using other (non-GNU) compilers it might be a good idea 18236ac495dSmrg to check for <code class="code">string::at</code> separately. 18336ac495dSmrg</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.second.eof"></a>No <code class="code">std::char_traits<char>::eof</code></h4></div></div></div><p> 18436ac495dSmrg Use some kind of autoconf test, plus this: 18536ac495dSmrg</p><pre class="programlisting"> 18636ac495dSmrg#ifdef HAVE_CHAR_TRAITS 18736ac495dSmrg#define CPP_EOF std::char_traits<char>::eof() 18836ac495dSmrg#else 18936ac495dSmrg#define CPP_EOF EOF 19036ac495dSmrg#endif 19136ac495dSmrg</pre></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.second.stringclear"></a>No <code class="code">string::clear</code></h4></div></div></div><p> 19236ac495dSmrg There are two functions for deleting the contents of a string: 19336ac495dSmrg <code class="code">clear</code> and <code class="code">erase</code> (the latter returns the 19436ac495dSmrg string). 19536ac495dSmrg</p><pre class="programlisting"> 19636ac495dSmrgvoid 19736ac495dSmrgclear() { _M_mutate(0, this->size(), 0); } 19836ac495dSmrg</pre><pre class="programlisting"> 19936ac495dSmrgbasic_string& 20036ac495dSmrgerase(size_type __pos = 0, size_type __n = npos) 20136ac495dSmrg{ 20236ac495dSmrg return this->replace(_M_check(__pos), _M_fold(__pos, __n), 20336ac495dSmrg _M_data(), _M_data()); 20436ac495dSmrg} 20536ac495dSmrg</pre><p> 20636ac495dSmrg Unfortunately, <code class="code">clear</code> is not implemented in this 20736ac495dSmrg version, so you should use <code class="code">erase</code> (which is probably 20836ac495dSmrg faster than <code class="code">operator=(charT*)</code>). 20936ac495dSmrg</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.second.ostreamform_istreamscan"></a> 21036ac495dSmrg Removal of <code class="code">ostream::form</code> and <code class="code">istream::scan</code> 21136ac495dSmrg extensions 21236ac495dSmrg</h4></div></div></div><p> 21336ac495dSmrg These are no longer supported. Please use stringstreams instead. 21436ac495dSmrg</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.second.stringstreams"></a>No <code class="code">basic_stringbuf</code>, <code class="code">basic_stringstream</code></h4></div></div></div><p> 21536ac495dSmrg Although the ISO standard <code class="code">i/ostringstream</code>-classes are 21636ac495dSmrg provided, (<code class="filename"><sstream></code>), for 21736ac495dSmrg compatibility with older implementations the pre-ISO 21836ac495dSmrg <code class="code">i/ostrstream</code> (<code class="filename"><strstream></code>) interface is also provided, 21936ac495dSmrg with these caveats: 22036ac495dSmrg</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p> 22136ac495dSmrg <code class="code">strstream</code> is considered to be deprecated 22236ac495dSmrg </p></li><li class="listitem"><p> 22336ac495dSmrg <code class="code">strstream</code> is limited to <code class="code">char</code> 22436ac495dSmrg </p></li><li class="listitem"><p> 22536ac495dSmrg with <code class="code">ostringstream</code> you don't have to take care of 22636ac495dSmrg terminating the string or freeing its memory 22736ac495dSmrg </p></li><li class="listitem"><p> 22836ac495dSmrg <code class="code">istringstream</code> can be re-filled (clear(); 22936ac495dSmrg str(input);) 23036ac495dSmrg </p></li></ul></div><p> 23136ac495dSmrg You can then use output-stringstreams like this: 23236ac495dSmrg</p><pre class="programlisting"> 23336ac495dSmrg#ifdef HAVE_SSTREAM 23436ac495dSmrg# include <sstream> 23536ac495dSmrg#else 23636ac495dSmrg# include <strstream> 23736ac495dSmrg#endif 23836ac495dSmrg 23936ac495dSmrg#ifdef HAVE_SSTREAM 24036ac495dSmrg std::ostringstream oss; 24136ac495dSmrg#else 24236ac495dSmrg std::ostrstream oss; 24336ac495dSmrg#endif 24436ac495dSmrg 24536ac495dSmrgoss << "Name=" << m_name << ", number=" << m_number << std::endl; 24636ac495dSmrg... 24736ac495dSmrg#ifndef HAVE_SSTREAM 24836ac495dSmrg oss << std::ends; // terminate the char*-string 24936ac495dSmrg#endif 25036ac495dSmrg 25136ac495dSmrg// str() returns char* for ostrstream and a string for ostringstream 25236ac495dSmrg// this also causes ostrstream to think that the buffer's memory 25336ac495dSmrg// is yours 25436ac495dSmrgm_label.set_text(oss.str()); 25536ac495dSmrg#ifndef HAVE_SSTREAM 25636ac495dSmrg // let the ostrstream take care of freeing the memory 25736ac495dSmrg oss.freeze(false); 25836ac495dSmrg#endif 25936ac495dSmrg</pre><p> 26036ac495dSmrg Input-stringstreams can be used similarly: 26136ac495dSmrg</p><pre class="programlisting"> 26236ac495dSmrgstd::string input; 26336ac495dSmrg... 26436ac495dSmrg#ifdef HAVE_SSTREAM 26536ac495dSmrgstd::istringstream iss(input); 26636ac495dSmrg#else 26736ac495dSmrgstd::istrstream iss(input.c_str()); 26836ac495dSmrg#endif 26936ac495dSmrg 27036ac495dSmrgint i; 27136ac495dSmrgiss >> i; 27236ac495dSmrg</pre><p> One (the only?) restriction is that an istrstream cannot be re-filled: 27336ac495dSmrg</p><pre class="programlisting"> 27436ac495dSmrgstd::istringstream iss(numerator); 27536ac495dSmrgiss >> m_num; 27636ac495dSmrg// this is not possible with istrstream 27736ac495dSmrgiss.clear(); 27836ac495dSmrgiss.str(denominator); 27936ac495dSmrgiss >> m_den; 28036ac495dSmrg</pre><p> 28136ac495dSmrgIf you don't care about speed, you can put these conversions in 28236ac495dSmrg a template-function: 28336ac495dSmrg</p><pre class="programlisting"> 28436ac495dSmrgtemplate <class X> 28536ac495dSmrgvoid fromString(const string& input, X& any) 28636ac495dSmrg{ 28736ac495dSmrg#ifdef HAVE_SSTREAM 28836ac495dSmrgstd::istringstream iss(input); 28936ac495dSmrg#else 29036ac495dSmrgstd::istrstream iss(input.c_str()); 29136ac495dSmrg#endif 29236ac495dSmrgX temp; 29336ac495dSmrgiss >> temp; 29436ac495dSmrgif (iss.fail()) 29536ac495dSmrgthrow runtime_error(..) 29636ac495dSmrgany = temp; 29736ac495dSmrg} 29836ac495dSmrg</pre><p> 29936ac495dSmrg Another example of using stringstreams is in <a class="link" href="strings.html#strings.string.shrink" title="Shrink to Fit">this howto</a>. 30036ac495dSmrg</p><p> There is additional information in the libstdc++-v2 info files, in 30136ac495dSmrgparticular <span class="quote">“<span class="quote">info iostream</span>”</span>. 30236ac495dSmrg</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.second.wchar"></a>Little or no wide character support</h4></div></div></div><p> 30336ac495dSmrg Classes <code class="classname">wstring</code> and 30436ac495dSmrg <code class="classname">char_traits<wchar_t></code> are 30536ac495dSmrg not supported. 30636ac495dSmrg </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.second.iostream_templates"></a>No templatized iostreams</h4></div></div></div><p> 30736ac495dSmrg Classes <code class="classname">wfilebuf</code> and 30836ac495dSmrg <code class="classname">wstringstream</code> are not supported. 30936ac495dSmrg </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.second.thread_safety"></a>Thread safety issues</h4></div></div></div><p> 31036ac495dSmrg Earlier GCC releases had a somewhat different approach to 31136ac495dSmrg threading configuration and proper compilation. Before GCC 3.0, 31236ac495dSmrg configuration of the threading model was dictated by compiler 31336ac495dSmrg command-line options and macros (both of which were somewhat 31436ac495dSmrg thread-implementation and port-specific). There were no 31536ac495dSmrg guarantees related to being able to link code compiled with one 31636ac495dSmrg set of options and macro setting with another set. 31736ac495dSmrg </p><p> 31836ac495dSmrg For GCC 3.0, configuration of the threading model used with 31936ac495dSmrg libraries and user-code is performed when GCC is configured and 32036ac495dSmrg built using the --enable-threads and --disable-threads options. 32136ac495dSmrg The ABI is stable for symbol name-mangling and limited functional 32236ac495dSmrg compatibility exists between code compiled under different 32336ac495dSmrg threading models. 32436ac495dSmrg </p><p> 32536ac495dSmrg The libstdc++ library has been designed so that it can be used in 32636ac495dSmrg multithreaded applications (with libstdc++-v2 this was only true 32736ac495dSmrg of the STL parts.) The first problem is finding a 32836ac495dSmrg <span class="emphasis"><em>fast</em></span> method of implementation portable to 32936ac495dSmrg all platforms. Due to historical reasons, some of the library is 33036ac495dSmrg written against per-CPU-architecture spinlocks and other parts 33136ac495dSmrg against the gthr.h abstraction layer which is provided by gcc. A 33236ac495dSmrg minor problem that pops up every so often is different 33336ac495dSmrg interpretations of what "thread-safe" means for a 334a2dc1f3fSmrg library (not a general program). We currently use the <a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/thread_safety.html" target="_top">same 33536ac495dSmrg definition that SGI</a> uses for their STL subset. However, 33636ac495dSmrg the exception for read-only containers only applies to the STL 33736ac495dSmrg components. This definition is widely-used and something similar 33836ac495dSmrg will be used in the next version of the C++ standard library. 33936ac495dSmrg </p><p> 34036ac495dSmrg Here is a small link farm to threads (no pun) in the mail 34136ac495dSmrg archives that discuss the threading problem. Each link is to the 34236ac495dSmrg first relevant message in the thread; from there you can use 34336ac495dSmrg "Thread Next" to move down the thread. This farm is in 34436ac495dSmrg latest-to-oldest order. 34536ac495dSmrg </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p> 34636ac495dSmrg Our threading expert Loren gives a breakdown of <a class="link" href="http://gcc.gnu.org/ml/libstdc++/2001-10/msg00024.html" target="_top">the 34736ac495dSmrg six situations involving threads</a> for the 3.0 34836ac495dSmrg release series. 34936ac495dSmrg </p></li><li class="listitem"><p> 35036ac495dSmrg <a class="link" href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html" target="_top"> 35136ac495dSmrg This message</a> inspired a recent updating of issues with 35236ac495dSmrg threading and the SGI STL library. It also contains some 35336ac495dSmrg example POSIX-multithreaded STL code. 35436ac495dSmrg </p></li></ul></div><p> 35536ac495dSmrg (A large selection of links to older messages has been removed; 35636ac495dSmrg many of the messages from 1999 were lost in a disk crash, and the 35736ac495dSmrg few people with access to the backup tapes have been too swamped 35836ac495dSmrg with work to restore them. Many of the points have been 35936ac495dSmrg superseded anyhow.) 36036ac495dSmrg </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.third"></a>Third</h3></div></div></div><p> The third generation GNU C++ library is called libstdc++, or 36136ac495dSmrglibstdc++-v3. 36236ac495dSmrg</p><p>The subset commonly known as the Standard Template Library 36336ac495dSmrg (clauses 23 through 25, mostly) is adapted from the final release 36436ac495dSmrg of the SGI STL (version 3.3), with extensive changes. 36536ac495dSmrg </p><p>A more formal description of the V3 goals can be found in the 36636ac495dSmrg official <a class="link" href="source_design_notes.html" title="Design Notes">design document</a>. 36736ac495dSmrg </p><p>Portability notes and known implementation limitations are as follows.</p><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.third.headers"></a>Pre-ISO headers removed</h4></div></div></div><p> The pre-ISO C++ headers 36836ac495dSmrg (<code class="filename"><iostream.h></code>, 36936ac495dSmrg <code class="filename"><defalloc.h></code> etc.) are 37036ac495dSmrg not supported. 37136ac495dSmrg</p><p>For those of you new to ISO C++ (welcome, time travelers!), the 37236ac495dSmrg ancient pre-ISO headers have new names. 37336ac495dSmrg The C++ FAQ has a good explanation in <a class="link" href="https://isocpp.org/wiki/faq/coding-standards#std-headers" target="_top">What's 37436ac495dSmrg the difference between <xxx> and <xxx.h> headers?</a>. 37536ac495dSmrg </p><p>Porting between pre-ISO headers and ISO headers is simple: headers 37636ac495dSmrglike <code class="filename"><vector.h></code> can be replaced with <code class="filename"><vector></code> and a using 37736ac495dSmrgdirective <code class="code">using namespace std;</code> can be put at the global 37836ac495dSmrgscope. This should be enough to get this code compiling, assuming the 37936ac495dSmrgother usage is correct. 38036ac495dSmrg</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.third.hash"></a>Extension headers hash_map, hash_set moved to ext or backwards</h4></div></div></div><p>At this time most of the features of the SGI STL extension have been 38136ac495dSmrg replaced by standardized libraries. 38236ac495dSmrg In particular, the <code class="classname">unordered_map</code> and 38336ac495dSmrg <code class="classname">unordered_set</code> containers of TR1 and C++ 2011 38436ac495dSmrg are suitable replacements for the non-standard 38536ac495dSmrg <code class="classname">hash_map</code> and <code class="classname">hash_set</code> 38636ac495dSmrg containers in the SGI STL. 38736ac495dSmrg </p><p> Header files <code class="filename"><hash_map></code> and <code class="filename"><hash_set></code> moved 38836ac495dSmrgto <code class="filename"><ext/hash_map></code> and <code class="filename"><ext/hash_set></code>, 38936ac495dSmrgrespectively. At the same time, all types in these files are enclosed 39036ac495dSmrgin <code class="code">namespace __gnu_cxx</code>. Later versions deprecate 39136ac495dSmrgthese files, and suggest using TR1's <code class="filename"><unordered_map></code> 39236ac495dSmrgand <code class="filename"><unordered_set></code> instead. 39336ac495dSmrg</p><p>The extensions are no longer in the global or <code class="code">std</code> 39436ac495dSmrg namespaces, instead they are declared in the <code class="code">__gnu_cxx</code> 39536ac495dSmrg namespace. For maximum portability, consider defining a namespace 39636ac495dSmrg alias to use to talk about extensions, e.g.: 39736ac495dSmrg </p><pre class="programlisting"> 39836ac495dSmrg #ifdef __GNUC__ 39936ac495dSmrg #if __GNUC__ < 3 40036ac495dSmrg #include <hash_map.h> 40136ac495dSmrg namespace extension { using ::hash_map; }; // inherit globals 40236ac495dSmrg #else 40336ac495dSmrg #include <backward/hash_map> 40436ac495dSmrg #if __GNUC__ == 3 && __GNUC_MINOR__ == 0 40536ac495dSmrg namespace extension = std; // GCC 3.0 40636ac495dSmrg #else 40736ac495dSmrg namespace extension = ::__gnu_cxx; // GCC 3.1 and later 40836ac495dSmrg #endif 40936ac495dSmrg #endif 41036ac495dSmrg #else // ... there are other compilers, right? 41136ac495dSmrg namespace extension = std; 41236ac495dSmrg #endif 41336ac495dSmrg 41436ac495dSmrg extension::hash_map<int,int> my_map; 41536ac495dSmrg </pre><p>This is a bit cleaner than defining typedefs for all the 41636ac495dSmrg instantiations you might need. 41736ac495dSmrg </p><p>The following autoconf tests check for working HP/SGI hash containers. 41836ac495dSmrg</p><pre class="programlisting"> 41936ac495dSmrg# AC_HEADER_EXT_HASH_MAP 42036ac495dSmrgAC_DEFUN([AC_HEADER_EXT_HASH_MAP], [ 42136ac495dSmrg AC_CACHE_CHECK(for ext/hash_map, 42236ac495dSmrg ac_cv_cxx_ext_hash_map, 42336ac495dSmrg [AC_LANG_SAVE 42436ac495dSmrg AC_LANG_CPLUSPLUS 42536ac495dSmrg ac_save_CXXFLAGS="$CXXFLAGS" 42636ac495dSmrg CXXFLAGS="$CXXFLAGS -Werror" 42736ac495dSmrg AC_TRY_COMPILE([#include <ext/hash_map>], [using __gnu_cxx::hash_map;], 42836ac495dSmrg ac_cv_cxx_ext_hash_map=yes, ac_cv_cxx_ext_hash_map=no) 42936ac495dSmrg CXXFLAGS="$ac_save_CXXFLAGS" 43036ac495dSmrg AC_LANG_RESTORE 43136ac495dSmrg ]) 43236ac495dSmrg if test "$ac_cv_cxx_ext_hash_map" = yes; then 43336ac495dSmrg AC_DEFINE(HAVE_EXT_HASH_MAP,,[Define if ext/hash_map is present. ]) 43436ac495dSmrg fi 43536ac495dSmrg]) 43636ac495dSmrg</pre><pre class="programlisting"> 43736ac495dSmrg# AC_HEADER_EXT_HASH_SET 43836ac495dSmrgAC_DEFUN([AC_HEADER_EXT_HASH_SET], [ 43936ac495dSmrg AC_CACHE_CHECK(for ext/hash_set, 44036ac495dSmrg ac_cv_cxx_ext_hash_set, 44136ac495dSmrg [AC_LANG_SAVE 44236ac495dSmrg AC_LANG_CPLUSPLUS 44336ac495dSmrg ac_save_CXXFLAGS="$CXXFLAGS" 44436ac495dSmrg CXXFLAGS="$CXXFLAGS -Werror" 44536ac495dSmrg AC_TRY_COMPILE([#include <ext/hash_set>], [using __gnu_cxx::hash_set;], 44636ac495dSmrg ac_cv_cxx_ext_hash_set=yes, ac_cv_cxx_ext_hash_set=no) 44736ac495dSmrg CXXFLAGS="$ac_save_CXXFLAGS" 44836ac495dSmrg AC_LANG_RESTORE 44936ac495dSmrg ]) 45036ac495dSmrg if test "$ac_cv_cxx_ext_hash_set" = yes; then 45136ac495dSmrg AC_DEFINE(HAVE_EXT_HASH_SET,,[Define if ext/hash_set is present. ]) 45236ac495dSmrg fi 45336ac495dSmrg]) 45436ac495dSmrg</pre></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.third.nocreate_noreplace"></a>No <code class="code">ios::nocreate/ios::noreplace</code>. 45536ac495dSmrg</h4></div></div></div><p>Historically these flags were used with iostreams to control whether 45636ac495dSmrgnew files are created or not when opening a file stream, similar to the 45736ac495dSmrg<code class="code">O_CREAT</code> and <code class="code">O_EXCL</code> flags for the 45836ac495dSmrg<code class="function">open(2)</code> system call. Because iostream modes correspond 45936ac495dSmrgto <code class="function">fopen(3)</code> modes these flags are not supported. 46036ac495dSmrgFor input streams a new file will not be created anyway, so 46136ac495dSmrg<code class="code">ios::nocreate</code> is not needed. 46236ac495dSmrgFor output streams, a new file will be created if it does not exist, which is 46336ac495dSmrgconsistent with the behaviour of <code class="function">fopen</code>. 46436ac495dSmrg</p><p>When one of these flags is needed a possible alternative is to attempt 46536ac495dSmrgto open the file using <span class="type">std::ifstream</span> first to determine whether 46636ac495dSmrgthe file already exists or not. This may not be reliable however, because 46736ac495dSmrgwhether the file exists or not could change between opening the 46836ac495dSmrg<span class="type">std::istream</span> and re-opening with an output stream. If you need 46936ac495dSmrgto check for existence and open a file as a single operation then you will 47036ac495dSmrgneed to use OS-specific facilities outside the C++ standard library, such 47136ac495dSmrgas <code class="function">open(2)</code>. 47236ac495dSmrg</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.third.streamattach"></a> 47336ac495dSmrgNo <code class="code">stream::attach(int fd)</code> 47436ac495dSmrg</h4></div></div></div><p> 47536ac495dSmrg Phil Edwards writes: It was considered and rejected for the ISO 47636ac495dSmrg standard. Not all environments use file descriptors. Of those 47736ac495dSmrg that do, not all of them use integers to represent them. 47836ac495dSmrg </p><p> 47936ac495dSmrg For a portable solution (among systems which use 48036ac495dSmrg file descriptors), you need to implement a subclass of 48136ac495dSmrg <code class="code">std::streambuf</code> (or 48236ac495dSmrg <code class="code">std::basic_streambuf<..></code>) which opens a file 48336ac495dSmrg given a descriptor, and then pass an instance of this to the 48436ac495dSmrg stream-constructor. 48536ac495dSmrg </p><p> 48636ac495dSmrg An extension is available that implements this. 487*c0a68be4Smrg <code class="filename"><ext/stdio_filebuf.h></code> 488*c0a68be4Smrg contains a derived class called 489*c0a68be4Smrg <code class="classname">__gnu_cxx::stdio_filebuf</code>. 49036ac495dSmrg This class can be constructed from a C <code class="code">FILE*</code> or a file 49136ac495dSmrg descriptor, and provides the <code class="code">fd()</code> function. 49236ac495dSmrg </p><p> 49336ac495dSmrg For another example of this, refer to 49436ac495dSmrg <a class="link" href="http://www.josuttis.com/cppcode/fdstream.html" target="_top">fdstream example</a> 49536ac495dSmrg by Nicolai Josuttis. 49636ac495dSmrg</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.third.support_cxx98"></a> 49736ac495dSmrgSupport for C++98 dialect. 49836ac495dSmrg</h4></div></div></div><p>Check for complete library coverage of the C++1998/2003 standard. 49936ac495dSmrg</p><pre class="programlisting"> 50036ac495dSmrg# AC_HEADER_STDCXX_98 50136ac495dSmrgAC_DEFUN([AC_HEADER_STDCXX_98], [ 50236ac495dSmrg AC_CACHE_CHECK(for ISO C++ 98 include files, 50336ac495dSmrg ac_cv_cxx_stdcxx_98, 50436ac495dSmrg [AC_LANG_SAVE 50536ac495dSmrg AC_LANG_CPLUSPLUS 50636ac495dSmrg AC_TRY_COMPILE([ 50736ac495dSmrg #include <cassert> 50836ac495dSmrg #include <cctype> 50936ac495dSmrg #include <cerrno> 51036ac495dSmrg #include <cfloat> 51136ac495dSmrg #include <ciso646> 51236ac495dSmrg #include <climits> 51336ac495dSmrg #include <clocale> 51436ac495dSmrg #include <cmath> 51536ac495dSmrg #include <csetjmp> 51636ac495dSmrg #include <csignal> 51736ac495dSmrg #include <cstdarg> 51836ac495dSmrg #include <cstddef> 51936ac495dSmrg #include <cstdio> 52036ac495dSmrg #include <cstdlib> 52136ac495dSmrg #include <cstring> 52236ac495dSmrg #include <ctime> 52336ac495dSmrg 52436ac495dSmrg #include <algorithm> 52536ac495dSmrg #include <bitset> 52636ac495dSmrg #include <complex> 52736ac495dSmrg #include <deque> 52836ac495dSmrg #include <exception> 52936ac495dSmrg #include <fstream> 53036ac495dSmrg #include <functional> 53136ac495dSmrg #include <iomanip> 53236ac495dSmrg #include <ios> 53336ac495dSmrg #include <iosfwd> 53436ac495dSmrg #include <iostream> 53536ac495dSmrg #include <istream> 53636ac495dSmrg #include <iterator> 53736ac495dSmrg #include <limits> 53836ac495dSmrg #include <list> 53936ac495dSmrg #include <locale> 54036ac495dSmrg #include <map> 54136ac495dSmrg #include <memory> 54236ac495dSmrg #include <new> 54336ac495dSmrg #include <numeric> 54436ac495dSmrg #include <ostream> 54536ac495dSmrg #include <queue> 54636ac495dSmrg #include <set> 54736ac495dSmrg #include <sstream> 54836ac495dSmrg #include <stack> 54936ac495dSmrg #include <stdexcept> 55036ac495dSmrg #include <streambuf> 55136ac495dSmrg #include <string> 55236ac495dSmrg #include <typeinfo> 55336ac495dSmrg #include <utility> 55436ac495dSmrg #include <valarray> 55536ac495dSmrg #include <vector> 55636ac495dSmrg ],, 55736ac495dSmrg ac_cv_cxx_stdcxx_98=yes, ac_cv_cxx_stdcxx_98=no) 55836ac495dSmrg AC_LANG_RESTORE 55936ac495dSmrg ]) 56036ac495dSmrg if test "$ac_cv_cxx_stdcxx_98" = yes; then 56136ac495dSmrg AC_DEFINE(STDCXX_98_HEADERS,,[Define if ISO C++ 1998 header files are present. ]) 56236ac495dSmrg fi 56336ac495dSmrg]) 56436ac495dSmrg</pre></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.third.support_tr1"></a> 56536ac495dSmrgSupport for C++TR1 dialect. 56636ac495dSmrg</h4></div></div></div><p>Check for library coverage of the TR1 standard. 56736ac495dSmrg</p><pre class="programlisting"> 56836ac495dSmrg# AC_HEADER_STDCXX_TR1 56936ac495dSmrgAC_DEFUN([AC_HEADER_STDCXX_TR1], [ 57036ac495dSmrg AC_CACHE_CHECK(for ISO C++ TR1 include files, 57136ac495dSmrg ac_cv_cxx_stdcxx_tr1, 57236ac495dSmrg [AC_LANG_SAVE 57336ac495dSmrg AC_LANG_CPLUSPLUS 57436ac495dSmrg AC_TRY_COMPILE([ 57536ac495dSmrg #include <tr1/array> 57636ac495dSmrg #include <tr1/ccomplex> 57736ac495dSmrg #include <tr1/cctype> 57836ac495dSmrg #include <tr1/cfenv> 57936ac495dSmrg #include <tr1/cfloat> 58036ac495dSmrg #include <tr1/cinttypes> 58136ac495dSmrg #include <tr1/climits> 58236ac495dSmrg #include <tr1/cmath> 58336ac495dSmrg #include <tr1/complex> 58436ac495dSmrg #include <tr1/cstdarg> 58536ac495dSmrg #include <tr1/cstdbool> 58636ac495dSmrg #include <tr1/cstdint> 58736ac495dSmrg #include <tr1/cstdio> 58836ac495dSmrg #include <tr1/cstdlib> 58936ac495dSmrg #include <tr1/ctgmath> 59036ac495dSmrg #include <tr1/ctime> 59136ac495dSmrg #include <tr1/cwchar> 59236ac495dSmrg #include <tr1/cwctype> 59336ac495dSmrg #include <tr1/functional> 59436ac495dSmrg #include <tr1/memory> 59536ac495dSmrg #include <tr1/random> 59636ac495dSmrg #include <tr1/regex> 59736ac495dSmrg #include <tr1/tuple> 59836ac495dSmrg #include <tr1/type_traits> 59936ac495dSmrg #include <tr1/unordered_set> 60036ac495dSmrg #include <tr1/unordered_map> 60136ac495dSmrg #include <tr1/utility> 60236ac495dSmrg ],, 60336ac495dSmrg ac_cv_cxx_stdcxx_tr1=yes, ac_cv_cxx_stdcxx_tr1=no) 60436ac495dSmrg AC_LANG_RESTORE 60536ac495dSmrg ]) 60636ac495dSmrg if test "$ac_cv_cxx_stdcxx_tr1" = yes; then 60736ac495dSmrg AC_DEFINE(STDCXX_TR1_HEADERS,,[Define if ISO C++ TR1 header files are present. ]) 60836ac495dSmrg fi 60936ac495dSmrg]) 61036ac495dSmrg</pre><p>An alternative is to check just for specific TR1 includes, such as <unordered_map> and <unordered_set>. 61136ac495dSmrg</p><pre class="programlisting"> 61236ac495dSmrg# AC_HEADER_TR1_UNORDERED_MAP 61336ac495dSmrgAC_DEFUN([AC_HEADER_TR1_UNORDERED_MAP], [ 61436ac495dSmrg AC_CACHE_CHECK(for tr1/unordered_map, 61536ac495dSmrg ac_cv_cxx_tr1_unordered_map, 61636ac495dSmrg [AC_LANG_SAVE 61736ac495dSmrg AC_LANG_CPLUSPLUS 61836ac495dSmrg AC_TRY_COMPILE([#include <tr1/unordered_map>], [using std::tr1::unordered_map;], 61936ac495dSmrg ac_cv_cxx_tr1_unordered_map=yes, ac_cv_cxx_tr1_unordered_map=no) 62036ac495dSmrg AC_LANG_RESTORE 62136ac495dSmrg ]) 62236ac495dSmrg if test "$ac_cv_cxx_tr1_unordered_map" = yes; then 62336ac495dSmrg AC_DEFINE(HAVE_TR1_UNORDERED_MAP,,[Define if tr1/unordered_map is present. ]) 62436ac495dSmrg fi 62536ac495dSmrg]) 62636ac495dSmrg</pre><pre class="programlisting"> 62736ac495dSmrg# AC_HEADER_TR1_UNORDERED_SET 62836ac495dSmrgAC_DEFUN([AC_HEADER_TR1_UNORDERED_SET], [ 62936ac495dSmrg AC_CACHE_CHECK(for tr1/unordered_set, 63036ac495dSmrg ac_cv_cxx_tr1_unordered_set, 63136ac495dSmrg [AC_LANG_SAVE 63236ac495dSmrg AC_LANG_CPLUSPLUS 63336ac495dSmrg AC_TRY_COMPILE([#include <tr1/unordered_set>], [using std::tr1::unordered_set;], 63436ac495dSmrg ac_cv_cxx_tr1_unordered_set=yes, ac_cv_cxx_tr1_unordered_set=no) 63536ac495dSmrg AC_LANG_RESTORE 63636ac495dSmrg ]) 63736ac495dSmrg if test "$ac_cv_cxx_tr1_unordered_set" = yes; then 63836ac495dSmrg AC_DEFINE(HAVE_TR1_UNORDERED_SET,,[Define if tr1/unordered_set is present. ]) 63936ac495dSmrg fi 64036ac495dSmrg]) 64136ac495dSmrg</pre></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.third.support_cxx11"></a> 64236ac495dSmrgSupport for C++11 dialect. 64336ac495dSmrg</h4></div></div></div><p>Check for baseline language coverage in the compiler for the C++11 standard. 64436ac495dSmrg</p><pre class="programlisting"> 64536ac495dSmrg# AC_COMPILE_STDCXX_11 64636ac495dSmrgAC_DEFUN([AC_COMPILE_STDCXX_11], [ 64736ac495dSmrg AC_CACHE_CHECK(if g++ supports C++11 features without additional flags, 64836ac495dSmrg ac_cv_cxx_compile_cxx11_native, 64936ac495dSmrg [AC_LANG_SAVE 65036ac495dSmrg AC_LANG_CPLUSPLUS 65136ac495dSmrg AC_TRY_COMPILE([ 65236ac495dSmrg template <typename T> 65336ac495dSmrg struct check final 65436ac495dSmrg { 65536ac495dSmrg static constexpr T value{ __cplusplus }; 65636ac495dSmrg }; 65736ac495dSmrg 65836ac495dSmrg typedef check<check<bool>> right_angle_brackets; 65936ac495dSmrg 66036ac495dSmrg int a; 66136ac495dSmrg decltype(a) b; 66236ac495dSmrg 66336ac495dSmrg typedef check<int> check_type; 66436ac495dSmrg check_type c{}; 66536ac495dSmrg check_type&& cr = static_cast<check_type&&>(c); 66636ac495dSmrg 66736ac495dSmrg static_assert(check_type::value == 201103L, "C++11 compiler");],, 66836ac495dSmrg ac_cv_cxx_compile_cxx11_native=yes, ac_cv_cxx_compile_cxx11_native=no) 66936ac495dSmrg AC_LANG_RESTORE 67036ac495dSmrg ]) 67136ac495dSmrg 67236ac495dSmrg AC_CACHE_CHECK(if g++ supports C++11 features with -std=c++11, 67336ac495dSmrg ac_cv_cxx_compile_cxx11_cxx, 67436ac495dSmrg [AC_LANG_SAVE 67536ac495dSmrg AC_LANG_CPLUSPLUS 67636ac495dSmrg ac_save_CXXFLAGS="$CXXFLAGS" 67736ac495dSmrg CXXFLAGS="$CXXFLAGS -std=c++11" 67836ac495dSmrg AC_TRY_COMPILE([ 67936ac495dSmrg template <typename T> 68036ac495dSmrg struct check final 68136ac495dSmrg { 68236ac495dSmrg static constexpr T value{ __cplusplus }; 68336ac495dSmrg }; 68436ac495dSmrg 68536ac495dSmrg typedef check<check<bool>> right_angle_brackets; 68636ac495dSmrg 68736ac495dSmrg int a; 68836ac495dSmrg decltype(a) b; 68936ac495dSmrg 69036ac495dSmrg typedef check<int> check_type; 69136ac495dSmrg check_type c{}; 69236ac495dSmrg check_type&& cr = static_cast<check_type&&>(c); 69336ac495dSmrg 69436ac495dSmrg static_assert(check_type::value == 201103L, "C++11 compiler");],, 69536ac495dSmrg ac_cv_cxx_compile_cxx11_cxx=yes, ac_cv_cxx_compile_cxx11_cxx=no) 69636ac495dSmrg CXXFLAGS="$ac_save_CXXFLAGS" 69736ac495dSmrg AC_LANG_RESTORE 69836ac495dSmrg ]) 69936ac495dSmrg 70036ac495dSmrg AC_CACHE_CHECK(if g++ supports C++11 features with -std=gnu++11, 70136ac495dSmrg ac_cv_cxx_compile_cxx11_gxx, 70236ac495dSmrg [AC_LANG_SAVE 70336ac495dSmrg AC_LANG_CPLUSPLUS 70436ac495dSmrg ac_save_CXXFLAGS="$CXXFLAGS" 70536ac495dSmrg CXXFLAGS="$CXXFLAGS -std=gnu++11" 70636ac495dSmrg AC_TRY_COMPILE([ 70736ac495dSmrg template <typename T> 70836ac495dSmrg struct check final 70936ac495dSmrg { 71036ac495dSmrg static constexpr T value{ __cplusplus }; 71136ac495dSmrg }; 71236ac495dSmrg 71336ac495dSmrg typedef check<check<bool>> right_angle_brackets; 71436ac495dSmrg 71536ac495dSmrg int a; 71636ac495dSmrg decltype(a) b; 71736ac495dSmrg 71836ac495dSmrg typedef check<int> check_type; 71936ac495dSmrg check_type c{}; 72036ac495dSmrg check_type&& cr = static_cast<check_type&&>(c); 72136ac495dSmrg 72236ac495dSmrg static_assert(check_type::value == 201103L, "C++11 compiler");],, 72336ac495dSmrg ac_cv_cxx_compile_cxx11_gxx=yes, ac_cv_cxx_compile_cxx11_gxx=no) 72436ac495dSmrg CXXFLAGS="$ac_save_CXXFLAGS" 72536ac495dSmrg AC_LANG_RESTORE 72636ac495dSmrg ]) 72736ac495dSmrg 72836ac495dSmrg if test "$ac_cv_cxx_compile_cxx11_native" = yes || 72936ac495dSmrg test "$ac_cv_cxx_compile_cxx11_cxx" = yes || 73036ac495dSmrg test "$ac_cv_cxx_compile_cxx11_gxx" = yes; then 73136ac495dSmrg AC_DEFINE(HAVE_STDCXX_11,,[Define if g++ supports C++11 features. ]) 73236ac495dSmrg fi 73336ac495dSmrg]) 73436ac495dSmrg</pre><p>Check for library coverage of the C++2011 standard. 73536ac495dSmrg (Some library headers are commented out in this check, they are 73636ac495dSmrg not currently provided by libstdc++). 73736ac495dSmrg</p><pre class="programlisting"> 73836ac495dSmrg# AC_HEADER_STDCXX_11 73936ac495dSmrgAC_DEFUN([AC_HEADER_STDCXX_11], [ 74036ac495dSmrg AC_CACHE_CHECK(for ISO C++11 include files, 74136ac495dSmrg ac_cv_cxx_stdcxx_11, 74236ac495dSmrg [AC_REQUIRE([AC_COMPILE_STDCXX_11]) 74336ac495dSmrg AC_LANG_SAVE 74436ac495dSmrg AC_LANG_CPLUSPLUS 74536ac495dSmrg ac_save_CXXFLAGS="$CXXFLAGS" 74636ac495dSmrg CXXFLAGS="$CXXFLAGS -std=gnu++11" 74736ac495dSmrg 74836ac495dSmrg AC_TRY_COMPILE([ 74936ac495dSmrg #include <cassert> 75036ac495dSmrg #include <ccomplex> 75136ac495dSmrg #include <cctype> 75236ac495dSmrg #include <cerrno> 75336ac495dSmrg #include <cfenv> 75436ac495dSmrg #include <cfloat> 75536ac495dSmrg #include <cinttypes> 75636ac495dSmrg #include <ciso646> 75736ac495dSmrg #include <climits> 75836ac495dSmrg #include <clocale> 75936ac495dSmrg #include <cmath> 76036ac495dSmrg #include <csetjmp> 76136ac495dSmrg #include <csignal> 76236ac495dSmrg #include <cstdalign> 76336ac495dSmrg #include <cstdarg> 76436ac495dSmrg #include <cstdbool> 76536ac495dSmrg #include <cstddef> 76636ac495dSmrg #include <cstdint> 76736ac495dSmrg #include <cstdio> 76836ac495dSmrg #include <cstdlib> 76936ac495dSmrg #include <cstring> 77036ac495dSmrg #include <ctgmath> 77136ac495dSmrg #include <ctime> 77236ac495dSmrg // #include <cuchar> 77336ac495dSmrg #include <cwchar> 77436ac495dSmrg #include <cwctype> 77536ac495dSmrg 77636ac495dSmrg #include <algorithm> 77736ac495dSmrg #include <array> 77836ac495dSmrg #include <atomic> 77936ac495dSmrg #include <bitset> 78036ac495dSmrg #include <chrono> 78136ac495dSmrg // #include <codecvt> 78236ac495dSmrg #include <complex> 78336ac495dSmrg #include <condition_variable> 78436ac495dSmrg #include <deque> 78536ac495dSmrg #include <exception> 78636ac495dSmrg #include <forward_list> 78736ac495dSmrg #include <fstream> 78836ac495dSmrg #include <functional> 78936ac495dSmrg #include <future> 79036ac495dSmrg #include <initializer_list> 79136ac495dSmrg #include <iomanip> 79236ac495dSmrg #include <ios> 79336ac495dSmrg #include <iosfwd> 79436ac495dSmrg #include <iostream> 79536ac495dSmrg #include <istream> 79636ac495dSmrg #include <iterator> 79736ac495dSmrg #include <limits> 79836ac495dSmrg #include <list> 79936ac495dSmrg #include <locale> 80036ac495dSmrg #include <map> 80136ac495dSmrg #include <memory> 80236ac495dSmrg #include <mutex> 80336ac495dSmrg #include <new> 80436ac495dSmrg #include <numeric> 80536ac495dSmrg #include <ostream> 80636ac495dSmrg #include <queue> 80736ac495dSmrg #include <random> 80836ac495dSmrg #include <ratio> 80936ac495dSmrg #include <regex> 81036ac495dSmrg #include <scoped_allocator> 81136ac495dSmrg #include <set> 81236ac495dSmrg #include <sstream> 81336ac495dSmrg #include <stack> 81436ac495dSmrg #include <stdexcept> 81536ac495dSmrg #include <streambuf> 81636ac495dSmrg #include <string> 81736ac495dSmrg #include <system_error> 81836ac495dSmrg #include <thread> 81936ac495dSmrg #include <tuple> 82036ac495dSmrg #include <typeindex> 82136ac495dSmrg #include <typeinfo> 82236ac495dSmrg #include <type_traits> 82336ac495dSmrg #include <unordered_map> 82436ac495dSmrg #include <unordered_set> 82536ac495dSmrg #include <utility> 82636ac495dSmrg #include <valarray> 82736ac495dSmrg #include <vector> 82836ac495dSmrg ],, 82936ac495dSmrg ac_cv_cxx_stdcxx_11=yes, ac_cv_cxx_stdcxx_11=no) 83036ac495dSmrg AC_LANG_RESTORE 83136ac495dSmrg CXXFLAGS="$ac_save_CXXFLAGS" 83236ac495dSmrg ]) 83336ac495dSmrg if test "$ac_cv_cxx_stdcxx_11" = yes; then 83436ac495dSmrg AC_DEFINE(STDCXX_11_HEADERS,,[Define if ISO C++11 header files are present. ]) 83536ac495dSmrg fi 83636ac495dSmrg]) 83736ac495dSmrg</pre><p>As is the case for TR1 support, these autoconf macros can be made for a finer-grained, per-header-file check. For 83836ac495dSmrg<code class="filename"><unordered_map></code> 83936ac495dSmrg</p><pre class="programlisting"> 84036ac495dSmrg# AC_HEADER_UNORDERED_MAP 84136ac495dSmrgAC_DEFUN([AC_HEADER_UNORDERED_MAP], [ 84236ac495dSmrg AC_CACHE_CHECK(for unordered_map, 84336ac495dSmrg ac_cv_cxx_unordered_map, 84436ac495dSmrg [AC_REQUIRE([AC_COMPILE_STDCXX_11]) 84536ac495dSmrg AC_LANG_SAVE 84636ac495dSmrg AC_LANG_CPLUSPLUS 84736ac495dSmrg ac_save_CXXFLAGS="$CXXFLAGS" 84836ac495dSmrg CXXFLAGS="$CXXFLAGS -std=gnu++11" 84936ac495dSmrg AC_TRY_COMPILE([#include <unordered_map>], [using std::unordered_map;], 85036ac495dSmrg ac_cv_cxx_unordered_map=yes, ac_cv_cxx_unordered_map=no) 85136ac495dSmrg CXXFLAGS="$ac_save_CXXFLAGS" 85236ac495dSmrg AC_LANG_RESTORE 85336ac495dSmrg ]) 85436ac495dSmrg if test "$ac_cv_cxx_unordered_map" = yes; then 85536ac495dSmrg AC_DEFINE(HAVE_UNORDERED_MAP,,[Define if unordered_map is present. ]) 85636ac495dSmrg fi 85736ac495dSmrg]) 85836ac495dSmrg</pre><pre class="programlisting"> 85936ac495dSmrg# AC_HEADER_UNORDERED_SET 86036ac495dSmrgAC_DEFUN([AC_HEADER_UNORDERED_SET], [ 86136ac495dSmrg AC_CACHE_CHECK(for unordered_set, 86236ac495dSmrg ac_cv_cxx_unordered_set, 86336ac495dSmrg [AC_REQUIRE([AC_COMPILE_STDCXX_11]) 86436ac495dSmrg AC_LANG_SAVE 86536ac495dSmrg AC_LANG_CPLUSPLUS 86636ac495dSmrg ac_save_CXXFLAGS="$CXXFLAGS" 86736ac495dSmrg CXXFLAGS="$CXXFLAGS -std=gnu++11" 86836ac495dSmrg AC_TRY_COMPILE([#include <unordered_set>], [using std::unordered_set;], 86936ac495dSmrg ac_cv_cxx_unordered_set=yes, ac_cv_cxx_unordered_set=no) 87036ac495dSmrg CXXFLAGS="$ac_save_CXXFLAGS" 87136ac495dSmrg AC_LANG_RESTORE 87236ac495dSmrg ]) 87336ac495dSmrg if test "$ac_cv_cxx_unordered_set" = yes; then 87436ac495dSmrg AC_DEFINE(HAVE_UNORDERED_SET,,[Define if unordered_set is present. ]) 87536ac495dSmrg fi 87636ac495dSmrg]) 87736ac495dSmrg</pre><p> 87836ac495dSmrg Some C++11 features first appeared in GCC 4.3 and could be enabled by 87936ac495dSmrg <code class="option">-std=c++0x</code> and <code class="option">-std=gnu++0x</code> for GCC 88036ac495dSmrg releases which pre-date the 2011 standard. Those C++11 features and GCC's 88136ac495dSmrg support for them were still changing until the 2011 standard was finished, 88236ac495dSmrg but the autoconf checks above could be extended to test for incomplete 88336ac495dSmrg C++11 support with <code class="option">-std=c++0x</code> and 88436ac495dSmrg <code class="option">-std=gnu++0x</code>. 88536ac495dSmrg</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.third.iterator_type"></a> 88636ac495dSmrg <code class="code">Container::iterator_type</code> is not necessarily <code class="code">Container::value_type*</code> 88736ac495dSmrg</h4></div></div></div><p> 88836ac495dSmrg This is a change in behavior from older versions. Now, most 88936ac495dSmrg <span class="type">iterator_type</span> typedefs in container classes are POD 89036ac495dSmrg objects, not <span class="type">value_type</span> pointers. 89136ac495dSmrg</p></div></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id-1.3.6.3.8.5.2"></a><p><span class="title"><em> 89236ac495dSmrg <a class="link" href="http://www.kegel.com/gcc/gcc4.html" target="_top"> 89336ac495dSmrg Migrating to GCC 4.1 89436ac495dSmrg </a> 89536ac495dSmrg </em>. </span><span class="author"><span class="firstname">Dan</span> <span class="surname">Kegel</span>. </span></p></div><div class="biblioentry"><a id="id-1.3.6.3.8.5.3"></a><p><span class="title"><em> 89636ac495dSmrg <a class="link" href="https://lists.debian.org/debian-gcc/2006/03/msg00405.html" target="_top"> 89736ac495dSmrg Building the Whole Debian Archive with GCC 4.1: A Summary 89836ac495dSmrg </a> 89936ac495dSmrg </em>. </span><span class="author"><span class="firstname">Martin</span> <span class="surname">Michlmayr</span>. </span></p></div><div class="biblioentry"><a id="id-1.3.6.3.8.5.4"></a><p><span class="title"><em> 90036ac495dSmrg <a class="link" href="http://annwm.lbl.gov/~leggett/Atlas/gcc-3.2.html" target="_top"> 90136ac495dSmrg Migration guide for GCC-3.2 90236ac495dSmrg </a> 90336ac495dSmrg </em>. </span></p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="api.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_porting.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="appendix_free.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">API Evolution and Deprecation History </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix C. 90436ac495dSmrg Free Software Needs Free Documentation 90536ac495dSmrg 90636ac495dSmrg</td></tr></table></div></body></html>