mrslezak
commented
3 years ago Okay I started the port of QuantExt and resolved the errors on VS2017 Windows 10 with Boost 1.77.0 and QuantLib 1.23, using the Windows 8.1SDK and haven't finished the testsuite. Once the testsuite is done, it should be about ready to merge into QuantLib. If anyone wants to help with this, my repo is here: https://github.com/mrslezak/Engine check the 1st commit there were various issues with the formatting using the code as is posted here on Windows 10, but now it compiles fine. The offline installer for VS2017 Community was failing for me on download so I ended up using this ISO and then adding the C++ needed features afterwards: https://drive.google.com/file/d/1b5lqWOE421vDw-wDPxBBxixEcienyhx2
Anyhow on the testsuite the issues seem to be mostly around missing semicolons and then dategeneration.cpp has quite a few calendars that are not members of QuantLib::DateGeneration such as:
Error C2039 'ThirdThursday': is not a member of 'QuantLib::DateGeneration' QuantExtTestSuite c:\engine\quantext\test\dategeneration.cpp 83 Same thing for ThirdFriday, MondayAfterThirdFriday and TuesdayAfterThirdFriday, basically everything in that dategeneration.cpp
This leads me to believe the QuantLib dategenerationrule.hpp file (they did not include) that ORE is using is a modified version, as the mentioned rules are not inside the latest file. Does anyone have the file with these undeclared calendar rules??? You can see the latest file is missing all of these rules: https://github.com/lballabio/QuantLib/blob/master/ql/time/dategenerationrule.hpp
pcaspers
I'm just wondering why, I know it's not required by the BSD license, but is there a reason for leaving the QuantExt extensions outside of the QuantLib library itself? If it was pushed to the QuantLib library, there would be many more "eyes" on it from the open source community, and therefore likely more development upon its work. I understand it is the work of the company in support of Open Source Risk, but this would potentially simplify the development ahead for both OSR and QuantLib. And likely reduce maintenance on the side of the OpenSourceRisk project team. I suppose the real question: is it OSR's desire to keep their extensions separate? If they were integrated into QuantLib, along with the test suite, then it would be maintained by QuantLib devs and updates would be automatically done on their side, freeing up the work that OSR devs would have to do with every incremental update of QuantLib. I see there was a session in 2018 where this was discussed, but haven't seen it done yet.
I'm attempting to port it over but I am not exactly a C++ expert. So some of the functions I'm potentially breaking but keeping a list for those that know C++ well so they can fix it properly if they need those functions (I personally don't), mostly by commenting out problematic code segment declarations in MSVC 14.1 (Visual Studio 2017 Community), or adding missing include files that have needed definitions imported. I suppose I'll see if I broke anything by running the QuantExt testsuite against it once I work through the errors. But this would be SO MUCH FASTER if someone well versed in C++ was helping me do it. I'll get the changes into my GitHub fork probably in the next week or so, once I get it compiling as a standalone library.