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

lokki

Well-known member
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 :)
 
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.
 
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
 
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.
 
This all sounds more like a buffer overflow (or array index out of bounds) in your code. Or something similar.
 
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.
 
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 :)
 
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.
 
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?
 
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?
 
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)
 
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...
 
Back
Top