Paul Eggert wrote: > On 2026-01-05 10:12, Jonathan Wakely wrote: > > - char const *utf8 = u8"UTF-8 string \u2500"; > > + auto const *utf8 = u8"UTF-8 string \u2500"; > > Thanks, I installed that into Gnulib for now
The change looks good: it tests for the presence of two features of C++11 [1][2]. > though I'm still > interested in the more-ambitious approach (taken by bleeding-edge > Autoconf) of not fiddling with C++ versions here. > https://cgit.git.savannah.gnu.org/cgit/autoconf.git/commit/?id=056518b94ecd487bcbefdb69046b3f52c4168222 I understand the motivation of this change: The old AC_PROG_CXX code was made for the situation (predominant from ca. 2000 to 2015) where the C++ standard had evolved and the compilers supported the new standard when the appropriate -std=... option was given, but the compiler's default had not been bumped for a long time. Since ca. 2020, the compilers not only support the new standards, but also do so by default (despite the occasional backward-incompatibilities between the C++ standards versions). The patch mentioned above terminates a catch-up game between the C++ standards and the Autoconf versions. BUT in doing so, it makes it harder for the user / distro to build a package: The user now needs to try e.g. -std=gnu++23 or -std=gnu++26 depending on the package, and see which of them produces the fewest compilation errors. This is against the principle of Autoconf. The principle of Autoconf is that the package's author *declares* the requirements, and Autoconf arranges for setting CXX and CXXFLAGS so that these requirements are met. In this case, it means the package's author should declare the C++ standard that the package requires, and if that is new enough, Autoconf should add -std=gnu++23 or -std=gnu++26 as needed. For instance, assume we change AC_PROG_CXX so that it takes an optional standard version: - AC_PROG_CXX should not change the CXX variable. - AC_PROG_CXX([98]) should not change the CXX variable. - AC_PROG_CXX([11]) should try the -std=gnu++11 option and, if it is needed and it works, add it to the CXX variable. - AC_PROG_CXX([17]) should try the -std=gnu++17 option and, if it is needed and it works, add it to the CXX variable. - AC_PROG_CXX([20]) should try the -std=gnu++20 option and, if it is needed and it works, add it to the CXX variable. - AC_PROG_CXX([23]) should try the -std=gnu++23 option and, if it is needed and it works, add it to the CXX variable. - AC_PROG_CXX([26]) should try the -std=gnu++26 option and, if it is needed and it works, add it to the CXX variable. This will make it unnecessary for the user / distro to try different CXX values (CXX="g++", CXX="g++ -std=gnu++23", CXX="g++ -std=gnu++26"). And, as far as I can see, it is future-proof in the sense that it will not misbehave when the same package is built 5 or 10 years from now, with GCC 20 or GCC 25 — except for the occasional backward-incompatibilities that the C++ standards committee tries to avoid. Bruno [1] https://cppreference.com/w/cpp/language/string_literal.html [2] https://cppreference.com/w/cpp/language/auto.html
