Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #68213 > unrolled thread

{}

Started byDaniel <danielaparker@gmail.com>
First post2019-09-04 05:58 -0700
Last post2019-09-06 11:27 -0700
Articles 10 — 4 participants

Back to article view | Back to comp.lang.c++


Contents

  {} Daniel <danielaparker@gmail.com> - 2019-09-04 05:58 -0700
    Re: {} Ian Collins <ian-news@hotmail.com> - 2019-09-05 06:59 +1200
      Re: {} Daniel <danielaparker@gmail.com> - 2019-09-04 12:48 -0700
      Re: {} Manfred <noname@add.invalid> - 2019-09-05 14:12 +0200
        Re: {} Öö Tiib <ootiib@hot.ee> - 2019-09-05 08:24 -0700
          Re: {} Manfred <noname@add.invalid> - 2019-09-05 20:52 +0200
          Re: {} Daniel <danielaparker@gmail.com> - 2019-09-05 13:23 -0700
            Re: {} Öö Tiib <ootiib@hot.ee> - 2019-09-05 23:44 -0700
              Re: {} Öö Tiib <ootiib@hot.ee> - 2019-09-06 02:06 -0700
                Re: {} Daniel <danielaparker@gmail.com> - 2019-09-06 11:27 -0700

#68213 — {}

FromDaniel <danielaparker@gmail.com>
Date2019-09-04 05:58 -0700
Subject{}
Message-ID<7e1483e8-b52a-42a6-be3d-5e0e8ee9b437@googlegroups.com>
Consider

#include <iostream>
#include <initializer_list>

struct arg_t
{
};

constexpr arg_t arg = arg_t();

class C
{
public:
    C(size_t n)	{}
};

class A
{
public:
    explicit A(size_t n)
    {
	std::cout << "1\n";
    }
    A(std::initializer_list<C> item)
    {
	std::cout << "2\n";
    }
    A(arg_t, size_t n)
    {
        std::cout << "3\n";
    }
    A(arg_t, std::initializer_list<C> item)
    {
        std::cout << "4\n";
    }
};

int main()
{
    A a{ { 2 } };  // (1)
    A b{ arg, { 2 } };  // (2)
}

Output (vs2019):

2
3

I don't understand why one of these constructors is using the 
initializer_list, and the other is not. Explanation?

Thanks,
Daniel

[toc] | [next] | [standalone]


#68220

FromIan Collins <ian-news@hotmail.com>
Date2019-09-05 06:59 +1200
Message-ID<gtafsoFnafoU2@mid.individual.net>
In reply to#68213
On 05/09/2019 00:58, Daniel wrote:
> Consider
> 
> #include <iostream>
> #include <initializer_list>
> 
> struct arg_t
> {
> };
> 
> constexpr arg_t arg = arg_t();
> 
> class C
> {
> public:
>      C(size_t n)	{}
> };
> 
> class A
> {
> public:
>      explicit A(size_t n)
>      {
> 	std::cout << "1\n";
>      }
>      A(std::initializer_list<C> item)
>      {
> 	std::cout << "2\n";
>      }
>      A(arg_t, size_t n)
>      {
>          std::cout << "3\n";
>      }
>      A(arg_t, std::initializer_list<C> item)
>      {
>          std::cout << "4\n";
>      }
> };
> 
> int main()
> {
>      A a{ { 2 } };  // (1)
>      A b{ arg, { 2 } };  // (2)
> }
> 
> Output (vs2019):
> 
> 2
> 3
> 
> I don't understand why one of these constructors is using the
> initializer_list, and the other is not. Explanation?

Does the compiler issue any warnings?

gcc gives your expected result (2,4), clang thinks you intended to call 
A(arg_t, size_t n) and issues a warning

/tmp/x.cc:40:15: warning: braces around scalar initializer 
[-Wbraced-scalar-init]
     A b{ arg, { 2 } };  // (2)
               ^~~~~~

I'm not sure which one is correct in this case!

Cheers,
Ian.

[toc] | [prev] | [next] | [standalone]


#68222

