<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!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-NS Stylesheets V1.78.1" /><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. Porting and Maintenance </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 separate GNU project, although reliably paired with GCC. Rumors imply that it had a working relationship with at least two kinds of dinosaur. </p><p>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 <code class="classname">list<T></code> and do not need to be created by <code class="function">genclass</code>. (For that matter, templates exist now and are well-supported, whereas genclass (mostly) predates them.) </p><p>There are other classes in libg++ that are not specified in the ISO Standard (e.g., statistical analysis). While there are a lot of really useful things that are used by a lot of people, the Standards Committee couldn't include everything, and so a lot of those <span class="quote">“<span class="quote">obvious</span>”</span> classes didn't get included. </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>. </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> In earlier versions of the standard, <code class="filename"><fstream.h></code>, <code class="filename"><ostream.h></code> and <code class="filename"><istream.h></code> used to define <code class="code">cout</code>, <code class="code">cin</code> and so on. ISO C++ specifies that one needs to include <code class="filename"><iostream></code> explicitly to get the required definitions. </p><p> Some include adjustment may be required.</p><p>This project is no longer maintained or supported, and the sources archived. For the desperate, the <a class="link" href="http://gcc.gnu.org/extensions.html" target="_top">GCC extensions page</a> describes where to find the last libg++ source. The code is considered replaced and rewritten. </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> The second generation GNU C++ library was called libstdc++, or libstdc++-v2. It spans the time between libg++ and pre-ISO C++ standardization and is usually associated with the following GCC releases: egcs 1.x, gcc 2.95, and gcc 2.96. </p><p> The STL portions of this library are based on SGI/HP STL release 3.11. </p><p> This project is no longer maintained or supported, and the sources archived. The code is considered replaced and rewritten. </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.second.std"></a>Namespace <code class="code">std::</code> not supported</h4></div></div></div><p> Some care is required to support C++ compiler and or library implementation that do not have the standard library in <code class="code">namespace std</code>. </p><p> The following sections list some possible solutions to support compilers that cannot ignore <code class="code">std::</code>-qualified names. </p><p> 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 <code class="code">std::</code>, as the compilers use <code class="option">-fno-honor-std</code> (ignore <code class="code">std::</code>, <code class="code">:: = std::</code>) by default. That is, the responsibility for enabling or disabling <code class="code">std::</code> is on the user; the maintainer does not have to care about it. This probably applies to some other compilers as well. </p><p> Second, experiment with a variety of pre-processor tricks. </p><p> By defining <code class="code">std</code> as a macro, fully-qualified namespace calls become global. Volia. </p><pre class="programlisting"> #ifdef WICKEDLY_OLD_COMPILER # define std #endif </pre><p> Thanks to Juergen Heinzl who posted this solution on gnu.gcc.help. </p><p> Another pre-processor based approach is to define a macro <code class="code">NAMESPACE_STD</code>, which is defined to either <span class="quote">“<span class="quote"> </span>”</span> or <span class="quote">“<span class="quote">std</span>”</span> based on a compile-type test. On GNU systems, this can be done with autotools by means of an autoconf test (see below) for <code class="code">HAVE_NAMESPACE_STD</code>, then using that to set a value for the <code class="code">NAMESPACE_STD</code> macro. At that point, one is able to use <code class="code">NAMESPACE_STD::string</code>, which will evaluate to <code class="code">std::string</code> or <code class="code">::string</code> (i.e., in the global namespace on systems that do not put <code class="code">string</code> in <code class="code">std::</code>). </p><pre class="programlisting"> 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 ]) </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> The following illustrate implementation-allowed illegal iterator use, and then correct use. </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p> you cannot do <code class="code">ostream::operator<<(iterator)</code> to print the address of the iterator => use <code class="code">operator<< &*iterator</code> instead </p></li><li class="listitem"><p> you cannot clear an iterator's reference (<code class="code">iterator = 0</code>) => use <code class="code">iterator = iterator_type();</code> </p></li><li class="listitem"><p> <code class="code">if (iterator)</code> won't work any more => use <code class="code">if (iterator != iterator_type())</code> </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 </h4></div></div></div><p> Glibc 2.0.x and 2.1.x define <code class="filename"><ctype.h></code> functionality as macros (isspace, isalpha etc.). </p><p> This implementations of libstdc++, however, keep these functions as macros, and so it is not back-portable to use fully qualified names. For example: </p><pre class="programlisting"> #include <cctype> int main() { std::isspace('X'); } </pre><p> Results in something like this: </p><pre class="programlisting"> std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ; </pre><p> A solution is to modify a header-file so that the compiler tells <code class="filename"><ctype.h></code> to define functions instead of macros: </p><pre class="programlisting"> // This keeps isalnum, et al from being propagated as macros. #if __linux__ # define __NO_CTYPE 1 #endif </pre><p> Then, include <code class="filename"><ctype.h></code> </p><p> Another problem arises if you put a <code class="code">using namespace std;</code> declaration at the top, and include <code class="filename"><ctype.h></code>. This will result in ambiguities between the definitions in the global namespace (<code class="filename"><ctype.h></code>) and the definitions in namespace <code class="code">std::</code> (<code class="code"><cctype></code>). </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> One solution is to add an autoconf-test for this: </p><pre class="programlisting"> 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(<span class="quote">“<span class="quote">test_string</span>”</span>); test_string.at(3); ], [AC_MSG_RESULT(yes) AC_DEFINE(HAVE_CONTAINER_AT)], [AC_MSG_RESULT(no)]) </pre><p> If you are using other (non-GNU) compilers it might be a good idea to check for <code class="code">string::at</code> separately. </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> Use some kind of autoconf test, plus this: </p><pre class="programlisting"> #ifdef HAVE_CHAR_TRAITS #define CPP_EOF std::char_traits<char>::eof() #else #define CPP_EOF EOF #endif </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> There are two functions for deleting the contents of a string: <code class="code">clear</code> and <code class="code">erase</code> (the latter returns the string). </p><pre class="programlisting"> void clear() { _M_mutate(0, this->size(), 0); } </pre><pre class="programlisting"> 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()); } </pre><p> Unfortunately, <code class="code">clear</code> is not implemented in this version, so you should use <code class="code">erase</code> (which is probably faster than <code class="code">operator=(charT*)</code>). </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.second.ostreamform_istreamscan"></a> Removal of <code class="code">ostream::form</code> and <code class="code">istream::scan</code> extensions </h4></div></div></div><p> These are no longer supported. Please use stringstreams instead. </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> Although the ISO standard <code class="code">i/ostringstream</code>-classes are provided, (<code class="filename"><sstream></code>), for compatibility with older implementations the pre-ISO <code class="code">i/ostrstream</code> (<code class="filename"><strstream></code>) interface is also provided, with these caveats: </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p> <code class="code">strstream</code> is considered to be deprecated </p></li><li class="listitem"><p> <code class="code">strstream</code> is limited to <code class="code">char</code> </p></li><li class="listitem"><p> with <code class="code">ostringstream</code> you don't have to take care of terminating the string or freeing its memory </p></li><li class="listitem"><p> <code class="code">istringstream</code> can be re-filled (clear(); str(input);) </p></li></ul></div><p> You can then use output-stringstreams like this: </p><pre class="programlisting"> #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 </pre><p> Input-stringstreams can be used similarly: </p><pre class="programlisting"> std::string input; ... #ifdef HAVE_SSTREAM std::istringstream iss(input); #else std::istrstream iss(input.c_str()); #endif int i; iss >> i; </pre><p> One (the only?) restriction is that an istrstream cannot be re-filled: </p><pre class="programlisting"> std::istringstream iss(numerator); iss >> m_num; // this is not possible with istrstream iss.clear(); iss.str(denominator); iss >> m_den; </pre><p> If you don't care about speed, you can put these conversions in a template-function: </p><pre class="programlisting"> 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; } </pre><p> Another example of using stringstreams is in <a class="link" href="strings.html#strings.string.shrink" title="Shrink to Fit">this howto</a>. </p><p> There is additional information in the libstdc++-v2 info files, in particular <span class="quote">“<span class="quote">info iostream</span>”</span>. </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> Classes <code class="classname">wstring</code> and <code class="classname">char_traits<wchar_t></code> are not supported. </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> Classes <code class="classname">wfilebuf</code> and <code class="classname">wstringstream</code> are not supported. </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> 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. </p><p> 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. </p><p> 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 <span class="emphasis"><em>fast</em></span> 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 <a class="link" href="http://www.sgi.com/tech/stl/thread_safety.html" target="_top">same definition that SGI</a> 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. </p><p> 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. </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p> 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 six situations involving threads</a> for the 3.0 release series. </p></li><li class="listitem"><p> <a class="link" href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html" target="_top"> This message</a> inspired a recent updating of issues with threading and the SGI STL library. It also contains some example POSIX-multithreaded STL code. </p></li></ul></div><p> (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.) </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 libstdc++-v3. </p><p>The subset commonly known as the Standard Template Library (clauses 23 through 25, mostly) is adapted from the final release of the SGI STL (version 3.3), with extensive changes. </p><p>A more formal description of the V3 goals can be found in the official <a class="link" href="source_design_notes.html" title="Design Notes">design document</a>. </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 moved to backwards or removed</h4></div></div></div><p> The pre-ISO C++ headers (<code class="filename"><iostream.h></code>, <code class="filename"><defalloc.h></code> etc.) are available, unlike previous libstdc++ versions, but inclusion generates a warning that you are using deprecated headers. </p><p>This compatibility layer is constructed by including the standard C++ headers, and injecting any items in <code class="code">std::</code> into the global namespace. </p><p>For those of you new to ISO C++ (welcome, time travelers!), no, that isn't a typo. Yes, the headers really have new names. Marshall Cline's C++ FAQ Lite has a good explanation in <a class="link" href="http://www.parashift.com/c++-faq-lite/std-headers.html" target="_top">What's the difference between <xxx> and <xxx.h> headers?</a>. </p><p> Some include adjustment may be required. What follows is an autoconf test that defines <code class="code">PRE_STDCXX_HEADERS</code> when they exist.</p><pre class="programlisting"> # AC_HEADER_PRE_STDCXX AC_DEFUN([AC_HEADER_PRE_STDCXX], [ AC_CACHE_CHECK(for pre-ISO C++ include files, ac_cv_cxx_pre_stdcxx, [AC_LANG_SAVE AC_LANG_CPLUSPLUS ac_save_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -Wno-deprecated" # Omit defalloc.h, as compilation with newer compilers is problematic. AC_TRY_COMPILE([ #include <new.h> #include <iterator.h> #include <alloc.h> #include <set.h> #include <hashtable.h> #include <hash_set.h> #include <fstream.h> #include <tempbuf.h> #include <istream.h> #include <bvector.h> #include <stack.h> #include <rope.h> #include <complex.h> #include <ostream.h> #include <heap.h> #include <iostream.h> #include <function.h> #include <multimap.h> #include <pair.h> #include <stream.h> #include <iomanip.h> #include <slist.h> #include <tree.h> #include <vector.h> #include <deque.h> #include <multiset.h> #include <list.h> #include <map.h> #include <algobase.h> #include <hash_map.h> #include <algo.h> #include <queue.h> #include <streambuf.h> ],, ac_cv_cxx_pre_stdcxx=yes, ac_cv_cxx_pre_stdcxx=no) CXXFLAGS="$ac_save_CXXFLAGS" AC_LANG_RESTORE ]) if test "$ac_cv_cxx_pre_stdcxx" = yes; then AC_DEFINE(PRE_STDCXX_HEADERS,,[Define if pre-ISO C++ header files are present. ]) fi ]) </pre><p>Porting between pre-ISO headers and ISO headers is simple: headers like <code class="filename"><vector.h></code> can be replaced with <code class="filename"><vector></code> and a using directive <code class="code">using namespace std;</code> can be put at the global scope. This should be enough to get this code compiling, assuming the other usage is correct. </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 replaced by standardized libraries. In particular, the <code class="classname">unordered_map</code> and <code class="classname">unordered_set</code> containers of TR1 and C++ 2011 are suitable replacements for the non-standard <code class="classname">hash_map</code> and <code class="classname">hash_set</code> containers in the SGI STL. </p><p> Header files <code class="filename"><hash_map></code> and <code class="filename"><hash_set></code> moved to <code class="filename"><ext/hash_map></code> and <code class="filename"><ext/hash_set></code>, respectively. At the same time, all types in these files are enclosed in <code class="code">namespace __gnu_cxx</code>. Later versions deprecate these files, and suggest using TR1's <code class="filename"><unordered_map></code> and <code class="filename"><unordered_set></code> instead. </p><p>The extensions are no longer in the global or <code class="code">std</code> namespaces, instead they are declared in the <code class="code">__gnu_cxx</code> namespace. For maximum portability, consider defining a namespace alias to use to talk about extensions, e.g.: </p><pre class="programlisting"> #ifdef __GNUC__ #if __GNUC__ < 3 #include <hash_map.h> namespace extension { using ::hash_map; }; // inherit globals #else #include <backward/hash_map> #if __GNUC__ == 3 && __GNUC_MINOR__ == 0 namespace extension = std; // GCC 3.0 #else namespace extension = ::__gnu_cxx; // GCC 3.1 and later #endif #endif #else // ... there are other compilers, right? namespace extension = std; #endif extension::hash_map<int,int> my_map; </pre><p>This is a bit cleaner than defining typedefs for all the instantiations you might need. </p><p>The following autoconf tests check for working HP/SGI hash containers. </p><pre class="programlisting"> # AC_HEADER_EXT_HASH_MAP AC_DEFUN([AC_HEADER_EXT_HASH_MAP], [ AC_CACHE_CHECK(for ext/hash_map, ac_cv_cxx_ext_hash_map, [AC_LANG_SAVE AC_LANG_CPLUSPLUS ac_save_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -Werror" AC_TRY_COMPILE([#include <ext/hash_map>], [using __gnu_cxx::hash_map;], ac_cv_cxx_ext_hash_map=yes, ac_cv_cxx_ext_hash_map=no) CXXFLAGS="$ac_save_CXXFLAGS" AC_LANG_RESTORE ]) if test "$ac_cv_cxx_ext_hash_map" = yes; then AC_DEFINE(HAVE_EXT_HASH_MAP,,[Define if ext/hash_map is present. ]) fi ]) </pre><pre class="programlisting"> # AC_HEADER_EXT_HASH_SET AC_DEFUN([AC_HEADER_EXT_HASH_SET], [ AC_CACHE_CHECK(for ext/hash_set, ac_cv_cxx_ext_hash_set, [AC_LANG_SAVE AC_LANG_CPLUSPLUS ac_save_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -Werror" AC_TRY_COMPILE([#include <ext/hash_set>], [using __gnu_cxx::hash_set;], ac_cv_cxx_ext_hash_set=yes, ac_cv_cxx_ext_hash_set=no) CXXFLAGS="$ac_save_CXXFLAGS" AC_LANG_RESTORE ]) if test "$ac_cv_cxx_ext_hash_set" = yes; then AC_DEFINE(HAVE_EXT_HASH_SET,,[Define if ext/hash_set is present. ]) fi ]) </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>. </h4></div></div></div><p>Historically these flags were used with iostreams to control whether new files are created or not when opening a file stream, similar to the <code class="code">O_CREAT</code> and <code class="code">O_EXCL</code> flags for the <code class="function">open(2)</code> system call. Because iostream modes correspond to <code class="function">fopen(3)</code> modes these flags are not supported. For input streams a new file will not be created anyway, so <code class="code">ios::nocreate</code> is not needed. For output streams, a new file will be created if it does not exist, which is consistent with the behaviour of <code class="function">fopen</code>. </p><p>When one of these flags is needed a possible alternative is to attempt to open the file using <span class="type">std::ifstream</span> first to determine whether the file already exists or not. This may not be reliable however, because whether the file exists or not could change between opening the <span class="type">std::istream</span> and re-opening with an output stream. If you need to check for existence and open a file as a single operation then you will need to use OS-specific facilities outside the C++ standard library, such as <code class="function">open(2)</code>. </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.third.streamattach"></a> No <code class="code">stream::attach(int fd)</code> </h4></div></div></div><p> Phil Edwards writes: It was considered and rejected for the ISO standard. Not all environments use file descriptors. Of those that do, not all of them use integers to represent them. </p><p> For a portable solution (among systems which use file descriptors), you need to implement a subclass of <code class="code">std::streambuf</code> (or <code class="code">std::basic_streambuf<..></code>) which opens a file given a descriptor, and then pass an instance of this to the stream-constructor. </p><p> An extension is available that implements this. <code class="filename"><ext/stdio_filebuf.h></code> contains a derived class called <a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00074.html" target="_top"><code class="code">__gnu_cxx::stdio_filebuf</code></a>. This class can be constructed from a C <code class="code">FILE*</code> or a file descriptor, and provides the <code class="code">fd()</code> function. </p><p> For another example of this, refer to <a class="link" href="http://www.josuttis.com/cppcode/fdstream.html" target="_top">fdstream example</a> by Nicolai Josuttis. </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.third.support_cxx98"></a> Support for C++98 dialect. </h4></div></div></div><p>Check for complete library coverage of the C++1998/2003 standard. </p><pre class="programlisting"> # AC_HEADER_STDCXX_98 AC_DEFUN([AC_HEADER_STDCXX_98], [ AC_CACHE_CHECK(for ISO C++ 98 include files, ac_cv_cxx_stdcxx_98, [AC_LANG_SAVE AC_LANG_CPLUSPLUS AC_TRY_COMPILE([ #include <cassert> #include <cctype> #include <cerrno> #include <cfloat> #include <ciso646> #include <climits> #include <clocale> #include <cmath> #include <csetjmp> #include <csignal> #include <cstdarg> #include <cstddef> #include <cstdio> #include <cstdlib> #include <cstring> #include <ctime> #include <algorithm> #include <bitset> #include <complex> #include <deque> #include <exception> #include <fstream> #include <functional> #include <iomanip> #include <ios> #include <iosfwd> #include <iostream> #include <istream> #include <iterator> #include <limits> #include <list> #include <locale> #include <map> #include <memory> #include <new> #include <numeric> #include <ostream> #include <queue> #include <set> #include <sstream> #include <stack> #include <stdexcept> #include <streambuf> #include <string> #include <typeinfo> #include <utility> #include <valarray> #include <vector> ],, ac_cv_cxx_stdcxx_98=yes, ac_cv_cxx_stdcxx_98=no) AC_LANG_RESTORE ]) if test "$ac_cv_cxx_stdcxx_98" = yes; then AC_DEFINE(STDCXX_98_HEADERS,,[Define if ISO C++ 1998 header files are present. ]) fi ]) </pre></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.third.support_tr1"></a> Support for C++TR1 dialect. </h4></div></div></div><p>Check for library coverage of the TR1 standard. </p><pre class="programlisting"> # AC_HEADER_STDCXX_TR1 AC_DEFUN([AC_HEADER_STDCXX_TR1], [ AC_CACHE_CHECK(for ISO C++ TR1 include files, ac_cv_cxx_stdcxx_tr1, [AC_LANG_SAVE AC_LANG_CPLUSPLUS AC_TRY_COMPILE([ #include <tr1/array> #include <tr1/ccomplex> #include <tr1/cctype> #include <tr1/cfenv> #include <tr1/cfloat> #include <tr1/cinttypes> #include <tr1/climits> #include <tr1/cmath> #include <tr1/complex> #include <tr1/cstdarg> #include <tr1/cstdbool> #include <tr1/cstdint> #include <tr1/cstdio> #include <tr1/cstdlib> #include <tr1/ctgmath> #include <tr1/ctime> #include <tr1/cwchar> #include <tr1/cwctype> #include <tr1/functional> #include <tr1/memory> #include <tr1/random> #include <tr1/regex> #include <tr1/tuple> #include <tr1/type_traits> #include <tr1/unordered_set> #include <tr1/unordered_map> #include <tr1/utility> ],, ac_cv_cxx_stdcxx_tr1=yes, ac_cv_cxx_stdcxx_tr1=no) AC_LANG_RESTORE ]) if test "$ac_cv_cxx_stdcxx_tr1" = yes; then AC_DEFINE(STDCXX_TR1_HEADERS,,[Define if ISO C++ TR1 header files are present. ]) fi ]) </pre><p>An alternative is to check just for specific TR1 includes, such as <unordered_map> and <unordered_set>. </p><pre class="programlisting"> # AC_HEADER_TR1_UNORDERED_MAP AC_DEFUN([AC_HEADER_TR1_UNORDERED_MAP], [ AC_CACHE_CHECK(for tr1/unordered_map, ac_cv_cxx_tr1_unordered_map, [AC_LANG_SAVE AC_LANG_CPLUSPLUS AC_TRY_COMPILE([#include <tr1/unordered_map>], [using std::tr1::unordered_map;], ac_cv_cxx_tr1_unordered_map=yes, ac_cv_cxx_tr1_unordered_map=no) AC_LANG_RESTORE ]) if test "$ac_cv_cxx_tr1_unordered_map" = yes; then AC_DEFINE(HAVE_TR1_UNORDERED_MAP,,[Define if tr1/unordered_map is present. ]) fi ]) </pre><pre class="programlisting"> # AC_HEADER_TR1_UNORDERED_SET AC_DEFUN([AC_HEADER_TR1_UNORDERED_SET], [ AC_CACHE_CHECK(for tr1/unordered_set, ac_cv_cxx_tr1_unordered_set, [AC_LANG_SAVE AC_LANG_CPLUSPLUS AC_TRY_COMPILE([#include <tr1/unordered_set>], [using std::tr1::unordered_set;], ac_cv_cxx_tr1_unordered_set=yes, ac_cv_cxx_tr1_unordered_set=no) AC_LANG_RESTORE ]) if test "$ac_cv_cxx_tr1_unordered_set" = yes; then AC_DEFINE(HAVE_TR1_UNORDERED_SET,,[Define if tr1/unordered_set is present. ]) fi ]) </pre></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.third.support_cxx11"></a> Support for C++11 dialect. </h4></div></div></div><p>Check for baseline language coverage in the compiler for the C++11 standard. </p><pre class="programlisting"> # AC_COMPILE_STDCXX_11 AC_DEFUN([AC_COMPILE_STDCXX_11], [ AC_CACHE_CHECK(if g++ supports C++11 features without additional flags, ac_cv_cxx_compile_cxx11_native, [AC_LANG_SAVE AC_LANG_CPLUSPLUS AC_TRY_COMPILE([ template <typename T> struct check final { static constexpr T value{ __cplusplus }; }; typedef check<check<bool>> right_angle_brackets; int a; decltype(a) b; typedef check<int> check_type; check_type c{}; check_type&& cr = static_cast<check_type&&>(c); static_assert(check_type::value == 201103L, "C++11 compiler");],, ac_cv_cxx_compile_cxx11_native=yes, ac_cv_cxx_compile_cxx11_native=no) AC_LANG_RESTORE ]) AC_CACHE_CHECK(if g++ supports C++11 features with -std=c++11, ac_cv_cxx_compile_cxx11_cxx, [AC_LANG_SAVE AC_LANG_CPLUSPLUS ac_save_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -std=c++11" AC_TRY_COMPILE([ template <typename T> struct check final { static constexpr T value{ __cplusplus }; }; typedef check<check<bool>> right_angle_brackets; int a; decltype(a) b; typedef check<int> check_type; check_type c{}; check_type&& cr = static_cast<check_type&&>(c); static_assert(check_type::value == 201103L, "C++11 compiler");],, ac_cv_cxx_compile_cxx11_cxx=yes, ac_cv_cxx_compile_cxx11_cxx=no) CXXFLAGS="$ac_save_CXXFLAGS" AC_LANG_RESTORE ]) AC_CACHE_CHECK(if g++ supports C++11 features with -std=gnu++11, ac_cv_cxx_compile_cxx11_gxx, [AC_LANG_SAVE AC_LANG_CPLUSPLUS ac_save_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -std=gnu++11" AC_TRY_COMPILE([ template <typename T> struct check final { static constexpr T value{ __cplusplus }; }; typedef check<check<bool>> right_angle_brackets; int a; decltype(a) b; typedef check<int> check_type; check_type c{}; check_type&& cr = static_cast<check_type&&>(c); static_assert(check_type::value == 201103L, "C++11 compiler");],, ac_cv_cxx_compile_cxx11_gxx=yes, ac_cv_cxx_compile_cxx11_gxx=no) CXXFLAGS="$ac_save_CXXFLAGS" AC_LANG_RESTORE ]) if test "$ac_cv_cxx_compile_cxx11_native" = yes || test "$ac_cv_cxx_compile_cxx11_cxx" = yes || test "$ac_cv_cxx_compile_cxx11_gxx" = yes; then AC_DEFINE(HAVE_STDCXX_11,,[Define if g++ supports C++11 features. ]) fi ]) </pre><p>Check for library coverage of the C++2011 standard. (Some library headers are commented out in this check, they are not currently provided by libstdc++). </p><pre class="programlisting"> # AC_HEADER_STDCXX_11 AC_DEFUN([AC_HEADER_STDCXX_11], [ AC_CACHE_CHECK(for ISO C++11 include files, ac_cv_cxx_stdcxx_11, [AC_REQUIRE([AC_COMPILE_STDCXX_11]) AC_LANG_SAVE AC_LANG_CPLUSPLUS ac_save_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -std=gnu++11" AC_TRY_COMPILE([ #include <cassert> #include <ccomplex> #include <cctype> #include <cerrno> #include <cfenv> #include <cfloat> #include <cinttypes> #include <ciso646> #include <climits> #include <clocale> #include <cmath> #include <csetjmp> #include <csignal> #include <cstdalign> #include <cstdarg> #include <cstdbool> #include <cstddef> #include <cstdint> #include <cstdio> #include <cstdlib> #include <cstring> #include <ctgmath> #include <ctime> // #include <cuchar> #include <cwchar> #include <cwctype> #include <algorithm> #include <array> #include <atomic> #include <bitset> #include <chrono> // #include <codecvt> #include <complex> #include <condition_variable> #include <deque> #include <exception> #include <forward_list> #include <fstream> #include <functional> #include <future> #include <initializer_list> #include <iomanip> #include <ios> #include <iosfwd> #include <iostream> #include <istream> #include <iterator> #include <limits> #include <list> #include <locale> #include <map> #include <memory> #include <mutex> #include <new> #include <numeric> #include <ostream> #include <queue> #include <random> #include <ratio> #include <regex> #include <scoped_allocator> #include <set> #include <sstream> #include <stack> #include <stdexcept> #include <streambuf> #include <string> #include <system_error> #include <thread> #include <tuple> #include <typeindex> #include <typeinfo> #include <type_traits> #include <unordered_map> #include <unordered_set> #include <utility> #include <valarray> #include <vector> ],, ac_cv_cxx_stdcxx_11=yes, ac_cv_cxx_stdcxx_11=no) AC_LANG_RESTORE CXXFLAGS="$ac_save_CXXFLAGS" ]) if test "$ac_cv_cxx_stdcxx_11" = yes; then AC_DEFINE(STDCXX_11_HEADERS,,[Define if ISO C++11 header files are present. ]) fi ]) </pre><p>As is the case for TR1 support, these autoconf macros can be made for a finer-grained, per-header-file check. For <code class="filename"><unordered_map></code> </p><pre class="programlisting"> # AC_HEADER_UNORDERED_MAP AC_DEFUN([AC_HEADER_UNORDERED_MAP], [ AC_CACHE_CHECK(for unordered_map, ac_cv_cxx_unordered_map, [AC_REQUIRE([AC_COMPILE_STDCXX_11]) AC_LANG_SAVE AC_LANG_CPLUSPLUS ac_save_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -std=gnu++11" AC_TRY_COMPILE([#include <unordered_map>], [using std::unordered_map;], ac_cv_cxx_unordered_map=yes, ac_cv_cxx_unordered_map=no) CXXFLAGS="$ac_save_CXXFLAGS" AC_LANG_RESTORE ]) if test "$ac_cv_cxx_unordered_map" = yes; then AC_DEFINE(HAVE_UNORDERED_MAP,,[Define if unordered_map is present. ]) fi ]) </pre><pre class="programlisting"> # AC_HEADER_UNORDERED_SET AC_DEFUN([AC_HEADER_UNORDERED_SET], [ AC_CACHE_CHECK(for unordered_set, ac_cv_cxx_unordered_set, [AC_REQUIRE([AC_COMPILE_STDCXX_11]) AC_LANG_SAVE AC_LANG_CPLUSPLUS ac_save_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -std=gnu++11" AC_TRY_COMPILE([#include <unordered_set>], [using std::unordered_set;], ac_cv_cxx_unordered_set=yes, ac_cv_cxx_unordered_set=no) CXXFLAGS="$ac_save_CXXFLAGS" AC_LANG_RESTORE ]) if test "$ac_cv_cxx_unordered_set" = yes; then AC_DEFINE(HAVE_UNORDERED_SET,,[Define if unordered_set is present. ]) fi ]) </pre><p> Some C++11 features first appeared in GCC 4.3 and could be enabled by <code class="option">-std=c++0x</code> and <code class="option">-std=gnu++0x</code> for GCC releases which pre-date the 2011 standard. Those C++11 features and GCC's support for them were still changing until the 2011 standard was finished, but the autoconf checks above could be extended to test for incomplete C++11 support with <code class="option">-std=c++0x</code> and <code class="option">-std=gnu++0x</code>. </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="backwards.third.iterator_type"></a> <code class="code">Container::iterator_type</code> is not necessarily <code class="code">Container::value_type*</code> </h4></div></div></div><p> This is a change in behavior from older versions. Now, most <span class="type">iterator_type</span> typedefs in container classes are POD objects, not <span class="type">value_type</span> pointers. </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> <a class="link" href="http://www.kegel.com/gcc/gcc4.html" target="_top"> Migrating to GCC 4.1 </a> </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> <a class="link" href="http://lists.debian.org/debian-gcc/2006/03/msg00405.html" target="_top"> Building the Whole Debian Archive with GCC 4.1: A Summary </a> </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> <a class="link" href="http://annwm.lbl.gov/~leggett/Atlas/gcc-3.2.html" target="_top"> Migration guide for GCC-3.2 </a> </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. Free Software Needs Free Documentation </td></tr></table></div></body></html>