[wwwdocs] Add a note about in-class initialization of static data member

[wwwdocs] Add a note about in-class initialization of static data member

[Marek Polacek]

Does this look ok?

Index: porting_to.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.9
diff -u -r1.9 porting_to.html
--- porting_to.html	10 Feb 2016 17:21:54 -0000	1.9
+++ porting_to.html	11 Feb 2016 14:18:59 -0000
@@ -269,6 +269,25 @@
 to port the code to use C++11's <code>std::unique_ptr</code> instead.
 </p>
 
+<h3>'constexpr' needed for in-class initialization of static data member</h3>
+
+<p>
+Since C++11, the <code>constexpr</code> keyword is needed when initializing
+a non-integral static data member in a class.  Thus the following program is
+accepted in C++03 (albeit with a <tt>-Wpedantic</tt> warning):
+</p>
+
+<pre><code>
+struct X {
+  const static double i = 10;
+};
+</pre></code>
+
+<p>
+While in C++11, the program above is rejected with an error.  The fix is to
+use <code>constexpr</code> instead of <code>const</code>.
+</p>
+
 <h2>-Wmisleading-indentation</h2>
 <p>
 A new warning <code>-Wmisleading-indentation</code> was added

	Marek

Re: [wwwdocs] Add a note about in-class initialization of static data member

[Jonathan Wakely]

On 11/02/16 15:20 +0100, Marek Polacek wrote:
>Does this look ok?

Looks OK, although how about stressing that it was only allowed as an
extension previously, e.g. ...


>Index: porting_to.html
>===================================================================
>RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
>retrieving revision 1.9
>diff -u -r1.9 porting_to.html
>--- porting_to.html	10 Feb 2016 17:21:54 -0000	1.9
>+++ porting_to.html	11 Feb 2016 14:18:59 -0000
>@@ -269,6 +269,25 @@
> to port the code to use C++11's <code>std::unique_ptr</code> instead.
> </p>
>
>+<h3>'constexpr' needed for in-class initialization of static data member</h3>
>+

In C++98 in-class initialization of static data members is only
allowed for integral types, but as an extension G++ also allowed it
for floating point types:

>+
>+<pre><code>
>+struct X {
>+  const static double i = 10;
>+};
>+</pre></code>

The C++11 standard supports that in-class initialization using
<code>constexpr</code> instead, so the GNU extension is no longer
supported for C++11 or later. Programs relying on the extension will
be rejected with an error. The fix is to
use <code>constexpr</code> instead of <code>const</code>.

Re: [wwwdocs] Add a note about in-class initialization of static data member

[Marek Polacek]

On Thu, Feb 11, 2016 at 03:26:13PM +0000, Jonathan Wakely wrote:
> On 11/02/16 15:20 +0100, Marek Polacek wrote:
> >Does this look ok?
> 
> Looks OK, although how about stressing that it was only allowed as an
> extension previously, e.g. ...

So like this?  I've also added a note about stricter flexarr members rules.

Index: porting_to.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.9
diff -u -r1.9 porting_to.html
--- porting_to.html	10 Feb 2016 17:21:54 -0000	1.9
+++ porting_to.html	11 Feb 2016 16:38:38 -0000
@@ -269,6 +269,41 @@
 to port the code to use C++11's <code>std::unique_ptr</code> instead.
 </p>
 
+<h3>'constexpr' needed for in-class initialization of static data member</h3>
+
+<p>
+Since C++11, the <code>constexpr</code> keyword is needed when initializing
+a non-integral static data member in a class.  Thus the following program is
+accepted in C++03 (albeit with a <tt>-Wpedantic</tt> warning):
+</p>
+
+<pre><code>
+struct X {
+  const static double i = 10;
+};
+</pre></code>
+
+<p>
+The C++11 standard supports that in-class initialization using
+<code>constexpr</code> instead, so the GNU extension is no longer supported for
+C++11 or later.  Programs relying on the extension will be rejected with an
+error.  The fix is to use <code>constexpr</code> instead of <code>const</code>.
+</p>
+
+<h3>Stricter flexible array member rules</h3>
+
+<p>
+As of this release, the C++ compiler is now more strict about flexible array
+member rules.  As a consequence, the following code is no longer accepted:
+</p>
+
+<pre><code>
+union U {
+  int i;
+  char a[];
+};
+</pre></code>
+
 <h2>-Wmisleading-indentation</h2>
 <p>
 A new warning <code>-Wmisleading-indentation</code> was added

	Marek