FromDaniel <danielaparker@gmail.com>
Date2019-09-04 12:48 -0700
Message-ID<0d7ced84-46df-4eeb-ab5f-2454a894c443@googlegroups.com>
In reply to#68220
On Wednesday, September 4, 2019 at 2:59:50 PM UTC-4, Ian Collins wrote:
> On 05/09/2019 00:58, Daniel wrote:
> > Consider
> > 
> > #include <iostream>
> > #include <initializer_list>
> > 
> > struct arg_t
> > {
> > };
> > 
> > constexpr arg_t arg = arg_t();
> > 
> > class C
> > {
> > public:
> >      C(size_t n)	{}
> > };
> > 
> > class A
> > {
> > public:
> >      explicit A(size_t n)
> >      {
> > 	std::cout << "1\n";
> >      }
> >      A(std::initializer_list<C> item)
> >      {
> > 	std::cout << "2\n";
> >      }
> >      A(arg_t, size_t n)
> >      {
> >          std::cout << "3\n";
> >      }
> >      A(arg_t, std::initializer_list<C> item)
> >      {
> >          std::cout << "4\n";
> >      }
> > };
> > 
> > int main()
> > {
> >      A a{ { 2 } };  // (1)
> >      A b{ arg, { 2 } };  // (2)
> > }
> > 
> > Output (vs2019):
> > 
> > 2
> > 3
> > 
> > I don't understand why one of these constructors is using the
> > initializer_list, and the other is not. Explanation?
> 
> Does the compiler issue any warnings?
> 
> gcc gives your expected result (2,4), clang thinks you intended to call 
> A(arg_t, size_t n) and issues a warning
> 
> /tmp/x.cc:40:15: warning: braces around scalar initializer 
> [-Wbraced-scalar-init]
>      A b{ arg, { 2 } };  // (2)
>                ^~~~~~
> 
> I'm not sure which one is correct in this case!
> 

Thanks for the observations, I thought I understood the issues with the 
uniform initialization and std::initializer_list, but I don't understand this 
result. vs2019 doesn't give any warnings at level 4, apart from my 
unreferenced parameters.

Best regards,
Daniel 

[toc] | [prev] | [next] | [standalone]


#68226

FromManfred <noname@add.invalid>
Date2019-09-05 14:12 +0200
Message-ID<qkqu3r$p9g$1@gioia.aioe.org>
In reply to#68220
On 9/4/2019 8:59 PM, Ian Collins wrote:
> On 05/09/2019 00:58, Daniel wrote:
>> Consider
>>
>> #include <iostream>
>> #include <initializer_list>
>>
>> struct arg_t
>> {
>> };
>>
>> constexpr arg_t arg = arg_t();
>>
>> class C
>> {
>> public:
>>      C(size_t n)    {}
>> };
>>
>> class A
>> {
>> public:
>>      explicit A(size_t n)
>>      {
>>     std::cout << "1\n";
>>      }
>>      A(std::initializer_list<C> item)
>>      {
>>     std::cout << "2\n";
>>      }
>>      A(arg_t, size_t n)
>>      {
>>          std::cout << "3\n";
>>      }
>>      A(arg_t, std::initializer_list<C> item)
>>      {
>>          std::cout << "4\n";
>>      }
>> };
>>
>> int main()
>> {
>>      A a{ { 2 } };  // (1)
>>      A b{ arg, { 2 } };  // (2)
>> }
>>
>> Output (vs2019):
>>
>> 2
>> 3
>>
>> I don't understand why one of these constructors is using the
>> initializer_list, and the other is not. Explanation?
> 
> Does the compiler issue any warnings?
> 
> gcc gives your expected result (2,4), clang thinks you intended to call 
> A(arg_t, size_t n) and issues a warning
> 
> /tmp/x.cc:40:15: warning: braces around scalar initializer 
> [-Wbraced-scalar-init]
>      A b{ arg, { 2 } };  // (2)
>                ^~~~~~
> 
> I'm not sure which one is correct in this case!
> 
> Cheers,
> Ian.

To me, it looks like gcc is the correct one.

[toc] | [prev] | [next] | [standalone]


#68228

