wrong order of elements in QList

[qtbeginner0]

Thanks for the replys guys. As I would like to understand the bug first I will try the workarounds after that.
After you pointed me to the sorting, I did some more research.
Can someone explain the strange stepping through the code in QtCreator?
(the order of the steps when I use "Step Over" are placed at the end of the code lines)

case RS2::EntityCircle:  
  a = center.angleTo(*v);                                                  1.
  dist = reversed?
              fmod(sa - a + 2.*M_PI,2.*M_PI):                              3.
              fmod(a - sa + 2.*M_PI,2.*M_PI);                              2. 4. 6.
//            qDebug("angle centerTostartPoint: %f",sa);
//            qDebug("angle centerToNextIntersection: %f",a);
//            qDebug("distance: %f",dist);
  qDebug("counted the useres: %d",v.use_count());                          5. 7.
  break;

case RS2::EntityCircle:  
  a = center.angleTo(*v);                                                  1.
  dist = reversed?
              fmod(sa - a + 2.*M_PI,2.*M_PI):                              3.
              fmod(a - sa + 2.*M_PI,2.*M_PI);                              2. 4. 6.
//            qDebug("angle centerTostartPoint: %f",sa);
//            qDebug("angle centerToNextIntersection: %f",a);
//            qDebug("distance: %f",dist);
  qDebug("counted the useres: %d",v.use_count());                          5. 7.
  break;

To copy to clipboard, switch view to plain text mode 

I would have expected the following order of the stepping:
line2
line5 (until now that's the same what QtCreator does; reversed is false)
line9

[wysota]

What is so strange in the order the debugger steps through the code? That's the order the code executes.

[qtbeginner0]

What I don't understand is, why QtCreator steps to line 4 in the 3. step. Cause reversed is false, shouldn't it just leave out line 4?
Why does QtCreator execute line 5 again in step 4? Wasn't that already done in step 2. ?
Why does QtCreator jump back to line 5 in step 6. for the third time?

What I was thinking it would do:
1. assign a ->line 2
2. check reversed -> line 3
3. reversed is false -> line 5
4. assign dist -> line 3
5. qDebug

[wysota]

Creator does not step into anything. The debugger does based on the order of which instructions are executed. Apparently the compiler builds the code in such a way, that the execution takes place in such particular order. As for "line 4" in my opinion this is a mark that the "?" instruction is executed and as it is the last symbol in line 3, the compiler (becasue of whatever reason) marks it as the next line. I really wouldn't worry about this, if you have doubts take a look at the instructions on assembly level or disable optimizations and then run the code through the debugger again. All this however does not bring you any closer to solving your original problem.

What I was thinking it would do:
1. assign a ->line 2
2. check reversed -> line 3
3. reversed is false -> line 5
4. assign dist -> line 3
5. qDebug

I would think it first calculates 2.*M_PI as this is used in both cases so it can be precalculated, then it'd check the condition, calculate sa-a or a-sa based on the condition, then add the result to 2*M_PI, then execute fmod on the result, then assign it to the dist variable and finally print out the debug statement. Of course, if v.use_count() is independent of the result of "dist", the compiler might put the debug statement between any two instructions in the whole section.

[qtbeginner0]

All this however does not bring you any closer to solving your original problem.

Ok.

...the compiler might put the debug statement between any two instructions in the whole section

Didn't know that.

So I had some more debugging fun.
The problem is, that calculation of "a" is a little off compared to sa.
I don't know why this happens cause both angles are calculated using the SAME function and the SAME
point.

double sa = center.angleTo(sp);
...
double a;
...
a = center.angleTo(*v);

double sa = center.angleTo(sp);
...
double a;
...
a = center.angleTo(*v);

To copy to clipboard, switch view to plain text mode 

double angleTo(const RS_Vector& v) const;

double angleTo(const RS_Vector& v) const;

To copy to clipboard, switch view to plain text mode 

here is sp and v from the watch list (they are the same point/coordinates)

sp RS_Vector
valid true bool
x 170.15564366033121 double
y 20.000000048775643 double
z 0 double


v std::shared_ptr<RS_Vector>
__shared_ptr<RS_Vector, (__gnu_cxx::_Lock_policy)2> std::__shared_ptr<RS_Vector, (__gnu_cxx::_Lock_policy)2>
_M_ptr @0x8ac7ff0 RS_Vector
valid true bool
x 170.15564366033121 double
y 20.000000048775643 double
z 0 double
_M_refcount std::__shared_count<(__gnu_cxx::_Lock_policy)2>



here is the result of a - sa (as you can see it's e-16) (should be 0 as it is the same point in this case)

result of a - sa: -4.4408920985006261617e-16

As I already told, adding qDebug("angle centerToNextIntersection: %f",a) will somehow lead to
the result 0 of a - sa. Does anybody have an idea what qDebug does to "a"?
I don't get how qDebug does influence the calculation of "a" and why the reseults of calculating
the same angle of the same point using the same function, differ from each other (without qDebug())?