-4

Ok, so I am working on an interface on qt, and I am using qtcreator as an IDE. The thing is that the algorithm works normally on mac, but on windows the same program gets an error. error that I get

the only difference is the compiler. The compiler I am using on windows is the visual c++, and on mac is clang (I think). Is it possible that the same algorithm works on mac but doesn't on windows? If so, what problem could it be?

EDIT: I see that I got downvoted. I don't know exactly why. I know already what the error means, vector subscription out of range. The thing is that I don't want to waste time trying to find where the error is because it actually works fine on mac. Also the pc is better than the mac one.

EDIT 2: Indeed it looks like the same code works differently on windows than on mac. Tomorrow I will test it on mac to try to understand this, but the code that changes is this one:

vector<double> create_timeVector(double simulationTime, double step) {
        vector<double> time;
        time.push_back(0);
        double i = 0;
        do {
            ++i;
            time.push_back(time[i-1] + step);
        } while (time[i] < simulationTime);
        return time;
    }

The size of the vector that is returned is one size bigger on windows than on the mac. The thing is that I didn't make any changes on the code.

lhahn
  • 1,241
  • 2
  • 14
  • 40
  • It probably means your code relies on some undefined behaviour and the actual behaviour on Windows is different from the behaviour on Mac. However, without the code, it is unlikely anyone can help, and it is also likely that the code is too big to make a good question on SO. – Jonathan Leffler Sep 03 '14 at 00:59
  • If you don't want to "waste time" finding the error, why did you post this question? – Blastfurnace Sep 03 '14 at 01:00
  • 2
    @Blastfurnace: he doesn't want to waste his own time on it; he wants us to waste our time answering the unanswerable. – Jonathan Leffler Sep 03 '14 at 01:01
  • I don't want to waste time trying to find the error on the wrong place. If it is possible that the same algorithm could cause different behaviors than I would post the code – lhahn Sep 03 '14 at 01:03
  • It was really a theoretical question, I don't know why you are offended. I don't want to waste your time posting something that may not be even wrong – lhahn Sep 03 '14 at 01:04
  • @lhahn: Consider it from our perspective, how can someone answer this with no code? A buggy program can definitely exhibit different behavior on another OS, compiler, compiler options, etc. You probably have a bug on the Mac as well but it doesn't manifest itself as obviously as on the PC build. – Blastfurnace Sep 03 '14 at 01:10
  • @Blastfurnace: that was the answer I was expecting. I don't want to post 200 hundred lines of code and say it doesn't work, instead I think it is more useful generalizing a bit more, since my original program (on mac) did not show any bugs. If someone said that a program exactly the same with the same entries should behave the same way I would not bother posting the code, and I would probably try to find the error somewhere else, thus not "wasting time". Of course it is my opinion, but it is nice if someone try to explain why they are so offended by it. – lhahn Sep 03 '14 at 01:16
  • @Blastfurnace: Yes, I think this question would probably be better suited for programmers (site), since it is a theoretical one. – lhahn Sep 03 '14 at 01:20

2 Answers2

1

The probable reason why it works differently is that you're using a floating point calculation to determine when the loop is to stop (or keep going, depending on how you look at it).

time.push_back(time[i-1] + step);
        } while (time[i] < simulationTime);

You have step as a double, simulationTime as a double, and a vector<double> called time being used. That is a recipe for loops running inconsistently across compilers, compiler optimizations, etc.

Floating point is not exact. The way to make the loops consistent is to not use any floating point calculations in the looping condition.

In other words, by hook or by crook, compute the number of calculations you need by using integer arithmetic. If you need to step 100 times, then it's 100, not a value computed from floating point arithmetic:

For example:

for (float i = 0.01F; i <= 1.0F; i+=0.01F) 
{ 
  // use i in some sort of calculation
}

The number of times that loop executes can be 99 times, or it can be 100 times. It depends on the compiler and any floating point optimizations that may apply. To fix this:

for (int i = 1; i <= 100; ++i ) 
{ 
  float dI = static_cast<float>(i) / 100.0F;
  // use dI instead of i some sort of calculation
}

As long as i isn't changed in the loop, the loop is guaranteed to always do 100 iterations, regardless of the hardware, compiler optimizations, etc.

See this: Any risk of using float variables as loop counters and their fractional increment/decrement for non "==" conditions?

Community
  • 1
  • 1
PaulMcKenzie
  • 34,698
  • 4
  • 24
  • 45
0

vector subscript out of range means that you used [n] on a vector, and n was less than 0 or greater than or equal to the number of elements in the vector.

This causes undefined behaviour, so different compilers may react in different ways.

To get reliable behaviour in this case, one way is to use .at(n) instead of [] and make sure you catch exceptions. Another way is to check your index values before applying them, so that you never access out of bounds in the first place.

M.M
  • 138,810
  • 21
  • 208
  • 365
  • Windows: for (int i = 0; i != time.size() - 1; ++i), MAC: for (int i = 0; i != time.size() - 1; ++i) (That is the change I made, now it works), the reason is that time.size() is one unit bigger on windows. The strange thing is that the algorithm is the same, I am still trying to figure it out. – lhahn Sep 03 '14 at 01:48
  • May be an issue with floating point (most real numbers cannot be represented exactly in floating point of course). It'd be better for your loop to use an integral type for the step count – M.M Sep 03 '14 at 02:00
  • I already changed in the code "double i;" to "int i" but the problem still persists – lhahn Sep 03 '14 at 02:02
  • 1
    @lhahn - More than likely, you're "off by one" due to using floating point calculation to determine when to stop looping. – PaulMcKenzie Sep 03 '14 at 02:50