Enhancement: libc++ provides string_view for all C++ language levels

[mclow]

abseil-cpp/absl/base/config.h

Line 363 in 2a62fbd

#define ABSL_HAVE_STD_STRING_VIEW 1

Yes, even C++03. :-)

You can test this thus:

#ifdef __has_include
# if __has_include(<string_view>)
#  include <string_view>
#  if __cplusplus >= 201703L || defined(_LIBCPP_STRING_VIEW)
#   define ABSL_HAVE_STD_STRING_VIEW 1
#  endif
# endif
#endif

[atkawa7]

@mclow @derekmauro @rogeeff Should be careful about __has_include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
https://bugs.chromium.org/p/chromium/issues/detail?id=759349&desc=2

[zhangxy988]

@atkawa7 IIRC, the bug is about using libstdc++ with -std=<version older than c++17>. Since we are also checking __cplusplus >= 201703L, the bug should NOT be a concern.

[atkawa7]

@zhangxy988 See google/crc32c@d0f929a

[zhangxy988]

@atkawa7 The commit seems strange to me: the bug in the original code is in #if !defined(_MSC_VER) || __cplusplus >= 201703L which is ignoring the __cplusplus >= 201703L check on any non MSVC compiler (GCC, Clang), and this should be fixed as #if !defined(_MSC_VER) && __cpluscplus >= 201703L (or simply #if __cplusplus >= 201703L since _MSC_VER set __cpluscplus to 199711).
So, I don't think this has anything to do with the GCC bug.

[atkawa7]

@zhangxy988 They are two different bugs but similar. So should be careful

[JonathanDCohen]

This is really about libc++, yes? So really we just want to check for libc++, and handle the msvc and libstdc++ cases separately.

According to this stackoverflow we can do this by something like

#include <ciso646>
// ...
#ifdef _LIBCPP_VERSION
#define ABSL_HAVE_STD_STRING_VIEW 1
#else 
// ...

@mclow is this a reasonable idea?

[mclow]

Almost - you still have to check for the existence of the <string_view> header. Old versions of libc++ didn't have this. but if the header is there, then you have string_view

[EricWF]

@mclow @JonathanDCohen Alternatively (if you don't have __has_include, but you should), you could probably check that _LIBCPP_VERSION >= 4000.

[mclow]

Maybe if you don't have __has_include maybe you should just fail (and say "no std::string_view)

[JonathanDCohen]

Sorry for the silence here. I've had this sitting around internally for a bit, and there's some concern that libc++ backporting string_view is technically non-conforming, and could be surprising w.r.t. ADL. We also have to take a look at our FDO profiles before landing this as this would potentially change the mangled symbol names for anything taking a string_view

[mclow]

I think that "non-conforming" is a bit harsh. It's an extension, like marking the default constructor of vector as noexcept.