1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905
  
     | 
    
      <?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 Vsnapshot" /><meta name="keywords" content="ISO C++, backwards" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="appendix_porting.html" title="Appendix B.  Porting and Maintenance" /><link rel="prev" href="api.html" title="API Evolution and Deprecation History" /><link rel="next" href="appendix_free.html" title="Appendix C.  Free Software Needs Free Documentation" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Backwards Compatibility</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="api.html">Prev</a> </td><th width="60%" align="center">Appendix B. 
  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 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
      not supported.
</p><p>For those of you new to ISO C++ (welcome, time travelers!), the
      ancient pre-ISO headers have new names.
      The C++ FAQ has a good explanation in <a class="link" href="https://isocpp.org/wiki/faq/coding-standards#std-headers" target="_top">What's
      the difference between <xxx> and <xxx.h> headers?</a>.
   </p><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="https://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> 
     |