Re: [wwwdocs] Add a note about in-class initialization of static data member

[Jonathan Wakely]

On 11/02/16 17:39 +0100, Marek Polacek wrote:
>On Thu, Feb 11, 2016 at 03:26:13PM +0000, Jonathan Wakely wrote:
>> On 11/02/16 15:20 +0100, Marek Polacek wrote:
>> >Does this look ok?
>>
>> Looks OK, although how about stressing that it was only allowed as an
>> extension previously, e.g. ...
>
>So like this?  I've also added a note about stricter flexarr members rules.

I think the first paragraph is a bit confusing. Both sentences are
true, but the first does not follow from the second, so "thus" is not
appropriate. Maybe just change "Thus" to "As a GNU extension".


>Index: porting_to.html
>===================================================================
>RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
>retrieving revision 1.9
>diff -u -r1.9 porting_to.html
>--- porting_to.html	10 Feb 2016 17:21:54 -0000	1.9
>+++ porting_to.html	11 Feb 2016 16:38:38 -0000
>@@ -269,6 +269,41 @@
> to port the code to use C++11's <code>std::unique_ptr</code> instead.
> </p>
>
>+<h3>'constexpr' needed for in-class initialization of static data member</h3>
>+
>+<p>
>+Since C++11, the <code>constexpr</code> keyword is needed when initializing
>+a non-integral static data member in a class.  Thus the following program is
>+accepted in C++03 (albeit with a <tt>-Wpedantic</tt> warning):
>+</p>
>+
>+<pre><code>
>+struct X {
>+  const static double i = 10;
>+};
>+</pre></code>
>+
>+<p>
>+The C++11 standard supports that in-class initialization using
>+<code>constexpr</code> instead, so the GNU extension is no longer supported for
>+C++11 or later.  Programs relying on the extension will be rejected with an
>+error.  The fix is to use <code>constexpr</code> instead of <code>const</code>.
>+</p>
>+
>+<h3>Stricter flexible array member rules</h3>
>+
>+<p>
>+As of this release, the C++ compiler is now more strict about flexible array
>+member rules.  As a consequence, the following code is no longer accepted:
>+</p>
>+
>+<pre><code>
>+union U {
>+  int i;
>+  char a[];
>+};
>+</pre></code>
>+
> <h2>-Wmisleading-indentation</h2>
> <p>
> A new warning <code>-Wmisleading-indentation</code> was added
>
>	Marek

Re: [wwwdocs] Add a note about in-class initialization of static data member

[Marek Polacek]

On Thu, Feb 11, 2016 at 05:01:58PM +0000, Jonathan Wakely wrote:
> On 11/02/16 17:39 +0100, Marek Polacek wrote:
> >On Thu, Feb 11, 2016 at 03:26:13PM +0000, Jonathan Wakely wrote:
> >>On 11/02/16 15:20 +0100, Marek Polacek wrote:
> >>>Does this look ok?
> >>
> >>Looks OK, although how about stressing that it was only allowed as an
> >>extension previously, e.g. ...
> >
> >So like this?  I've also added a note about stricter flexarr members rules.
> 
> I think the first paragraph is a bit confusing. Both sentences are
> true, but the first does not follow from the second, so "thus" is not
> appropriate. Maybe just change "Thus" to "As a GNU extension".

Indeed, how could I not notice?  I'll go with "As a GNU extension".

Thanks much.

	Marek

Re: [wwwdocs] Add a note about in-class initialization of static data member

[Martin Sebor]

