diff mbox

[wwwdocs] New bits to porting_to

Message ID alpine.LSU.2.20.1602141402550.3806@anthias
State New
Headers show

Commit Message

Gerald Pfeifer Feb. 14, 2016, 1:14 p.m. UTC 
Hi Marek,

On Wed, 10 Feb 2016, Marek Polacek wrote:
> +The additional overloads can cause the compiler to reject invalid code that
> +was accepted before.  An example of such code is the below:

which additional overloads does this refer to?

> +#include <stdlib.h>
> +int
> +foo (unsigned x)

Usually I'd merge the two lines above to make the example shorter
(even if that then does not meet the GNU Coding Standards), but 
beauty is in the eye of the beholder. ;-)  

> +Since calling <code>abs()</code> on an unsigned value doesn't make sense,
> +this code will become explicitly invalid as per discussion in the LWG.

How is this related to overloads?  I feel there is some tacit
knowledge involved, which I and presuambly many of our users
may be lacking?

> +<h3>Links</h3>

Did you mean to add anything here?  Right now it's still empty.

Gerald

PS: I applied the small markup/formatting patch below.

Comments

Jonathan Wakely Feb. 14, 2016, 5:39 p.m. UTC | #1 
On 14/02/16 14:14 +0100, Gerald Pfeifer wrote:
>Hi Marek,
>
>On Wed, 10 Feb 2016, Marek Polacek wrote:
>> +The additional overloads can cause the compiler to reject invalid code that
>> +was accepted before.  An example of such code is the below:
>
>which additional overloads does this refer to?

The clue is in the title of that section:

  Call of overloaded 'abs(unsigned int&)' is ambiguous

That's a subsection of "Header <stdlib.h> changes" which says "The C++
header defines additional overloads of some functions", which refers
to 'abs' (in fact that's the only extra overload C++ adds to
<stdlib.h>, unlike <math.h> which has loads added).

It could be changed to "defines additional overloads of
<code>abs</code>" if that helps.

>> +Since calling <code>abs()</code> on an unsigned value doesn't make sense,
>> +this code will become explicitly invalid as per discussion in the LWG.
>
>How is this related to overloads?  I feel there is some tacit
>knowledge involved, which I and presuambly many of our users
>may be lacking?

The error you get for that code is the title of the section, and is
because there are overloads of 'abs' for signed types but no overload
that matches an unsigned type.
diff mbox

Patch

Index: gcc-6/porting_to.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.13
diff -u -r1.13 porting_to.html
--- gcc-6/porting_to.html	12 Feb 2016 16:28:27 -0000	1.13
+++ gcc-6/porting_to.html	14 Feb 2016 13:11:43 -0000
@@ -161,7 +161,7 @@ 
 <code>std::terminate</code>.  By default GCC will now issue a warning for
 throw-expressions in <code>noexcept</code> functions, including destructors,
 that would immediately result in a call to terminate.  The new warning can be
-disabled with <tt>-Wno-terminate</tt>.  It is possible to restore the old
+disabled with <code>-Wno-terminate</code>.  It is possible to restore the old
 behavior when defining the destructor like this:
 </p>
 <pre><code>
@@ -220,7 +220,7 @@ 
 the C++ standard library.
 </p>
 
-<h4>Call of overloaded 'abs(unsigned int&amp;)' is ambiguous</h4>
+<h4>Call of overloaded '<code>abs(unsigned int&amp;)</code>' is ambiguous</h4>
 
 <p>
 The additional overloads can cause the compiler to reject invalid code that
@@ -391,8 +391,9 @@ 
 <h2>Enhanced <code>-Wnonnull</code></h2>
 <p>
 The <code>-Wnonnull</code> warning has been improved so that it also warns
-about comparing parameters declared as nonnull with <code>NULL</code>.  For
-example, the compiler will warn about the following code:
+about comparing parameters declared as <code>nonnull</code> with
+<code>NULL</code>.  For example, the compiler will warn about the
+following code:
 </p>
 
 <pre><code>