Fw: new requirement of "constexpr" for static const float data members is too restrictive

Fw: new requirement of "constexpr" for static const float data members is too restrictive

[Roman Kononov]

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

$ cat test.cc 
struct X { static float const v=1; };

$ g++ -c -std=gnu++0x test.cc 
test.cc:1:33: error: 'constexpr' needed for in-class initialization of
static data member 'v' of non-integral type

This will break a great deal of existing c++ code preventing easy
transition to c++0x. Maybe, the constexpr requirement should be relaxed
in gnu++0x mode.

Please see the trivial patch.

Thanks

[-- Attachment #2: constexpr-float.patch --]
[-- Type: text/x-patch, Size: 561 bytes --]

Index: gcc/cp/decl.c
===================================================================
--- gcc/cp/decl.c	(revision 167200)
+++ gcc/cp/decl.c	(working copy)
@@ -7436,7 +7436,7 @@
      in check_initializer.  */
   if (DECL_P (decl) && DECL_DECLARED_CONSTEXPR_P (decl))
     return 0;
-  else if (cxx_dialect >= cxx0x && !INTEGRAL_OR_ENUMERATION_TYPE_P (type))
+  else if (cxx_dialect >= cxx0x && !INTEGRAL_OR_ENUMERATION_TYPE_P (type) && flag_iso)
     {
       if (literal_type_p (type))
 	error ("%<constexpr%> needed for in-class initialization of static "

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

[Andrew Pinski]

On Mon, Nov 29, 2010 at 1:24 PM, Roman Kononov <roman@xtremedata.com> wrote:
> $ cat test.cc
> struct X { static float const v=1; };
>
> $ g++ -c -std=gnu++0x test.cc
> test.cc:1:33: error: 'constexpr' needed for in-class initialization of
> static data member 'v' of non-integral type
>
> This will break a great deal of existing c++

well this code is not valid C++03 code to begin with.

-- Pinski

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Roman Kononov]

2010-11-29 13:25 CST, Andrew Pinski <pinskia@gmail.com> wrote:
>well this code is not valid C++03 code to begin with.

I agree. I mean "existing gnu++" if you will.

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

[Marc Glisse]

On Mon, 29 Nov 2010, Andrew Pinski wrote:

> On Mon, Nov 29, 2010 at 1:24 PM, Roman Kononov <roman@xtremedata.com> wrote:
>> $ cat test.cc
>> struct X { static float const v=1; };
>>
>> $ g++ -c -std=gnu++0x test.cc
>> test.cc:1:33: error: 'constexpr' needed for in-class initialization of
>> static data member 'v' of non-integral type
>>
>> This will break a great deal of existing c++
>
> well this code is not valid C++03 code to begin with.

It is a gcc extension documented here:
http://gcc.gnu.org/onlinedocs/gcc/Deprecated-Features.html

C++0X seems like the right time to drop a deprecated feature, especially 
since an alternative is now available.

-- 
Marc Glisse

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

[Gabriel Dos Reis]

On Mon, Nov 29, 2010 at 3:24 PM, Roman Kononov <roman@xtremedata.com> wrote:
> $ cat test.cc
> struct X { static float const v=1; };
>
> $ g++ -c -std=gnu++0x test.cc
> test.cc:1:33: error: 'constexpr' needed for in-class initialization of
> static data member 'v' of non-integral type
>
> This will break a great deal of existing c++ code preventing easy
> transition to c++0x. Maybe, the constexpr requirement should be relaxed
> in gnu++0x mode.
>
> Please see the trivial patch.

I believe you may be confused.

Your program does not use `constexpr' at all, so I think your $SUBJECT and
prognosis is not right.  The above code is invalid C++03 code.  It stays
invalid in C++0x.  However, if you do want to write something like that
in C++0x, you do have to use `constexpr' -- that is what the diagnostic
message is saying.

Summary: this is a non-issue.

-- Gaby

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

[Ian Lance Taylor]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> On Mon, Nov 29, 2010 at 3:24 PM, Roman Kononov <roman@xtremedata.com> wrote:
>> $ cat test.cc
>> struct X { static float const v=1; };
>>
>> $ g++ -c -std=gnu++0x test.cc
>> test.cc:1:33: error: 'constexpr' needed for in-class initialization of
>> static data member 'v' of non-integral type
>>
>> This will break a great deal of existing c++ code preventing easy
>> transition to c++0x. Maybe, the constexpr requirement should be relaxed
>> in gnu++0x mode.
>>
>> Please see the trivial patch.
>
> I believe you may be confused.
>
> Your program does not use `constexpr' at all, so I think your $SUBJECT and
> prognosis is not right.  The above code is invalid C++03 code.  It stays
> invalid in C++0x.  However, if you do want to write something like that
> in C++0x, you do have to use `constexpr' -- that is what the diagnostic
> message is saying.
>
> Summary: this is a non-issue.

We could decide not to do anything about this, but I don't think it's a
non-issue.  With -std=gnu++98 g++ accepts this invalid code.  That is,
it is a g++ extension, and the code is properly rejected with
-pedantic-errors.  We could decide to carry the extension forward to
-std=gnu++0x.  Or we could decide to carry the extension forward to
-std=gnu++0x when -fpermissive is used.  Or we could decide to just drop
the extension.

The main problem with the last option is that it complicates the
migration of existing gnu++98 programs to gnu++0x.  It becomes necessary
to add constexpr to use gnu++0x.  Unfortunately, gnu++98 rejects
constexpr.  So there is no simple way to modify this program to be both
valid gnu++98 and valid gnu++0x.  That makes the transition more
difficult.

It seems to me that it would be better for our users to accept this code
in gnu++0x mode with -fpermissive.

Ian

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Miles Bader]

Ian Lance Taylor <iant@google.com> writes:
> We could decide not to do anything about this, but I don't think it's a
> non-issue.  With -std=gnu++98 g++ accepts this invalid code.  That is,
> it is a g++ extension, and the code is properly rejected with
> -pedantic-errors.  We could decide to carry the extension forward to
> -std=gnu++0x.  Or we could decide to carry the extension forward to
> -std=gnu++0x when -fpermissive is used.  Or we could decide to just drop
> the extension.
>
> The main problem with the last option is that it complicates the
> migration of existing gnu++98 programs to gnu++0x.  It becomes necessary
> to add constexpr to use gnu++0x.  Unfortunately, gnu++98 rejects
> constexpr.  So there is no simple way to modify this program to be both
> valid gnu++98 and valid gnu++0x.  That makes the transition more
> difficult.
>
> It seems to me that it would be better for our users to accept this code
> in gnu++0x mode with -fpermissive.

I agree.

I used to use this feature a lot, and indeed that was the primary reason
I _didn't_ use -pedantic-errors.

It's nice that C++0x has an official way to support this feature (it
seems very silly that C++98 didn't), but there are surely many projects
that don't want to commit to C++0x just yet.

[Recently I went through and changed all my uses of "static const float"
fields to use inline static methods instead, which is at least portable,
but yuck, how ugly is that...]

BTW, if it's decided that `-fpermissive' should be necessary, I think
the error message should note that ...

-Miles

-- 
Once, adj. Enough.

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

[Andrew Pinski]

On Mon, Nov 29, 2010 at 4:20 PM, Ian Lance Taylor <iant@google.com> wrote:
> We could decide not to do anything about this, but I don't think it's a
> non-issue.  With -std=gnu++98 g++ accepts this invalid code.  That is,
> it is a g++ extension, and the code is properly rejected with
> -pedantic-errors.  We could decide to carry the extension forward to
> -std=gnu++0x.  Or we could decide to carry the extension forward to
> -std=gnu++0x when -fpermissive is used.  Or we could decide to just drop
> the extension.
>
> The main problem with the last option is that it complicates the
> migration of existing gnu++98 programs to gnu++0x.  It becomes necessary
> to add constexpr to use gnu++0x.  Unfortunately, gnu++98 rejects
> constexpr.  So there is no simple way to modify this program to be both
> valid gnu++98 and valid gnu++0x.  That makes the transition more
> difficult.
>
> It seems to me that it would be better for our users to accept this code
> in gnu++0x mode with -fpermissive.

Except it is documented as a Deprecated feature already so it is
different from a documented extension.  I would say we should just
drop it as it is documented already as deprecated.

-- Pinski

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Gabriel Dos Reis]

