C++17's string_view (was Re: Making use of move semantics?)

[Murray Cumming <murrayc murrayc com>]

On Sun, 2017-05-21 at 15:03 +0100, Daniel Boles wrote:
[snip]
> > I guess we might start taking std::string_view with C++17 instead
> > of
> > std::string and this might largely take care of this.
>
>
> I don't see how string_view would make any difference to whether or
> not we end up copying strings. Can it?

I've tried it out now, so here are some thoughts:

I had hoped that std::string_view would avoid copying of C strings in
the temporary std::string in cases like this:

void use_string(const std::string& str) {
  gtk_label_set_text(str.c_str());
}
...
use_string("abc");

I think that the "abc" will be copied by the std::string constructor,
though we really only want a const char* anyway.

I had hoped that this would let us just use the original const char*:

void use_string_view(const std::string_view& str) {
  gtk_label_set_text(str.c_str());
}
...
use_string_view("abc");

But there is no std::string_view::c_str() because string_view doesn't
assume that its underlying array is null-terminated. It couldn't assume
that while sometimes being just a view of part an existing array.


So, we need to do this:

void use_string_view(const std::string_view& str) {
  gtk_label_set_text(str.to_string().c_str());
}
...
use_string_view("abc");

That std::string_view::to_string() does a copy, so I don't think we've
gained anything compared to taking a std::string.


And if we pass a std::string, we'd have a copy where we wouldn't have
had one before:

void use_string_view(const std::string_view& str) {
  gtk_label_set_text(str.to_string().c_str());
}
...
use_string_view(some_std_string);


So, I think:
1. We would use std::string_view everywhere if all the C functions took
  a length instead of assuming null-termination. That's not going to
happen.

2. Overriding all methods to take either a const char* or a std::string
(ignoring ustring for now), would avoid the extra array copy, but I
don't think it's worth it other than for methods that typically take
very large strings.

3. GTK+ functions that take very large strings tend to take a length,
to avoid the need for copying. For instance,
gtk_text_buffer_set_text(). We could take std::string_view there, but
then our use of std::string_view::to_string() would be wasteful when
someone passes a std::string to our method.

This is discouraging, so I hope I'm wrong about something.

> Separately, how would string_view interact with Glib::ustring?
> Glancing at the available documentation, my guess is "it wouldn't",
> since it seems to be based on fixed-width characters, not to be
> context-sensitive. So it may not be a suitable replacement for
> ustring.

I guess std::string_view deals with bytes, regardless of their
encoding, just as std::string does. If we keep using Glib::ustring,
we'd maybe want to have a Glib::ustring_view, at least as just a type
alias.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com