| Message ID | 1454519619.4486.17.camel@redhat.com |
|---|---|
| State | New |
| Headers | show |
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.
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?
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
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.
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.
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>