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


Groups > comp.lang.c++ > #88371

Re: g++ -c -Werror -Weverything exercise_2_17.cpp

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.lang.c++
Subject Re: g++ -c -Werror -Weverything exercise_2_17.cpp
Date 2023-01-03 11:47 +0100
Organization A noiseless patient Spider
Message-ID <tp114i$23usn$1@dont-email.me> (permalink)
References (5 earlier) <topj40$hak$1@gioia.aioe.org> <topl5s$11pd6$2@dont-email.me> <tp0hrr$iih$2@gioia.aioe.org> <tp0mqs$22vmh$1@dont-email.me> <tp0rjt$4ea$1@gioia.aioe.org>

Show all headers | View raw


On 03/01/2023 10:13, Juha Nieminen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>>> I cannot comprehend the reason to make that one particular situation
>>> special.
>>
>> It is better than nothing.
> 
> Now that I think about it, I actually don't know if the "narrowing
> conversion" warning given by gcc (and I think also clang) when such
> a conversion happens in initializer lists in particular is just
> because the developers of the compiler decided so, or whether the
> newer C++ standards mandate something along those lines.

The standards mandate it (as you note below).

> 
> However, looking it up, it seems that indeed the C++11 standard
> forbids list-initialization with implicit narrowing conversions.
> (It also seems to disallow it for aggregate initialization.)
> 
> It's a bit annoying to have this inconsistency in the language.
> (Overall, as great as "uniform initialization" sounds on paper,
> in practice it causes a lot of headaches. At a very minimum they
> should have used a different syntax for initializer lists.)

I think a bit of inconsistency and ugly syntax is almost inevitable here 
- backwards compatibility makes it practically impossible to change 
existing behaviour.  I don't know how the language could have done 
anything better here.

Back to comp.lang.c++ | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

g++  -c -Werror -Weverything exercise_2_17.cpp "gdo...@gmail.com" <gdotone@gmail.com> - 2022-12-27 01:22 -0800
  Re: g++ -c -Werror -Weverything exercise_2_17.cpp Öö Tiib <ootiib@hot.ee> - 2022-12-27 02:50 -0800
  Re: g++  -c -Werror -Weverything exercise_2_17.cpp Juha Nieminen <nospam@thanks.invalid> - 2022-12-29 20:33 +0000
    Re: g++ -c -Werror -Weverything exercise_2_17.cpp Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-29 23:20 +0200
      Re: g++ -c -Werror -Weverything exercise_2_17.cpp Juha Nieminen <nospam@thanks.invalid> - 2022-12-30 21:05 +0000
        Re: g++ -c -Werror -Weverything exercise_2_17.cpp Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-30 23:33 +0200
          Re: g++ -c -Werror -Weverything exercise_2_17.cpp Juha Nieminen <nospam@thanks.invalid> - 2022-12-31 15:05 +0000
            Re: g++ -c -Werror -Weverything exercise_2_17.cpp David Brown <david.brown@hesbynett.no> - 2022-12-31 16:40 +0100
              Re: g++ -c -Werror -Weverything exercise_2_17.cpp Juha Nieminen <nospam@thanks.invalid> - 2023-01-03 06:27 +0000
                Re: g++ -c -Werror -Weverything exercise_2_17.cpp David Brown <david.brown@hesbynett.no> - 2023-01-03 08:51 +0100
                Re: g++ -c -Werror -Weverything exercise_2_17.cpp Juha Nieminen <nospam@thanks.invalid> - 2023-01-03 09:13 +0000
                Re: g++ -c -Werror -Weverything exercise_2_17.cpp David Brown <david.brown@hesbynett.no> - 2023-01-03 11:47 +0100
            Re: g++ -c -Werror -Weverything exercise_2_17.cpp Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-31 18:50 +0200
              Re: g++ -c -Werror -Weverything exercise_2_17.cpp David Brown <david.brown@hesbynett.no> - 2022-12-31 18:47 +0100

csiph-web