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

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

initializer list type deduction rules

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

Contents

  initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-09 07:54 +0000
    Re: initializer list type deduction rules Bo Persson <bo@bo-persson.se> - 2022-08-09 10:43 +0200
    Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-09 09:00 -0700
      Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-09 16:06 +0000
        Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-10 02:32 +0000
          Re: initializer list type deduction rules Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-10 09:11 +0300
            Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-10 06:57 +0000
          Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-10 07:31 +0000
        Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-10 00:40 -0700
          Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-10 07:55 +0000
            Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-10 01:13 -0700
              Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-10 08:21 +0000
                Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-10 11:13 -0700
                  Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 08:26 +0000
                    Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 03:38 -0700
                      Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 10:48 +0000
                        Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 04:54 -0700
                          Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 14:34 +0000
                            Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 08:34 -0700
                              Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 15:57 +0000
                                Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 09:16 -0700
                                  Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-13 09:35 +0000
                                    Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-13 09:44 -0700
                                      Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-14 11:12 +0000
                      Re: initializer list type deduction rules scott@slp53.sl.home (Scott Lurndal) - 2022-08-12 14:58 +0000
                        Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 08:59 -0700
                          Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 16:11 +0000
                          Re: initializer list type deduction rules scott@slp53.sl.home (Scott Lurndal) - 2022-08-12 16:44 +0000
                            Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 12:08 -0700
                              Re: initializer list type deduction rules scott@slp53.sl.home (Scott Lurndal) - 2022-08-12 19:58 +0000
                                Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 16:42 -0700
                        Re: initializer list type deduction rules David Brown <david.brown@hesbynett.no> - 2022-08-13 18:14 +0200
                          Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-14 11:06 +0000
                            Re: initializer list type deduction rules David Brown <david.brown@hesbynett.no> - 2022-08-15 11:34 +0200
                              Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-15 19:03 +0000
                                Re: initializer list type deduction rules David Brown <david.brown@hesbynett.no> - 2022-08-15 21:23 +0200
                                  Re: initializer list type deduction rules red floyd <no.spam.here@its.invalid> - 2022-08-15 13:51 -0700
                                  Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-16 19:16 +0000
                                    Re: initializer list type deduction rules Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-21 22:23 +0300
                                      Re: initializer list type deduction rules David Brown <david.brown@hesbynett.no> - 2022-08-22 08:08 +0200
                                        Re: initializer list type deduction rules Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-22 11:37 +0300
                                          Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-22 10:23 +0000
            Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-11 06:24 +0000
              Re: initializer list type deduction rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-11 16:37 +0100
                Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-11 20:12 +0000
                  Re: initializer list type deduction rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-12 00:09 +0100
                    Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-12 11:51 +0000
              Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 08:29 +0000
                Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-12 12:08 +0000
                  Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 14:37 +0000
                  Re: initializer list type deduction rules scott@slp53.sl.home (Scott Lurndal) - 2022-08-12 15:01 +0000
                    Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-15 06:04 +0000
    Re: initializer list type deduction rules Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-08-09 16:08 -0700
      Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-10 02:34 +0000

Page 3 of 3 — ← Prev page 1 2 [3]

#86013

22.08.2022 09:08 David Brown kirjutas:
> On 21/08/2022 21:23, Paavo Helde wrote:
>> 16.08.2022 22:16 Muttley@dastardlyhq.com kirjutas:
>>> Certainly not my experience using Eclipse and VC++ has rather complex 
>>> solution
>>> files so no idea how they would interact with make/cmake.
>>>
>>
>> CMake can easily generate these VC++ project files.
>>
>> Pure make is for masochists, akin to drawing pictures by manually 
>> typing Postscript code. Of course, CMake can easily generate standard 
>> makefiles as well.
>>
> 
> Sometimes people have more complicated needs.  CMake might be a fine 
> solution for many projects (and AIUI it is certainly a great idea if you 
> need to support VC++ as well as Linux/gcc projects), but it will not 
> handle everything.  Make is arguably "lower level" than CMake, and it 
> has more than its share of idiosyncrasies, but it is also more flexible 
> - CMake can generate "standard" makefiles, but not "non-standard" 
> makefiles.
> 
> I'm all in favour of using the best tools for the job, but that doesn't 
> mean dismissing other tools with a wave of the hand.

Right, there are certainly situations when one needs to go lower level. 
Alas, in retrospect I realize that in my work I have never encountered 
such situations and all the brain cells I have lost while creating and 
maintaining raw Makefiles were in vain.

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

#86014

