This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[www-patch] bugs.html rewrite, part 1: factor out non-bugs section
- From: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
- To: gcc-patches at gcc dot gnu dot org
- Date: Thu, 14 Aug 2003 14:45:48 +0200 (CEST)
- Subject: [www-patch] bugs.html rewrite, part 1: factor out non-bugs section
- Reply-to: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
Our bug reporting instructions need attention IMHO:
(a) They are out of date and/or incomplete: E.g. we talk about C++ problems
when upgrading from gcc 2.95.x to 3.0 but do not address the problems
with missing "template" and "typename" keywords. Aliasing problems
are something similar (broken code which used to do the right thing
but does not so any more).
(b) The structure could be improved (e.g. bugs and non-bugs should be
separated).
(c) The information is spread across different files (e.g. bugs.html and
bugreport.texi).
(d) Bugzilla is poorly integrated in the bug reporting instructions
(we talk about how to format mails to the bug database, but don't
explain Bugzilla - at least not in bugs.html).
(e) And many many more.
I decided to do something about it and started with bugs.html since this
seems to be the most important file in the bug reporting documentation.
The first patch (see below) addresses (b), i.e. it factors out the non-bugs
and puts them into a separate section (called "Non-bugs" - surprise!)
To match the new structure I had to modify the table of contents and the
introductionary text at the beginning of the sections.
The work I'm doing is intended to be incremental, so this patch is by
no means complete. It basically does some sorting, that's all (it looks ugly,
but that's only because diff doesn't handle moving very well). Cleaning
up those two sections and addressing (a) will be done in follow-up patches.
(Okay, you caught me: in addition the patch below cleans up some minor XHTML
flaws - the document now validates as XHTML 1.0 *Strict* [at least before
preprocessing takes places which adds some "align" attributes].)
Gerald already pre-approved the patch in private mail. So I'm going to
commit the patch this weekend, if nobody votes against it.
Regards,
Volker
==============================================================================
--- bugs.html Thu Aug 14 11:03:47 2003
+++ bugs.html Thu Aug 14 10:08:43 2003
@@ -15,31 +15,39 @@
<h2>Table of Contents</h2>
<ul>
<li><a href="#report">Reporting Bugs</a>
- <ul>
- <li><a href="#need">What we need</a></li>
- <li><a href="#dontwant">What we DON'T want</a></li>
- <li><a href="#where">Where to post it</a></li>
- <li><a href="#detailed">Detailed bug reporting instructions</a></li>
- <li><a href="#gnat">Detailed bug reporting instructions for GNAT</a></li>
- <li><a href="#pch">Detailed bug reporting instructions when using a precompiled header</a></li>
- </ul>
+ <ul>
+ <li><a href="#need">What we need</a></li>
+ <li><a href="#dontwant">What we DON'T want</a></li>
+ <li><a href="#where">Where to post it</a></li>
+ <li><a href="#detailed">Detailed bug reporting instructions</a></li>
+ <li><a href="#gnat">Detailed bug reporting instructions for GNAT</a></li>
+ <li><a href="#pch">Detailed bug reporting instructions when using a precompiled header</a></li>
+ </ul>
</li>
<li><a href="#known">Frequently Reported Bugs in GCC</a>
- <ul>
- <li><a href="#general">General</a></li>
- <li><a href="#fortran">Fortran</a></li>
- <li><a href="#c">C</a></li>
- <li><a href="#cplusplus">C++</a>
<ul>
- <li><a href="#updating">Common problems updating from G++ 2.95 to
- G++ 3.0</a></li>
- <li><a href="#nonbugs">Non-bugs</a></li>
- <li><a href="#missing">Missing features</a></li>
- <li><a href="#parsing">Parse errors for "simple" code</a></li>
+ <li><a href="#cxx">C++</a>
+ <ul>
+ <li><a href="#cxx-abi">ABI bugs</a></li>
+ <li><a href="#missing">Missing features</a></li>
+ <li><a href="#parsing">Parse errors for "simple" code</a></li>
+ </ul>
+ </li>
+ <li><a href="#fortran">Fortran</a></li>
</ul>
+</li>
+<li><a href="#nonbugs">Non-bugs</a>
+ <ul>
+ <li><a href="#nonbugs_general">General</a></li>
+ <li><a href="#nonbugs_c">C</a></li>
+ <li><a href="#nonbugs_cxx">C++</a>
+ <ul>
+ <li><a href="#updating">Common problems updating from G++ 2.95 to
+ G++ 3.0</a></li>
+ </ul>
</li>
- </ul>
- </li>
+ </ul>
+</li>
</ul>
<hr />
@@ -69,8 +77,8 @@ requested in this summary.</p>
<h3><a name="need">What we need</a></h3>
-Please include in your bug report all of the following items, the first
-three of which can be obtained from the output of <code>gcc -v</code>:
+<p>Please include in your bug report all of the following items, the first
+three of which can be obtained from the output of <code>gcc -v</code>:</p>
<ul>
<li>the exact version of GCC;</li>
@@ -155,8 +163,8 @@ that</a> when reporting bugs that appear
collecting the command line below, as well as its output and the
preprocessed file it generates.</p>
-<blockquote><code>gcc -v -save-temps <i>all-your-options
-source-file</i></code></blockquote>
+<blockquote><p><code>gcc -v -save-temps <i>all-your-options
+source-file</i></code></p></blockquote>
<p>Typically the preprocessed file (extension <code>.i</code> for C or
<code>.ii</code> for C++, and <code>.f</code> if the preprocessor is used on
@@ -280,6 +288,139 @@ reproduce the problem.</p>
<h1><a name="known">Frequently Reported Bugs in GCC</a></h1>
+<p>This is a list of bugs in GCC that are reported very often, but not
+yet fixed. While it is certainly better to fix bugs instead of documenting
+them, this document might save people the effort of writing a bug report
+when the bug is already well-known.</p>
+
+<p>There are many reasons why a reported bug doesn't get fixed.
+It might be difficult to fix, or fixing it might break compatibility.
+Often, reports get a low priority when there is a simple work-around.
+In particular, bugs caused by invalid code have a simple work-around:
+<em>fix the code</em>.</p>
+
+<hr />
+
+<h2><a name="cxx">C++</a></h2>
+
+<h3><a name="cxx-abi">ABI bugs</a></h3>
+
+<p>GCC 3.0 had a new ABI, which affected class layout, function mangling and
+calling conventions. We had intended it to be complete, but unfortunately
+some issues came to light, too late to fix in the 3.0 series.
+The ABI should not change in dot releases, so we addressed most issues
+in GCC 3.1.</p>
+
+<dl>
+
+<dt>Covariant return types</dt>
+
+<dd>Up to (and including) GCC 3.3 we did not implement non-trivial
+covariant returns. This has been addressed for GCC 3.4.</dd>
+
+</dl>
+
+<h3><a name="missing">Missing features</a></h3>
+<p>We know some things are missing from G++.</p>
+
+<dl>
+
+<dt>The <code>export</code> keyword is not implemented.</dt>
+<dd><p>Most C++ compilers (G++ included) do not yet implement
+<code>export</code>, which is necessary for separate compilation of
+template declarations and definitions. Without <code>export</code>, a
+template definition must be in scope to be used. The obvious
+workaround is simply to place all definitions in the header
+itself. Alternatively, the compilation unit containing template
+definitions may be included from the header.</p></dd>
+
+<dt>Two stage lookup in templates is not implemented.</dt>
+<dd><p>[14.6] specifies how names are looked up inside a template. G++
+does not do this correctly, but for most templates this will not be
+noticeable.</p></dd>
+
+</dl>
+
+<h3><a name="parsing">Parse errors for "simple" code</a></h3>
+
+<p>Up to and including GCC 3.0, the compiler will give "parse error" for
+seemingly simple code, such as</p>
+
+<pre>
+struct A{
+ A();
+ A(int);
+ void func();
+};
+
+struct B{
+ B(A);
+ B(A,A);
+ void func();
+};
+
+void foo(){
+ B b(A(),A(1)); //Variable b, initialized with two temporaries
+ B(A(2)).func(); //B temporary, initialized with A temporary
+}
+</pre>
+
+<p>The problem is that GCC starts to parse the declaration of
+<code>b</code> as a function <code>b</code> returning <code>B</code>,
+taking a function returning <code>A</code> as an argument. When it
+sees the 1, it is too late. The work-around in these cases is to add
+additional parentheses around the expressions that are mistaken as
+declarations:</p>
+
+<pre>
+ (B(A(2))).func();
+</pre>
+
+<p>Sometimes, even that is not enough; to show the compiler that this
+should be really an expression, a comma operator with a dummy argument
+can be used:</p>
+
+<pre>
+ B b((0,A()),A(1));
+</pre>
+
+<p>Another example is the parse error for the <code>return</code>
+statement in</p>
+
+<pre>
+struct A{};
+
+struct B{
+ A a;
+ A f1(bool);
+};
+
+A B::f1(bool b)
+{
+ if (b)
+ return (A());
+ return a;
+}
+</pre>
+
+<p>The problem is that the compiler interprets <code>A()</code> as a
+function (taking no arguments, returning <code>A</code>), and
+<code>(A()</code>) as a cast - with a missing expression, hence the
+parse error. The work-around is to omit the parentheses:</p>
+
+<pre>
+ if (b)
+ return A();
+</pre>
+
+<p>This problem occurs in a number of variants; in <code>throw</code>
+statements, people also frequently put the object in parentheses. The
+exact error also somewhat varies with the compiler version. The
+work-arounds proposed do not change the semantics of the program at
+all; they make them perhaps less readable.</p>
+
+<hr />
+
<h2><a name="fortran">Fortran</a></h2>
<p>Fortran bugs are documented in the G77 manual rather than
@@ -289,41 +430,56 @@ Trouble with GNU Fortran</a> in the G77
<hr />
-<h2><a name="c">C</a></h2>
+<h1><a name="nonbugs">Non-bugs</a></h1>
-<p>The following are not bugs in the C compiler, but are reported
-often enough to warrant a mention here.</p>
+<p>The following are not actually bugs, but are reported often
+enough to warrant a mention here.</p>
-<dl>
-<dt>Cannot initialize a static variable with <code>stdin</code>.</dt>
-<dd><p>This has nothing to do with GCC, but people ask us about it a
-lot. Code like this:</p>
+<p>Programming languages themselves change. Earlier versions of GCC
+might have accepted source code that is <em>no longer</em> valid.
+This means that code which might have "worked" in a previous version,
+is now rejected. You should update your code to match recent language
+standards (this holds especially for C++).</p>
+
+<hr />
+<h2><a name="nonbugs_general">General</a></h2>
+
+<dl>
+<dt>Problems with floating point computations.</dt>
+<dd><p>In a number of cases, GCC appears to perform floating point
+computations incorrectly. For example, the C++ program</p>
<blockquote><pre>
-#include <stdio.h>
+#include <iostream>
-FILE *yyin = stdin;
+int main() {
+
+ double min = 0.0;
+ double max = 0.5;
+ double width = 0.01;
+ std::cout << (int)(((max - min) / width) - 1) << std::endl;
+
+}
</pre></blockquote>
+<p>might print 49 on some systems and optimization levels, and 48 on
+others.</p>
-<p>will not compile with GNU libc (GNU/Linux libc6), because
-<code>stdin</code> is not a constant. This was done deliberately, to make
-it easier to maintain binary compatibility when the type <code>FILE</code>
-needs to be changed. It is surprising for people used to traditional Unix
-C libraries, but it is permitted by the C standard.</p>
+<p>The is the result of <em>rounding</em>: The computer cannot
+represent all real numbers exactly, so it has to use
+approximations. When computing with approximation, the computer needs
+to round to the nearest representable number.</p>
-<p>This construct commonly occurs in code generated by old versions of
-lex or yacc. We suggest you try regenerating the parser with a
-current version of flex or bison, respectively. In your own code, the
-appropriate fix is to move the initialization to the beginning of
-main.</p>
+<p>This is not a bug in the compiler, but an inherent limitation of
+the float and double types. Please study
+<a href="http://www.validlab.com/goldberg/paper.ps";>this paper</a>
+for more information.</p></dd>
+</dl>
-<p>There is a common misconception that the GCC developers are
-responsible for GNU libc. These are in fact two entirely separate
-projects; please check the
-<a href="http://www.gnu.org/software/glibc/";>GNU libc web pages</a>
-for details.
-</p></dd>
+<hr />
+
+<h2><a name="nonbugs_c">C</a></h2>
+<dl>
<dt>Cannot use preprocessor directive in macro arguments.</dt>
<dd><p>Let me guess... you wrote code that looks something like this:</p>
<blockquote><pre>
@@ -336,21 +492,17 @@ for details.
);
</pre></blockquote>
<p>and you got a whole pile of error messages:</p>
-<blockquote><code>
-
-test.c:11: warning: preprocessing directive not recognized within
-macro arg<br />
-test.c:11: warning: preprocessing directive not recognized within
-macro arg<br />
-test.c:11: warning: preprocessing directive not recognized within
-macro arg<br />
-test.c: In function `foo':<br />
-test.c:6: undefined or invalid # directive<br />
-test.c:8: undefined or invalid # directive<br />
-test.c:9: parse error before `24'<br />
-test.c:10: undefined or invalid # directive<br />
-test.c:11: parse error before `#'<br />
-</code></blockquote>
+<blockquote><pre>
+test.c:11: warning: preprocessing directive not recognized within macro arg
+test.c:11: warning: preprocessing directive not recognized within macro arg
+test.c:11: warning: preprocessing directive not recognized within macro arg
+test.c: In function `foo':
+test.c:6: undefined or invalid # directive
+test.c:8: undefined or invalid # directive
+test.c:9: parse error before `24'
+test.c:10: undefined or invalid # directive
+test.c:11: parse error before `#'
+</pre></blockquote>
<p><strong>Update:</strong> As of GCC 3.2 this kind of construct is
always accepted and CPP will probably do what you expect, but see the
@@ -379,138 +531,50 @@ in addition to being more portable.</p>
<p>In recent versions of glibc, <code>printf</code> is among the
functions which are implemented as macros.</p></dd>
-</dl>
-
-<hr />
-
-<h2><a name="cplusplus">C++</a></h2>
-
-<p>This is the list of bugs (and non-bugs) in g++ (aka GNU C++) that
-are reported very often, but not yet fixed. While it is certainly
-better to fix bugs instead of documenting them, this document might
-save people the effort of writing a bug report when the bug is already
-well-known. <a href="#report">How to report bugs</a> tells you how to
-report a bug.</p>
-
-<p>There are many reasons why reported bugs don't get fixed. It might
-be difficult to fix, or fixing it might break compatibility. Often,
-reports get a low priority when there is a simple work-around. In
-particular, bugs caused by invalid C++ code have a simple work-around,
-<em>fix the code</em>. Now that there is an agreed ISO/ANSI standard
-for C++, the compiler has a definitive document to adhere to. Earlier
-versions might have accepted source code that is <em>no longer</em>
-C++. This means that code which might have `worked' in a previous
-version, is now rejected. You should update your code to be C++.</p>
-
-<p>You should try to use the latest stable release of the GNU C++
-compiler.</p>
-
-<h3><a name="updating">Common problems updating from G++ 2.95 to G++
-3.0</a></h3>
-
-<p>G++ 3.0 conforms much closer to the ISO C++ standard (available at
-<a href="http://www.ncits.org/cplusplus.htm";>http://www.ncits.org/cplusplus.htm</a>).</p>
-
-<p>We have also implemented some of the core and library defect reports
-(available at
-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html";>http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html</a>
-&
-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html";>
-http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html</a>
-respectively).</p>
-
-<ul>
-
-<li>The ABI has changed. This means that both class layout and name
-mangling is different. You <em>must</em> recompile all c++ libraries (if
-you don't you will get link errors).</li>
-
-<li>The standard library is much more conformant, and uses the
-<code>std::</code> namespace.</li>
-
-<li><code>std::</code> is now a real namespace, not an alias for
-<code>::</code>.</li>
-
-<li>The standard header files for the c library don't end with
-<code>.h</code>, but begin with <code>c</code> (i.e.
-<code><cstdlib></code> rather than <code><stdlib.h></code>).
-The <code>.h</code> names are still available, but are deprecated.</li>
-
-<li><code><strstream></code> is deprecated, use
-<code><sstream></code> instead.</li>
-
-<li><code>streambuf::seekoff</code> &
-<code>streambuf::seekpos</code> are private, instead use
-<code>streambuf::pubseekoff</code> &
-<code>streambuf::pubseekpos</code> respectively.</li>
-
-<li>If <code>std::operator << (std::ostream &, long long)</code>
-doesn't exist, you need to recompile libstdc++ with
-<code>--enable-long-long</code>.</li>
-
-</ul>
-
-This means you may get lots of errors about things like
-<code>strcmp</code> not being found. You've most likely forgotten to
-tell the compiler to look in the <code>std::</code> namespace. There are
-several ways to do this,
-
-<ul>
-
-<li>Say, <code>std::strcmp</code> at the call. This is the most explicit
-way of saying what you mean.</li>
-
-<li>Say, <code>using std::strcmp;</code> somewhere before the call. You
-will need to do this for each function or type you wish to use from the
-standard library.</li>
-
-<li>Say, <code>using namespace std;</code> somewhere before the call.
-This is the quick-but-dirty fix. This brings the <em>whole</em> of the
-<code>std::</code> namespace into scope. <em>Never</em> do this in a
-header file, as you will be forcing users of your header file to do the
-same.</li>
-</ul>
-
-<h3><a name="abi">ABI bugs</a></h3>
+<dt>Cannot initialize a static variable with <code>stdin</code>.</dt>
+<dd><p>This has nothing to do with GCC, but people ask us about it a
+lot. Code like this:</p>
-<p>3.0 had a new ABI, which affected class layout, function mangling and
-calling conventions. We had intended it to be complete, unfortunately
-some issues came to light, too late to fix in the 3.0 series.
-The ABI should not change in dot releases, so we addressed most issues
-in GCC 3.1.
-</p>
+<blockquote><pre>
+#include <stdio.h>
-<dl>
+FILE *yyin = stdin;
+</pre></blockquote>
-<dt>Covariant return types</dt>
+<p>will not compile with GNU libc, because <code>stdin</code> is not a
+constant. This was done deliberately, to make it easier to maintain
+binary compatibility when the type <code>FILE</code> needs to be changed.
+It is surprising for people used to traditional Unix C libraries, but it
+is permitted by the C standard.</p>
-<dd>Up to (and including) GCC 3.3 we did not implement non-trivial
-covariant returns. This has been addressed for GCC 3.4.</dd>
+<p>This construct commonly occurs in code generated by old versions of
+lex or yacc. We suggest you try regenerating the parser with a
+current version of flex or bison, respectively. In your own code, the
+appropriate fix is to move the initialization to the beginning of
+main.</p>
+<p>There is a common misconception that the GCC developers are
+responsible for GNU libc. These are in fact two entirely separate
+projects; please check the
+<a href="http://www.gnu.org/software/glibc/";>GNU libc web pages</a>
+for details.
+</p></dd>
</dl>
-<h3><a name="nonbugs">Non-bugs</a></h3>
+<hr />
-<p>This section lists several features that have been reported as bugs, but
-are not; in addition, the manual contains a section on
-<a href="http://gcc.gnu.org/onlinedocs/gcc/C---Misunderstandings.html";>Common
-Misunderstandings with GNU C++</a>.</p>
+<h2><a name="nonbugs_cxx">C++</a></h2>
<dl>
-
<dt>Nested classes can access private types of the containing
class.</dt>
+
<dd><p>G++ now implements type access control on member types. Defect
report 45 clarifies that nested classes are members of the class they
are nested in, and so are granted access to private members of that
class.</p></dd>
-<dt>Classes in exception specifiers must be complete types.</dt>
-<dd><p>[15.4]/1 tells you that you cannot have an incomplete type, or
-pointer to incomplete (other than <code><i>cv</i> void *</code>) in
-an exception specification.</p></dd>
-
<dt>G++ emits two copies of constructors and destructors.</dt>
<dd><p>In general there are <em>three</em> types of constructors (and
@@ -523,14 +587,6 @@ destructors).</p>
<p>The first two are different, when virtual base classes are involved.
</p></dd>
-<dt>Exceptions don't work in multithreaded applications.</dt>
-
-<dd><p>You need to rebuild g++ and libstdc++ with
-<code>--enable-threads</code>. Remember, c++ exceptions are not like
-hardware interrupts. You cannot throw an exception in one thread and
-catch it in another. You cannot throw an exception from a signal
-handler, and catch it in the main thread.</p></dd>
-
<dt>Global destructors are not run in the correct order.</dt>
<dd><p>Global destructors should be run in the reverse order of their
@@ -542,34 +598,19 @@ switch on by default, as it requires a <
library (<code>libc</code>, <code>glibc</code>, or
equivalent).</p></dd>
-<dt>Problems with floating point computations.</dt>
-<dd><p>In a number of cases, GCC appears to perform floating point
-computations incorrectly. For example, the program</p>
-<blockquote><code>
-#include <iostream><br />
-<br />
-int main() {<br />
-<br />
- double min = 0.0;<br />
- double max = 0.5;<br />
- double width = 0.01;<br />
- std::cout << (int)(((max - min) / width) - 1) <<
- std::endl;<br />
-<br />
-}<br />
-</code></blockquote>
-<p>might print 49 on some systems and optimization levels, and 48 on
-others.</p>
+<dt>Classes in exception specifiers must be complete types.</dt>
-<p>The is the result of <em>rounding</em>: The computer cannot
-represent all real numbers exactly, so it has to use
-approximations. When computing with approximation, the computer needs
-to round to the nearest representable number.</p>
+<dd><p>[15.4]/1 tells you that you cannot have an incomplete type, or
+pointer to incomplete (other than <code><i>cv</i> void *</code>) in
+an exception specification.</p></dd>
-<p>This is not a bug in the compiler, but an inherent limitation of
-the float and double types. Please study
-<a href="http://www.validlab.com/goldberg/paper.ps";>this paper</a>
-for more information.</p></dd>
+<dt>Exceptions don't work in multithreaded applications.</dt>
+
+<dd><p>You need to rebuild g++ and libstdc++ with
+<code>--enable-threads</code>. Remember, c++ exceptions are not like
+hardware interrupts. You cannot throw an exception in one thread and
+catch it in another. You cannot throw an exception from a signal
+handler, and catch it in the main thread.</p></dd>
<dt>Templates, scoping, and digraphs.</dt>
@@ -593,100 +634,78 @@ The simplest way to avoid this is to wri
::X></code>, i.e. place a space between the opening angle bracket
and the scope operator.
</p></dd>
+</dl>
+<h3><a name="updating">Common problems updating from G++ 2.95 to G++
+3.0</a></h3>
+<p>G++ 3.0 conforms much closer to the ISO C++ standard (available at
+<a href="http://www.ncits.org/cplusplus.htm";>http://www.ncits.org/cplusplus.htm</a>).</p>
-</dl>
+<p>We have also implemented some of the core and library defect reports
+(available at
+<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html";>http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html</a>
+&
+<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html";>
+http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html</a>
+respectively).</p>
-<h3><a name="missing">Missing features</a></h3>
-<p>We know some things are missing from G++.</p>
+<ul>
-<dl>
+<li>The ABI has changed. This means that both class layout and name
+mangling is different. You <em>must</em> recompile all c++ libraries (if
+you don't you will get link errors).</li>
-<dt>The <code>export</code> keyword is not implemented.</dt>
-<dd><p>Most C++ compilers (G++ included) do not yet implement
-<code>export</code>, which is necessary for separate compilation of
-template declarations and definitions. Without <code>export</code>, a
-template definition must be in scope to be used. The obvious
-workaround is simply to place all definitions in the header
-itself. Alternatively, the compilation unit containing template
-definitions may be included from the header.</p></dd>
+<li>The standard library is much more conformant, and uses the
+<code>std::</code> namespace.</li>
-<dt>Two stage lookup in templates is not implemented.</dt>
-<dd><p>[14.6] specifies how names are looked up inside a template. G++
-does not do this correctly, but for most templates this will not be
-noticeable.</p></dd>
+<li><code>std::</code> is now a real namespace, not an alias for
+<code>::</code>.</li>
-</dl>
+<li>The standard header files for the c library don't end with
+<code>.h</code>, but begin with <code>c</code> (i.e.
+<code><cstdlib></code> rather than <code><stdlib.h></code>).
+The <code>.h</code> names are still available, but are deprecated.</li>
-<h3><a name="parsing">Parse errors for "simple" code</a></h3>
+<li><code><strstream></code> is deprecated, use
+<code><sstream></code> instead.</li>
-Up to and including GCC 3.0, the compiler will give "parse error" for
-seemingly simple code, such as
+<li><code>streambuf::seekoff</code> &
+<code>streambuf::seekpos</code> are private, instead use
+<code>streambuf::pubseekoff</code> &
+<code>streambuf::pubseekpos</code> respectively.</li>
-<pre>
-struct A{
- A();
- A(int);
- void func();
-};
+<li>If <code>std::operator << (std::ostream &, long long)</code>
+doesn't exist, you need to recompile libstdc++ with
+<code>--enable-long-long</code>.</li>
-struct B{
- B(A);
- B(A,A);
- void func();
-};
+</ul>
-void foo(){
- B b(A(),A(1)); //Variable b, initialized with two temporaries
- B(A(2)).func(); //B temporary, initialized with A temporary
-}
-</pre>
-The problem is that GCC starts to parse the declaration of
-<code>b</code> as a function <code>b</code> returning <code>B</code>,
-taking a function returning <code>A</code> as an argument. When it
-sees the 1, it is too late. The work-around in these cases is to add
-additional parentheses around the expressions that are mistaken as
-declarations:
-<pre>
- (B(A(2))).func();
-</pre>
-Sometimes, even that is not enough; to show the compiler that this
-should be really an expression, a comma operator with a dummy argument
-can be used:
-<pre>
- B b((0,A()),A(1));
-</pre>
-<p>
-Another example is the parse error for the <code>return</code>
-statement in</p>
-<pre>
-struct A{};
+<p>This means you may get lots of errors about things like
+<code>strcmp</code> not being found. You've most likely forgotten to
+tell the compiler to look in the <code>std::</code> namespace. There are
+several ways to do this,</p>
-struct B{
- A a;
- A f1(bool);
-};
+<ul>
-A B::f1(bool b)
-{
- if (b)
- return (A());
- return a;
-}
-</pre>
-<p>The problem is that the compiler interprets <code>A()</code> as a
-function (taking no arguments, returning <code>A</code>), and
-<code>(A()</code>) as a cast - with a missing expression, hence the
-parse error. The work-around is to omit the parentheses:</p>
-<pre>
- if (b)
- return A();
-</pre>
-<p>This problem occurs in a number of variants; in <code>throw</code>
-statements, people also frequently put the object in parentheses. The
-exact error also somewhat varies with the compiler version. The
-work-arounds proposed do not change the semantics of the program at
-all; they make them perhaps less readable.</p>
+<li>Say, <code>std::strcmp</code> at the call. This is the most explicit
+way of saying what you mean.</li>
+
+<li>Say, <code>using std::strcmp;</code> somewhere before the call. You
+will need to do this for each function or type you wish to use from the
+standard library.</li>
+
+<li>Say, <code>using namespace std;</code> somewhere before the call.
+This is the quick-but-dirty fix. This brings the <em>whole</em> of the
+<code>std::</code> namespace into scope. <em>Never</em> do this in a
+header file, as you will be forcing users of your header file to do the
+same.</li>
+
+</ul>
+
+
+<p>In addition to the problems listed above, the manual contains a section on
+<a href="http://gcc.gnu.org/onlinedocs/gcc/C---Misunderstandings.html";>Common
+Misunderstandings with GNU C++</a>.</p>
</body>
</html>
==============================================================================