On 02/11/2016 09:39 AM, Marek Polacek wrote:
> On Thu, Feb 11, 2016 at 03:26:13PM +0000, Jonathan Wakely wrote:
>> On 11/02/16 15:20 +0100, Marek Polacek wrote:
>>> Does this look ok?
>>
>> Looks OK, although how about stressing that it was only allowed as an
>> extension previously, e.g. ...
>
> So like this?  I've also added a note about stricter flexarr members rules.
>
> Index: porting_to.html
> ===================================================================
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
> retrieving revision 1.9
> diff -u -r1.9 porting_to.html
> --- porting_to.html	10 Feb 2016 17:21:54 -0000	1.9
> +++ porting_to.html	11 Feb 2016 16:38:38 -0000
> @@ -269,6 +269,41 @@
>   to port the code to use C++11's <code>std::unique_ptr</code> instead.
>   </p>
>
> +<h3>'constexpr' needed for in-class initialization of static data member</h3>
> +
> +<p>
> +Since C++11, the <code>constexpr</code> keyword is needed when initializing
> +a non-integral static data member in a class.  Thus the following program is
> +accepted in C++03 (albeit with a <tt>-Wpedantic</tt> warning):
> +</p>
> +
> +<pre><code>
> +struct X {
> +  const static double i = 10;
> +};

It''s interesting that when the example is modified to use a double
initializer it is rejected with a hard error even in C++ 03 mode
when -Wpedantic (but not -Werror) is used.  That seems like a bug.
If it isn't, it might be worth mentioning the constraint that the
initializer must be a integer in the text above.

   struct X {
     const static double i = 3.14;
   };

   error: floating-point literal cannot appear in a constant-expression
     const static double i = 3.14;
                            ^~~~

> +</pre></code>
> +
> +<p>
> +The C++11 standard supports that in-class initialization using
> +<code>constexpr</code> instead, so the GNU extension is no longer supported for
> +C++11 or later.  Programs relying on the extension will be rejected with an
> +error.  The fix is to use <code>constexpr</code> instead of <code>const</code>.
> +</p>
> +
> +<h3>Stricter flexible array member rules</h3>
> +
> +<p>
> +As of this release, the C++ compiler is now more strict about flexible array
> +member rules.  As a consequence, the following code is no longer accepted:

In light of bug 69550 I think it might be useful to also mention
(or show an example) that structs with a flexible array as the
only member are rejected as well.

Martin

> +</p>
> +
> +<pre><code>
> +union U {
> +  int i;
> +  char a[];
> +};
> +</pre></code>
> +
>   <h2>-Wmisleading-indentation</h2>
>   <p>
>   A new warning <code>-Wmisleading-indentation</code> was added
>
> 	Marek
>

Re: [wwwdocs] Add a note about in-class initialization of static data member

[Marek Polacek]

On Thu, Feb 11, 2016 at 10:09:19AM -0700, Martin Sebor wrote:
> It''s interesting that when the example is modified to use a double
> initializer it is rejected with a hard error even in C++ 03 mode
> when -Wpedantic (but not -Werror) is used.  That seems like a bug.
> If it isn't, it might be worth mentioning the constraint that the
> initializer must be a integer in the text above.
> 
>   struct X {
>     const static double i = 3.14;
>   };
> 
>   error: floating-point literal cannot appear in a constant-expression
>     const static double i = 3.14;
>                            ^~~~

Hm, indeed; I hadn't notice that.  Dunno if is a bug (clang++ accepts this
with a warning).  I've added ", provided the initializer is an integer",
that should be enough.

> >+<h3>Stricter flexible array member rules</h3>
> >+
> >+<p>
> >+As of this release, the C++ compiler is now more strict about flexible array
> >+member rules.  As a consequence, the following code is no longer accepted:
> 
> In light of bug 69550 I think it might be useful to also mention
> (or show an example) that structs with a flexible array as the
> only member are rejected as well.

Somehow I knew you'd have something to add here ;).  How about this then?

Index: porting_to.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.9
diff -u -r1.9 porting_to.html
--- porting_to.html	10 Feb 2016 17:21:54 -0000	1.9
+++ porting_to.html	11 Feb 2016 17:58:43 -0000
@@ -269,6 +269,53 @@
 to port the code to use C++11's <code>std::unique_ptr</code> instead.
 </p>
 
