{} initialization inconsistency

[porp...@gmail.com]

Hi All,

My g++ version 7.2.0 shows the following messages while compiling the code snippets:

int b = {2.5};
error: narrowing conversion of ‘2.5e+0’ from ‘double’ to ‘int’ inside { } [-Wnarrowing]

double f = 2.5;
int b = {f};
warning: narrowing conversion of ‘f’ from ‘double’ to ‘int’ inside { } [-Wnarrowing]

Why the g++'s output is inconsistent. I do not pass any extra parameters to g++ in both cases.
Of course in the second case g++ generates a binary.

Thanks for clarification

[Marcel Mueller]

In the first case it is sure that the value 2.5 will never be assigned
while in the second case the value of f might be changed meanwhile to a
whole number or the truncation might be intended.

I f were a compile time constant you would probably end up with the
error too.


Marcel

[James R. Kuyper]

When you use the numeric literal, g++ knows that 2.5 will be converted
to 2.0, losing information, so it treats it as an error.

When you use the variable, g++ doesn't necessarily know which value that
variable will have at the time of the conversion. If it had, for
instance, the value 3.0, the narrowing conversion wouldn't be a problem.
Since it can't be sure, it only provides a warning.
Note: if there's only one value the variable could hold at that point in
the program, it might be perfectly safe, or it might be dangerous, and
g++ could, in principle, use that information to decide whether an error
message is needed. However, g++ is not required to figure out what value
the variable must hold, and might not bother attempting to do so.

[Alf P. Steinbach]

A potentially narrowing conversion isn't allowed for curly braces
initialization.

As a practical matter the `warning` is therefore incorrect for
standard-conforming mode.

However, the C++ standard itself doesn't differentiate between different
kinds of diagnostics such as “warning” versus “error”: that's a strong
in-practice convention, but not a formal requirement. At one time this
was discussed at length, how the compiler could choose to treat an
unnoticeably short blinking of the Caps Lock indicator as a diagnostic,
use that to diagnose ANY code as a language extension, and proceed to
produce an arbitrary executable, being formally correct. Which
exemplifies that the C++ standard is much more a practical guide for
compiler vendors than a formal description of the language.


Cheers!

- Alf

[James R. Kuyper]

Such a program is ill-formed (8.5.1p2), and violates a diagnosable rule.
The only requirement on an implementation translating such code is that
it produce at least one diagnostic (1.4p2). There's no requirement that,
for instance, it must reject the program.

> As a practical matter the `warning` is therefore incorrect for
> standard-conforming mode.

A "warning" qualifies as a diagnostic message for purposes of
standard-conformance, so long as the implementation's documentation
identifies it as such (1.3.6). Most compilers have at least some
situations where they produce warnings instead of error messages, and
continue translating the program, even when a diagnostic is mandatory.

[Alf P. Steinbach]

Considering only the rhetorical, it was a good idea to delete my
paragraph stating that, and inserting your own as a response, as if
somehow I'd missed that.

Note that the paragraph you deleted to insert your own, was much more
accurate than the one you inserted.

Your statement implies that the standard talks about warnings versus
errors: it doesn't.

> Most compilers have at least some
> situations where they produce warnings instead of error messages, and
> continue translating the program, even when a diagnostic is mandatory.

Cheers & hth.,

- Alf

[james...@verizon.net]

On Wednesday, October 11, 2017 at 5:13:12 PM UTC-4, Alf P. Steinbach wrote:
> On 10/11/2017 8:51 PM, James R. Kuyper wrote:
> > On 2017-10-11 14:20, Alf P. Steinbach wrote:

...

> >> As a practical matter the `warning` is therefore incorrect for
> >> standard-conforming mode.
> >
> > A "warning" qualifies as a diagnostic message for purposes of
> > standard-conformance, so long as the implementation's documentation
> > identifies it as such (1.3.6).
>
> Considering only the rhetorical, it was a good idea to delete my
> paragraph stating that, and inserting your own as a response, as if
> somehow I'd missed that.

The paragraph I deleted did not clarify that identification of something as a diagnostic is entirely at the implementation's discretion, it's not limited to a binary distinction between "warnings" and "errors". You mentioned other more absurd possibilities being discussed, but you dismissed them as if permission to use those other possibilities was an unintentional defect in the standard, rather than a deliberate decision on the part of the committee.

My words didn't emphasize that fact either, but they did include a citation of the relevant text, from which that conclusion can be reached. I generally prefer to provide citations rather than arguments, where possible, leaving the reader free to reach his own conclusions about the meaning of the cited text.

> Note that the paragraph you deleted to insert your own, was much more
> accurate than the one you inserted.
>
> Your statement implies that the standard talks about warnings versus
> errors: it doesn't.

I intended no such implication, and I see no such implication. I could, with equal accuracy, have said that "A blinking Christmas tree light qualifies as a diagnostic message for purposes of standard-conformance, so long as the implementation's documentation identifies it as such." Perhaps the absurdity of that true statement would have made my point clearer?