FromÖö Tiib <ootiib@hot.ee>
Date2019-09-05 08:24 -0700
Message-ID<4866a84c-cc09-4ba2-920f-c325a6045fb5@googlegroups.com>
In reply to#68226
On Thursday, 5 September 2019 15:12:56 UTC+3, Manfred  wrote:
> On 9/4/2019 8:59 PM, Ian Collins wrote:
> > On 05/09/2019 00:58, Daniel wrote:
> >> Consider
> >>
> >> #include <iostream>
> >> #include <initializer_list>
> >>
> >> struct arg_t
> >> {
> >> };
> >>
> >> constexpr arg_t arg = arg_t();
> >>
> >> class C
> >> {
> >> public:
> >>      C(size_t n)    {}
> >> };
> >>
> >> class A
> >> {
> >> public:
> >>      explicit A(size_t n)
> >>      {
> >>     std::cout << "1\n";
> >>      }
> >>      A(std::initializer_list<C> item)
> >>      {
> >>     std::cout << "2\n";
> >>      }
> >>      A(arg_t, size_t n)
> >>      {
> >>          std::cout << "3\n";
> >>      }
> >>      A(arg_t, std::initializer_list<C> item)
> >>      {
> >>          std::cout << "4\n";
> >>      }
> >> };
> >>
> >> int main()
> >> {
> >>      A a{ { 2 } };  // (1)
> >>      A b{ arg, { 2 } };  // (2)
> >> }
> >>
> >> Output (vs2019):
> >>
> >> 2
> >> 3
> >>
> >> I don't understand why one of these constructors is using the
> >> initializer_list, and the other is not. Explanation?
> > 
> > Does the compiler issue any warnings?
> > 
> > gcc gives your expected result (2,4), clang thinks you intended to call 
> > A(arg_t, size_t n) and issues a warning
> > 
> > /tmp/x.cc:40:15: warning: braces around scalar initializer 
> > [-Wbraced-scalar-init]
> >      A b{ arg, { 2 } };  // (2)
> >                ^~~~~~
> > 
> > I'm not sure which one is correct in this case!
> > 
> > Cheers,
> > Ian.
> 
> To me, it looks like gcc is the correct one.

It may be unsure and so it is bad that only clang warns about it.
The [dcl.init.list] has felt ambiguous since 2011 and so
gcc, clang, MSVC and ICC have had slight differences with
those initializer_lists.
Current issue seems to be about differences of interpretation 
of "list has a single element" special cases in it.
 

[toc] | [prev] | [next] | [standalone]


#68235

FromManfred <noname@add.invalid>
Date2019-09-05 20:52 +0200
Message-ID<qkrlh9$bdm$1@gioia.aioe.org>
In reply to#68228
On 9/5/2019 5:24 PM, Öö Tiib wrote:
> On Thursday, 5 September 2019 15:12:56 UTC+3, Manfred  wrote:
>> On 9/4/2019 8:59 PM, Ian Collins wrote:
>>> On 05/09/2019 00:58, Daniel wrote:
>>>> Consider
>>>>
>>>> #include <iostream>
>>>> #include <initializer_list>
>>>>
>>>> struct arg_t
>>>> {
>>>> };
>>>>
>>>> constexpr arg_t arg = arg_t();
>>>>
>>>> class C
>>>> {
>>>> public:
>>>>       C(size_t n)    {}
>>>> };
>>>>
>>>> class A
>>>> {
>>>> public:
>>>>       explicit A(size_t n)
>>>>       {
>>>>      std::cout << "1\n";
>>>>       }
>>>>       A(std::initializer_list<C> item)
>>>>       {
>>>>      std::cout << "2\n";
>>>>       }
>>>>       A(arg_t, size_t n)
>>>>       {
>>>>           std::cout << "3\n";
>>>>       }
>>>>       A(arg_t, std::initializer_list<C> item)
>>>>       {
>>>>           std::cout << "4\n";
>>>>       }
>>>> };
>>>>
>>>> int main()
>>>> {
>>>>       A a{ { 2 } };  // (1)
>>>>       A b{ arg, { 2 } };  // (2)
>>>> }
>>>>
>>>> Output (vs2019):
>>>>
>>>> 2
>>>> 3
>>>>
>>>> I don't understand why one of these constructors is using the
>>>> initializer_list, and the other is not. Explanation?
>>>
>>> Does the compiler issue any warnings?
>>>
>>> gcc gives your expected result (2,4), clang thinks you intended to call
>>> A(arg_t, size_t n) and issues a warning
>>>
>>> /tmp/x.cc:40:15: warning: braces around scalar initializer
>>> [-Wbraced-scalar-init]
>>>       A b{ arg, { 2 } };  // (2)
>>>                 ^~~~~~
>>>
>>> I'm not sure which one is correct in this case!
>>>
>>> Cheers,
>>> Ian.
>>
>> To me, it looks like gcc is the correct one.
> 
> It may be unsure and so it is bad that only clang warns about it.
> The [dcl.init.list] has felt ambiguous since 2011 and so
> gcc, clang, MSVC and ICC have had slight differences with
> those initializer_lists.
> Current issue seems to be about differences of interpretation
> of "list has a single element" special cases in it.
>   
> 