On Mon, Nov 29, 2010 at 11:51 PM, Miles Bader <miles@gnu.org> wrote:
> Ian Lance Taylor <iant@google.com> writes:
>> We could decide not to do anything about this, but I don't think it's a
>> non-issue.  With -std=gnu++98 g++ accepts this invalid code.  That is,
>> it is a g++ extension, and the code is properly rejected with
>> -pedantic-errors.  We could decide to carry the extension forward to
>> -std=gnu++0x.  Or we could decide to carry the extension forward to
>> -std=gnu++0x when -fpermissive is used.  Or we could decide to just drop
>> the extension.
>>
>> The main problem with the last option is that it complicates the
>> migration of existing gnu++98 programs to gnu++0x.  It becomes necessary
>> to add constexpr to use gnu++0x.  Unfortunately, gnu++98 rejects
>> constexpr.  So there is no simple way to modify this program to be both
>> valid gnu++98 and valid gnu++0x.  That makes the transition more
>> difficult.
>>
>> It seems to me that it would be better for our users to accept this code
>> in gnu++0x mode with -fpermissive.
>
> I agree.
>
> I used to use this feature a lot, and indeed that was the primary reason
> I _didn't_ use -pedantic-errors.
>
> It's nice that C++0x has an official way to support this feature (it
> seems very silly that C++98 didn't), but there are surely many projects
> that don't want to commit to C++0x just yet.
>
> [Recently I went through and changed all my uses of "static const float"
> fields to use inline static methods instead, which is at least portable,
> but yuck, how ugly is that...]

