0

I want to switch from math.h to cmath for an embedded application. I am a bit skeptical about switching the from math.h to cmath lib, as this embedded system is quiet sensitive to change in precision from the computations. So I would like to know if cmath borrows it's implementations from and wraps around c++ compatible code? Or does c++ have it's own implementation that is different from ?

Deepak Kiran
  • 195
  • 3
  • 15
  • It's up to the implementation (compiler and library). I've yet to see any mention of any implementation that has `` and `` behave differently in a way that affects numerical precision (assuming compiling with same options, of course - some compilers do have options to change floating point representation). – Peter Feb 13 '20 at 10:11
  • 1
    Does this answer your question? [#include vs #include in a C++ program](https://stackoverflow.com/questions/15656434/include-cmath-vs-include-math-h-in-a-c-program) – anastaciu Feb 13 '20 at 10:19
  • Looks like an X-Y question you are asking about whether cmath uses math.h, but are actually concerned about the consequences of using cmath in an embedded system. – Clifford Feb 13 '20 at 12:47
  • cmath is just the C++ alternative syntax to math.h. In the parallel universe where ISO standards are made, some prophet in the early 90s predicted that futuristic operative systems wouldn't have file extensions. Therefore, the standard committee in this parallel universe attempted to remove `#include ` from C++. So C standard libs have to be included with `#include ` instead. If this seems like a royally stupid thing to you, that would be because it is a royally stupid thing. 30 years later, operative systems still have file extensions... – Lundin Feb 13 '20 at 13:09
  • @Lundin : The omission of .h from standard header files pre-dates ISO standardisation I think. It is explained in Stroustrup. A filename extension implies a file, whereas an implementation may have the library functions "built-in" and use the include directive as a "switch" to make the functions available without actually reading a file as such. I.e. it is not that an operating system might not have filename extensions, rather that the "header" need not be a file. I am not saying the rationale is compelling, merely that it is not as ill-considered as you have stated. – Clifford Feb 13 '20 at 16:20
  • @Lundin : One helpful (probably accidental) outcome of the decision is that `std::string` is declared in ``. Having `` referring to a different file in C++ code than it does in C code would be painful - so it overcomes that possible name-space issue. – Clifford Feb 13 '20 at 16:23
  • @Clifford Early 90s = before standardization in 98. Old Turbo C++ didn't support omitting the .h for example. One of countless misguided features of that language... – Lundin Feb 13 '20 at 17:46
  • @Lundin : I was reading from Stroustrup 3rd ed 1997. To be fair the ISO C++98 was no doubt more-or-less complete by them - they either decided it or adopted it from common use I guess. Not one of the things about C++ I'd get exercised about though. Almost everything added since C++98 however... – Clifford Feb 13 '20 at 18:19
  • @Clifford Stroustrup invented the language in the 1980s and it was pretty consistent until standardization work started. I learnt C++ around this time in the late 90s and the prevailing PC compiler was still Borland Turbo C++ 3 for DOS, which didn't support any of the new features. STL was an extension. And Borland was forced to rapidly release new compilers all the time back then, none of them compatible with the previous one, as soon as some "brilliant" mind in the standard committee came up with a new idea. It was a complete mess until C++98 settled, which didn't happen until early 2000s. – Lundin Feb 14 '20 at 08:41
  • @Lundin I am not arguing any different. Your views on C++ at as ever, strident. I was merely providing context and rationale for the lack of .h. This is not really the place for a history lesson. – Clifford Feb 14 '20 at 09:19

1 Answers1

1

Whether or not including cmath causes math.h to be included is strictly implementation specific. However both are merely declarative, and whether inclusion of either causes the same object library code to be linked is also implementation specific. That said it is very likely that an implementation will use the same code and often math.h will be a nested include in .

cmath adds overloads for float, long double and integer types whereas in math.h uses double almost exclusively. This can lead to more optimal implementations, or it may simply be a type cast to the C library function - again it is implementation specific.

as this embedded system is quiet sensitive to change in precision from the computations.

The behaviour might change if you do not have precise type agreement with the math.h declared functions. If for example you have float arguments with implicit casts to double math.h arguments, using cmath may cause a better matching overload to be used.

So I would like to know if cmath borrows it's implementations from and wraps around c++ compatible code? Or does c++ have it's own implementation that is different from?

Check your implementation, test it, and verify your code has correct type agreement to avoid the use of overloads. That said, if you do that there is no compelling advantage in using cmath - the primary benefit of which is overloads for types other than double leading to potentially more efficient code. It potentially has significant performance advantages for example if your processor has a single precision FPU or no FPU and you use float for efficiency.

Your best solution is to build it and test it - thoroughly. As it is implementation specific, you will have to test it for your specific tool-chain and target, as it is not defined by the language or library specification how it should be done.

Clifford
  • 88,407
  • 13
  • 85
  • 165