please wait
Warning C4244 ??
Oct 28, 2015 at 11:32am
Hello, I'm getting an error:
warning C4244: 'argument' : conversion from 'time_t' to 'unsigned int', possible loss of data
If I double click on this error on error list, it takes to the line where srand(time(0)) is coded.I have srand(time(0)) in three functions ..
Can anyone help me how to fix this? Or if I'm wrong in something ..
Pls. tell me what to do. Thanks in advance!
warning C4244: 'argument' : conversion from 'time_t' to 'unsigned int', possible loss of data
If I double click on this error on error list, it takes to the line where srand(time(0)) is coded.I have srand(time(0)) in three functions ..
Can anyone help me how to fix this? Or if I'm wrong in something ..
Pls. tell me what to do. Thanks in advance!
Oct 28, 2015 at 11:43am
It is not an error but a warning.
You may use a cast (like static_cast<int>(...)), but it is not really relevant for this purpose.
You may use a cast (like static_cast<int>(...)), but it is not really relevant for this purpose.
Oct 28, 2015 at 11:44amclosed account (48T7M4Gy)
If you decide not to ignore the warning then use
time_t instead of int for the corresponding seed parameter. Oct 28, 2015 at 1:14pm
The time function returns a value of type time_t, which is usually a signed integer. The srand function takes an unsigned integer as argument. This means that the signed integer has to be converted into an unsigned integer. Your compiler is warning you about this, but in this case there is no harm in doing this. If you want you could cast the integer to unsigned before passing it to srand.
This will get rid of the warning.
|
|
This will get rid of the warning.
Oct 28, 2015 at 4:10pmclosed account (E0p9LyTq)
| Peter87 wrote: |
|---|
| The time function returns a value of type time_t, which is usually a signed integer. |
C11 changed that:
http://en.cppreference.com/w/c/chrono/time_t
Oct 28, 2015 at 6:06pmclosed account (E0p9LyTq)
| Peter87 wrote: |
|---|
| I didn't know that, but how does this affect C++? |
The change could break code that treats it is an alias for a integral type, C or C++.
Oct 28, 2015 at 6:51pm
> C11 changed that
C++ is based on C99; it is unaware of C11.
> The change could break code that treats it is an alias for a integral type, C or C++.
Though changes brought about by C11 are irrelevant to C++, in theory C++ code that assumes that time_t is an integral type could be broken. C99, and consequently C++, have never insisted that time_t must be an integral type; time_t is "an Arithmetic type capable of representing times".
In practice, in every real-life C++ implementation, time_t is an integral type holding the current Unix time. https://en.wikipedia.org/wiki/Unix_time
C++ is based on C99; it is unaware of C11.
| C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:1999 Programming languages — C (hereinafter referred to as the C standard) - IS |
> The change could break code that treats it is an alias for a integral type, C or C++.
Though changes brought about by C11 are irrelevant to C++, in theory C++ code that assumes that time_t is an integral type could be broken. C99, and consequently C++, have never insisted that time_t must be an integral type; time_t is "an Arithmetic type capable of representing times".
In practice, in every real-life C++ implementation, time_t is an integral type holding the current Unix time. https://en.wikipedia.org/wiki/Unix_time
Last edited on Oct 28, 2015 at 6:54pm
Oct 28, 2015 at 6:56pmclosed account (E0p9LyTq)
| JLBorges wrote: |
|---|
| C++ is based on C99; it is unaware of C11. |
I was mistaken. Thank you.
I knew that C and C++ had started diverging, I wasn't completely aware as to when.
Oct 28, 2015 at 6:59pmclosed account (48T7M4Gy)
Of course there is the Microsoft rendition of their compiler warning message that we can't overlook
https://msdn.microsoft.com/en-us/library/th7a07tz.aspx
https://msdn.microsoft.com/en-us/library/th7a07tz.aspx
Last edited on Oct 28, 2015 at 7:24pm
Oct 28, 2015 at 7:16pm
There is no error here: std::srand( std::time(nullptr) ) ;
Even if std::time_t is not an integral type, at most, there would be a warning about a narrowing conversion.
In contrast, this could well be (usually is) an ill-formed construct, which must be diagnosed:
std::srand( { std::time(nullptr) } ) ; // *** error: narrowing conversion
Even if std::time_t is not an integral type, at most, there would be a warning about a narrowing conversion.
In contrast, this could well be (usually is) an ill-formed construct, which must be diagnosed:
std::srand( { std::time(nullptr) } ) ; // *** error: narrowing conversion
Oct 28, 2015 at 7:33pmclosed account (48T7M4Gy)
That's strictly speaking correct, it is a warning rather than an error. However the distinction is more semantic/pedantic than really addressing the OP question especially when Microsoft make it clear - especially since it's their call.
Oct 28, 2015 at 7:53pm
> However the distinction is more semantic/pedantic
The distinction between an ill-formed programming construct and a well-formed one is semantic and/or syntactic; but it certainly is not pedantic.
> especially when Microsoft make it clear
To their credit, Microsoft has not even hinted that this is an erroneous construct. Their compiler merely warns about "possible loss of data"; MSDN adds that the conversion "may have" a problem due to implicit conversions.
> especially since it's their call.
It is not Microsoft's call. The International standard for C++ specifies that implicit conversions between arithmetic types is a feature of C++. Microsoft really has no choice in the matter.
The distinction between an ill-formed programming construct and a well-formed one is semantic and/or syntactic; but it certainly is not pedantic.
> especially when Microsoft make it clear
To their credit, Microsoft has not even hinted that this is an erroneous construct. Their compiler merely warns about "possible loss of data"; MSDN adds that the conversion "may have" a problem due to implicit conversions.
> especially since it's their call.
It is not Microsoft's call. The International standard for C++ specifies that implicit conversions between arithmetic types is a feature of C++. Microsoft really has no choice in the matter.
Oct 28, 2015 at 8:02pm
Well done! It is very good if one has the ability to laugh at one's own stupidity; it would be even better if one profits by learning something from it when it is pointed out.
Topic archived. No new replies allowed.