<?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">
<?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 Stylesheets V1.73.2" /><meta name="keywords" content=" ISO C++ , backwards " /><meta name="keywords" content=" ISO C++ , library " /><link rel="start" href="../spine.html" title="The GNU C++ Library Documentation" /><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="sect1" lang="en" xml:lang="en"><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="sect2" lang="en" xml:lang="en"><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
+<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 V1.75.2" /><meta name="keywords" content=" ISO C++ , backwards " /><meta name="keywords" content=" ISO C++ , library " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><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="sect1" title="Backwards Compatibility"><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="sect2" title="First"><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.
separate GNU project, although reliably paired with GCC. Rumors imply
that it had a working relationship with at least two kinds of
dinosaur.
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
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
In earlier versions of the standard,
<code class="filename">fstream.h</code>,
<code class="filename">ostream.h</code>
In earlier versions of the standard,
<code class="filename">fstream.h</code>,
<code class="filename">ostream.h</code>
the <a class="ulink" 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.
the <a class="ulink" 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.
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.
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.
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.
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.
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.
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.
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
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
probably applies to some other compilers as well.
</p><p>
Second, experiment with a variety of pre-processor tricks.
probably applies to some other compilers as well.
</p><p>
Second, experiment with a variety of pre-processor tricks.
By defining <code class="code">std</code> as a macro, fully-qualified namespace
calls become global. Volia.
</p><pre class="programlisting">
By defining <code class="code">std</code> as a macro, fully-qualified namespace
calls become global. Volia.
</p><pre class="programlisting">
</p><p>
Another pre-processor based approach is to define a macro
<code class="code">NAMESPACE_STD</code>, which is defined to either
</p><p>
Another pre-processor based approach is to define a macro
<code class="code">NAMESPACE_STD</code>, which is defined to either
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>
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>
- AC_TRY_COMPILE([#include <iostream>
- std::istream& is = std::cin;],,
+ AC_TRY_COMPILE([#include <iostream>
+ std::istream& is = std::cin;],,
The following illustrate implementation-allowed illegal iterator
use, and then correct use.
The following illustrate implementation-allowed illegal iterator
use, and then correct use.
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
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
you cannot clear an iterator's reference (<code class="code">iterator =
0</code>) => use <code class="code">iterator = iterator_type();</code>
you cannot clear an iterator's reference (<code class="code">iterator =
0</code>) => use <code class="code">iterator = iterator_type();</code>
- <code class="code">if (iterator != iterator_type())</code>
- </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id386430"></a><code class="code">isspace</code> from <code class="filename">cctype</code> is a macro
- </h4></div></div></div><p>
+ <code class="code">if (iterator != iterator_type())</code>
+ </p></li></ul></div></div><div class="sect3" title="isspace from cctype is a macro"><div class="titlepage"><div><div><h4 class="title"><a id="id508938"></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:
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">
-std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ;
-</pre><p>
+</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">
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">
(<code class="filename">ctype.h</code>) and the
definitions in namespace <code class="code">std::</code>
(<code class="code"><cctype></code>).
(<code class="filename">ctype.h</code>) and the
definitions in namespace <code class="code">std::</code>
(<code class="code"><cctype></code>).
One solution is to add an autoconf-test for this:
</p><pre class="programlisting">
AC_MSG_CHECKING(for container::at)
One solution is to add an autoconf-test for this:
</p><pre class="programlisting">
AC_MSG_CHECKING(for container::at)
</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.
</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.
Use some kind of autoconf test, plus this:
</p><pre class="programlisting">
#ifdef HAVE_CHAR_TRAITS
Use some kind of autoconf test, plus this:
</p><pre class="programlisting">
#ifdef HAVE_CHAR_TRAITS
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">
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">
clear() { _M_mutate(0, this->size(), 0); }
</pre><pre class="programlisting">
clear() { _M_mutate(0, this->size(), 0); }
</pre><pre class="programlisting">
return this->replace(_M_check(__pos), _M_fold(__pos, __n),
return this->replace(_M_check(__pos), _M_fold(__pos, __n),
}
</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>).
}
</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>).
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:
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:
</pre><p> One (the only?) restriction is that an istrstream cannot be re-filled:
</p><pre class="programlisting">
std::istringstream iss(numerator);
</pre><p> One (the only?) restriction is that an istrstream cannot be re-filled:
</p><pre class="programlisting">
std::istringstream iss(numerator);
Classes <code class="classname">wstring</code> and
<code class="classname">char_traits<wchar_t></code> are
not supported.
Classes <code class="classname">wstring</code> and
<code class="classname">char_traits<wchar_t></code> are
not supported.
Classes <code class="classname">wfilebuf</code> and
<code class="classname">wstringstream</code> are not supported.
Classes <code class="classname">wfilebuf</code> and
<code class="classname">wstringstream</code> are not supported.
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
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
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.
first relevant message in the thread; from there you can use
"Thread Next" to move down the thread. This farm is in
latest-to-oldest order.
Our threading expert Loren gives a breakdown of <a class="ulink" 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.
Our threading expert Loren gives a breakdown of <a class="ulink" 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.
- 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>
+ 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.)
(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.)
- (chapters 23 through 25, mostly) is adapted from the final release
- of the SGI STL (version 3.3), with extensive changes.
+ (chapters 23 through 25, mostly) is adapted from the final release
+ of the SGI STL (version 3.3), with extensive changes.
(<code class="code">iostream.h</code>, <code class="code">defalloc.h</code> etc.) are
available, unlike previous libstdc++ versions, but inclusion
generates a warning that you are using deprecated headers.
(<code class="code">iostream.h</code>, <code class="code">defalloc.h</code> etc.) are
available, unlike previous libstdc++ versions, but inclusion
generates a warning that you are using deprecated headers.
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.
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="sect3"
lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id365186"></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 unordered_map and unordered_set containers of TR1
- are suitable replacement for the non-standard hash_map and hash_set
- containers in the SGI STL.
+</p></div><div class="sect3"
title="Extension headers hash_map, hash_set moved to ext or backwards"><div class="titlepage"><div><div><h4 class="title"><a id="id426772"></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 unordered_map and unordered_set containers of TR1
+ are suitable replacement for the non-standard hash_map and hash_set
+ 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
</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
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>
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.:
+ 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.:
- #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
+ #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
</p><p>The following autoconf tests check for working HP/SGI hash containers.
</p><pre class="programlisting">
# AC_HEADER_EXT_HASH_MAP
</p><p>The following autoconf tests check for working HP/SGI hash containers.
</p><pre class="programlisting">
# AC_HEADER_EXT_HASH_MAP
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_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_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_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"
</h4></div></div></div><p> The existence of <code class="code">ios::nocreate</code> being used for
input-streams has been confirmed, most probably because the author
thought it would be more correct to specify nocreate explicitly. So
it can be left out for input-streams.
</h4></div></div></div><p> The existence of <code class="code">ios::nocreate</code> being used for
input-streams has been confirmed, most probably because the author
thought it would be more correct to specify nocreate explicitly. So
it can be left out for input-streams.
-</p><p>For output streams, “<span class="quote">nocreate</span>” is probably the default,
+</p><p>For output streams, <span class="quote">“<span class="quote">nocreate</span>”</span> is probably the default,
unless you specify <code class="code">std::ios::trunc</code> ? To be safe, you can
open the file for reading, check if it has been opened, and then
decide whether you want to create/replace or not. To my knowledge,
even older implementations support <code class="code">app</code>, <code class="code">ate</code>
and <code class="code">trunc</code> (except for <code class="code">app</code> ?).
unless you specify <code class="code">std::ios::trunc</code> ? To be safe, you can
open the file for reading, check if it has been opened, and then
decide whether you want to create/replace or not. To my knowledge,
even older implementations support <code class="code">app</code>, <code class="code">ate</code>
and <code class="code">trunc</code> (except for <code class="code">app</code> ?).
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
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
<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
<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
</p><p>
An extension is available that implements this.
<code class="filename">ext/stdio_filebuf.h</code> contains a derived class called
</p><p>
An extension is available that implements this.
<code class="filename">ext/stdio_filebuf.h</code> contains a derived class called
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
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
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">
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">
Support for C++TR1 dialect.
</h4></div></div></div><p>Check for library coverage of the TR1 standard.
</p><pre class="programlisting">
Support for C++TR1 dialect.
</h4></div></div></div><p>Check for library coverage of the TR1 standard.
</p><pre class="programlisting">
Support for C++0x dialect.
</h4></div></div></div><p>Check for baseline language coverage in the compiler for the C++0xstandard.
</p><pre class="programlisting">
Support for C++0x dialect.
</h4></div></div></div><p>Check for baseline language coverage in the compiler for the C++0xstandard.
</p><pre class="programlisting">
test "$ac_cv_cxx_compile_cxx0x_gxx" = yes; then
AC_DEFINE(HAVE_STDCXX_0X,,[Define if g++ supports C++0x features. ])
fi
test "$ac_cv_cxx_compile_cxx0x_gxx" = yes; then
AC_DEFINE(HAVE_STDCXX_0X,,[Define if g++ supports C++0x features. ])
fi
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_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_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_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"
Container::iterator_type is not necessarily Container::value_type*
</h4></div></div></div><p>
This is a change in behavior from the previous version. Now, most
<span class="type">iterator_type</span> typedefs in container classes are POD
objects, not <span class="type">value_type</span> pointers.
Container::iterator_type is not necessarily Container::value_type*
</h4></div></div></div><p>
This is a change in behavior from the previous version. 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="id364087"></a><p>[<abbr class="abbrev">
- kegel41
- </abbr>] <span class="title"><i>
- Migrating to GCC 4.1
- </i>. </span><span class="author"><span class="firstname">Dan</span> <span class="surname">Kegel</span>. </span><span class="biblioid">
+</p></div></div><div class="bibliography" title="Bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id489958"></a><p><span class="biblioid">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id374201"></a><p>[<abbr class="abbrev">
- kegel41
- </abbr>] <span class="title"><i>
- Building the Whole Debian Archive with GCC 4.1: A Summary
- </i>. </span><span class="author"><span class="firstname">Martin</span> <span class="surname">Michlmayr</span>. </span><span class="biblioid">
+ <em class="citetitle">
+ Migrating to GCC 4.1
+ </em>
+ </a>
+ . </span><span class="author"><span class="firstname">Dan</span> <span class="surname">Kegel</span>. </span></p></div><div class="biblioentry"><a id="id489988"></a><p><span class="biblioid">
- . </span></p></div><div class="biblioentry"><a id="id374234"></a><p>[<abbr class="abbrev">
- lbl32
- </abbr>] <span class="title"><i>
- Migration guide for GCC-3.2
- </i>. </span><span class="biblioid">
+ . </span><span class="author"><span class="firstname">Martin</span> <span class="surname">Michlmayr</span>. </span></p></div><div class="biblioentry"><a id="id490020"></a><p><span class="biblioid">
- . </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="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix C. Free Software Needs Free Documentation</td></tr></table></div></body></html>
+ . </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="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix C.
+ Free Software Needs Free Documentation
+
+</td></tr></table></div></body></html>
OSDN Git Service
