[Warning] converting to `unsigned int' from `double';

[er]

Hello,

How do I get rid of the warning below without changing the type of n,
while keeping the scientific format? Is static_cast<unsigned>(5e4) the
only way?

const unsigned n = 5e4; // [Warning] converting to `unsigned int' from
`double';

I use : Win7-32 V6.1.7100 Dev-C++ 5.0 beta 9.2 with Mingw/GCC 3.4.2

Thanks.

 

[Vaclav Haisman]

er wrote, On 9.1.2010 16:36:

Hello,

How do I get rid of the warning below without changing the type of n,
while keeping the scientific format? Is static_cast<unsigned>(5e4) the
only way?

const unsigned n = 5e4; // [Warning] converting to `unsigned int' from
`double';

Either use 50000 instead or add a static_cast to unsigned.

 

[Alf P. Steinbach]

* er:

Hello,

How do I get rid of the warning below without changing the type of n,
while keeping the scientific format? Is static_cast<unsigned>(5e4) the
only way?

const unsigned n = 5e4; // [Warning] converting to `unsigned int' from
`double';

I use : Win7-32 V6.1.7100 Dev-C++ 5.0 beta 9.2 with Mingw/GCC 3.4.2

You shouldn't use 'unsigned' for other than bit level manipulation.

The standard library does, for historical reasons, and it sucks.

Ignoring that very good advice (which if you're a smart man is what you should
pay heed to), to just get rid of the warning (brainless dog's or copy-cat's
solution),

unsigned const n = unsigned( 5e4 );

One reply else-thread recommends static_cast. In this context using static_cast
is meaningless, for there's no chance at all that the type involved will change.
But using unsigned is of course infinitely more silly, so just don't do it.

Another reply else-thread suggests that 5e4 may not exactly represent 50000 on
all C++ implementations. But there's no need to be concerned about that: no
actually used floating point representation fails to represent 50000 exactly,
and no future floating point representation will fail. On the other hand, do
think about doing things like

int const n = 50*1000;


Cheers & hth.,

- Alf

 

[James Kanze]

(e-mail address removed):

How do I get rid of the warning below without changing the
type of n, while keeping the scientific format? Is
static_cast<unsigned>(5e4) the only way?
const unsigned n = 5e4; // [Warning] converting to `unsigned int' from
`double';

Note that if the underlying floating-point representation does
not support exact value 50000, the implementation can choose a
nearest representable value, either smaller or larger, so
theoretically you can end up with n== 49999.

Note that the underlying floating-point representation is
required to support 50000. Maybe not exactly (although it's hard
to imagine a conforming one that didn't do it exactly), but at
least enough for a round-trip conversion.

I am not sure if this is just theoretical or not. In IEEE
floating-point standard all integers fitting in the mantissa
of a double are exactly representable, so you should be safe
at least on common desktop platforms, which are all using IEEE
AFAIK. But why should one introduce even theoretically
non-portable code without a good reason?

Because there's no portability issue?

A more reasonable question is why one would want to write an
integer value using exponential notation, other than to confuse
the reader a little bit.

 

[Öö Tiib]

A more reasonable question is why one would want to write an
integer value using exponential notation, other than to confuse
the reader a little bit.

The exponential notation is still fine because result matches with
expectations. Things break loose when they start to use notation like
012 to "beatify" their code and then do not understand why it is 10
and not 12.

 

[er]

Thank you to all the responders.

You shouldn't use 'unsigned' for other than bit level manipulation.

Including to signify the assumption that the quantity is never
negative such as the number of iterations in a loop?

 

[Victor Bazarov]

Thank you to all the responders.


Including to signify the assumption that the quantity is never
negative such as the number of iterations in a loop?

Actually, yes. "Number of" anything should always be an int. If there
is a need to signify anything in your program, have an 'assert' or an
'if' with a 'throw'.

Why 'int'? Well, simple, really. Imagine that your loop counter is the
"current" index from 0 up to whatever the total number of iterations is.
Make the loop counter 'int' and the top 'unsigned', and you get a
conversion warning, reminding you that negative 'int' values will become
positive 'unsigned' ones which most likely doesn't fit your logic.
Yech! Need to shut that warning up, right? Well, hell, let's make the
loop counter 'unsigned' too, yes? The next thing we know, somebody sees
the code

for (i = 0; i < topnumber; ++i)

and decides to rewrite it to count backwards:

for (i = topnumber; --i >= 0

what happens?

Unless your 'long' is the same size as 'int' *and* you need to count
something above INT_MAX, don't use 'unsigned' for counting.

V

 

[Michael Tsang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Why 'int'? Well, simple, really. Imagine that your loop counter is the
"current" index from 0 up to whatever the total number of iterations is.
Make the loop counter 'int' and the top 'unsigned', and you get a
conversion warning, reminding you that negative 'int' values will become
positive 'unsigned' ones which most likely doesn't fit your logic.
Yech! Need to shut that warning up, right? Well, hell, let's make the
loop counter 'unsigned' too, yes? The next thing we know, somebody sees
the code

for (i = 0; i < topnumber; ++i)

and decides to rewrite it to count backwards:

for (i = topnumber; --i >= 0

I would write
for(std::size_t i = 0; i < topnumber; ++i)
instead, declaring the counter in the header.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktVwUIACgkQm4klUUKw07DbCgCeI1n6sOKcv6x3XA5VMXdcPXG+
iRgAnj7jD/aJ2bloFEpVfDq87F1RiL72
=nUCJ
-----END PGP SIGNATURE-----