On Mon, 22 Aug 2022 11:37:55 +0300
Paavo Helde <eesnimi@osa.pri.ee> wrote:
>22.08.2022 09:08 David Brown kirjutas:
>> On 21/08/2022 21:23, Paavo Helde wrote:
>>> 16.08.2022 22:16 Muttley@dastardlyhq.com kirjutas:
>>>> Certainly not my experience using Eclipse and VC++ has rather complex 
>>>> solution
>>>> files so no idea how they would interact with make/cmake.
>>>>
>>>
>>> CMake can easily generate these VC++ project files.
>>>
>>> Pure make is for masochists, akin to drawing pictures by manually 
>>> typing Postscript code. Of course, CMake can easily generate standard 
>>> makefiles as well.
>>>
>> 
>> Sometimes people have more complicated needs.  CMake might be a fine 
>> solution for many projects (and AIUI it is certainly a great idea if you 
>> need to support VC++ as well as Linux/gcc projects), but it will not 
>> handle everything.  Make is arguably "lower level" than CMake, and it 
>> has more than its share of idiosyncrasies, but it is also more flexible 
>> - CMake can generate "standard" makefiles, but not "non-standard" 
>> makefiles.
>> 
>> I'm all in favour of using the best tools for the job, but that doesn't 
>> mean dismissing other tools with a wave of the hand.
>
>Right, there are certainly situations when one needs to go lower level. 
>Alas, in retrospect I realize that in my work I have never encountered 
>such situations and all the brain cells I have lost while creating and 
>maintaining raw Makefiles were in vain.

IME people often make makefiles far more complex than they need to be or they
just copy a makefile from another project and don't tailor them to their needs,
instead just changing the build filenames and leaving in a load of unrequired 
cruft.

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

#85845

Muttley@dastardlyhq.com wrote:
> The more pertinent question is why the C++ committee felt the need to 
> duplicate the functionality of typedef.

typedef is confusing. The average person learning C or C++ very easily
gets the impression that typedef works like:

    typedef TheType AliasName;

But that's not at all how it works. It just happens to conform to that
form with elementary types (because that's how elementary type variables
are declared), but when such a person finds the need to create a type
alias eg. for a function pointer (or any of the other more complicated
types, like array pointers), he'll be highly confused because the
above pattern doesn't work with them. A bit of research needs to be
done to find out that eg. a function pointer alias needs to be written
in a quite confusing way:

    typedef int(*AliasName)(int, int, double);

(Understanding typedef becomes easier when you realize that it's just
as if you were declaring a normal variable, and you just add 'typedef'
at the beginning. But given how obscure function and array pointers are...)

The new alternative is more logical, consistent and easier to understand:

    using AliasName = TheType;

In this case it *does* always work using that pattern.

> On a large C++ unix project that only uses typedefs for defining types:
> 
> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)")

