On 3/2/20 9:51 PM, Kim Barrett wrote:
On Mar 2, 2020, at 7:00 AM, Andrew Haley <aph@redhat.com> wrote:
On 11/19/18 8:39 PM, Kim Barrett wrote:
I don't see any benefit to making the first C++ code change that uses a new feature also incorporate the needed build system changes. Indeed, how does one develop that feature usage unless one has the build system changes already in hand?
It seems to me that if the documentation says one can use some new language feature but the build system hasn't been updated to actually support doing so, then the documentation is wrong. And recall that this JEP includes making some new features available immediately. (That initial list might be modified as part of this JEP discussion.)
What is the status of this? I thought we'd decide, but I still see
$1_CXXSTD_CXXFLAG="-std=gnu++98"
in flags-cflags.m4
I need std::make_unsigned in order to fix some undefined behaviour in HotSpot. I could implement it myself in share/metaprogramming but if we've agreed to allow C++14, can we please get it done now? Thx.
In light of JEP 362 "Deprecate the Solaris and SPARC Ports" https://bugs.openjdk.java.net/browse/JDK-8231554 with the intended removal of Oracle Developer Studio (aka Solaris Studio) as a supported compiler sometime soon, we don't want to spend effort getting HotSpot to production quality on that platform with C++11/14 features enabled and in use.
OK. So, I guess this means that we're stuck with C++98 (!) for a while. It's not too hard for me to write the support for make_unsigned and add it to share/metaprogramming. I'll do that and see what people say. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671