If you are doing that, why don't you write a simpler code by
just defining (e.g. initializing) the data member outside the class?

>
> BTW, if it's decided that `-fpermissive' should be necessary, I think
> the error message should note that ...
>
> -Miles
>
> --
> Once, adj. Enough.
>
>

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Miles Bader]

On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> If you are doing that, why don't you write a simpler code by
> just defining (e.g. initializing) the data member outside the class?

'cause I want the compiler to be able to use (inline) the underlying values.

-Miles

-- 
Cat is power.  Cat is peace.

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Gabriel Dos Reis]

On Tue, Nov 30, 2010 at 2:17 AM, Miles Bader <miles@gnu.org> wrote:
> On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>> If you are doing that, why don't you write a simpler code by
>> just defining (e.g. initializing) the data member outside the class?
>
> 'cause I want the compiler to be able to use (inline) the underlying values.

then write even simple code: dispense with the class stuff and use
bona fide `const float' at namespace scope.  It works with all compilers
and all versions of GCC/g++.

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Miles Bader]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>>> If you are doing that, why don't you write a simpler code by
>>> just defining (e.g. initializing) the data member outside the class?
>>
>> 'cause I want the compiler to be able to use (inline) the underlying values.
>
> then write even simple code: dispense with the class stuff and use
> bona fide `const float' at namespace scope.  It works with all compilers
> and all versions of GCC/g++.

Right, but I want it in the class namespace.

I.e., I can choose between various types of ugliness -- wrong namespace,
funny syntax, or (currently) gcc-dependence.  I used to choose gcc-
dependence, but then switched to funny syntax.  In the future when c++0x
support is more widespread, of course, I won't have to make such an
annoying choice any more...

-Miles

-- 
XML is like violence.  If it doesn't solve your problem, you're not
using enough of it.

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Gabriel Dos Reis]

