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="sect3" title="No ios_base"><div class="titlepage"><div><div><h4 class="title"><a id="id
646429"></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="sect3" title="No cout in ostream.h, no cin in istream.h"><div class="titlepage"><div><div><h4 class="title"><a id="id
646461"></a>No <code class="code">cout</code> in <code class="code">ostream.h</code>, no <code class="code">cin</code> in <code class="code">istream.h</code></h4></div></div></div><p>
+</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="sect3" title="No ios_base"><div class="titlepage"><div><div><h4 class="title"><a id="id
508624"></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="sect3" title="No cout in ostream.h, no cin in istream.h"><div class="titlepage"><div><div><h4 class="title"><a id="id
508656"></a>No <code class="code">cout</code> in <code class="code">ostream.h</code>, no <code class="code">cin</code> in <code class="code">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>
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.
-</p></div></div><div class="sect2" title="Second"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.second"></a>Second</h3></div></div></div><p>
+</p></div></div><div class="sect2" title="Second"><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>
+</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="sect3" title="Namespace std:: not supported"><div class="titlepage"><div><div><h4 class="title"><a id="id
646559"></a>Namespace <code class="code">std::</code> not supported</h4></div></div></div><p>
+</p><div class="sect3" title="Namespace std:: not supported"><div class="titlepage"><div><div><h4 class="title"><a id="id
508754"></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>
+ </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
probably applies to some other compilers as well.
</p><p>
Second, experiment with a variety of pre-processor tricks.
- </p><p>
+ </p><p>
By defining <code class="code">std</code> as a macro, fully-qualified namespace
calls become global. Volia.
</p><pre class="programlisting">
ac_cv_cxx_have_std_namespace,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
- AC_TRY_COMPILE([#include <iostream>
- std::istream& is = std::cin;],,
+ 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
])
AC_DEFINE(HAVE_NAMESPACE_STD,,[Define if g++ supports namespace std. ])
fi
])
-</pre></div><div class="sect3" title="Illegal iterator usage"><div class="titlepage"><div><div><h4 class="title"><a id="id
699742"></a>Illegal iterator usage</h4></div></div></div><p>
+</pre></div><div class="sect3" title="Illegal iterator usage"><div class="titlepage"><div><div><h4 class="title"><a id="id
508877"></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" type="disc"><li class="listitem"><p>
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="sect3" title="isspace from cctype is a macro"><div class="titlepage"><div><div><h4 class="title"><a id="id699804"></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:
- </p><pre class="programlisting">
-#include <cctype>
-int main() { std::isspace('X'); }
+ </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>
+</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.
+// This keeps isalnum, et al from being propagated as macros.
#if __linux__
# define __NO_CTYPE 1
#endif
(<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="sect3" title="No vector::at, deque::at, string::at"><div class="titlepage"><div><div><h4 class="title"><a id="id
699897"></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>
+</p></div><div class="sect3" title="No vector::at, deque::at, string::at"><div class="titlepage"><div><div><h4 class="title"><a id="id
502656"></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)
#include <vector>
#include <deque>
#include <string>
-
+
using namespace std;
],
[
</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="sect3" title="No std::char_traits<char>::eof"><div class="titlepage"><div><div><h4 class="title"><a id="id
716937"></a>No <code class="code">std::char_traits<char>::eof</code></h4></div></div></div><p>
+</p></div><div class="sect3" title="No std::char_traits<char>::eof"><div class="titlepage"><div><div><h4 class="title"><a id="id
502694"></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
#else
#define CPP_EOF EOF
#endif
-</pre></div><div class="sect3" title="No string::clear"><div class="titlepage"><div><div><h4 class="title"><a id="id
716955"></a>No <code class="code">string::clear</code></h4></div></div></div><p>
+</pre></div><div class="sect3" title="No string::clear"><div class="titlepage"><div><div><h4 class="title"><a id="id
502712"></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
+void
clear() { _M_mutate(0, this->size(), 0); }
</pre><pre class="programlisting">
-basic_string&
+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());
+ _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="sect3" title="Removal of ostream::form and istream::scan extensions"><div class="titlepage"><div><div><h4 class="title"><a id="id717001"></a>
+</p></div><div class="sect3" title="Removal of ostream::form and istream::scan extensions"><div class="titlepage"><div><div><h4 class="title"><a id="id502758"></a>
Removal of <code class="code">ostream::form</code> and <code class="code">istream::scan</code>
extensions
-</h4></div></div></div><p>
+</h4></div></div></div><p>
These are no longer supported. Please use stringstreams instead.
-</p></div><div class="sect3" title="No basic_stringbuf, basic_stringstream"><div class="titlepage"><div><div><h4 class="title"><a id="id
717020"></a>No <code class="code">basic_stringbuf</code>, <code class="code">basic_stringstream</code></h4></div></div></div><p>
+</p></div><div class="sect3" title="No basic_stringbuf, basic_stringstream"><div class="titlepage"><div><div><h4 class="title"><a id="id
502777"></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" type="disc"><li class="listitem"><p>
+</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
<code class="code">strstream</code> is considered to be deprecated
- </p></li><li class="listitem"><p>
+ </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>
+ </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>
+ 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);)
+ str(input);)
</p></li></ul></div><p>
You can then use output-stringstreams like this:
</p><pre class="programlisting">
#endif
int i;
-iss >> 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);
throw runtime_error(..)
any = temp;
}
-</pre><p>
- Another example of using stringstreams is in <a class="link" href="bk01pt05ch13s05.html" title="Shrink to Fit">this howto</a>.
+</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="sect3" title="Little or no wide character support"><div class="titlepage"><div><div><h4 class="title"><a id="id
717171"></a>Little or no wide character support</h4></div></div></div><p>
+</p></div><div class="sect3" title="Little or no wide character support"><div class="titlepage"><div><div><h4 class="title"><a id="id
502928"></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="sect3" title="No templatized iostreams"><div class="titlepage"><div><div><h4 class="title"><a id="id
717190"></a>No templatized iostreams</h4></div></div></div><p>
+ </p></div><div class="sect3" title="No templatized iostreams"><div class="titlepage"><div><div><h4 class="title"><a id="id
502947"></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="sect3" title="Thread safety issues"><div class="titlepage"><div><div><h4 class="title"><a id="id
717209"></a>Thread safety issues</h4></div></div></div><p>
+ </p></div><div class="sect3" title="Thread safety issues"><div class="titlepage"><div><div><h4 class="title"><a id="id
502966"></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
release series.
</p></li><li class="listitem"><p>
<a class="ulink" 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>
+ 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
</p></div></div><div class="sect2" title="Third"><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
- (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.
</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="sect3" title="Pre-ISO headers moved to backwards or removed"><div class="titlepage"><div><div><h4 class="title"><a id="id
706015"></a>Pre-ISO headers moved to backwards or removed</h4></div></div></div><p> The pre-ISO C++ headers
+ 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="sect3" title="Pre-ISO headers moved to backwards or removed"><div class="titlepage"><div><div><h4 class="title"><a id="id
426691"></a>Pre-ISO headers moved to backwards or removed</h4></div></div></div><p> The pre-ISO C++ 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.
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -Wno-deprecated"
+ CXXFLAGS="$CXXFLAGS -Wno-deprecated"
# Omit defalloc.h, as compilation with newer compilers is problematic.
AC_TRY_COMPILE([
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" title="Extension headers hash_map, hash_set moved to ext or backwards"><div class="titlepage"><div><div><h4 class="title"><a id="id
706097"></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="id
426772"></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
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.:
</p><pre class="programlisting">
#ifdef __GNUC__
#if __GNUC__ < 3
- #include <hash_map.h>
- namespace extension { using ::hash_map; }; // inherit globals
+ #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
+ #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;
+ namespace extension = std;
#endif
- extension::hash_map<int,int> my_map;
+ extension::hash_map<int,int> my_map;
</pre><p>This is a bit cleaner than defining typedefs for all the
- instantiations you might need.
+ 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_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -Werror"
+ 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_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -Werror"
+ 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_DEFINE(HAVE_EXT_HASH_SET,,[Define if ext/hash_set is present. ])
fi
])
-</pre></div><div class="sect3" title="No ios::nocreate/ios::noreplace."><div class="titlepage"><div><div><h4 class="title"><a id="id706200"></a>No <code class="code">ios::nocreate/ios::noreplace</code>.
+</pre></div><div class="sect3" title="No ios::nocreate/ios::noreplace."><div class="titlepage"><div><div><h4 class="title"><a id="id426874"></a>No <code class="code">ios::nocreate/ios::noreplace</code>.
</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
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> ?).
-</p></div><div class="sect3" title="No stream::attach(int fd)"><div class="titlepage"><div><div><h4 class="title"><a id="id703184"></a>
+</p></div><div class="sect3" title="No stream::attach(int fd)"><div class="titlepage"><div><div><h4 class="title"><a id="id426921"></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
<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.
+ stream-constructor.
</p><p>
An extension is available that implements this.
<code class="filename">ext/stdio_filebuf.h</code> contains a derived class called
descriptor, and provides the <code class="code">fd()</code> function.
</p><p>
For another example of this, refer to
- <a class="ulink" href="http://www.josuttis.com/cppcode/fdstream.html" target="_top">fdstream example</a>
+ <a class="ulink" href="http://www.josuttis.com/cppcode/fdstream.html" target="_top">fdstream example</a>
by Nicolai Josuttis.
-</p></div><div class="sect3" title="Support for C++98 dialect."><div class="titlepage"><div><div><h4 class="title"><a id="id703247"></a>
+</p></div><div class="sect3" title="Support for C++98 dialect."><div class="titlepage"><div><div><h4 class="title"><a id="id426985"></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_DEFINE(STDCXX_98_HEADERS,,[Define if ISO C++ 1998 header files are present. ])
fi
])
-</pre></div><div class="sect3" title="Support for C++TR1 dialect."><div class="titlepage"><div><div><h4 class="title"><a id="id703275"></a>
+</pre></div><div class="sect3" title="Support for C++TR1 dialect."><div class="titlepage"><div><div><h4 class="title"><a id="id489807"></a>
Support for C++TR1 dialect.
</h4></div></div></div><p>Check for library coverage of the TR1 standard.
</p><pre class="programlisting">
AC_DEFINE(HAVE_TR1_UNORDERED_SET,,[Define if tr1/unordered_set is present. ])
fi
])
-</pre></div><div class="sect3" title="Support for C++0x dialect."><div class="titlepage"><div><div><h4 class="title"><a id="id703319"></a>
+</pre></div><div class="sect3" title="Support for C++0x dialect."><div class="titlepage"><div><div><h4 class="title"><a id="id489851"></a>
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">
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([
template <typename T>
- struct check
+ struct check
{
static_assert(sizeof(int) <= sizeof(T), "not big enough");
};
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=c++0x"
+ CXXFLAGS="$CXXFLAGS -std=c++0x"
AC_TRY_COMPILE([
template <typename T>
- struct check
+ struct check
{
static_assert(sizeof(int) <= sizeof(T), "not big enough");
};
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=gnu++0x"
+ CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([
template <typename T>
- struct check
+ struct check
{
static_assert(sizeof(int) <= sizeof(T), "not big enough");
};
AC_LANG_RESTORE
])
- if test "$ac_cv_cxx_compile_cxx0x_native" = yes ||
- test "$ac_cv_cxx_compile_cxx0x_cxx" = yes ||
+ if test "$ac_cv_cxx_compile_cxx0x_native" = yes ||
+ test "$ac_cv_cxx_compile_cxx0x_cxx" = yes ||
test "$ac_cv_cxx_compile_cxx0x_gxx" = yes; then
AC_DEFINE(HAVE_STDCXX_0X,,[Define if g++ supports C++0x features. ])
fi
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=gnu++0x"
+ CXXFLAGS="$CXXFLAGS -std=gnu++0x"
AC_TRY_COMPILE([
#include <cassert>
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=gnu++0x"
+ CXXFLAGS="$CXXFLAGS -std=gnu++0x"
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_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=gnu++0x"
+ CXXFLAGS="$CXXFLAGS -std=gnu++0x"
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_DEFINE(HAVE_UNORDERED_SET,,[Define if unordered_set is present. ])
fi
])
-</pre></div><div class="sect3" title="Container::iterator_type is not necessarily Container::value_type*"><div class="titlepage"><div><div><h4 class="title"><a id="id703396"></a>
+</pre></div><div class="sect3" title="Container::iterator_type is not necessarily Container::value_type*"><div class="titlepage"><div><div><h4 class="title"><a id="id489928"></a>
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" title="Bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry" title="Migrating to GCC 4.1"><a id="id703425"></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 class="ulink" href="http://www.kegel.com/gcc/gcc4.html" target="_top">
- </a>
- . </span></p></div><div class="biblioentry" title="Building the Whole Debian Archive with GCC 4.1: A Summary"><a id="id703458"></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">
<a class="ulink" href="http://lists.debian.org/debian-gcc/2006/03/msg00405.html" target="_top">
+ <em class="citetitle">
+ Building the Whole Debian Archive with GCC 4.1: A Summary
+ </em>
</a>
- . </span></p></div><div class="biblioentry" title="Migration guide for GCC-3.2"><a id="id703491"></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">
<a class="ulink" href="http://annwm.lbl.gov/~leggett/Atlas/gcc-3.2.html" target="_top">
+ <em class="citetitle">
+ Migration guide for GCC-3.2
+ </em>
</a>
. </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
OSDN Git Service
