First of all, great work. This is probably the most thorough and streamlined backport of string_view publicly available, and I thank you for making it such.

I'm using it to replace Google's Abseil implementation, which still has some rough edges, and certainly drags in a lot of baggage for someone who just needs string_view.

One of my biggest motivations for using string_view is to facilitate string keyed associative containers with compile-time lookup, which opens the door to many useful things with zero runtime overhead. However, this requires constexpr comparison to be available... This string_view delegates operator== to char_traits::compare() which is part of std, and as such is required NOT to be marked constexpr in pre-C++17 compilation. This is despite the compiler being perfectly able to perform constexpr comparisons.

In my case then, there is little value in backporting string_view if it doesn't backport its benefits too.

My workaround solution for this was deriving my own char_traits to implement a constexpr compare(), and then deriving my own string_view, as shown below. Perhaps you can think of a better way to backport constexpr comparison.

Thx

namespace my_own {
    namespace _detail {
        struct char_traits : public std::char_traits<char> {
            static constexpr int compare( const char_type* s1, const char_type* s2, std::size_t count ) {
                ... compiler specific ...
            }
        };
        using plain_string_view = nonstd::basic_string_view<char>;
    }
    class string_view : public nonstd::basic_string_view<char, _detail::char_traits> {
        using Base = nonstd::basic_string_view<char, _detail::char_traits>;
    public:
        using Base::Base;
        // need to provide own implicit conversions with std::string, since it uses the default char_traits
        operator string() const noexcept { return string(data(), size()); }
        string_view(string const & s) noexcept : Base(s.data(), s.size()) {}
        // provide implicit conversions with a string view that uses standard char_traits
        constexpr operator _detail::plain_string_view() const {return {data(), size()};}
        constexpr string_view(_detail::plain_string_view p) : Base(p.data(), p.size()) {}
    };
    inline std::ostream & operator<<(std::ostream & os, string_view sv) { return os << _detail::plain_string_view(sv); }
} // namespace

Hello! Thanks for your great library.

I need to use your library in an Intel SGX Enclave where we can't use standard streams (for security reasons).

In order to use your library I needed to exclude those lines from the header

Hello,