+<h3>'constexpr' needed for in-class initialization of static data member</h3>
+
+<p>
+Since C++11, the <code>constexpr</code> keyword is needed when initializing a
+non-integral static data member in a class.  As a GNU extension, the following
+program is accepted in C++03 (albeit with a <tt>-Wpedantic</tt> warning),
+provided the initializer is an integer:
+</p>
+
+<pre><code>
+struct X {
+  const static double i = 10;
+};
+</pre></code>
+
+<p>
+The C++11 standard supports that in-class initialization using
+<code>constexpr</code> instead, so the GNU extension is no longer supported for
+C++11 or later.  Programs relying on the extension will be rejected with an
+error.  The fix is to use <code>constexpr</code> instead of <code>const</code>.
+</p>
+
+<h3>Stricter flexible array member rules</h3>
+
+<p>
+As of this release, the C++ compiler is now more strict about flexible array
+member rules.  As a consequence, the following code is no longer accepted:
+</p>
+
+<pre><code>
+union U {
+  int i;
+  char a[];
+};
+</pre></code>
+
+<p>
+Furthermore, the C++ compiler now rejects structures with a flexible array
+member as the only member:
+</p>
+
+<pre><code>
+struct S {
+  char a[];
+};
+</pre></code>
+
 <h2>-Wmisleading-indentation</h2>
 <p>
 A new warning <code>-Wmisleading-indentation</code> was added

	Marek

Re: [wwwdocs] Add a note about in-class initialization of static data member

[Martin Sebor]

>>    struct X {
>>      const static double i = 3.14;
>>    };
>>
>>    error: floating-point literal cannot appear in a constant-expression
>>      const static double i = 3.14;
>>                             ^~~~
>
> Hm, indeed; I hadn't notice that.  Dunno if is a bug (clang++ accepts this
> with a warning).  I've added ", provided the initializer is an integer",
> that should be enough.

I don't think documenting this as a blanket restriction is right.
The code is silently accepted without -Wpedantic and few people
use the option so the added text would be misleading as is.  But
my feeling is that this is just a bug, in which case I wouldn't
expect to see it documented in any case.

>
> Somehow I knew you'd have something to add here ;).  How about this then?

The flexible array addition looks great to me. Thank you!

Martin

Re: [wwwdocs] Add a note about in-class initialization of static data member

[Marek Polacek]

On Thu, Feb 11, 2016 at 11:45:37AM -0700, Martin Sebor wrote:
> >>   struct X {
> >>     const static double i = 3.14;
> >>   };
> >>
> >>   error: floating-point literal cannot appear in a constant-expression
> >>     const static double i = 3.14;
> >>                            ^~~~
> >
> >Hm, indeed; I hadn't notice that.  Dunno if is a bug (clang++ accepts this
> >with a warning).  I've added ", provided the initializer is an integer",
> >that should be enough.
> 
> I don't think documenting this as a blanket restriction is right.
> The code is silently accepted without -Wpedantic and few people
> use the option so the added text would be misleading as is.  But
> my feeling is that this is just a bug, in which case I wouldn't
> expect to see it documented in any case.

Ok, I'll drop that note then.
 
> The flexible array addition looks great to me. Thank you!

Great.  I'll commit the patch.

	Marek

Re: [wwwdocs] Add a note about in-class initialization of static data member

[Martin Sebor]

>> The flexible array addition looks great to me. Thank you!
>
> Great.  I'll commit the patch.

Actually, there is one other thing that might be wort mentioning
about flexible array members.

The type and mangling of flexible array members has changed.  While
in GCC 5 and prior the type of a flexible array member is an array
of zero elements (a GCC extension), in 6 it is that of an array of
an unspecified bound (i.e., T[] as opposed to T[0]).  This is
a silent ABI change with no -fabi-version/-Wabi option.

Martin

Re: [wwwdocs] Add a note about in-class initialization of static data member

[Marek Polacek]

On Thu, Feb 11, 2016 at 01:36:49PM -0700, Martin Sebor wrote:
> >>The flexible array addition looks great to me. Thank you!
> >
> >Great.  I'll commit the patch.
> 
> Actually, there is one other thing that might be wort mentioning
> about flexible array members.
> 
> The type and mangling of flexible array members has changed.  While
> in GCC 5 and prior the type of a flexible array member is an array
> of zero elements (a GCC extension), in 6 it is that of an array of
> an unspecified bound (i.e., T[] as opposed to T[0]).  This is
> a silent ABI change with no -fabi-version/-Wabi option.

Aha.  I think you're better-suited to document this than I am.

	Marek

[wwwdocs] Mention flexible array type and mangling change

[Martin Sebor]

>> Actually, there is one other thing that might be wort mentioning
>> about flexible array members.
>>
>> The type and mangling of flexible array members has changed.  While
>> in GCC 5 and prior the type of a flexible array member is an array
>> of zero elements (a GCC extension), in 6 it is that of an array of
>> an unspecified bound (i.e., T[] as opposed to T[0]).  This is
>> a silent ABI change with no -fabi-version/-Wabi option.
>
> Aha.  I think you're better-suited to document this than I am.

Sure.  Here's the added text.  Please let me know if it's good to
check in.

Martin


Index: htdocs/gcc-6/porting_to.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.12
diff -u -r1.12 porting_to.html
--- htdocs/gcc-6/porting_to.html	11 Feb 2016 18:56:15 -0000	1.12
+++ htdocs/gcc-6/porting_to.html	11 Feb 2016 21:15:30 -0000
@@ -315,6 +315,15 @@
  };
  </code></pre>

+<p>
+Finally, the type and mangling of flexible array members has changed
+from previous releases.  While in GCC 5 and prior the type of a flexible
+array member is an array of zero elements (a GCC extension), in GCC 6 it
+is that of an array of an unspecified bound (i.e., <tt>T[]</tt> as opposed
+to <tt>T[0]</tt>).  This is a silent ABI change with no corresponding
+<tt>-fabi-version</tt> or <tt>-Wabi</tt> option to disable or warn about.
+</p>
+
  <h2>-Wmisleading-indentation</h2>
  <p>
  A new warning <code>-Wmisleading-indentation</code> was added

Re: [wwwdocs] Mention flexible array type and mangling change

[Marek Polacek]

On Thu, Feb 11, 2016 at 02:17:43PM -0700, Martin Sebor wrote:
> >>Actually, there is one other thing that might be wort mentioning
> >>about flexible array members.
> >>
> >>The type and mangling of flexible array members has changed.  While
> >>in GCC 5 and prior the type of a flexible array member is an array
> >>of zero elements (a GCC extension), in 6 it is that of an array of
> >>an unspecified bound (i.e., T[] as opposed to T[0]).  This is
> >>a silent ABI change with no -fabi-version/-Wabi option.
> >
> >Aha.  I think you're better-suited to document this than I am.
> 
> Sure.  Here's the added text.  Please let me know if it's good to
> check in.
> 
> Martin
> 
> 
> Index: htdocs/gcc-6/porting_to.html
> ===================================================================
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
> retrieving revision 1.12
> diff -u -r1.12 porting_to.html
> --- htdocs/gcc-6/porting_to.html	11 Feb 2016 18:56:15 -0000	1.12
> +++ htdocs/gcc-6/porting_to.html	11 Feb 2016 21:15:30 -0000
> @@ -315,6 +315,15 @@
>  };
>  </code></pre>
> 
> +<p>
> +Finally, the type and mangling of flexible array members has changed
> +from previous releases.  While in GCC 5 and prior the type of a flexible
> +array member is an array of zero elements (a GCC extension), in GCC 6 it
> +is that of an array of an unspecified bound (i.e., <tt>T[]</tt> as opposed
> +to <tt>T[0]</tt>).  This is a silent ABI change with no corresponding
> +<tt>-fabi-version</tt> or <tt>-Wabi</tt> option to disable or warn about.
> +</p>
> +

This seems ok to me, thanks.

	Marek