* [Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
@ 2011-01-25 4:16 ` schaub.johannes at googlemail dot com
2011-01-25 5:21 ` schaub.johannes at googlemail dot com
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: schaub.johannes at googlemail dot com @ 2011-01-25 4:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
Johannes Schaub <schaub.johannes at googlemail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #1 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-01-25 03:16:21 UTC ---
Adding Jason. AFAIK he's implemented this for GCC.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
2011-01-25 4:16 ` [Bug c++/47453] " schaub.johannes at googlemail dot com
@ 2011-01-25 5:21 ` schaub.johannes at googlemail dot com
2011-05-12 5:57 ` schaub.johannes at googlemail dot com
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: schaub.johannes at googlemail dot com @ 2011-01-25 5:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #2 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-01-25 03:37:01 UTC ---
(In reply to comment #0)
> In short, the intent seems to be that a "({ ... })" initializer is only allowed
> for class types, where it will hit 8.5.16p6.
>
I'm sorry. I meant 8.5p16 bullet 6. I don't want to add unnecessarily more
confusion to this :)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
2011-01-25 4:16 ` [Bug c++/47453] " schaub.johannes at googlemail dot com
2011-01-25 5:21 ` schaub.johannes at googlemail dot com
@ 2011-05-12 5:57 ` schaub.johannes at googlemail dot com
2011-07-29 6:09 ` d.v.a at ngs dot ru
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: schaub.johannes at googlemail dot com @ 2011-05-12 5:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #3 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-05-12 05:23:15 UTC ---
I think we have the FDIS clear about these cases now. To update:
// invalid
struct A { int a[2]; A():a({1, 2}) { } };
// invalid
int a({0});
// invalid
int const &b({0});
struct A { explicit A(int, int); A(int, long); };
// invalid
A c({1, 2});
// valid (by copy constructor).
A d({1, 2L});
// valid
A e{1, 2};
struct B {
template<typename ...T>
B(initializer_list<int>, T ...);
};
// invalid (the first phase only considers init-list ctors)
// (for the second phase, no constructor is viable)
B f{1, 2, 3};
// valid (T deduced to <>).
B g({1, 2, 3});
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (2 preceding siblings ...)
2011-05-12 5:57 ` schaub.johannes at googlemail dot com
@ 2011-07-29 6:09 ` d.v.a at ngs dot ru
2011-07-29 12:24 ` schaub.johannes at googlemail dot com
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: d.v.a at ngs dot ru @ 2011-07-29 6:09 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
__vic <d.v.a at ngs dot ru> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |d.v.a at ngs dot ru
--- Comment #4 from __vic <d.v.a at ngs dot ru> 2011-07-29 06:08:29 UTC ---
struct A { int a[2]; A():a({1, 2}) { } };
Should be valid. Example:
class cond_variable
{
::pthread_cond_t cond;
public:
constexpr cond_variable() : cond(PTHREAD_COND_INITIALIZER) {}
};
What is pthread_cond_t? Struct? Array? Scalar? How I can be sure this code is
accepted in any case? Uniform initialization initially address this issue.
Out of constructor one can use "=":
::pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
In constructor init-list "=" is prohibited therefore "()" must play a same
role.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (3 preceding siblings ...)
2011-07-29 6:09 ` d.v.a at ngs dot ru
@ 2011-07-29 12:24 ` schaub.johannes at googlemail dot com
2011-08-02 3:26 ` d.v.a at ngs dot ru
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: schaub.johannes at googlemail dot com @ 2011-07-29 12:24 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #5 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-07-29 12:23:35 UTC ---
(In reply to comment #4)
> struct A { int a[2]; A():a({1, 2}) { } };
>
> Should be valid. Example:
>
> class cond_variable
> {
> ::pthread_cond_t cond;
> public:
> constexpr cond_variable() : cond(PTHREAD_COND_INITIALIZER) {}
> };
>
> What is pthread_cond_t? Struct? Array? Scalar? How I can be sure this code is
> accepted in any case? Uniform initialization initially address this issue.
>
Why not say
constexpr cond_variable() : cond PTHREAD_COND_INITIALIZER { }
> Out of constructor one can use "=":
>
> ::pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
>
You can define it as follows to make it work in both cases
#define PTHREAD_COND_INITIALIZER {}
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (4 preceding siblings ...)
2011-07-29 12:24 ` schaub.johannes at googlemail dot com
@ 2011-08-02 3:26 ` d.v.a at ngs dot ru
2011-08-03 18:53 ` [Bug c++/47453] [DR 1214] " jason at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: d.v.a at ngs dot ru @ 2011-08-02 3:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #6 from __vic <d.v.a at ngs dot ru> 2011-08-02 03:25:10 UTC ---
>
> Why not say
>
> constexpr cond_variable() : cond PTHREAD_COND_INITIALIZER { }
>
What if PTHREAD_COND_INITIALIZER is a just scalar?
>
> You can define it as follows to make it work in both cases
>
> #define PTHREAD_COND_INITIALIZER {}
I cannot define/redefine this value. It's already defined in system headers...
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (5 preceding siblings ...)
2011-08-02 3:26 ` d.v.a at ngs dot ru
@ 2011-08-03 18:53 ` jason at gcc dot gnu.org
2011-08-03 19:17 ` schaub.johannes at googlemail dot com
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jason at gcc dot gnu.org @ 2011-08-03 18:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2011.08.03 18:52:08
AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org
|gnu.org |
Summary|Various non-conforming |[DR 1214] Various
|behaviors with |non-conforming behaviors
|braced-init-list |with braced-init-list
|initialization |initialization
Ever Confirmed|0 |1
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (6 preceding siblings ...)
2011-08-03 18:53 ` [Bug c++/47453] [DR 1214] " jason at gcc dot gnu.org
@ 2011-08-03 19:17 ` schaub.johannes at googlemail dot com
2011-08-05 19:16 ` jason at gcc dot gnu.org
2011-08-05 19:38 ` jason at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: schaub.johannes at googlemail dot com @ 2011-08-03 19:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #7 from Johannes Schaub <schaub.johannes at googlemail dot com> 2011-08-03 19:17:04 UTC ---
(In reply to comment #6)
> >
> > You can define it as follows to make it work in both cases
> >
> > #define PTHREAD_COND_INITIALIZER {}
>
> I cannot define/redefine this value. It's already defined in system headers...
Ah I wasn't aware. You can at least workaround it though.
class cond_variable
{
struct { ::pthread_cond_t cond; } wrapper;
public:
constexpr cond_variable() : wrapper{PTHREAD_COND_INITIALIZER} {}
};
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (7 preceding siblings ...)
2011-08-03 19:17 ` schaub.johannes at googlemail dot com
@ 2011-08-05 19:16 ` jason at gcc dot gnu.org
2011-08-05 19:38 ` jason at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: jason at gcc dot gnu.org @ 2011-08-05 19:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #8 from Jason Merrill <jason at gcc dot gnu.org> 2011-08-05 19:15:27 UTC ---
Author: jason
Date: Fri Aug 5 19:15:25 2011
New Revision: 177480
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177480
Log:
PR c++/47453
* typeck.c (build_x_compound_expr_from_list): Also complain
about ({...}).
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist56.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/initlist13.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist50.C
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c++/47453] [DR 1214] Various non-conforming behaviors with braced-init-list initialization
2011-01-25 4:12 [Bug c++/47453] New: Various non-conforming behaviors with braced-init-list initialization schaub.johannes at googlemail dot com
` (8 preceding siblings ...)
2011-08-05 19:16 ` jason at gcc dot gnu.org
@ 2011-08-05 19:38 ` jason at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: jason at gcc dot gnu.org @ 2011-08-05 19:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
Target Milestone|--- |4.7.0
--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> 2011-08-05 19:37:30 UTC ---
Implemented for 4.7.0. Currently this diagnostic is a pedwarn, i.e. only an
error with -pedantic-errors.
^ permalink raw reply [flat|nested] 11+ messages in thread