migrate to C++17, mainly to switch file system related stuff to std::filesystem
#240
Open
3 of 6 tasks
Comments
ped7g
referenced
this issue
Sep 16, 2024
…bstitution old syntax "-I~/path/" -> this is ignored by the shell, so "~" is not substituted with $HOME, because it's one string new syntax: "-I ~/path/" -> shell will treat ~/path as individual string and substitute the ~ (if it does that usually for you) Also the sjasmplus will now check all include paths before starting assembling and report if some can't be opened. And it reports if some starts with literal "~" (fopen will not substitute that, so if shell didn't before starting sjasmplus, report it as error). OLD SYNTAX STILL WORKS (and it's not going to be removed any time soon, if ever), but docs and --help will suggest the new syntax only.
|
@jurajlutter @kborowinski and other assigned: let me know if you disagree about bump to C++17, silence will be treated as agreement. |
|
No objections from my side. |
|
I've no objections. |
|
OK |
|
I’m fine with that, let´s bump to gcc9 as new minimum. |
ped7g
added a commit
that referenced
this issue
Dec 31, 2024
Related #240, should fix "check include paths" feature for windows, and simplify somewhat code base (and get rid of home-made filename patching functions, they seem robust enough and well tested, but I assume in the long term having C++ standard library implementation is better, even if it involves slightly more machine code executed here and there). This is not thorough refactoring of whole code base, working on it bit by bit, luckily the std::filesystem API is flexible enough to connect/disconnect it to rest of code through char[] fields, so I can replace the code partially and check test results. Commit v2 (replacing lot more variables and code than first proof of concept).
ped7g
added a commit
that referenced
this issue
Jan 2, 2025
Related #240, should fix "check include paths" feature for windows, and simplify somewhat code base (and get rid of home-made filename patching functions, they seem robust enough and well tested, but I assume in the long term having C++ standard library implementation is better, even if it involves slightly more machine code executed here and there). This is not thorough refactoring of whole code base, working on it bit by bit, luckily the std::filesystem API is flexible enough to connect/disconnect it to rest of code through char[] fields, so I can replace the code partially and check test results. Commit v2 (replacing lot more variables and code than first proof of concept).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
PLEASE COMMENT IN THIS ISSUE if you see any emerging problem by switching to C++17 (ie. you are actively using sjasmplus on platform which doesn't have latest compiler and you think it's worth to maintain C++14 compatibility with all the extra effort involved).
C++17 support across compilers: https://en.cppreference.com/w/cpp/compiler_support/17
C++17 support in GCC: https://gcc.gnu.org/projects/cxx-status.html#cxx17
libstdc++17 implementation not experimental since GCC-9: https://gcc.gnu.org/gcc-9/changes.html#libstdcxx
filesystem since: GCC9 (8 experimental), CLANG7 (experimental?), MSVC VS 2017 15.7, Apple clang 11.0.0
Another option is to use some library like https://github.com/gulrak/filesystem (C++11, single-header-lib, mostly compatible with
std::filesystemAPI with few minor differences).As far as I remember the C++14 was to support GCC5, consult with z00m first (Busy is unable to compile latest sources for years now, so he will be just more unable, until he starts to use some decent OS with regular compiler updates).
std::clamp"compiler" --versionto CI script so stuff like "gcc:latest" has version visible from build logstd::filesystemstd::bytefor fun, how much it would work or notThe text was updated successfully, but these errors were encountered: