No <code>ios_base</code>

Second @@ -80,504 +52,14 @@ considered replaced and rewritten. - The STL portions of this library are based on SGI/HP STL release 3.11. + The STL portions of that 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. + That project is no longer maintained or supported, and the sources + archived. The code was replaced and rewritten for libstdc++-v3. - - Portability notes and known implementation limitations are as follows. - - -

Namespace <code>std::</code> not supported - - - - 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 (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 -]) - -

- -

Illegal iterator usage - - - 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()) - - - -

- -

<code>isspace</code> from <filename class="headerfile"><cctype></filename> is a macro - - - - - Glibc 2.0.x and 2.1.x define <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 - <ctype.h>. This will - result in ambiguities between the definitions in the global namespace - (<ctype.h>) and the - definitions in namespace std:: - (<cctype>). - -

- -

No <code>vector::at</code>, <code>deque::at</code>, <code>string::at</code> - - - - 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. - - -

- -

No <code>std::char_traits<char>::eof</code> - - - - 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 - - -

- -

No <code>string::clear</code> - - - - 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*)). - -

- -

- Removal of <code>ostream::form</code> and <code>istream::scan</code> - extensions - - - - - These are no longer supported. Please use stringstreams instead. - -

- -

No <code>basic_stringbuf</code>, <code>basic_stringstream</code> - - - - Although the ISO standard i/ostringstream-classes are - provided, (<sstream>), for - compatibility with older implementations the pre-ISO - i/ostrstream (<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 this howto. - - - There is additional information in the libstdc++-v2 info files, in -particular info iostream. - -

- -

Little or no wide character support - - - Classes wstring and - char_traits<wchar_t> are - not supported. - -

- -

No templatized iostreams - - - Classes wfilebuf and - wstringstream are not supported. - -

- -

Thread safety issues - - - - 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 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 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.) - -