we are using string_view_lite to support the functionality in the GROMACS project (https://gitlab.com/gromacs/gromacs) for the current release before we are making the actual switch to C++17 and native support.

We recently got a report (https://gitlab.com/gromacs/gromacs/-/issues/3533) that the compilation of our code fails in the string_view compatibility layer with the following error when using the NEC compiler

"/gromacs-2020.1/src/gromacs/compat/string_view.h", line 894: error: incomplete type is not allowed
const basic_string_view v;

Are you aware of other compilers having similar issues?

Thanks for the help!

If you declare a string constant in the global space you might see clang-tidy showing the warning that "Initialization of X with static storage duration may throw an exception that cannot be caught". Actually initialization of the constant literal string never throws an exception.

Example:

const char* path = "file:///path/to/file.ext";

To fix it the following constructors should be marked noexcept:

nssv_constexpr basic_string_view( CharT const * s, size_type count ) nssv_noexcept

nssv_constexpr basic_string_view( CharT const * s) nssv_noexcept

By the way Traits::length(s) is marked constexpr starting from C++17. So the following constructor can only be marked constexpr for C++17+.

nssv_constexpr basic_string_view( CharT const * s)
    : data_( s )
    , size_( Traits::length(s) )
{}

... quoting Kate Gregory, Cpp2017.

• [x] Create initial code files string_view.hpp end test files and compilation command.
• [x] Create class template basic_string_view with method declarations.
• [x] Implement constructors
• [x] Implement assignment
• [x] Implement iterators
• [x] Implement element access
• [x] Implement capacity
• [x] Implement modifiers
• [x] Implement operations
• [x] Implement string conversion operations, class methods (optional extension)
• [x] Implement string conversion operations, free functions (optional extension)
• [x] Implement comparisons, primary
• [x] Implement comparisons, extended
• [x] Implement streaming
• [x] Implement "sv" literals
• [x] Implement std::hash<>
• [x] Setup Travis
• [x] Setup AppVeyor
• [x] Setup 'on Wandbox'
• [x] Setup 'on Godbolt'
• [x] Create Readme
• [x] Fine-tune Readme
• [x] Release 0.2.0
• [x] Setup 'on conan' (@agauniyal ?)
• [x] Update Readme

Interface and implementation

• string_view on cppreference.
• n4659 - C++17 Working Draft: string_view.
• Implementation by Marshall Clow.
• libc++: string_view.

Other implementations on GitHub

• Google's Abseil string_view (non-template).
• @thelink2012, Denilson das Mercês Amorim's standalone version of libc++'s string_view.
• @bitwizeshift, Matthew Rodusek's string_view Standalone
• @satoren 's string_view for C++03 C++11 C++14.
• @simber, Simon Simber's C++ string_view extension library..
• Search string view c++ on GitHub.

Presentations

• Marshall Clow. string_view - when to use it, and when not. CppCon 2015. video, slides.
• Neil MacIntosh. A few good types: Evolving array_view and string_view for safe C++ code. CppCon 2015. video, slides.

Proposals

• Jeffrey Yasskin. n3334 - Proposing array_ref and string_ref. 2012.
• Jeffrey Yasskin. n3921 - string_view: a non-owning reference to a string, revision 7. Adopted 2014-02.
• Alisdair Meredith. n4288 - Strike string_view::clear from Library Fundamentals. Adopted 2014-11.
• Neil MacIntosh. p0123 - Unifying the interfaces of string_view and array_view. 2015.
• Beman Dawes, Alisdair Meredith. p0220 - Adopt Library Fundamentals V1 TS Components for C++17 (R1). 2016.
• Marshall Clow. p0254 - Integrating std::string_view and std::string. Adopted 2016-06.
• Nicolai Josuttis. p0392 - Adapting string_view by filesystem paths. 2016.
• Marshall Clow. p0403 - Literal suffixes for basic_string_view. 2016.
• Peter Sommerlad. p0506 - use string_view for library function parameters instead of const string &/const char *. 2017.
• Daniel Krugler. wg2946 - LWG 2758's resolution missed further corrections. 2017.

It would be good if the header was compatible with -Wshadow. It has one error:

nssv_constexpr explicit not_in_view( basic_string_view v ) : v( v ) {} string_view.hpp:858:68: warning: declaration of ‘v’ shadows a member of ‘nonstd::sv_lite::basic_string_view<CharT, Traits>::not_in_view’ [-Wshadow]

The local argument just needs to be changed:

nssv_constexpr explicit not_in_view( basic_string_view view ) : v( view ) {}

A naive implementation of a constexpr alternative to std::search() for pairs of basic_string_views, using the basic_string_view::starts_with() method.

Note: Have not implemented this for rfind(); it would make sense to do both. Have also not touched the copyright notice.

In the write_to_stream method, the check on line 1384 is testing the stream.

    if ( !os )
        return os;

Should this check test the sentry instead?

  if (!sentry) {
    return os;
  }

This doesn't compile with VC 2010:

string_view s;
s == "";

Need to write s == string_view("");

This looks like a problem of the compiler that's probably hard to work around.

Hey, big fan! Currently I'm using optional-lite, span-lite, and string-view-lite. I noticed you recently updated optional and span to support a CMake's find_package feature. It would be incredibly useful for me if you also updated string-view-lite, since it lets me throw out my hand-rolled find_package for these libraries.

No worries if this isn't a high priority!

When building with clang on Windows using nssv_CONFIG_SELECT_STRING_VIEW=nssv_STRING_VIEW_NONSTD, you can get compilation errors due to multiple functions defined by string-view-lite mapping to the same mangled symbol name.

This does not occur when building with MSVC, because in that case string-view-lite ensures that the operator== functions have different signatures (see nssv_MSVC_ORDER).

$ cat >test.cpp <<EOF
#include "nonstd/string_view.hpp"
// Ensure both operator== functions are instantiated
int foo() { return "" == nonstd::string_view(""); }
int bar() { return nonstd::string_view("") == ""; }
EOF

$  clang-cl -Dnssv_CONFIG_SELECT_STRING_VIEW=nssv_STRING_VIEW_NONSTD -Fotest.obj -c test.cpp
In file included from test.cpp:1:
nonstd/string_view.hpp(1274,21): error: definition with same mangled name
      '[email protected]@[email protected]@@[email protected]@@[email protected][email protected]@[email protected]@@[email protected]@Z' as another definition
nssv_constexpr bool operator==(
                    ^
nonstd/string_view.hpp(1280,21): note: previous definition is here
nssv_constexpr bool operator==(
                    ^
1 error generated.

Tested under clang 11.0.1, MSVC 2019 19.28, string-view-lite 1.6.0.

I'm trying to compile one of the examples of my cuda-api-wrappers library, which uses string-view-lite, using C++14 instead of C++11 like I was compiling it so far. I get:

... snip ...
/home/eyalroz/src/mine/cuda-api-wrappers/examples/other/jitify/string_view.hpp:572:23: error: call to non-‘constexpr’ function ‘_FIter1 std::search(_FIter1, _FIter1, _FIter2, _FIter2) [with _FIter1 = const char*; _FIter2 = const char*]’
  572 |     return std::search( haystack.begin(), haystack.end(), needle.begin(), needle.end() );
      |            ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
... snip...

and, indead, std::search is not constexpr before C++20.

Currently, the find() method of basic_string_view is nssv_constexpr14. It seems to me it should be possible to make it constexpr since C++11 with tail-recursion iteration.

When introducing string_view into an old codebase, it is quite easy to accidentally leave nonsensical assignments from or comparisons to nullptr in your code. Adding a deleted constructor as follows allows developers to easily identify the offending assignments and comparisons:

#if nssv_CPP11_OR_GREATER
    nssv_constexpr basic_string_view( std::nullptr_t ) nssv_noexcept = delete;
#endif

C++23 will also disallow constructing std::basic_string_view from nullptr: https://github.com/cplusplus/papers/issues/887

• [x] on wandbox, update string_view.hpp to version 0.2.0
• [x] on godbolt, update string_view.hpp to version 0.2.0
• [ ] on godbolt, show string view lite's version number, see gsl lite
• [x] in Readme, update badge links of godbolt, wandbox
• [ ] review test/specification texts
• [ ] ...