Ardour
Tidy up libs/lua/LuaBridge/detail/Userdata.h
This fails to compile here it requires C++17, while Ardour's current codebase uses C++11.
I'm looking into updating our build systems to support C++17. Yet switching to C++17 so will also increase the min. OS versions that we can support since a more modern libc++ and/or libstdc++ is required on the target system.
Anyway, this change looks good and works nicely. Thanks! However due to the issues mentioned I cannot provide an ETA when we will merge it.
I was about to comment that I suggest to upgrade to C++17 given that it is stable since GCC 9.0 if I recall correctly, unless very old distros are a concern. I'll try again to find an alternative way that is C++11 compliant and not too hacky, although I personally think this is the most clear and straightforward way of expressing the intent.
BTW I did not get a compile error, so waf is not enforcing any C++ standard edition. That is why I thought it was OK and that it was only a matter of you the maintainers not disliking having just a bit of template meta-programming in the codebase.
Our Linux CI systems (Intel and ARM) use gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516. This way there is backwards compatibility to Ubuntu 16.04 (old libstdc++.so.5) and Raspbian for the RPi.
Perhaps we can drop this for Ardour 9.0.
macOS/ARM (clang 13.0) CI is fine with modern C++, and our Windows builder is also OK with C++17 (x86_64-w64-mingw32-gcc (GCC) 10-posix 20210110). But so far we uses ./waf configure --strict --cxx11 ...
I'll try again to find an alternative way that is C++11 compliant and not too hacky,
Don't bother. I expect it will just be waste of time without an actual benefit.
At some point we will should to move to modern C++17, and until then the current code works just fine.
Our Linux CI systems (Intel and ARM) use
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516. This way there is backwards compatibility to Ubuntu 16.04 (old libstdc++.so.5) and Raspbian for the RPi.
Then I guess the limit is C++14.
I'll leave this PR around, but I'd like to have the build system enforce C++11/14 compliance, so I and other contributors get a build failure if we use any C++17 or greater features. It would help a lot to get other PRs I have in the pipeline in a mergeable state.
get a build failure if we use any C++17 or greater features.
That is what the --cxx11 config option is for.
I have two other commits that require C++17. I think all these should be grouped up in single PR with the sole topic of C++17 improvements for when the upgrade is done.