Subversion Repositories openrisc

      ISO C++

      backwards

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.

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 list<T> and do not need to be

created by genclass.  (For that matter, templates exist

now and are well-supported, whereas genclass (mostly) predates them.)

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

obvious classes didn't get included.

Known Issues include many of the limitations of its immediate ancestor.

Portability notes and known implementation limitations are as follows.

 At least some older implementations don't have std::ios_base, so you should use std::ios::badbit, std::ios::failbit and std::ios::eofbit and std::ios::goodbit.

        In earlier versions of the standard,

        fstream.h,

        ostream.h

        and istream.h

        used to define

        cout, cin and so on. ISO C++ specifies that one needs to include

        iostream

        explicitly to get the required definitions.

 Some include adjustment may be required.

This project is no longer maintained or supported, and the sources

archived. For the desperate,

the GCC extensions

page 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 STL portions of this library are based on SGI/HP STL release 3.11.

  This project is no longer maintained or supported, and the sources

  archived.  The code is considered replaced and rewritten.

  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

    namespace std.

    The following sections list some possible solutions to support compilers

    that cannot ignore std::-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 std::, as the

    compilers use -fno-honor-std (ignore

    std::, :: = std::) by default. That is,

    the responsibility for enabling or disabling std:: is

    on the user; the maintainer does not have to care about it. This

    probably applies to some other compilers as well.

    Second, experiment with a variety of pre-processor tricks.

    By defining std as a macro, fully-qualified namespace

    calls become global. Volia.

#ifdef WICKEDLY_OLD_COMPILER

# define std

#endif

    Thanks to Juergen Heinzl who posted this solution on gnu.gcc.help.

    Another pre-processor based approach is to define a macro

    NAMESPACE_STD, which is defined to either

      or std based on a compile-type

    test. On GNU systems, this can be done with autotools by means of

    an autoconf test (see below) for HAVE_NAMESPACE_STD,

    then using that to set a value for the NAMESPACE_STD

    macro.  At that point, one is able to use

    NAMESPACE_STD::string, which will evaluate to

    std::string or ::string (i.e., in the

    global namespace on systems that do not put string in

    std::).

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

])

  The following illustrate implementation-allowed illegal iterator

  use, and then correct use.

      you cannot do ostream::operator<<(iterator)

      to print the address of the iterator => use

      operator<< &*iterator instead

      you cannot clear an iterator's reference (iterator =

      0) => use iterator = iterator_type();

      if (iterator) won't work any more => use

      if (iterator != iterator_type())

    Glibc 2.0.x and 2.1.x define 

    class="headerfile">ctype.h functionality as macros

    (isspace, isalpha etc.).

    This implementations of libstdc++, however, keep these functions

    as macros, and so it is not back-portable to use fully qualified

    names. For example:

#include <cctype>

int main() { std::isspace('X'); }

  Results in something like this:

std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ;

  A solution is to modify a header-file so that the compiler tells

  ctype.h to define functions

  instead of macros:

// This keeps isalnum, et al from being propagated as macros.

#if __linux__

# define __NO_CTYPE 1

#endif

  Then, include ctype.h

  Another problem arises if you put a using namespace

  std; declaration at the top, and include 

  class="headerfile">ctype.h. This will result in

  ambiguities between the definitions in the global namespace

  (ctype.h) and the

  definitions in namespace std::

  (<cctype>).

  One solution is to add an autoconf-test for this:

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(test_string);

test_string.at(3);

],

[AC_MSG_RESULT(yes)

AC_DEFINE(HAVE_CONTAINER_AT)],

[AC_MSG_RESULT(no)])

  If you are using other (non-GNU) compilers it might be a good idea

  to check for string::at separately.

  Use some kind of autoconf test, plus this:

#ifdef HAVE_CHAR_TRAITS

#define CPP_EOF std::char_traits<char>::eof()

#else

#define CPP_EOF EOF

#endif

  There are two functions for deleting the contents of a string:

  clear and erase (the latter returns the

  string).

void

clear() { _M_mutate(0, this->size(), 0); }

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());

}

  Unfortunately, clear is not implemented in this

  version, so you should use erase (which is probably

  faster than operator=(charT*)).

  These are no longer supported. Please use stringstreams instead.

  Although the ISO standard i/ostringstream-classes are

  provided, (sstream), for

  compatibility with older implementations the pre-ISO

  i/ostrstream (

  class="headerfile">strstream) interface is also provided,

  with these caveats:

      strstream is considered to be deprecated

      strstream is limited to char

      with ostringstream you don't have to take care of

      terminating the string or freeing its memory

      istringstream can be re-filled (clear();

      str(input);)

  You can then use output-stringstreams like this:

#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

      Input-stringstreams can be used similarly:

std::string input;

...

#ifdef HAVE_SSTREAM

std::istringstream iss(input);

#else

std::istrstream iss(input.c_str());

#endif

int i;

iss >> i;

 One (the only?) restriction is that an istrstream cannot be re-filled:

std::istringstream iss(numerator);

iss >> m_num;

// this is not possible with istrstream

iss.clear();

iss.str(denominator);

iss >> m_den;