On Tue, Nov 30, 2010 at 2:33 AM, Miles Bader <miles@gnu.org> wrote:
> Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>>>> If you are doing that, why don't you write a simpler code by
>>>> just defining (e.g. initializing) the data member outside the class?
>>>
>>> 'cause I want the compiler to be able to use (inline) the underlying values.
>>
>> then write even simple code: dispense with the class stuff and use
>> bona fide `const float' at namespace scope.  It works with all compilers
>> and all versions of GCC/g++.
>
> Right, but I want it in the class namespace.
>
> I.e., I can choose between various types of ugliness -- wrong namespace,
> funny syntax, or (currently) gcc-dependence.  I used to choose gcc-
> dependence, but then switched to funny syntax.  In the future when c++0x
> support is more widespread, of course, I won't have to make such an
> annoying choice any more...

hmm, that sounds like an awful lot of effort put into something that looked
to me as simple code to write using standard functionalities.  Though
I have to confess I do not understand why the class must be right and the
namespace must be  wrong.  (Maybe I have not seen the real code, I
don't know.)

Good luck.

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Miles Bader]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>> I.e., I can choose between various types of ugliness -- wrong namespace,
>> funny syntax, or (currently) gcc-dependence.  I used to choose gcc-
>> dependence, but then switched to funny syntax.  In the future when c++0x
>> support is more widespread, of course, I won't have to make such an
>> annoying choice any more...
>
> hmm, that sounds like an awful lot of effort put into something that looked
> to me as simple code to write using standard functionalities.  Though
> I have to confess I do not understand why the class must be right and the
> namespace must be  wrong.  (Maybe I have not seen the real code, I
> don't know.)

Exactly.  Which is "right" or "acceptable" depends on the details and
programming style, and is subjective to some degree.

Anyway, what's important is whether existing code _may_ have chosen to
use this gcc feature, and may not consider pre-c++0x alternatives
palatable.

The point was made that this feature was already deprecated -- but I
think given that a more-palatable option will be available in c++0x[*],
it would be nice to give users a certain amount of overlap during which
both the old (deprecated) and new features are both supported.  That
would suggest keeping this feature for a while still...

[If there were no such c++0x feature coming, I guess it would matter
less when the deprecation actually changed to removal.]

[*] "more palatable" because only definitions need be updated, not uses,
all attributes of the existing gcc-only code are maintained (inheritance
by subclasses, etc), and there's no need for a change in programming
style.

-Miles

-- 
Learning, n. The kind of ignorance distinguishing the studious.

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Richard Guenther]

On Tue, Nov 30, 2010 at 9:17 AM, Miles Bader <miles@gnu.org> wrote:
> On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>> If you are doing that, why don't you write a simpler code by
>> just defining (e.g. initializing) the data member outside the class?
>
> 'cause I want the compiler to be able to use (inline) the underlying values.

I think it'll do that with initializing the member outside of the class as well.

struct X { static float const v; };
const float X::v = 1;
int main()
{
  return (int)X::v;
}

at least works for me (even when not optimizing - huh).

Richard.

> -Miles
>
> --
> Cat is power.  Cat is peace.
>

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Marc Glisse]

On Tue, 30 Nov 2010, Richard Guenther wrote:

> On Tue, Nov 30, 2010 at 9:17 AM, Miles Bader <miles@gnu.org> wrote:
>> On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
>> <gdr@integrable-solutions.net> wrote:
>>> If you are doing that, why don't you write a simpler code by
>>> just defining (e.g. initializing) the data member outside the class?
>>
>> 'cause I want the compiler to be able to use (inline) the underlying values.
>
> I think it'll do that with initializing the member outside of the class as well.
>
> struct X { static float const v; };
> const float X::v = 1;
> int main()
> {
>  return (int)X::v;
> }
>
> at least works for me (even when not optimizing - huh).

I don't know the OP's code, but X would typically be in a header file, 
included in several translation units. And there is no static or inline 
you can write in front of "const float X::v = 1;" to help with that.

(with LTO the optimizations might still happen with X::v defined 
separately)

-- 
Marc Glisse

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Miles Bader]

Richard Guenther <richard.guenther@gmail.com> writes:
>>> If you are doing that, why don't you write a simpler code by
>>> just defining (e.g. initializing) the data member outside the class?
>>
>> 'cause I want the compiler to be able to use (inline) the underlying values.
>
> I think it'll do that with initializing the member outside of the class as well.
>
> struct X { static float const v; };
> const float X::v = 1;
> int main()
> {
>   return (int)X::v;
> }

That'll work if you only have one file ... but the only way that
definition of X::v would be visible to many users in a typical prog is
if it were in a header file -- and then you'll get a mulitple-definition
error for X::v when linking....

-miles

-- 
Justice, n. A commodity which in a more or less adulterated condition the
State sells to the citizen as a reward for his allegiance, taxes and personal
service.

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Roman Kononov]

On 2010-11-29, 22:26:31 -0800, Andrew Pinski <pinskia@gmail.com> wrote:
> 
> Except it is documented as a Deprecated feature already so it is
> different from a documented extension.  I would say we should just
> drop it as it is documented already as deprecated.

Are you going to drop the feature from g++98?

It is good to document that a feature is deprecated. It is even better
to give a warning at compile time before it's gone.

Roman

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Gabriel Dos Reis]

On Tue, Nov 30, 2010 at 5:39 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Nov 30, 2010 at 9:17 AM, Miles Bader <miles@gnu.org> wrote:
>> On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
>> <gdr@integrable-solutions.net> wrote:
>>> If you are doing that, why don't you write a simpler code by
>>> just defining (e.g. initializing) the data member outside the class?
>>
>> 'cause I want the compiler to be able to use (inline) the underlying values.
>
> I think it'll do that with initializing the member outside of the class as well.
>
> struct X { static float const v; };
> const float X::v = 1;
> int main()
> {
>  return (int)X::v;
> }
>
> at least works for me (even when not optimizing - huh).

I agree.  I think we have a case here where people will
say anything to justify a (mis)feature that leads to brittle
codes, and even more so a deprecated extension.
If people are worried about multiple translation units, they
will still have to provide a definition outside the class -- most
likely.  Which makes me really doubtful that the in-class initialization
provides a better alternative than the standard namespace scope
constant idiom.

Anyway, all this started as a confusion, and as far as I'm concerned
it is a non-issue.  It is up to you guys to decide what you do with it --
I don't think it really is a service to keep it.

-- Gaby

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Miles Bader]

On Tue, Nov 30, 2010 at 11:40 PM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> I agree.  I think we have a case here where people will
> say anything to justify a (mis)feature that leads to brittle
> codes

Why does it "lead to brittle codes"?

> If people are worried about multiple translation units, they
> will still have to provide a definition outside the class -- most
> likely

Why?

Certainly as in my experience, that's not true.

In C++ "static const" is a way of defining constants, and the fact
that integral class "constants" were allowed whereas floating-point
class "constants" were not was just a wart.

It's nice that c++0x has fixed this wart, but there was nothing wrong
with gcc's different method of doing so, beyond its lack of
portability.

-Miles

-- 
Cat is power.  Cat is peace.

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Gabriel Dos Reis]

On Tue, Nov 30, 2010 at 9:07 AM, Miles Bader <miles@gnu.org> wrote:

>> If people are worried about multiple translation units, they
>> will still have to provide a definition outside the class -- most
>> likely
>
> Why?

Because its address may be silently taken (through
binding to references), therefore a definition is needed.

> Certainly as in my experience, that's not true.

That is extra-ordinary, not the norm.

>
> In C++ "static const" is a way of defining constants, and the fact
> that integral class "constants" were allowed whereas floating-point
> class "constants" were not was just a wart.

This misfeature of in-class initialization is a 15-year old debate.
I doubt, it will be resolved on GCC development list.

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

[Ian Lance Taylor]

Andrew Pinski <pinskia@gmail.com> writes:

> On Mon, Nov 29, 2010 at 4:20 PM, Ian Lance Taylor <iant@google.com> wrote:
>> We could decide not to do anything about this, but I don't think it's a
>> non-issue.  With -std=gnu++98 g++ accepts this invalid code.  That is,
>> it is a g++ extension, and the code is properly rejected with
>> -pedantic-errors.  We could decide to carry the extension forward to
>> -std=gnu++0x.  Or we could decide to carry the extension forward to
>> -std=gnu++0x when -fpermissive is used.  Or we could decide to just drop
>> the extension.
>>
>> The main problem with the last option is that it complicates the
>> migration of existing gnu++98 programs to gnu++0x.  It becomes necessary
>> to add constexpr to use gnu++0x.  Unfortunately, gnu++98 rejects
>> constexpr.  So there is no simple way to modify this program to be both
>> valid gnu++98 and valid gnu++0x.  That makes the transition more
>> difficult.
>>
>> It seems to me that it would be better for our users to accept this code
>> in gnu++0x mode with -fpermissive.
>
> Except it is documented as a Deprecated feature already so it is
> different from a documented extension.  I would say we should just
> drop it as it is documented already as deprecated.

I don't think it is very helpful for us to drop a deprecated feature
which we don't even warn about.

If we take this path, can somebody write a patch for 4.6 to add a
-Wdeprecated warning for this?

Ian