_M_toupper(NULL),    _M_tolower(NULL),    _M_ctable(NULL),     _M_table(!__table             ? (const mask*) (__libc_attr._ctype_tbl->_class + 1)             : __table)   @{ @}@end example@noindentThere are two parts of this that you might choose to alter. The first,and most important, is the line involving @code{__libc_attr}.  That isIRIX system-dependent code that gets the base of the table mappingcharacter codes to attributes.  You need to substitute code that obtainsthe address of this table on your system.  If you want to use youroperating system's tables to map upper-case letters to lower-case, andvice versa, you should initialize @code{_M_toupper} and@code{_M_tolower} with those tables, in similar fashion.Now, you have to write two functions to convert from upper-case tolower-case, and vice versa.  Here are the IRIX versions:@examplecharctype<char>::do_toupper(char __c) const@{ return _toupper(__c); @}charctype<char>::do_tolower(char __c) const@{ return _tolower(__c); @}@end example@noindentYour C library provides equivalents to IRIX's @code{_toupper} and@code{_tolower}.  If you initialized @code{_M_toupper} and@code{_M_tolower} above, then you could use those tables instead.Finally, you have to provide two utility functions that convert stringsof characters.  The versions provided here will always work -- but youcould use specialized routines for greater performance if you havemachinery to do that on your system:@exampleconst char*ctype<char>::do_toupper(char* __low, const char* __high) const@{  while (__low < __high)    @{      *__low = do_toupper(*__low);      ++__low;    @}  return __high;@}const char* ctype<char>::do_tolower(char* __low, const char* __high) const@{  while (__low < __high)    @{      *__low = do_tolower(*__low);      ++__low;    @}  return __high;@}@end exampleYou must also provide the @file{ctype_inline.h} file, whichcontains a few more functions.  On most systems, you can just copy@file{config/os/generic/ctype_inline.h} and use it on your system.In detail, the functions provided test characters for particularproperties; they are analogous to the functions like @code{isalpha} and@code{islower} provided by the C library.The first function is implemented like this on IRIX:@exampleboolctype<char>::is(mask __m, char __c) const throw()@{ return (_M_table)[(unsigned char)(__c)] & __m; @}@end example@noindentThe @code{_M_table} is the table passed in above, in the constructor.This is the table that contains the bitmasks for each character.  Theimplementation here should work on all systems.The next function is:@exampleconst char*ctype<char>::is(const char* __low, const char* __high, mask* __vec) const throw()@{  while (__low < __high)    *__vec++ = (_M_table)[(unsigned char)(*__low++)];  return __high;@}@end example@noindentThis function is similar; it copies the masks for all the charactersfrom @code{__low} up until @code{__high} into the vector given by@code{__vec}.The last two functions again are entirely generic:@exampleconst char*ctype<char>::scan_is(mask __m, const char* __low, const char* __high) const throw()@{  while (__low < __high && !this->is(__m, *__low))    ++__low;  return __low;@}const char*ctype<char>::scan_not(mask __m, const char* __low, const char* __high) const throw()@{  while (__low < __high && this->is(__m, *__low))    ++__low;  return __low;@}@end example@c ---------------------------------------------------------------------@c Thread safety@c ---------------------------------------------------------------------@node Thread safety@chapter Thread safetyThe C++ library string functionality requires a couple of atomicoperations to provide thread-safety.  If you don't take any specialaction, the library will use stub versions of these functions that arenot thread-safe.  They will work fine, unless your applications aremulti-threaded.If you want to provide custom, safe, versions of these functions, thereare two distinct approaches.  One is to provide a version for your CPU,using assembly language constructs.  The other is to use thethread-safety primitives in your operating system.  In either case, youmake a file called @file{atomicity.h}, and the variable@code{ATOMICITYH} must point to this file.If you are using the assembly-language approach, put this code in@file{config/cpu/<chip>/atomicity.h}, where chip is the name ofyour processor (@pxref{CPU}).  No additional changes are necessary tolocate the file in this case; @code{ATOMICITYH} will be set by default.If you are using the operating system thread-safety primitives approach,you can also put this code in the same CPU directory, in which case no morework is needed to locate the file.  For examples of this approach,see the @file{atomicity.h} file for IRIX or IA64.Alternatively, if the primitives are more closely related to the OSthan they are to the CPU, you can put the @file{atomicity.h} file inthe @ref{Operating system} directory instead.  In this case, you mustedit @file{configure.target}, and in the switch statement that handlesoperating systems, override the @code{ATOMICITYH} variable to point tothe appropriate @code{os_include_dir}.  For examples of this approach,see the @file{atomicity.h} file for AIX.With those bits out of the way, you have to actually write@file{atomicity.h} itself.  This file should be wrapped in aninclude guard named @code{_BITS_ATOMICITY_H}.  It should define onetype, and two functions.  The type is @code{_Atomic_word}.  Here is the version used on IRIX:@exampletypedef long _Atomic_word;@end example@noindentThis type must be a signed integral type supporting atomic operations.If you're using the OS approach, use the same type used by your system'sprimitives.  Otherwise, use the type for which your CPU provides atomicprimitives.Then, you must provide two functions.  The bodies of these functionsmust be equivalent to those provided here, but using atomic operations:@examplestatic inline _Atomic_word__attribute__ ((__unused__))__exchange_and_add (_Atomic_word* __mem, int __val)@{  _Atomic_word __result = *__mem;  *__mem += __val;  return __result;@}static inline void__attribute__ ((__unused__))__atomic_add (_Atomic_word* __mem, int __val)@{  *__mem += __val;@}@end example@c ---------------------------------------------------------------------@c Numeric limits@c ---------------------------------------------------------------------@node Numeric limits@chapter Numeric limitsThe C++ library requires information about the fundamental data types,such as the minimum and maximum representable values of each type.You can define each of these values individually, but it is usuallyeasiest just to indicate how many bits are used in each of the datatypes and let the library do the rest.  For information about themacros to define, see the top of @file{include/bits/std_limits.h}.If you need to define any macros, you can do so in @file{os_defines.h}.However, if all operating systems for your CPU are likely to use thesame values, you can provide a CPU-specific file instead so that youdo not have to provide the same definitions for each operating system.To take that approach, create a new file called @file{cpu_limits.h} inyour CPU configuration directory (@pxref{CPU}).@c ---------------------------------------------------------------------@c Libtool@c ---------------------------------------------------------------------@node Libtool@chapter LibtoolThe C++ library is compiled, archived and linked with libtool.Explaining the full workings of libtool is beyond the scope of thisdocument, but there are a few, particular bits that are necessary forporting.Some parts of the libstdc++-v3 library are compiled with the libtool@code{--tags CXX} option (the C++ definitions for libtool).  Therefore,@file{ltcf-cxx.sh} in the top-level directory needs to have the correctlogic to compile and archive objects equivalent to the C version of libtool,@file{ltcf-c.sh}.  Some libtool targets have definitions for C but notfor C++, or C++ definitions which have not been kept up to date.The C++ run-time library contains initialization code that needs to berun as the library is loaded.  Often, that requires linking in specialobject files when the C++ library is built as a shared library, ortaking other system-specific actions.The libstdc++-v3 library is linked with the C version of libtool, eventhough it is a C++ library.  Therefore, the C version of libtool needs toensure that the run-time library initializers are run.  The usual way todo this is to build the library using @code{gcc -shared}.If you need to change how the library is linked, look at@file{ltcf-c.sh} in the top-level directory.  Find the switch statementthat sets @code{archive_cmds}.  Here, adjust the setting for youroperating system.@c ---------------------------------------------------------------------@c GFDL@c ---------------------------------------------------------------------@include fdl.texi@c ---------------------------------------------------------------------@c Epilogue@c ---------------------------------------------------------------------@contents@bye