If you don't care about speed, you can put these conversions in

      a template-function:

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;

}

  Another example of using stringstreams is in 

  linkend="strings.string.shrink">this howto.

 There is additional information in the libstdc++-v2 info files, in

particular info iostream.

    Classes wstring and

    char_traits<wchar_t> are

    not supported.

    Classes wfilebuf and

    wstringstream 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

    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.

    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.

     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

     fast 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 

     url="http://www.sgi.com/tech/stl/thread_safety.html">same

     definition that SGI 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.

     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.

            Our threading expert Loren gives a breakdown of 

            url="http://gcc.gnu.org/ml/libstdc++/2001-10/msg00024.html">the

            six situations involving threads for the 3.0

            release series.

        This message inspired a recent updating of issues with

        threading and the SGI STL library.  It also contains some

        example POSIX-multithreaded STL code.

     (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.)

 The third generation GNU C++ library is called libstdc++, or

libstdc++-v3.

      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.

      A more formal description of the V3 goals can be found in the

         official design document.

Portability notes and known implementation limitations are as follows.

 The pre-ISO C++ headers

      (iostream.h, defalloc.h etc.) are

      available, unlike previous libstdc++ versions, but inclusion

      generates a warning that you are using deprecated headers.

    This compatibility layer is constructed by including the

    standard C++ headers, and injecting any items in

    std:: into the global namespace.

   For those of you new to ISO C++ (welcome, time travelers!), no,

      that isn't a typo. Yes, the headers really have new names.

      Marshall Cline's C++ FAQ Lite has a good explanation in item

      [27.4].

 Some include adjustment may be required. What follows is an

autoconf test that defines PRE_STDCXX_HEADERS when they

exist.

# AC_HEADER_PRE_STDCXX

AC_DEFUN([AC_HEADER_PRE_STDCXX], [

  AC_CACHE_CHECK(for pre-ISO C++ include files,

  ac_cv_cxx_pre_stdcxx,

  [AC_LANG_SAVE

  AC_LANG_CPLUSPLUS

  ac_save_CXXFLAGS="$CXXFLAGS"

  CXXFLAGS="$CXXFLAGS -Wno-deprecated"

  # Omit defalloc.h, as compilation with newer compilers is problematic.

  AC_TRY_COMPILE([

  #include <new.h>

  #include <iterator.h>

  #include <alloc.h>

  #include <set.h>

  #include <hashtable.h>

  #include <hash_set.h>

  #include <fstream.h>

  #include <tempbuf.h>

  #include <istream.h>

  #include <bvector.h>

  #include <stack.h>

  #include <rope.h>

  #include <complex.h>

  #include <ostream.h>

  #include <heap.h>

  #include <iostream.h>

  #include <function.h>

  #include <multimap.h>

  #include <pair.h>

  #include <stream.h>

  #include <iomanip.h>

  #include <slist.h>

  #include <tree.h>

  #include <vector.h>

  #include <deque.h>

  #include <multiset.h>

  #include <list.h>

  #include <map.h>

  #include <algobase.h>

  #include <hash_map.h>

  #include <algo.h>

  #include <queue.h>

  #include <streambuf.h>

  ],,

  ac_cv_cxx_pre_stdcxx=yes, ac_cv_cxx_pre_stdcxx=no)

  CXXFLAGS="$ac_save_CXXFLAGS"

  AC_LANG_RESTORE

  ])

  if test "$ac_cv_cxx_pre_stdcxx" = yes; then

    AC_DEFINE(PRE_STDCXX_HEADERS,,[Define if pre-ISO C++ header files are present. ])

  fi

])

Porting between pre-ISO headers and ISO headers is simple: headers

like vector.h can be replaced with vector and a using

directive using namespace std; can be put at the global

scope. This should be enough to get this code compiling, assuming the

other usage is correct.

      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.

 Header files hash_map and hash_set moved

to ext/hash_map and  ext/hash_set,

respectively. At the same time, all types in these files are enclosed

in namespace __gnu_cxx. Later versions move deprecate

these files, and suggest using TR1's  unordered_map

and  unordered_set instead.

      The extensions are no longer in the global or std

         namespaces, instead they are declared in the __gnu_cxx

         namespace. For maximum portability, consider defining a namespace

         alias to use to talk about extensions, e.g.:

      #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;

      This is a bit cleaner than defining typedefs for all the

         instantiations you might need.

The following autoconf tests check for working HP/SGI hash containers.

# 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

])

# 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

])

 The existence of ios::nocreate 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.

For output streams, nocreate is probably the default,

unless you specify std::ios::trunc ? 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 app, ate

and trunc (except for app ?).

      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.

      For a portable solution (among systems which use

      file descriptors), you need to implement a subclass of

      std::streambuf (or

      std::basic_streambuf<..>) which opens a file

      given a descriptor, and then pass an instance of this to the

      stream-constructor.

      An extension is available that implements this.

      ext/stdio_filebuf.h contains a derived class called

      __gnu_cxx::stdio_filebuf.

      This class can be constructed from a C FILE* or a file

      descriptor, and provides the fd() function.

 For another example of this, refer to

      fdstream example

      by Nicolai Josuttis.

Check for complete library coverage of the C++1998/2003 standard.

# 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