On 3/2/20 9:51 PM, Kim Barrett wrote: >> On Mar 2, 2020, at 7:00 AM, Andrew Haley <a...@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
