[wwwdocs] Add common C++ issues to /gcc-6/porting_to.html

[wwwdocs] Add common C++ issues to /gcc-6/porting_to.html

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 90 bytes --]

This documents the most likely problems for C++ programs using GCC 6.

Committed to CVS.


[-- Attachment #2: patch.txt --]
[-- Type: text/x-patch, Size: 5316 bytes --]

Index: htdocs/gcc-6/porting_to.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.2
diff -u -r1.2 porting_to.html
--- htdocs/gcc-6/porting_to.html	27 Jan 2016 14:40:26 -0000	1.2
+++ htdocs/gcc-6/porting_to.html	2 Feb 2016 20:32:29 -0000
@@ -33,6 +33,132 @@
 
 <h2>C++ language issues</h2>
 
+<h3>Default standard is now GNU++14</h3>
+
+<p>
+GCC defaults to <code>-std=gnu++14</code> instead of <code>-std=gnu++98</code>.
+This brings several changes that users should be aware of.  The following
+paragraphs describe some of these changes and suggest how to deal with them.
+</p>
+
+<p>Some users might prefer to stay with gnu++98, in which case we suggest to
+use the <code>-std=gnu++98</code> command-line option, perhaps by putting it
+in <code>CXXFLAGS</code> or similar variables in Makefiles.</p>
+
+<h4>Narrowing conversions</h4>
+
+<p>
+The C++11 standard does not allow "narrowing conversions" inside braced
+initialization lists, meaning conversions to a type with less precision or
+a smaller range, for example:
+</p>
+<pre><code>
+    int i = 127;
+    char s[] = { i, 256 };
+</code></pre>
+
+<p>
+In the above example the value 127 would fit in <code>char</code> but
+because it's not a constant it is still a narrowing conversion. If the value
+256 is larger than <code>CHAR_MAX</code> then that is also a narrowing
+conversion. Narrowing conversions can be avoided by using an explicit cast,
+e.g. <code>(char)i</code>.
+</p>
+
+<h4>Invalid literal suffixes</h4>
+
+<p>
+The C++11 "user-defined literals" feature allows custom suffixes to be added
+to literals, so that for example <code>"Hello, world!"s</code> creates a
+<code>std::string</code> object. This means that code relying on string
+concatenation of string literals and macros might fail to compile, for
+example using <code>printf("%"PRIu64, uint64_value)</code> is not valid in
+C++11, because <code>PRIu64</code> is parsed as a literal suffix. To fix
+the code to compile in C++11 add whitespace between the string literal and the
+macro: <code>printf("%" PRIu64, uint64_value)</code>.
+</p>
+
+<h4>Cannot convert 'bool' to 'T*'</h4>
+
+<p>
+The current C++ standard only allows integer literals to be used as null
+pointer constants, so other constants such as <code>false</code> and
+<code>(1 - 1)</code> cannot be used where a null pointer is desired. Code that
+fails to compile with this error should be changed to use <code>nullptr</code>,
+or <code>0</code>, or <code>NULL</code>.
+</p>
+
+<h4>Cannot convert 'std::ostream' to 'bool'</h4>
+
+<p>
+Since C++11 iostream classes are no longer implicitly convertible to
+<code>void*</code> so it is no longer valid to do something like:
+</p>
+<pre><code>
+  bool valid(std::ostream&amp; os) { return os; }
+</code></pre>
+
+<p>
+Such code must be changed to convert the iostream object to <code>bool</code>
+explicitly:
+</p>
+
+<pre><code>
+  bool valid(std::ostream&amp; os) { return (bool)os; }
+</code></pre>
+
+<h3>Header dependency changes</h3>
+
+<p>
+The <code>&lt;algorithm&gt;</code> header has been changed to reduce the
+number of other headers it includes in C++11 mode or above.
+As such, C++ programs that used components defined in
+<code>&lt;random&gt;</code>, <code>&lt;vector&gt;</code>, or
+<code>&lt;memory&gt;</code> without explicitly including the right headers
+will no longer compile.
+</p>
+
+<h3>Header <code>&lt;cmath&gt;</code> changes</h3>
+
+<p>
+Some C libraries declare obsolete <code>int isinf(double)</code> or
+<code>int isnan(double)</code> functions in the <code>&lt;math.h&gt;</code>
+header. These functions conflict with standard C++ functions with the same
+name but a different return type (the C++ functions return <code>bool</code>).
+When the obsolete functions are declared by the C library the C++ library
+will use them and import them into namespace <code>std</code>
+instead of defining the correct signatures.
+</p>
+
+<h3>Header <code>&lt;math.h&gt;</code> changes</h3>
+
+<p>
+The C++ library now provides its own <code>&lt;math.h&gt;</code> header that
+wraps the C library header of the same name. The C++ header defines
+additional overloads of some functions and ensures that all standard
+functions are defined as real functions and not as macros.
+Code which assumes that <code>sin</code>, <code>cos</code>, <code>pow</code>,
+<code>isfinite</code> etc. are macros may no longer compile.
+</p>
+
+<h3>Header <code>&lt;stdlib.h&gt;</code> changes</h3>
+
+<p>
+The C++ library now provides its own <code>&lt;stdlib.h&gt;</code> header that
+wraps the C library header of the same name. The C++ header defines
+additional overloads of some functions and ensures that all standard
+functions are defined as real functions and not as macros.
+Code which assumes that <code>abs</code>, <code>malloc</code> etc.
+are macros may no longer compile.
+</p>
+
+<p>
+Programs which provide their own wrappers for <code>&lt;stdlib.h&gt;</code>
+or other standard headers are operating outside the standard and so are
+responsible for ensuring their headers work correctly with the headers in
+the C++ standard library.
+</p>
+
 <h2>-Wmisleading-indentation</h2>
 <p>
 A new warning <code>-Wmisleading-indentation</code> was added

[PATCH] Re: [wwwdocs] Add common C++ issues to /gcc-6/porting_to.html

[David Malcolm]

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

On Tue, 2016-02-02 at 20:36 +0000, Jonathan Wakely wrote:

I had some difficulty reading the new section; mostly due to the
leapfrogging of C++11 by the default (my immediate reaction was "why is
it talking about C++11 when the option says GNU++14?")

I'm attaching a patch which I hope clarifies it, for people like me who
aren't experts in C++ standards (with that as a caveat... I'm not an
expert in C++ standards).

Is the attached OK to commit? (it validates)

Some other notes below.

> Index: htdocs/gcc-6/porting_to.html
> ===================================================================
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
> retrieving revision 1.2
> diff -u -r1.2 porting_to.html
> --- htdocs/gcc-6/porting_to.html	27 Jan 2016 14:40:26 -0000	
> 1.2
> +++ htdocs/gcc-6/porting_to.html	2 Feb 2016 20:32:29 -0000

[...snip...]

> +<h4>Cannot convert 'bool' to 'T*'</h4>
> +
> +<p>
> +The current C++ standard only allows integer literals to be used as
> null

Which standard?

> +pointer constants, so other constants such as <code>false</code> and
> +<code>(1 - 1)</code> cannot be used where a null pointer is desired.
> Code that
> +fails to compile with this error should be changed to use
> <code>nullptr</code>,
> +or <code>0</code>, or <code>NULL</code>.
> +</p>
> +
> +<h4>Cannot convert 'std::ostream' to 'bool'</h4>
> +
> +<p>
> +Since C++11 iostream classes are no longer implicitly convertible to
> +<code>void*</code> so it is no longer valid to do something like:

Should there be a comma between "C++" and "iostream" here?  (or maybe
rewrite as: "As of C++, iostream classes"... ?)

[...snip...]


Hope this is constructive
Dave

[-- Attachment #2: cp-standards.patch --]
[-- Type: text/x-patch, Size: 1400 bytes --]

Index: htdocs/gcc-6/porting_to.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.3
diff -u -p -r1.3 porting_to.html
--- htdocs/gcc-6/porting_to.html	2 Feb 2016 20:34:14 -0000	1.3
+++ htdocs/gcc-6/porting_to.html	3 Feb 2016 17:04:50 -0000
@@ -36,8 +36,10 @@ manner. Additions and suggestions for im
 <h3>Default standard is now GNU++14</h3>
 
 <p>
-GCC defaults to <code>-std=gnu++14</code> instead of <code>-std=gnu++98</code>.
-This brings several changes that users should be aware of.  The following
+GCC 6 defaults to <code>-std=gnu++14</code> instead of <code>-std=gnu++98</code>:
+the C++14 standard, plus GNU extensions.
+This brings several changes that users should be aware of, some new with the C++14
+standard, others that appeared with the C++11 standard.  The following
 paragraphs describe some of these changes and suggest how to deal with them.
 </p>
 
@@ -45,6 +47,10 @@ paragraphs describe some of these change
 use the <code>-std=gnu++98</code> command-line option, perhaps by putting it
 in <code>CXXFLAGS</code> or similar variables in Makefiles.</p>
 
+<p>Alternatively, you might prefer to update to gnu++11, bringing in the C++11
+changes but not the C++14 ones.  If so, use the <code>-std=gnu++11</code>
+command-line option.</p>
+
 <h4>Narrowing conversions</h4>
 
 <p>

Re: [PATCH] Re: [wwwdocs] Add common C++ issues to /gcc-6/porting_to.html

[Jonathan Wakely]

On 03/02/16 12:13 -0500, David Malcolm wrote:
>On Tue, 2016-02-02 at 20:36 +0000, Jonathan Wakely wrote:
>
>I had some difficulty reading the new section; mostly due to the
>leapfrogging of C++11 by the default (my immediate reaction was "why is
>it talking about C++11 when the option says GNU++14?")
>
>I'm attaching a patch which I hope clarifies it, for people like me who
>aren't experts in C++ standards (with that as a caveat... I'm not an
>expert in C++ standards).
>
>Is the attached OK to commit? (it validates)
>
>Some other notes below.
>
>> Index: htdocs/gcc-6/porting_to.html
>> ===================================================================
>> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
>> retrieving revision 1.2
>> diff -u -r1.2 porting_to.html
>> --- htdocs/gcc-6/porting_to.html	27 Jan 2016 14:40:26 -0000	
>> 1.2
>> +++ htdocs/gcc-6/porting_to.html	2 Feb 2016 20:32:29 -0000
>
>[...snip...]
>
>> +<h4>Cannot convert 'bool' to 'T*'</h4>
>> +
>> +<p>
>> +The current C++ standard only allows integer literals to be used as
>> null
>
>Which standard?

The current one :-)

That was deliberate, because formally the C++11 standard _did_ allow
false and (1 - 1) as null pointer constants. That was changed for
C++14, but was the subject of a defect report against C++11 and so G++
implements the C++14 rule even in C++11 mode (as does Clang).

So it would be wrong to say C++11, and misleading to say C++14.

Maybe we should just say "The C++ standard no longer allows ..."


>> +pointer constants, so other constants such as <code>false</code> and
>> +<code>(1 - 1)</code> cannot be used where a null pointer is desired.
>> Code that
>> +fails to compile with this error should be changed to use
>> <code>nullptr</code>,
>> +or <code>0</code>, or <code>NULL</code>.
>> +</p>
>> +
>> +<h4>Cannot convert 'std::ostream' to 'bool'</h4>
>> +
>> +<p>
>> +Since C++11 iostream classes are no longer implicitly convertible to
>> +<code>void*</code> so it is no longer valid to do something like:
>
>Should there be a comma between "C++" and "iostream" here?  (or maybe
>rewrite as: "As of C++, iostream classes"... ?)

As long as we keep the "11" that would be an improvement, yes.

>[...snip...]
>
>
>Hope this is constructive
>Dave

>Index: htdocs/gcc-6/porting_to.html
>===================================================================
>RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
>retrieving revision 1.3
>diff -u -p -r1.3 porting_to.html
>--- htdocs/gcc-6/porting_to.html	2 Feb 2016 20:34:14 -0000	1.3
>+++ htdocs/gcc-6/porting_to.html	3 Feb 2016 17:04:50 -0000
>@@ -36,8 +36,10 @@ manner. Additions and suggestions for im
> <h3>Default standard is now GNU++14</h3>
> 
> <p>
>-GCC defaults to <code>-std=gnu++14</code> instead of <code>-std=gnu++98</code>.
>-This brings several changes that users should be aware of.  The following
>+GCC 6 defaults to <code>-std=gnu++14</code> instead of <code>-std=gnu++98</code>:
>+the C++14 standard, plus GNU extensions.
>+This brings several changes that users should be aware of, some new with the C++14
>+standard, others that appeared with the C++11 standard.  The following
> paragraphs describe some of these changes and suggest how to deal with them.
> </p>

Looks good to me.

>@@ -45,6 +47,10 @@ paragraphs describe some of these change
> use the <code>-std=gnu++98</code> command-line option, perhaps by putting it
> in <code>CXXFLAGS</code> or similar variables in Makefiles.</p>
> 
>+<p>Alternatively, you might prefer to update to gnu++11, bringing in the C++11
>+changes but not the C++14 ones.  If so, use the <code>-std=gnu++11</code>
>+command-line option.</p>

I see no harm in adding this, although the changes from C++98 to C++11
are huge, and the changes from C++11 to C++14 are tiny, so for the
purposes of porting code to work with GCC 6 it's unlikely to help.

Re: [PATCH] [wwwdocs] Add common C++ issues to /gcc-6/porting_to.html

[Mike Stump]

On Feb 3, 2016, at 9:13 AM, David Malcolm <dmalcolm@redhat.com> wrote:
>> +pointer constants, so other constants such as <code>false</code> and
>> +<code>(1 - 1)</code> cannot be used where a null pointer is desired.

So, I’d leave this out entirely.  The subject is porting, not the fine detail pedanticism only a language lawyer could love.  Was this text from a porting experience, or an invention based upon compiler/language mods?

Re: [PATCH] [wwwdocs] Add common C++ issues to /gcc-6/porting_to.html

[Jakub Jelinek]

On Wed, Feb 03, 2016 at 10:42:37AM -0800, Mike Stump wrote:
> On Feb 3, 2016, at 9:13 AM, David Malcolm <dmalcolm@redhat.com> wrote:
> >> +pointer constants, so other constants such as <code>false</code> and
> >> +<code>(1 - 1)</code> cannot be used where a null pointer is desired.
> 
> So, I’d leave this out entirely.  The subject is porting, not the fine detail pedanticism only a language lawyer could love.  Was this text from a porting experience, or an invention based upon compiler/language mods?

I believe trying to use false as pointer is from porting experience,
(1 - 1) most likely not really used in the wild, but just clarifies what is
and what is not the null pointer constant.

	Jakub

Re: [PATCH] [wwwdocs] Add common C++ issues to /gcc-6/porting_to.html

[Jonathan Wakely]

On 03/02/16 19:47 +0100, Jakub Jelinek wrote:
>On Wed, Feb 03, 2016 at 10:42:37AM -0800, Mike Stump wrote:
>> On Feb 3, 2016, at 9:13 AM, David Malcolm <dmalcolm@redhat.com> wrote:
>> >> +pointer constants, so other constants such as <code>false</code> and
>> >> +<code>(1 - 1)</code> cannot be used where a null pointer is desired.
>>
>> So, I’d leave this out entirely.  The subject is porting, not the fine detail pedanticism only a language lawyer could love.  Was this text from a porting experience, or an invention based upon compiler/language mods?
>
>I believe trying to use false as pointer is from porting experience,
>(1 - 1) most likely not really used in the wild, but just clarifies what is
>and what is not the null pointer constant.

Yes, there are *dozens* of packages that fail to build due to "return
false;" in a function that returns a pointer of some kind.

I can't imagine what the authors of that code were thinking, if they
were thinking, or what was wrong with "return NULL;" or "return 0;"
but it compiled in C++98 so apparently people did it.  It doesn't
compile in C++11, so I added it tothe page. The pedantic details of
which standard (or DR) changed the rules matter much less than the
fact the rules changed.

Re: [PATCH] [wwwdocs] Add common C++ issues to /gcc-6/porting_to.html

[Mike Stump]

On Feb 3, 2016, at 2:03 PM, Jonathan Wakely <jwakely@redhat.com> wrote:
> Yes, there are *dozens* of packages that fail to build due to "return
> false;" in a function that returns a pointer of some kind.

Wow, curious.  Anyway, that removes my objection.