Thanks for the link.
Indeed the wording seems ambiguous, and even the examples in (1.10) are 
of limited help:
     int a = {1};
     ...
     return { "Norah" }; // return list of one element

What would be the rationale to distinguish between these two cases?

Reading on, you probably mean clause (3.8). Here the examples focus on 
the constructor syntax only, but indeed there is a problem on where a 
single object or a list of one object is initialized.

[toc] | [prev] | [next] | [standalone]


#68238

FromDaniel <danielaparker@gmail.com>
Date2019-09-05 13:23 -0700
Message-ID<380ffd7a-aeee-4888-b5bf-304be8f69b3e@googlegroups.com>
In reply to#68228
On Thursday, September 5, 2019 at 11:24:51 AM UTC-4, Öö Tiib wrote:

> It may be unsure and so it is bad that only clang warns about it.
> The [dcl.init.list] has felt ambiguous since 2011 and so
> gcc, clang, MSVC and ICC have had slight differences with
> those initializer_lists.
> Current issue seems to be about differences of interpretation 
> of "list has a single element" special cases in it.

This appears to be the issue

https://wg21.cmeerw.net/cwg/issue1589

There is a suggested resolution that applies to 1589 in

https://wg21.cmeerw.net/cwg/issue1467

Anyone can tell me what is status "cd4"?

Thanks,
Daniel

[toc] | [prev] | [next] | [standalone]


#68251

FromÖö Tiib <ootiib@hot.ee>
Date2019-09-05 23:44 -0700
Message-ID<2aaf4c8a-710d-41ad-935b-bd2ddd691ee8@googlegroups.com>
In reply to#68238
On Thursday, 5 September 2019 23:23:48 UTC+3, Daniel  wrote:
> 
> Anyone can tell me what is status "cd4"?

The "C++ Standard Core Language Active Issues" document describes it as:
"CD4: A DR/DRWP or Accepted/WP issue not resolved in C++14 but included in the Committee Draft advanced for balloting at the June, 2014 WG21 meeting."
<http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html>

[toc] | [prev] | [next] | [standalone]


#68253

FromÖö Tiib <ootiib@hot.ee>
Date2019-09-06 02:06 -0700
Message-ID<d149740c-3991-4c52-9012-69904e82ad29@googlegroups.com>
In reply to#68251
On Friday, 6 September 2019 09:44:38 UTC+3, Öö Tiib  wrote:
> On Thursday, 5 September 2019 23:23:48 UTC+3, Daniel  wrote:
> > 
> > Anyone can tell me what is status "cd4"?
> 
> The "C++ Standard Core Language Active Issues" document describes it as:
> "CD4: A DR/DRWP or Accepted/WP issue not resolved in C++14 but included in the Committee Draft advanced for balloting at the June, 2014 WG21 meeting."
> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html>

In layman terms CD4 means that the changes proposed made it into C++17.

My current impression is that clang does not do what 
[over.ics.rank] of C++17 seems to say. The
<https://clang.llvm.org/cxx_dr_status.html> shows that they
consider themselves good with 1467 and 1589 since clang 3.7.  
Yet there are differences:

    #include <initializer_list>
    #include <string>
    #include <iostream>

    void f1(int)
    {
        std::cout << "f1 1\n";
    }

    void f1(std::initializer_list<long>)
    {
        std::cout << "f1 2\n";
    }

    void foo(char const*)
    {
        std::cout << "foo 1\n";
    }

    void foo(std::initializer_list<std::string>)
    {
        std::cout << "foo 2\n";
    }

    int main()
    {
        f1({42});      // both output fl 2 like standard suggests
        foo({"bar"});  // clang  outputs foo 1, g++  outputs foo 2
                              // despite standard seems to suggest foo 2
    }

[toc] | [prev] | [next] | [standalone]


#68261

FromDaniel <danielaparker@gmail.com>
Date2019-09-06 11:27 -0700
Message-ID<d2c6651a-8c9a-4194-ae76-becaba93cc4a@googlegroups.com>
In reply to#68253
On Friday, September 6, 2019 at 5:07:09 AM UTC-4, Öö Tiib wrote:
> 
> In layman terms CD4 means that the changes proposed made it into C++17.
> 
Thanks :-)
Daniel

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.c++


csiph-web