In any shell supporting globbing you can just write

    grep typedef **/*.(h|hpp|cc|cpp)

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

#85855

Juha Nieminen <nospam@thanks.invalid> writes:

> Muttley@dastardlyhq.com wrote:
>> The more pertinent question is why the C++ committee felt the need to 
>> duplicate the functionality of typedef.
>
> typedef is confusing. The average person learning C or C++ very easily
> gets the impression that typedef works like:
>
>     typedef TheType AliasName;

I suppose that depends on what they've read and seen.

> But that's not at all how it works. It just happens to conform to that
> form with elementary types (because that's how elementary type variables
> are declared), but when such a person finds the need to create a type
> alias eg. for a function pointer (or any of the other more complicated
> types, like array pointers), he'll be highly confused because the
> above pattern doesn't work with them. A bit of research needs to be
> done to find out that eg. a function pointer alias needs to be written
> in a quite confusing way:
>
>     typedef int(*AliasName)(int, int, double);
>
> (Understanding typedef becomes easier when you realize that it's just
> as if you were declaring a normal variable, and you just add 'typedef'
> at the beginning. But given how obscure function and array pointers
> are...)

I think it's easier for old hands who learned from the classic K&R.  K&R
was always very clear: typedef came late to C, and was added into the
syntax as a storage class specifier, just to get the job done.  Once you
know this, it's clear that typedef, like extern and static, just sits at
the front of a set of otherwise ordinary declarations.

> The new alternative is more logical, consistent and easier to understand:
>
>     using AliasName = TheType;
>
> In this case it *does* always work using that pattern.

Well that's an odd way to put it.  You gave the wrong pattern so of
course this new syntax looks more consistent.  typedef (like any
syntax!) also works using a consistent pattern.

-- 
Ben.

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

#85861

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Well that's an odd way to put it.  You gave the wrong pattern so of
> course this new syntax looks more consistent.  typedef (like any
> syntax!) also works using a consistent pattern.

Yeah, using C's crazy type declaration syntax, which only a fraction
C (or C++) programmers fully understand and remember by heart.

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

#85863

Juha Nieminen <nospam@thanks.invalid> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Well that's an odd way to put it.  You gave the wrong pattern so of
>> course this new syntax looks more consistent.  typedef (like any
>> syntax!) also works using a consistent pattern.
>
> Yeah, using C's crazy type declaration syntax, which only a fraction
> C (or C++) programmers fully understand and remember by heart.

I don't think there are that many people will write

  using fp = int (*)(int, double);

but just baulk at

  typedef int (*fp)(int, double);

What C calls a "type name" -- the int (*)(int, double) part -- is the
bit that bothers most people, at least in my limited experience.

But you probably have much wider experience of what modern C programmers
know and don't know.

-- 
Ben.

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

#85871

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Yeah, using C's crazy type declaration syntax, which only a fraction
>> C (or C++) programmers fully understand and remember by heart.
> 
> I don't think there are that many people will write
> 
>   using fp = int (*)(int, double);
> 
> but just baulk at
> 
>   typedef int (*fp)(int, double);
> 
> What C calls a "type name" -- the int (*)(int, double) part -- is the
> bit that bothers most people, at least in my limited experience.

If we are stuck with C's crazy type declaration syntax, at least it's
nice if it becomes even slightly easier to read.

In the 'using' version the name of the alias is extremely easy to find
with a quick visual scan, because it always comes after the 'using'
and before the '='. Especially if that's what you are interested in
you can ignore everything that comes after the '='.

In the 'typedef' version you have visually find and dig out the name
of the alias from among all the syntax gibberish. And a straightforward
function pointer type is still simple compared to the craziest and most
complex type declarations. (Consider that a more complicated declaration
may use *other* type aliases within it, so it becomes even harder to
find *this* type alias name with a quick visual scan. You really need
to start deciphering the gibberish to find out which one of the names
is the one you are interested in. In the 'using' version you can just
ignore everything after the '=', no matter how complicated.)

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

#85866

On Thu, 11 Aug 2022 06:24:13 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>Muttley@dastardlyhq.com wrote:
>> On a large C++ unix project that only uses typedefs for defining types:
>> 
>> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)")
>
>In any shell supporting globbing you can just write
>
>    grep typedef **/*.(h|hpp|cc|cpp)

Globbing doesn't do recursive searching, hence the find command. Plus your
syntax is wrong anyway and errors with or without quotes.

fenris$ echo $SHELL
/bin/bash
fenris$ grep typedef **/*.(h|hpp|cc|cpp)
-bash: syntax error near unexpected token `('
fenris$ grep typedef "**/*.(h|hpp|cc|cpp)"
grep: **/*.(h|hpp|cc|cpp): No such file or directory

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

#85873

Muttley@dastardlyhq.com wrote:
> On Thu, 11 Aug 2022 06:24:13 -0000 (UTC)
> Juha Nieminen <nospam@thanks.invalid> wrote:
>>Muttley@dastardlyhq.com wrote:
>>> On a large C++ unix project that only uses typedefs for defining types:
>>> 
>>> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)")
>>
>>In any shell supporting globbing you can just write
>>
>>    grep typedef **/*.(h|hpp|cc|cpp)
> 
> Globbing doesn't do recursive searching, hence the find command. Plus your
> syntax is wrong anyway and errors with or without quotes.
> 
> fenris$ echo $SHELL
> /bin/bash
> fenris$ grep typedef **/*.(h|hpp|cc|cpp)
> -bash: syntax error near unexpected token `('
> fenris$ grep typedef "**/*.(h|hpp|cc|cpp)"
> grep: **/*.(h|hpp|cc|cpp): No such file or directory

I would recommend using a real shell. But if you are using a lesser
shell interpreter you can try:

shopt -s globstar
grep typedef **/*.{h,hpp,cc,cpp}

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

#85878