[Alf P. Steinbach]

On 10/11/2017 11:46 PM, james...@verizon.net wrote:
> On Wednesday, October 11, 2017 at 5:13:12 PM UTC-4, Alf P. Steinbach
> wrote:
>> On 10/11/2017 8:51 PM, James R. Kuyper wrote:
>>> On 2017-10-11 14:20, Alf P. Steinbach wrote:
> ...
>>>> As a practical matter the `warning` is therefore incorrect for
>>>> standard-conforming mode.
>>>
>>> A "warning" qualifies as a diagnostic message for purposes of
>>> standard-conformance, so long as the implementation's
>>> documentation identifies it as such (1.3.6).
>>
>> Considering only the rhetorical, it was a good idea to delete my
>> paragraph stating that, and inserting your own as a response, as if
>> somehow I'd missed that.
>
> The paragraph I deleted did not clarify that identification of
> something as a diagnostic is entirely at the implementation's
> discretion,

Train on reading, my friend.

> it's not limited to a binary distinction between "warnings" and
> "errors".

And train on not offering this kind of absurd misrepresentation.

How many times must I tell you that the standard does not mention error
versus warning diagnostics, at all.

I mean, so that it registers, instead of being deleted by you, to
provide a misleading context for your own remarks?

When you clarify, in a debate with someone, that there are more
possibilities than X and Y, then you are implying that the someone has
labored under a misconception that only X and Y were possibilities.

That's pretty dumb to do when you've just deleted the someone's
paragraph discussing a third possibility:

> You mentioned other more absurd possibilities being discussed, but
> you dismissed them as if permission to use those other possibilities
> was an unintentional defect in the standard, rather than a deliberate
> decision on the part of the committee.

Not sure if it is a defect, but it's definitely a potential for improvement.

> My words didn't emphasize that fact either, but they did include a
> citation of the relevant text, from which that conclusion can be
> reached. I generally prefer to provide citations rather than
> arguments, where possible, leaving the reader free to reach his own
> conclusions about the meaning of the cited text.

If you don't like discussion & valuations then sit down alone with the
standard. It's available to everyone.

>> Note that the paragraph you deleted to insert your own, was much
>> more accurate than the one you inserted.
>>
>> Your statement implies that the standard talks about warnings
>> versus errors: it doesn't.
>
> I intended no such implication, and I see no such implication.

You wrote “A "warning" qualifies as a diagnostic message for purposes of
standard-conformance” followed by a not quoted reference to the
standard (presumably C++14). As if that reference said what you said. It
doesn't. It doesn't even use or mention that concept.

Keep in mind that readers don't have in front of their eyes what you
have in front of yours: their context is just what you /write/, not what
you see when you're writing it.

So again, I suggest you train on reading – not just what others write,
but also what you write yourself.

> I could, with equal accuracy, have said that "A blinking Christmas
> tree light qualifies as a diagnostic message for purposes of
> standard-conformance, so long as the implementation's documentation
> identifies it as such." Perhaps the absurdity of that true statement
> would have made my point clearer?

Yes, except that the point was made in my posting that you replied to.

[james...@verizon.net]

On Wednesday, October 11, 2017 at 8:05:56 PM UTC-4, Alf P. Steinbach wrote:
> On 10/11/2017 11:46 PM, james...@verizon.net wrote:
> > On Wednesday, October 11, 2017 at 5:13:12 PM UTC-4, Alf P. Steinbach
> > wrote:

...

> How many times must I tell you that the standard does not mention error
> versus warning diagnostics, at all.

I don't know. How long will it take you to realize that I never suggested otherwise? If you have no intention of recognizing that truth, I recommend dropping it here, I'm not going to bother responding again on that point.

> When you clarify, in a debate with someone, that there are more
> possibilities than X and Y, then you are implying that the someone has
> labored under a misconception that only X and Y were possibilities.
>
> That's pretty dumb to do when you've just deleted the someone's
> paragraph discussing a third possibility:

Not if that paragraph dismisses those possibilities with wording that incorrectly implies that allowing those possibilities was unintentional.

...

> >> Your statement implies that the standard talks about warnings
> >> versus errors: it doesn't.
> >
> > I intended no such implication, and I see no such implication.
>
> You wrote “A "warning" qualifies as a diagnostic message for purposes of
> standard-conformance” followed by a not quoted reference to the
> standard (presumably C++14). As if that reference said what you said. It
> doesn't. It doesn't even use or mention that concept.

You dropped a key phrase from that sentence "... so long as the implementation's documentation identifies it as such.". As a general rule, if your understanding of a sentence I've written is unchanged by removing a clause from that sentence, then you should consider the possibility that you didn't understand it correctly. My sentences do tend to be overly long and complicated, but their intended meaning generally depends upon all of those complications.