I have used VS Community 2015 for a few months but my project needs the "long double" to work. VS treats "long double" exactly like "double". I read that the Intel C++ Compiler would recognise and correctly compile the "long double".
So I downloaded and installed Intel C++ Compiler. Integrated it into VS and activated the Intel C++ Compiler in VS.
Fired off a compile and test and, imagine my disappointment when the "long double" still acted like a "double" as before (with VS C++ compiler). :(
Is there something else I must do to get a "long double" to work in 80bit as it should? As opposed to a 64bit "double"?
Thanks in anticipation :)
After MUCH more research I've found out it has something to do with option /Qlong-double but I have no idea how to add this option to the Intel C++ Compiler for my project?
Any ideas anybody?
Edit: Sorry for wasting your time but after further investigation (and it was well hidden) ;) I found the solution. I put the option in the "icl.cfg" file and it now compiles with 80bit variables. My project STILL doesn't work but that's another problem. I must have some intermediate computation(s?) somewhere that are overflowing????
I hope you are aware that Intel does not provide its own set of system libraries so any calls to the C or C++ runtime libraries will not work correctly if you use this switch. This includes printf(), etc.
There are claims everywhere that printf does work?
I haven't managed to get fprintf_s to work?
Dissapointingly /Qlong and /Qpc80 don't work as expected. It seems strange that you say run time routines can't be expected to work! Why is the job half done!? With double things work to E13, with long double it seems to work till about E17 far short of the E54 I expected! I'm glad I haven't paid for the compiler. After my trial I shall look for a different solution as Intel C++ isn't worth paying for, I'm sorry to say :(
Surely, you must recognize that ICL is marketed as a Visual Studio compatible compiler. In particular, the printf functions are taken unmodified from the Microsoft libraries and (with correct use of headers) involve casting long double to double. /Qpc80 (for compilation of main()) over-rides the x87 precision setting for which the Microsoft math libraries were designed, so discrepancies are possible there.
/fp:extended might have some implications for your usage. It's not clear from the documentation whether this sets /Qpc80, nor whether it is intended to make Windows behavior more like linux or like Microsoft.
/Qlong-double has issues of efficiency when used other than with /arch:IA32 /fp: (32-bit mode only). ICL abandoned support for Pentium-III where libraries mixing SSE float and X87 double were needed, as the market for software supporting that had disappeared, and the ICL features for that purpose didn't penetrate into the Microsoft side.
Intel support for long double was relatively weak in Pentium 4, foreshadowing continued efforts (not least, from Microsoft) to make the mode obsolete.
Having our own set of C/C++ runtime libraries on each platform we support would be a huge task. And keeping them compatible with Microsoft's library (including all of our classes having the same size and layout so that we would be link compatible with object files compiled with the Microsoft compiler) would be impossible.
Thanks for your reply Tim and Judith :)
I get that ICL is marketed as a Visual Studio compatible compiler but ICL also decided to offer /Qlong-double and /Qpc80 above VS. Shouldn't ICL then follow through with full 80bit functionality?
There appear to be Math libraries that claim to handle long doubles but I only want the basic computation with 80bit - multiply, divide, add and subtract is all I want to do. I can live with no "printing" but the basic math doesn't appear to work beyond 20 quadrillion.
I am an absolute newbie so I hope the fault is my coding. I have only been playing with C++ for a few months. I learned C++ playing with Arduinos. My background is a few assemblers, COBOL and BASIC :(
I'm playing with Mandelbrots. I got as far as I could with double so moved on to long double with expectation of E54 precision. E54 would be a lot less than others going to (effectively) E10000. Yes, I know that isn't long double but I am taking small steps in my journey.
I'm a retired programmer so the actual programming (of Mandelbrots) attracts me more than just using someone else's excellent solution. Eventually I will try perturbation and arbitrary precision etc but small steps, double to long double first.
With all due respect :D
If performance is not a big issue, Google
c++ extended precision
you will locate links to extended and arbitrary precision floating point libraries/classes
pick one that does not use the older ten bit (formerly long double).