OpenE2K
/
gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

index.html: Correct link to libg++ information. 

2003-02-01  Phil Edwards  <pme@gcc.gnu.org>

	* docs/html/faq/index.html:  Correct link to libg++ information.
	* docs/html/faq/index.txt:  Regenerated.

From-SVN: r62259
This commit is contained in:
Phil Edwards 2003-02-01 21:47:13 +00:00
parent 5d7bed9d6f
commit d6ed6fcc8f
3 changed files with 36 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
libstdc++-v3/ChangeLog
View File

@ -1,3 +1,8 @@
2003-02-01 Phil Edwards <pme@gcc.gnu.org>
* docs/html/faq/index.html: Correct link to libg++ information.
* docs/html/faq/index.txt: Regenerated.
2003-02-01 Paolo Carlini <pcarlini@unitus.it>
Benjamin Kosnik <bkoz@redhat.com>

6
libstdc++-v3/docs/html/faq/index.html
View File

@ -256,7 +256,7 @@ which is no longer available, thanks deja...-->
stuff&quot; classes will probably migrate there.)
</p>
<p>For the bold and/or desperate, the
<a href="http://gcc.gnu.org/fom_serv/cache/33.html">GCC FAQ</a>
<a href="http://gcc.gnu.org/extensions.html">GCC extensions page</a>
describes where to find the last libg++ source.
</p>
@ -504,8 +504,8 @@ which is no longer available, thanks deja...-->
platforms. The assembly code accidentally used opcodes that are
only available on the i486 and later. So if you configured GCC
to target, for example, i386-linux, but actually used the programs
on an i686, then you would encounter no problems. Only when
actually running the code on a i386 will the problem appear.
on an i686, then you would encounter no problems. Only when
actually running the code on a i386 will the problem appear.
</p>
<p>This is fixed in 3.2.2.
</p>

31
libstdc++-v3/docs/html/faq/index.txt
View File

@ -177,8 +177,8 @@
and happened to be started by members of the Standards Committee.
Certain "useful stuff" classes will probably migrate there.)
For the bold and/or desperate, the [61]GCC FAQ describes where to find
the last libg++ source.
For the bold and/or desperate, the [61]GCC extensions page describes
where to find the last libg++ source.
_________________________________________________________________
1.8 What if I have more questions?
@ -714,6 +714,31 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
headers whose directories are not searched directly, e.g.,
<sys/stat.h>, <X11/Xlib.h>.
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 Sgi { using ::hash_map; }; // inherit globals
#else
#include <ext/hash_map>
#if __GNUC_MINOR__ == 0
namespace Sgi = std; // GCC 3.0
#else
namespace Sgi = ::__gnu_cxx; // GCC 3.1 and later
#endif
#endif
#else // ... there are other compilers, right?
namespace Sgi = std;
#endif
Sgi::hash_map<int,int> my_map;
This is a bit cleaner than defining typedefs for all the
instantiations you might need.
Extensions to the library have [94]their own page.
_________________________________________________________________
@ -895,7 +920,7 @@ References
58. http://gcc.gnu.org/libstdc++/
59. ../17_intro/contribute.html
60. http://www.boost.org/
61. http://gcc.gnu.org/fom_serv/cache/33.html
61. http://gcc.gnu.org/extensions.html
62. mailto:libstdc++@gcc.gnu.org
63. mailto:pme@gcc.gnu.org
64. mailto:gdr@gcc.gnu.org