* Fw: new requirement of "constexpr" for static const float data members is too restrictive
@ 2010-11-29 22:47 Roman Kononov
2010-11-29 22:50 ` Andrew Pinski
2010-11-30 0:20 ` Gabriel Dos Reis
0 siblings, 2 replies; 22+ messages in thread
From: Roman Kononov @ 2010-11-29 22:47 UTC (permalink / raw)
To: gcc
[-- 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 "
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-29 22:47 Fw: new requirement of "constexpr" for static const float data members is too restrictive Roman Kononov
@ 2010-11-29 22:50 ` Andrew Pinski
2010-11-29 22:53 ` Roman Kononov
2010-11-29 23:24 ` Fw: " Marc Glisse
2010-11-30 0:20 ` Gabriel Dos Reis
1 sibling, 2 replies; 22+ messages in thread
From: Andrew Pinski @ 2010-11-29 22:50 UTC (permalink / raw)
To: Roman Kononov; +Cc: gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-29 22:50 ` Andrew Pinski
@ 2010-11-29 22:53 ` Roman Kononov
2010-11-29 23:24 ` Fw: " Marc Glisse
1 sibling, 0 replies; 22+ messages in thread
From: Roman Kononov @ 2010-11-29 22:53 UTC (permalink / raw)
To: Andrew Pinski; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-29 22:50 ` Andrew Pinski
2010-11-29 22:53 ` Roman Kononov
@ 2010-11-29 23:24 ` Marc Glisse
1 sibling, 0 replies; 22+ messages in thread
From: Marc Glisse @ 2010-11-29 23:24 UTC (permalink / raw)
To: Andrew Pinski; +Cc: Roman Kononov, gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-29 22:47 Fw: new requirement of "constexpr" for static const float data members is too restrictive Roman Kononov
2010-11-29 22:50 ` Andrew Pinski
@ 2010-11-30 0:20 ` Gabriel Dos Reis
2010-11-30 6:26 ` Ian Lance Taylor
1 sibling, 1 reply; 22+ messages in thread
From: Gabriel Dos Reis @ 2010-11-30 0:20 UTC (permalink / raw)
To: Roman Kononov; +Cc: gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 0:20 ` Gabriel Dos Reis
@ 2010-11-30 6:26 ` Ian Lance Taylor
2010-11-30 8:25 ` Miles Bader
2010-11-30 8:34 ` Fw: " Andrew Pinski
0 siblings, 2 replies; 22+ messages in thread
From: Ian Lance Taylor @ 2010-11-30 6:26 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: Roman Kononov, gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 6:26 ` Ian Lance Taylor
@ 2010-11-30 8:25 ` Miles Bader
2010-11-30 8:48 ` Gabriel Dos Reis
2010-11-30 8:34 ` Fw: " Andrew Pinski
1 sibling, 1 reply; 22+ messages in thread
From: Miles Bader @ 2010-11-30 8:25 UTC (permalink / raw)
To: gcc
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 8:25 ` Miles Bader
@ 2010-11-30 8:48 ` Gabriel Dos Reis
2010-11-30 9:05 ` Miles Bader
0 siblings, 1 reply; 22+ messages in thread
From: Gabriel Dos Reis @ 2010-11-30 8:48 UTC (permalink / raw)
To: Miles Bader; +Cc: gcc
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.
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 8:48 ` Gabriel Dos Reis
@ 2010-11-30 9:05 ` Miles Bader
2010-11-30 11:39 ` Gabriel Dos Reis
2010-11-30 13:53 ` Richard Guenther
0 siblings, 2 replies; 22+ messages in thread
From: Miles Bader @ 2010-11-30 9:05 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 9:05 ` Miles Bader
@ 2010-11-30 11:39 ` Gabriel Dos Reis
2010-11-30 11:52 ` Miles Bader
2010-11-30 13:53 ` Richard Guenther
1 sibling, 1 reply; 22+ messages in thread
From: Gabriel Dos Reis @ 2010-11-30 11:39 UTC (permalink / raw)
To: Miles Bader; +Cc: gcc
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++.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 11:39 ` Gabriel Dos Reis
@ 2010-11-30 11:52 ` Miles Bader
2010-11-30 12:00 ` Gabriel Dos Reis
0 siblings, 1 reply; 22+ messages in thread
From: Miles Bader @ 2010-11-30 11:52 UTC (permalink / raw)
To: gcc
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 11:52 ` Miles Bader
@ 2010-11-30 12:00 ` Gabriel Dos Reis
2010-11-30 13:08 ` Miles Bader
0 siblings, 1 reply; 22+ messages in thread
From: Gabriel Dos Reis @ 2010-11-30 12:00 UTC (permalink / raw)
To: Miles Bader; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 12:00 ` Gabriel Dos Reis
@ 2010-11-30 13:08 ` Miles Bader
0 siblings, 0 replies; 22+ messages in thread
From: Miles Bader @ 2010-11-30 13:08 UTC (permalink / raw)
To: gcc
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 9:05 ` Miles Bader
2010-11-30 11:39 ` Gabriel Dos Reis
@ 2010-11-30 13:53 ` Richard Guenther
2010-11-30 14:07 ` Marc Glisse
` (2 more replies)
1 sibling, 3 replies; 22+ messages in thread
From: Richard Guenther @ 2010-11-30 13:53 UTC (permalink / raw)
To: Miles Bader; +Cc: Gabriel Dos Reis, gcc
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.
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 13:53 ` Richard Guenther
@ 2010-11-30 14:07 ` Marc Glisse
2010-11-30 14:34 ` Miles Bader
2010-11-30 15:18 ` Gabriel Dos Reis
2 siblings, 0 replies; 22+ messages in thread
From: Marc Glisse @ 2010-11-30 14:07 UTC (permalink / raw)
To: Richard Guenther; +Cc: Miles Bader, Gabriel Dos Reis, gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 13:53 ` Richard Guenther
2010-11-30 14:07 ` Marc Glisse
@ 2010-11-30 14:34 ` Miles Bader
2010-11-30 15:18 ` Gabriel Dos Reis
2 siblings, 0 replies; 22+ messages in thread
From: Miles Bader @ 2010-11-30 14:34 UTC (permalink / raw)
To: gcc
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 13:53 ` Richard Guenther
2010-11-30 14:07 ` Marc Glisse
2010-11-30 14:34 ` Miles Bader
@ 2010-11-30 15:18 ` Gabriel Dos Reis
2010-11-30 17:40 ` Miles Bader
2 siblings, 1 reply; 22+ messages in thread
From: Gabriel Dos Reis @ 2010-11-30 15:18 UTC (permalink / raw)
To: Richard Guenther; +Cc: Miles Bader, gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 15:18 ` Gabriel Dos Reis
@ 2010-11-30 17:40 ` Miles Bader
2010-11-30 19:04 ` Gabriel Dos Reis
0 siblings, 1 reply; 22+ messages in thread
From: Miles Bader @ 2010-11-30 17:40 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: Richard Guenther, gcc
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 17:40 ` Miles Bader
@ 2010-11-30 19:04 ` Gabriel Dos Reis
0 siblings, 0 replies; 22+ messages in thread
From: Gabriel Dos Reis @ 2010-11-30 19:04 UTC (permalink / raw)
To: Miles Bader; +Cc: Richard Guenther, gcc
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 6:26 ` Ian Lance Taylor
2010-11-30 8:25 ` Miles Bader
@ 2010-11-30 8:34 ` Andrew Pinski
2010-11-30 14:40 ` Roman Kononov
2010-11-30 19:51 ` Fw: " Ian Lance Taylor
1 sibling, 2 replies; 22+ messages in thread
From: Andrew Pinski @ 2010-11-30 8:34 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Gabriel Dos Reis, Roman Kononov, gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 8:34 ` Fw: " Andrew Pinski
@ 2010-11-30 14:40 ` Roman Kononov
2010-11-30 19:51 ` Fw: " Ian Lance Taylor
1 sibling, 0 replies; 22+ messages in thread
From: Roman Kononov @ 2010-11-30 14:40 UTC (permalink / raw)
To: Andrew Pinski; +Cc: Ian Lance Taylor, Gabriel Dos Reis, gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-30 8:34 ` Fw: " Andrew Pinski
2010-11-30 14:40 ` Roman Kononov
@ 2010-11-30 19:51 ` Ian Lance Taylor
1 sibling, 0 replies; 22+ messages in thread
From: Ian Lance Taylor @ 2010-11-30 19:51 UTC (permalink / raw)
To: Andrew Pinski; +Cc: Gabriel Dos Reis, Roman Kononov, gcc
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
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2010-11-30 16:07 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-29 22:47 Fw: new requirement of "constexpr" for static const float data members is too restrictive Roman Kononov
2010-11-29 22:50 ` Andrew Pinski
2010-11-29 22:53 ` Roman Kononov
2010-11-29 23:24 ` Fw: " Marc Glisse
2010-11-30 0:20 ` Gabriel Dos Reis
2010-11-30 6:26 ` Ian Lance Taylor
2010-11-30 8:25 ` Miles Bader
2010-11-30 8:48 ` Gabriel Dos Reis
2010-11-30 9:05 ` Miles Bader
2010-11-30 11:39 ` Gabriel Dos Reis
2010-11-30 11:52 ` Miles Bader
2010-11-30 12:00 ` Gabriel Dos Reis
2010-11-30 13:08 ` Miles Bader
2010-11-30 13:53 ` Richard Guenther
2010-11-30 14:07 ` Marc Glisse
2010-11-30 14:34 ` Miles Bader
2010-11-30 15:18 ` Gabriel Dos Reis
2010-11-30 17:40 ` Miles Bader
2010-11-30 19:04 ` Gabriel Dos Reis
2010-11-30 8:34 ` Fw: " Andrew Pinski
2010-11-30 14:40 ` Roman Kononov
2010-11-30 19:51 ` Fw: " Ian Lance Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).