On Fri, 12 Aug 2022 12:08:46 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>Muttley@dastardlyhq.com wrote:
>> On Thu, 11 Aug 2022 06:24:13 -0000 (UTC)
>> Juha Nieminen <nospam@thanks.invalid> wrote:
>>>Muttley@dastardlyhq.com wrote:
>>>> On a large C++ unix project that only uses typedefs for defining types:
>>>> 
>>>> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)")
>>>
>>>In any shell supporting globbing you can just write
>>>
>>>    grep typedef **/*.(h|hpp|cc|cpp)
>> 
>> Globbing doesn't do recursive searching, hence the find command. Plus your
>> syntax is wrong anyway and errors with or without quotes.
>> 
>> fenris$ echo $SHELL
>> /bin/bash
>> fenris$ grep typedef **/*.(h|hpp|cc|cpp)
>> -bash: syntax error near unexpected token `('
>> fenris$ grep typedef "**/*.(h|hpp|cc|cpp)"
>> grep: **/*.(h|hpp|cc|cpp): No such file or directory
>
>I would recommend using a real shell. But if you are using a lesser
>shell interpreter you can try:
>
>shopt -s globstar
>grep typedef **/*.{h,hpp,cc,cpp}

Linux only.

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

#85882

Juha Nieminen <nospam@thanks.invalid> writes:
>Muttley@dastardlyhq.com wrote:
>> On Thu, 11 Aug 2022 06:24:13 -0000 (UTC)
>> Juha Nieminen <nospam@thanks.invalid> wrote:
>>>Muttley@dastardlyhq.com wrote:
>>>> On a large C++ unix project that only uses typedefs for defining types:
>>>> 
>>>> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)")
>>>
>>>In any shell supporting globbing you can just write
>>>
>>>    grep typedef **/*.(h|hpp|cc|cpp)
>> 
>> Globbing doesn't do recursive searching, hence the find command. Plus your
>> syntax is wrong anyway and errors with or without quotes.
>> 
>> fenris$ echo $SHELL
>> /bin/bash
>> fenris$ grep typedef **/*.(h|hpp|cc|cpp)
>> -bash: syntax error near unexpected token `('
>> fenris$ grep typedef "**/*.(h|hpp|cc|cpp)"
>> grep: **/*.(h|hpp|cc|cpp): No such file or directory
>
>I would recommend using a real shell.

You explicitly wrote 'any shell'.

The Bourne shell is the only real shell. David Korn
made it usable (ksh).  csh is a buggy POS.

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

#85927

Scott Lurndal <scott@slp53.sl.home> wrote:
> The Bourne shell is the only real shell.

Nah, it's one of the lesser shells I was talking about.

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

#85818

On 8/9/2022 12:54 AM, Juha Nieminen wrote:
> 
> Even in such a simple case as this:
> 
>    unsigned values[] = { 1, 2, 3, 5 10 };
> 
> vs. this:
> 
>    for(unsigned value: { 1, 2, 3, 5, 10 })
> 
> if you turn on enough compiler warnings eg. gcc will warn about the
> second one (converting 'int' to 'unsigned' may change the sign of the
> result) but not the first one. I believe that in the first case the
> compiler deduces the type of the initializer list to be 'unsigned'
> (even though the literals themselves are of type 'int'), while in
> the second case it does not.
> 

There's no point in searching for any hidden logic in this or trying to 
guess the reason. The message you describe is not a standard diagnostic 
message, i.e. it is not in any way mandated by the standard. Both 
examples are perfectly valid as is. No diagnostic of any kind is expected.

The two contexts are significantly different semantically, which means 
that they are likely handled by two different parts of the compiler. The 
message is just a whim of some developer, who inserted that message in 
one context and didn't bother to do something similar to the other context.

-- 
Best regards,
Andrey

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

#85822

Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> On 8/9/2022 12:54 AM, Juha Nieminen wrote:
>> Even in such a simple case as this:
>> 
>>    unsigned values[] = { 1, 2, 3, 5 10 };
>> 
>> vs. this:
>> 
>>    for(unsigned value: { 1, 2, 3, 5, 10 })
>> 
>> if you turn on enough compiler warnings eg. gcc will warn about the
>> second one (converting 'int' to 'unsigned' may change the sign of the
>> result) but not the first one. I believe that in the first case the
>> compiler deduces the type of the initializer list to be 'unsigned'
>> (even though the literals themselves are of type 'int'), while in
>> the second case it does not.
> 
> There's no point in searching for any hidden logic in this or trying to 
> guess the reason. The message you describe is not a standard diagnostic 
> message, i.e. it is not in any way mandated by the standard. Both 
> examples are perfectly valid as is. No diagnostic of any kind is expected.
> 
> The two contexts are significantly different semantically, which means 
> that they are likely handled by two different parts of the compiler. The 
> message is just a whim of some developer, who inserted that message in 
> one context and didn't bother to do something similar to the other context.

You are missing my point.

The point is not the warning itself. The point is that the warning
demonstrates that in the former case the values are treated as unsigned
ints, while in the second case they are treated as signed ints (even
though the variable is of type unsigned).

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web