Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 12 of 12

Thread: #include <algorithm> messes up float calculations (i guess)

  1. #1
    Senior Member
    Join Date
    Feb 2018
    Posts
    130

    #include <algorithm> messes up float calculations (i guess)

    hi there,

    because i was in need of a sort function and couldn't get qsort to work as i wanted in a teensy 3.6 project, i stumbled across std::sort.
    for that to work i had to include algorithm into my code. the sort works beautifully, however as soon as i include <algorithm> my float calculations in the sketch no longer work correctly, so it seems this include overrides the internal float definitions or what??

    is this a known issue? it took me a while to figure it out, because it seemed so far fetched, but as soon as i comment the include out all my float calculations are correct again.

    i am puzzled and would sure like some insight

  2. #2
    Senior Member
    Join Date
    Feb 2018
    Posts
    130
    ok replying to myself to clarify for others.

    moving the #include <alrogrithm> to the top of my includes, before <Arduino.h> fixes things. so it seems it is overriding some internal functions. i don't have the timeframe to look into this in more detail, just happy that it works now.

  3. #3
    Senior Member
    Join Date
    Jul 2014
    Posts
    3,440
    maybe avoiding
    Code:
    using namespace std;
    and use directly
    Code:
    std::sort
    could avoid side effects of <algorithm>
    but without source code difficult to say

    Edit: just say latest reply

  4. #4
    Senior Member
    Join Date
    Feb 2018
    Posts
    130
    well, even if i comment out my std::sort code (i was using it like this already) and only have the <algorithm> include in the wrong spot it messes up floats..

    i don't think posting my approx. 3000 lines of code is beneficial but i am happy to do so if it helps track this down.

  5. #5
    Senior Member
    Join Date
    Apr 2014
    Location
    -
    Posts
    9,756
    This all sounds more like a buffer overflow (or array index out of bounds) in your code. Or something similar.

  6. #6
    Senior Member
    Join Date
    Feb 2018
    Posts
    130
    ok, cool will look into this. so a simple move around of the #include <algorithm> can fix an out of bound array or buffer overflow? (or make the problem go away)? the code is exactly the same both times. i am honestly curious.
    my understanding of includes so far was, that they simply give access to other "functions" etc, and hence if you reorder them (which i did) and you got conflicting "declarations" you can sometimes fix them.

  7. #7
    Senior Member
    Join Date
    Apr 2014
    Location
    -
    Posts
    9,756
    Quote Originally Posted by lokki View Post
    so a simple move around of the #include <algorithm> can fix an out of bound array or buffer overflow? (or make the problem go away)?
    No, it now just overwrites other memory locations - where it is not that obvious or these locations are not used , at the moment.
    The problem is still there, I guess - but not visible

  8. #8
    Senior Member
    Join Date
    Feb 2018
    Posts
    130
    so even if i don't use the std::sort function (i commented it out for test purposes) and hence the include is not necessary for the compile to work it still affects the memory locations? shows me how little i know about all of that. from my limited observation i got from the teensy environment i thought includes were only "included" once you use a function from them. at least the console implies so (by showing same memory usage and program size, no matter what you include, as long as you don't use it).

    this led me to believe that the <algorithm> include actually overwrites arduino/teensy functions.

  9. #9
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,813
    I also experienced that kind of stuff but the other way round. The unfortunate habit of #defining things like abs, max etc in Arduino sometimes messes up standard c++ libraries/headers. Never saw anything like this with floats but I wouldn't be surprised. Can you post an example?

  10. #10
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,878
    Only way to be sure would be to create a small example to post that demonstrates the problem.

    qsort not working? Float math going odd using the #include <alrogrithm>, depending on placement?

  11. #11
    Senior Member
    Join Date
    Feb 2018
    Posts
    130
    well qsort not working was probably me being stupid. i will try to come up with an example as time permits. i will also look into my code for potential overflows. i agree that it sounds like a bug in my code, i was just baffled that a simple replacement of an include could make the bug appear and disappear (even if i don't use functions from that include)

  12. #12
    Senior Member
    Join Date
    Feb 2018
    Posts
    130
    Quote Originally Posted by luni View Post
    I also experienced that kind of stuff but the other way round. The unfortunate habit of #defining things like abs, max etc in Arduino sometimes messes up standard c++ libraries/headers. Never saw anything like this with floats but I wouldn't be surprised. Can you post an example?

    to be fair, the code is rather longish, and the problem manifested itself in a section with float calculations, but it could be something else preventing this calculations to work properly, i haven't looked into it that extensively. will try to make an example...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •