Why is there no implicit conversion from std::string_view to std::string?
C++17String ViewC++17 Problem Overview
There is an implicit conversion from std::string
to std::string_view
and it's not considered unsafe, even though this surely may cause a lot of dangling references if programmer is not careful.
On the other hand, there's no implicit conversion from std::string_view
to std::string
using same argument but in the completely opposite fashion: because programmer may be not careful.
It's lovely that C++ has a replacement for a raw const char*
pointer, while making it super confusing and stripped to the bone:
- Implicit
const char*
->std::string
: OK - Implicit
std::string_view
->std::string
: NOPE - Assignment
std::string
=const char*
: OK - Assignment
std::string
=std::string_view
: OK - Appending
std::string
+=const char*
: OK - Appending
std::string
+=std::string_view
: OK - Concatenation
const char*
+std::string
: OK - Concatenation
std::string_view
+std::string
: NOPE - Concatenation
std::string
+const char*
: OK - Concatenation
std::string
+std::string_view
: NOPE
Am I missing something or is this a total nonsense?
In the end, how useful is this string view without all the crucial pieces that make it similar to const char*
? What's the point of integrating it into the ecosystem of stdlib while not making the last step to make it complete? After all, if we need an object that represents a piece of a string we could write our own. Actually, a lot of libraries already have done that, years ago. The whole point of making something standard is to make it useful for widest range of use cases, isn't it?
Are they going to fix this in C++23?
C++17 Solutions
Solution 1 - C++17
The problem is that std::string_view
-> std::string
makes a copy of the underlying memory, complete with heap allocation, whereas the implicit std::string
-> std::string_view
does not. If you've bothered to use a std::string_view
in the first place then you obviously care about copies, so you don't want one to happen implicitly.
Consider this example:
void foo1(const std::string& x)
{
foo2(x);
}
void foo2(std::string_view x)
{
foo3(x);
}
void foo3(const std::string& x)
{
// Use x...
}
The function foo2
could've used a const std::string&
parameter, but used a std::string_view
so that it is more efficient if you pass in a string that isn't a std::string
; no surprises there. But it's less efficient than if you'd just given it a const std::string&
parameter!
- When
foo2
is called with astd::string
argument (e.g. byfoo1
): Whenfoo2
callsfoo3
, it creates a copy of the string. If it had aconst std::string&
argument, it could've used the object it already had. - When
foo2
is called with aconst char*
argument: Astd::string
copy has to be made sooner or later; with aconst std::string&
parameter it gets made earlier, but overall there's exactly one copy either way.
Now imagine foo2
calls multiple functions like foo3
, or calls foo3
in a loop; it's making exactly the same std::string
object over and over. You'd want the compiler to notify you about this.
Solution 2 - C++17
Because expensive implicit conversions are undesirable...
You only listed one implicit conversion out of your entire set of examples: const char*
-> std::string
; and you're asking for another one. In all of the other 'OK'-marked functions - allocations of memory are obvious/explicit:
- Assignments: When you assign anything to an owning object with variable storage size, it is understood that an allocation may be necessary. (Unless it's a move-assignment, but never mind that.)
- Append I: when you append to an owning object with variable storage size, it is even more obvious it will need to allocate to accommodate the additional data. (It might have enough reserved space, but nobody guarantees this about strings.)
- Concatenations: In all three cases, memory is allocated for the result only, not for any intermediate object. Allocation for the result is obviously necessary, since the operands of the concatenation remain intact (and can't be assumed to hold the result anyway).
Implicit conversions in general have benefits and detriments. C++ is actually mostly stingy with these, and inherits most implicit conversions from C. But - const char*
to std::string
is an exception. As @ArthurTacca notes, it allocates memory. Now, the
C++ core guidelines say:
> C.164: Avoid implicit conversion operators
>
> Reason:
> Implicit conversions can be essential (e.g., double to int)
> but often cause surprises (e.g., String to C-style string).
and this is doubly the case when the unintended conversion performs expensive operations like allocation, which have side effects, and may make system calls.
PS - std::string_view
has quite a few gotchas; see this CppCon 2018 talk by Victor Ciura:
Enough string_view
to hang ourselves with
So remember it's not some kind of universal panacea; it's another class that you need to use with care, not carelessness.
... an explicit constructor is sufficient.
There actually does exist an explicit constructor of std::string
from std::string_view
. Use it - by passing std::string{my_string_view}
to a function taking a string.