I'm writing a method that creates a copy of an array of arrays of floats. I was getting some extremely weird values after debugging this, so I thought I'd ask about this since I wasn't able to figure this out by reading about C++ array FAQs.
Here's the relevant parts of the code (it's part of an enormous program, with most of the stuff irrelevant for this post):
// height and width are integer global variables
void method () {
float testArray[height][width];
for(int j = 0; j < height; ++j) {
for(int i = 0; i < width; ++i) {
testArray[j][i] -= 0.0;
std::cout << testArray[j][i] << std::endl;
}
}
}
(In my tests, height = 32 and width = 256, but that shouldn't be relevant.) When I initialize testArray, it's values should all be 0.0, correct? Then, in the loop, I subtract 0.0 from a certain element in testArray, which should logically not change the value at all. But printing the values of testArray as a debugging step result in some weird values, such as the following snippet:
[...]
0
[...]
-3.23805e-24
[...]
8.40779e-45
[...]
1.79513e+37
[...]
0
[...]
3.19586e+36
[...]
The most worrisome values are the infinite ones, such as the fourth number listed above. I honestly don't know why this is occurring. Shouldn't all these values still be approximately 0.0? I thought it had to do with imprecision of floating point arithmetic, but that shouldn't result in an infinite value ....
No, when you declare your array like that it will be uninitialized since it's a builtin type. You'll need to initialize it to zero yourself before doing the subtraction.
But note that declaring an array as you have (with presumably non-const dimensions) is a compiler extension and not part of the language.
I would just use vector which solves both problems at once.
std::vector<std::vector<float> > testArray(height, std::vector<float>(width));
Try initializing the values in the array:
float testArray[height][width] = {};
This line creates an uninitialized array, element values can be any garbage:
float testArray[height][width];
To initialize it with float default values (zero) use following syntax:
float testArray[height][width] = {};
THIS ANSWER IS WRONG, BUT I AM LEAVING IT SO NOONE TRIES IT!
Use this very explicit definition:
float testArray[height][width] = {{0.0f}};
to ensure that every value in your array is initialized to zero. Otherwise, the values in the array will be undefined. I feel that this is the most "readable" solution.
WHY IS IT WRONG?
As #Dave mentions below, although this solution works for this case, it is misleading. It explicitly assignes only the first element of testArray to 0.0, while it value-initializes all the other elements in the array.
The correct solution is indeed:
float testArray[height][width] = {};
which value-initializes all the elements in the array (to the default value 0.0f for type float.
Related
I want to set all the index value to -1 in a double array.
Here is my code :
double dp[505];
memset(dp,-1,sizeof(dp));
cout<<dp[0]<<"\n";
But it is showing nan when i try to print its value.
What does nan mean?
Is it possible to use memset() in double array?
In C++, you can write:
double initValue = -1;
std::fill_n(dp, 505, initValue);
memsetting a double array with a non-double value won't work.
memset operates on bytes, not floats, and a double with all bytes set to -1 does not equal -1. I think you're looking for std::fill:
#include <algorithm>
std::fill(dp, dp + 505, -1.0);
Or, in C++11:
#include <algorithm>
#include <iterator>
std::fill(std::begin(dp), std::end(dp), -1.0);
You have set each element of the array to be filled with the byte 0xFF (i.e. the char representation of -1).
No floating point number is represented by a series of 0xFF bytes, so on printing the double, you see NaN (i.e. 'not a number'). This is in apparent contrast to memset'ting the bytes to zero, which is legal as a string of 0 bytes is a double with value zero. See Is it legal to use memset(,0,) on array of doubles?.
If you meant to set every entry to -1.0 (i.e. a double), then use std::fill or std::fill_n in C++ or a loop in C, e.g.
int n;
for (n = 0 ; n < 505 ; n++)
dp[n] = -1.0;
From the man page of memset:
The memset() function fills the first n bytes of the memory area pointed to by s with the constant byte c.
The problem is that you want to fill an array of doubles with the constant -1.0 but sizeof(double) > 1 so memset actually fills in garbage which happens to end up as a NaN.
If you are using C++, the std::fill function is your friend. Actually, since you are writing to your array for the first time, std::uninitialized_fill would be correct. Although for the builtin double type there should be no difference but it is always good to be precise.
constexpr std::size_t length = 505;
double values[length];
std::uninitialized_fill(values, values + length, -1.0);
memset sets bytes, so you get double-values where each byte is -1.
Instead in C++ use std::vector, then write
vector<double> dp( 505, -1.0 );
It's that simple.
If dp is a global vector and you need to set it to -1 a number of times, then you can simply do this:
dp = vector<double>( dp.size(), -1.0 );
However, it's generally not a good idea to use non-const global variables.
Alternatively one can use std::fill, or just a loop, or just about any technique that still treat the double values as double values. But std::vector is preferable also for many other reasons than greatly simplifying the fill-it task. In particular a std::vector can be resized, it takes care of copying, and it automates the memory management, doing that part correctly and transparent to you.
nan means not a number.
cant see why its not working.
maybe because precision is not set : (cout.precision(15);)
check this:
How do I print a double value with full precision using cout?
But im not sure at all it will works :o
i checked memset source code and there's no problem with negative :D
But it can be a problem with doubles :
memset(dst0, c0, length) void *dst0;
register int c0;
register size_t length;
Have you tried to compile with Werror flag ?
Although answers for you question have been given, I just wanted you to note that
sizeof(dp)
outputs the number of bytes used to code the variable in memory.
In your case, dp is a pointer to a double. It will then be equal to the size of a pointer (4), no matter wether or not memery has been allocated.
sizeof(*dp) will output the size of a double (8).
In order to use the length of a
The following code crashes C++ with a runtime error:
#include <string>
using namespace std;
int main() {
string s = "aa";
for (int i = 0; i < s.length() - 3; i++) {
}
}
While this code does not crash:
#include <string>
using namespace std;
int main() {
string s = "aa";
int len = s.length() - 3;
for (int i = 0; i < len; i++) {
}
}
I just don't have any idea how to explain it. What could be the reason for this behavior?
s.length() is unsigned integer type. When you subtract 3, you make it negative. For an unsigned, it means very big.
A workaround (valid as long the string is long up to INT_MAX) would be to do like this:
#include <string>
using namespace std;
int main() {
string s = "aa";
for (int i = 0; i < static_cast<int> (s.length() ) - 3; i++) {
}
}
Which would never enter the loop.
A very important detail is that you have probably received a warning "comparing signed and unsigned value". The problem is that if you ignore those warnings, you enter the very dangerous field of implicit "integer conversion"(*), which has a defined behaviour, but it is difficult to follow: the best is to never ignore those compiler warnings.
(*) You might also be interested to know about "integer promotion".
First of all: why does it crash? Let's step through your program like a debugger would.
Note: I'll assume that your loop body isn't empty, but accesses the string. If this isn't the case, the cause of the crash is undefined behaviour through integer overflow. See Richard Hansens answer for that.
std::string s = "aa";//assign the two-character string "aa" to variable s of type std::string
for ( int i = 0; // create a variable i of type int with initial value 0
i < s.length() - 3 // call s.length(), subtract 3, compare the result with i. OK!
{...} // execute loop body
i++ // do the incrementing part of the loop, i now holds value 1!
i < s.length() - 3 // call s.length(), subtract 3, compare the result with i. OK!
{...} // execute loop body
i++ // do the incrementing part of the loop, i now holds value 2!
i < s.length() - 3 // call s.length(), subtract 3, compare the result with i. OK!
{...} // execute loop body
i++ // do the incrementing part of the loop, i now holds value 3!
.
.
We would expect the check i < s.length() - 3 to fail right away, since the length of s is two (we only every given it a length at the beginning and never changed it) and 2 - 3 is -1, 0 < -1 is false. However we do get an "OK" here.
This is because s.length() isn't 2. It's 2u. std::string::length() has return type size_t which is an unsigned integer. So going back to the loop condition, we first get the value of s.length(), so 2u, now subtract 3. 3 is an integer literal and interpreted by the compiler as type int. So the compiler has to calculate 2u - 3, two values of different types. Operations on primitive types only work for same types, so one has to be converted into the other. There are some strict rules, in this case, unsigned "wins", so 3 get's converted to 3u. In unsigned integers, 2u - 3u can't be -1u as such a number does not exists (well, because it has a sign of course!). Instead it calculates every operation modulo 2^(n_bits), where n_bits is the number of bits in this type (usually 8, 16, 32 or 64). So instead of -1 we get 4294967295u (assuming 32bit).
So now the compiler is done with s.length() - 3 (of course it's much much faster than me ;-) ), now let's go for the comparison: i < s.length() - 3. Putting in the values: 0 < 4294967295u. Again, different types, 0 becomes 0u, the comparison 0u < 4294967295u is obviously true, the loop condition is positively checked, we can now execute the loop body.
After incrementing, the only thing that changes in the above is the value of i. The value of i will again be converted into an unsigned int, as the comparison needs it.
So we have
(0u < 4294967295u) == true, let's do the loop body!
(1u < 4294967295u) == true, let's do the loop body!
(2u < 4294967295u) == true, let's do the loop body!
Here's the problem: What do you do in the loop body? Presumably you access the i^th character of your string, don't you? Even though it wasn't your intention, you didn't only accessed the zeroth and first, but also the second! The second doesn't exists (as your string only has two characters, the zeroth and first), you access memory you shouldn't, the program does whatever it wants (undefined behaviour). Note that the program isn't required to crash immediately. It can seem to work fine for another half an hour, so these mistakes are hard to catch. But it's always dangerous to access memory beyond the bounds, this is where most crashes come from.
So in summary, you get a different value from s.length() - 3 from that what you'd expect, this results in a positive loop condition check, that leads to repetitive execution of the loop body, which in itself accesses memory it shouldn't.
Now let's see how to avoid that, i.e. how to tell the compiler what you actually meant in your loop condition.
Lengths of strings and sizes of containers are inherently unsigned so you should use an unsigned integer in for loops.
Since unsigned int is fairly long and therefore undesirable to write over and over again in loops, just use size_t. This is the type every container in the STL uses for storing length or size. You may need to include cstddef to assert platform independence.
#include <cstddef>
#include <string>
using namespace std;
int main() {
string s = "aa";
for ( size_t i = 0; i + 3 < s.length(); i++) {
// ^^^^^^ ^^^^
}
}
Since a < b - 3 is mathematically equivalent to a + 3 < b, we can interchange them. However, a + 3 < b prevents b - 3 to be a huge value. Recall that s.length() returns an unsigned integer and unsigned integers perform operations module 2^(bits) where bits is the number of bits in the type (usually 8, 16, 32 or 64). Therefore with s.length() == 2, s.length() - 3 == -1 == 2^(bits) - 1.
Alternatively, if you want to use i < s.length() - 3 for personal preference, you have to add a condition:
for ( size_t i = 0; (s.length() > 3) && (i < s.length() - 3); ++i )
// ^ ^ ^- your actual condition
// ^ ^- check if the string is long enough
// ^- still prefer unsigned types!
Actually, in the first version you loop for a very long time, as you compare i to an unsigned integer containing a very large number. The size of a string is (in effect) the same as size_t which is an unsigned integer. When you subtract the 3 from that value it underflows and goes on to be a big value.
In the second version of the code, you assign this unsigned value to a signed variable, and so you get the correct value.
And it's not actually the condition or the value that causes the crash, it's most likely that you index the string out of bounds, a case of undefined behavior.
Assuming you left out important code in the for loop
Most people here seem unable to reproduce the crash—myself included—and it looks like the other answers here are based on the assumption that you left out some important code in the body of the for loop, and that the missing code is what is causing your crash.
If you are using i to access memory (presumably characters in the string) in the body of the for loop, and you left that code out of your question in an attempt to provide a minimal example, then the crash is easily explained by the fact that s.length() - 3 has the value SIZE_MAX due to modular arithmetic on unsigned integer types. SIZE_MAX is a very big number, so i will keep getting bigger until it is used to access an address that triggers a segfault.
However, your code could theoretically crash as-is, even if the body of the for loop is empty. I am unaware of any implementations that would crash, but maybe your compiler and CPU are exotic.
The following explanation does not assume that you left out code in your question. It takes on faith that the code you posted in your question crashes as-is; that it isn't an abbreviated stand-in for some other code that crashes.
Why your first program crashes
Your first program crashes because that is its reaction to undefined behavior in your code. (When I try running your code, it terminates without crashing because that is my implementation's reaction to the undefined behavior.)
The undefined behavior comes from overflowing an int. The C++11 standard says (in [expr] clause 5 paragraph 4):
If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined.
In your example program, s.length() returns a size_t with value 2. Subtracting 3 from that would yield negative 1, except size_t is an unsigned integer type. The C++11 standard says (in [basic.fundamental] clause 3.9.1 paragraph 4):
Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2n where n is the number of bits in the value representation of that particular size of integer.46
46) This implies that unsigned arithmetic does not overflow because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting unsigned integer type.
This means that the result of s.length() - 3 is a size_t with value SIZE_MAX. This is a very big number, bigger than INT_MAX (the largest value representable by int).
Because s.length() - 3 is so big, execution spins in the loop until i gets to INT_MAX. On the very next iteration, when it tries to increment i, the result would be INT_MAX + 1 but that is not in the range of representable values for int. Thus, the behavior is undefined. In your case, the behavior is to crash.
On my system, my implementation's behavior when i is incremented past INT_MAX is to wrap (set i to INT_MIN) and keep going. Once i reaches -1, the usual arithmetic conversions (C++ [expr] clause 5 paragraph 9) cause i to equal SIZE_MAX so the loop terminates.
Either reaction is appropriate. That is the problem with undefined behavior—it might work as you intend, it might crash, it might format your hard drive, or it might cancel Firefly. You never know.
How your second program avoids the crash
As with the first program, s.length() - 3 is a size_t type with value SIZE_MAX. However, this time the value is being assigned to an int. The C++11 standard says (in [conv.integral] clause 4.7 paragraph 3):
If the destination type is signed, the value is unchanged if it can be represented in the destination type (and bit-field width); otherwise, the value is implementation-defined.
The value SIZE_MAX is too big to be representable by an int, so len gets an implementation-defined value (probably -1, but maybe not). The condition i < len will eventually be true regardless of the value assigned to len, so your program will terminate without encountering any undefined behavior.
The type of s.length() is size_t with a value of 2, therefore s.length() - 3 is also an unsigned type size_t and it has a value of SIZE_MAX which is implementation defined (which is 18446744073709551615 if its size is 64 bit). It is at least 32 bit type (can be 64 bit in 64 bit platforms) and this high number means an indefinite loop. In order to prevent this problem you can simply cast s.length() to int:
for (int i = 0; i < (int)s.length() - 3; i++)
{
//..some code causing crash
}
In the second case len is -1 because it is a signed integer and it does not enter the loop.
When it comes to crashing, this "infinite" loop is not the direct cause of the crash. If you share the code within the loop you can get further explanation.
Since s.length() is unsigned type quantity, when you do s.length()-3, it becomes negative and negative values are stored as large positive values (due to unsigned conversion specifications) and the loop goes infinite and hence it crashes.
To make it work, you must typecast the s.length() as :
static_cast < int > (s.length())
The problem you are having arises from the following statement:
i < s.length() - 3
The result of s.length() is of the unsigned size_t type.
If you imagine the binary representation of two:
0...010
And you then substitute three from this, you are effectively taking off 1 three times, that is:
0...001
0...000
But then you have a problem, removing the third digit it underflows, as it attempts to get another digit from the left:
1...111
This is what happens no matter if you have an unsigned or signed type, however the difference is the signed type uses the Most Significant Bit (or MSB) to represent if the number is negative or not. When the undeflow occurs it simply represents a negative for the signed type.
On the other hand, size_t is unsigned. When it underflows it will now represent the highest number size_t can possibly represent. Thus the loop is practically infinite (Depending on your computer, as this effects the maximum of size_t).
In order to fix this problem, you can manipulate the code you have in a few different ways:
int main() {
string s = "aa";
for (size_t i = 3; i < s.length(); i++) {
}
}
or
int main() {
string s = "aa";
for (size_t i = 0; i + 3 < s.length(); i++) {
}
}
or even:
int main() {
string s = "aa";
for(size_t i = s.length(); i > 3; --i) {
}
}
The important things to note is that the substitution has been omitted and instead addition has been used elsewhere with the same logical evaluations.
Both the first and last ones change the value of i that is available inside the for loop whereas the second will keep it the same.
I was tempted to provide this as an example of code:
int main() {
string s = "aa";
for(size_t i = s.length(); --i > 2;) {
}
}
After some thought I realised this was a bad idea. Readers' exercise is to work out why!
The reason is the same as
int a = 1000000000;
long long b = a * 100000000; would give error. When compilers multiplies these numbers it evaluates it as ints, since a and literal 1000000000 are ints, and since 10^18 is much more large than the upper bound of int, it will give error.
In your case we have s.length() - 3, as s.length() is unsigned int, it cant be negative, and since s.length() - 3 is evaluated as unsigned int, and its value is -1, it gives error here too.
I want to know why this loops runs even when result.bad_matches.size()=0
for (int i = 1; i <= result.badmatches.size() - 1; i++)
{
...
}
Also, is there any other way I could stop it from running when badmatches size is 0 without using an if condition?
This depends on the type size() returns. It is probably a standard container and thus will be an unsigned type and those types wrap around on overflow. That means it the result of subtracting one will be the maximum value of that type.
Either use a comparison that doesn't require you to subtract from the size (<, !=) or just use iterators or a for-auto loop. Under any circumstance you should at least use the same type for iterating as the nested size_type of the container and not int.
for(auto& x : result.badmatches) {
// ...
}
use while(result.badmatches.size()) to NOT execute it.
result.badmatches.size()-1 this will be converted to -1. If its an unsigned integer, then -1 is interpreted as 0xFFFFFFFF(on a 32 bit machine). This will make the loop run for 2^32 or 2^64 times. To avoid this, use while() as before IF you're certain that result.badmatches.size() will return 0.
size must be returning an unsigned so 0-1 is getting upgraded to unsigned and so is the left value.
So for int size of 4 bytes, -1 will be represented as 2^32 -1 in unsigned int.
If you don't want this behavior then just cast it like this : static_cast <signed int > (result.badmatches.size());
PS: I've not touched C++ for past 4 years pl. excuse little mistakes.
The right way is:
for (int i=0;i< result.badmatches.size() ;++i)
{
}
If you specifically don't want this loop to enter when the sise of the collection is zero then you could check for ! badmatches.empty() assuming that badmatches is an STL container. However, if you structure your code slightly differently, you'll probably overcome this issue without having to do that:
for (size_t i=0; i < result.badmatches.size(); i++)
{
}
I've changed the int to size_t which is the same type that size() returns (an unsigned integer), changed the initial value to 0 and the comparison so that it will exit if i >= result.badmatches.size() Generally, I'd say that this is the clearest way of presenting an indexed approach as it matches the natural indexing of collections and if you need 1, 2, 3 ... rather than 0, 1, 2 in your loop, then you can address that within it.
If you're still having problems, two questions:
Is there anything in your loop that might alter the value of result.badmatches.size()?
Is your code multithreaded with a possibility that result.badmatches.size() could change by actions on another thread?
After understanding the problem explained by #Prototype Stark #Aga , i came to a more simpler solution , using which i can keep my initial index to 1 .
for(int i=1;i+1<=result.badmatches.size();i++)
Thanks for all the help , it's much clearer now .
I have doubt regarding sizeof(). I know it gives the number of bytes used in an array. My question is what if the array is not defined, but it declared.
example:
float array[3];
int p = sizeof(array);
The value yielded by sizeof depends solely on the type, not anything that happens at run time1.
That said, despite the name, float array(3); simply defines a single float, with an initial value of 3, so int p=sizeof(array); is equivalent to int p = sizeof(float);.
Edit: (to correspond to edited question): yes, float array[3]; defines an array of 3 floats, so int p = sizeof(array); is equivalent to int p = 3 * sizeof(float);
1 In C++. As of C99, the situation in C is somewhat different (but irrelevant to the question at hand).
You are not declaring an array of floats when you use this code
float array(3);
you have simple created a float variable called array with value 3. Your call of sizeof on this variable just returns the size of float. Had you declared it properly
float float_array[3];
and called sizeof(float_array) you would get the value you expect - 3*sizeof(float)
sizeof() does not give the number of bytes used in an array, your definition is incomplete and partially incorrect.
http://en.cppreference.com/w/cpp/language/sizeof says:
"sizeof( type) --returns size in bytes of the object representation of type"
Also float array[3] is the correct way to declare an array of floats with 3 elements as other people have noted.
Finally, sizeof( array) would return 12, whereas sizeof( array) would return 16 if you declared it with 4 elements, and sizeof( array) would return 40 if you declared an array of 5 doubles instead of floats, at least on my system. Of course, number of bytes used for data types may change from system to system.
Having some trouble finding the sum of a 2D vector. Does this look ok?
int sumOfElements(vector<iniMatrix> &theBlocks)
{
int theSum = 0;
for(unsigned i=0; (i < theBlocks.size()); i++)
{
for(unsigned j=0; (j < theBlocks[i].size()); j++)
{
theSum +=theBlocks[i][j];
}
}
return theSum;
}
It returns a negative number, however, it should return a positive number..
Hope someone can help :)
The code looks proper in an abstract sense, but you may be overflowing theSum. You can try making theSum type double to see what value you get to help sort out the proper integral type to use for it.
double sumOfElements(vector<iniMatrix> &theBlocks)
{
double theSum = 0;
/* ... */
return theSum;
}
When you observe the returned value, you can see if it would fit in an int or if you need to use a wider long or long long type.
If all the values in the matrix are positive, you should consider using one of the unsigned integral types. which would double your range of allowed values.
The problem is obviously the int exceeds its boundary (like others said)
For signed data types it becomes negative when overflow, and for unsigned datatypes it starts from zero again after overflow.
If you want to detect overflow pragmatically, you can paste these lines instead of the additional line.
if( theSum > int(theSum + theBlocks[i][j]) )
//print error message, throw exception, break, ...
break;
else
theSum += theBlocks[i][j];
For more generic solution to work with more data types and more operations than addition, check this: How to detect integer overflow?
A solution would be using unsigned long long and if it exceeds its boundary too, you need to use third party libraries for big integers.
Like Mokhtar Ashour says, it's may be that the variable theSum overflows. Try making it either unsigned if no numbers are negative, or change the type from int (which is 32 bits) to long long (which is 64 bits).
I think it may be int overflow problem. to make sure, you may insert a condition after the inner loop finishes to see if your result exceeds the int range.
if(result>sizeof(int))
cout<<"hitting boundaries";
a better way to test if you exceed the int boundaries is to print the result after the inner loop ends and notice the result.
.if so, just use a bigger data type.