83

Since C++17, we have std::string_view, a light-weight view into a contiguous sequence of characters that avoids unnecessary copying of data. Instead of having a const std::string& parameter, it is now often recommended to use std::string_view.

However, one quickly finds out that switching from const std::string& to std::string_view breaks code that uses string concatenation as there is no support for concatenating std::string and std::string_view:

std::string{"abc"} + std::string_view{"def"}; // ill-formed (fails to compile)
std::string_view{"abc"} + std::string{"def"}; // ill-formed (fails to compile)

Why is there no support for concatenating std::string and std::string_view in the standard?

vitaut
  • 37,224
  • 19
  • 144
  • 248
s3rvac
  • 6,983
  • 7
  • 40
  • 65
  • 14
    Most likely an oversight. That said, it doesn't take much to add a `operator +` to make the code work. – NathanOliver Jun 19 '17 at 17:29
  • 8
    Just found this: https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/1RcShRhrmRc – NathanOliver Jun 19 '17 at 17:38
  • 2
    What I also miss is a member function of std::basic_string that returns the std::basic_string_view of a sub-string (similar to the "substr" member function), perhaps named "substr_view". – CAF Jun 19 '17 at 18:06
  • 1
    have a look at this. https://github.com/OlafvdSpek/xbt/blob/master/misc/xbt/string_view.h – asad_nitp Sep 27 '17 at 17:12

1 Answers1

45

The reason for this is given in n3512 string_ref: a non-owning reference to a string, revision 2 by Jeffrey Yasskin:

I also omitted operator+(basic_string, basic_string_ref) because LLVM returns a lightweight object from this overload and only performs the concatenation lazily. If we define this overload, we'll have a hard time introducing that lightweight concatenation later.

It has been later suggested on the std-proposals mailing list to add these operator overloads to the standard.

vitaut
  • 37,224
  • 19
  • 144
  • 248
  • 73
    Wow. Just wow! This seems to be the *worst* possible reason for leaving something out. The standard is supposed to be for the good of the *language,* not for any particular implementation. I'm also wary of the "performs the concatenation lazily" - does this mean that, should we have a memory shortage, the exception for adding to the original string will *also* be deferred? I sure as hell hope not, I want to know if an operation fails when *I* do it, not ten minutes later when I access the result. – paxdiablo Dec 10 '17 at 03:57
  • 4
    Hopefully someone submit's a proposal to include these operators. – vitaut Dec 10 '17 at 04:00
  • 3
    In the [fmtlib/fmt](https://github.com/fmtlib/fmt) library works great with `string_view`. – void.pointer Aug 19 '19 at 20:45
  • 8
    [`std::basic_string::append()`](https://en.cppreference.com/w/cpp/string/basic_string/append) has an overload that accepts everything that can be implicitly converted to a `std::string_view`. Of course this is not the same as `operator+()`. – Brandlingo Dec 09 '19 at 15:06
  • 1
    What alternatives do the commentators here do suggest if one needs an efficient c++ string concatenation(i.e. string builder)? For example, c# libraries has an efficient uri_builder class, which takes a group of strings and creates one by using a to_string() method; which in affect could be realized if string_view were to have a +() overload. – b.g. Jul 01 '20 at 08:37
  • my_s.insert(0, my_sv); // s = sv + s my_s.append(my_sv); // s = s + sv – vSzemkel Dec 31 '20 at 13:58