ashaduri
Xcode older version and cpp 14 compatibility problem, a possible fix with boost
DESCRIPTION
-
In our project, with XCode 12.4, Target lowest iOS 9, cant compile the code--due to c++17 compatibility
-
I really like the idea of using string_view to achieve 0-copy, and I want this lib to work anyway.
- So I made type adaption with boost::string_view to avoid c++ 17 requirements
- The unit tests within the code are so good, which make the modification a lot easier and I managed to get all tests to pass.
- Code is running in our CI system; iOS, Android, no compile error.
-
To ashaduri: I am not sure you like the idea of using boost. Some macros are more or less seem to contaminate the elegance of the origin code. I am trying to integrate this lib into our project to improve some table performance. Tell me if you find any problem.
CODE EXPLAIN
Type adaptation
- std::string_view to csv_string_view(boost:string_view/std::string_view)
- std::optional to csv_optional(boost::optional/std::optional)
- std::variant to csv_variant(boost::variant/std::variant)
- std::nullopt to csv_nullopt(boost::none_t/std::nullopt)
- std::bad_variant_access(boost::variant2::bad_variant_access/std::bad_variant_access)
- String to CsvString to avoid conflict with what may happen: typedef std::string String
Grammar
- if(assignment; condition) to assignment; if(condition)
- std::holds_alternative<Type>(value_) to if(boost::get<Type>(&value_) != nullptr)
- std::get<Type>(&value_) to directly using result of boost::get<Type>(&value_), if not nullptr
Patch Info
- Base on: b8b0e136733b5efee71c809e2d54c3835c34beb4 Fix Catch2 include path to be SYSTEM include.
- Both git format-patch and patched code are submitted
Xcode-Cpp14-compatibility-Patch.zip
Hello @alenwesker ,
First of all, thank you for using this library and actually adapting the code to your needs.
I'm happy you did so much work and were able to do a Boost port with all the tests passing.
However, I'm not sure about merging the patches into the main code, mainly due to the following reasons:
- It was intended as a clean, pure C++17 library from the start, so no dependencies (even if optional).
- I wanted to utilize C++17 to the fullest, to create a truly modern library (hence the compile-time nature).
- Having macros which replace half of the code makes the maintenance twice as hard, especially with Boost also evolving.
Having said that, I understand that sometimes, going against the vision of the project is simply necessary to "get the work done". What I mean is, I would welcome from you (and encourage) an alternative fork with Boost support.
As for iOS/Android, do you have any information on which XCode / iOS and Android versions would support this code "as is"? I'm open to small patches (and, if possible, setting up GitHub Actions for these systems).
Thanks, Alexander
Agree. Sometimes I feel so troublesome to adapt code to Xcode. While AndroidStudio and VS work well in most cases, Xcode keeps generating wired compiling warnings/errors. Although most are reasonable regulations on code stability, one can't simply update Xcode while needing older platforms' compatibility. This patch issue is just in case someone needs it.
I will contribute a formal patch as I continue using it on the ongoing project.
Thank you for your reply.