Hacker News Reader

Comment by saagarjha | Hacker News Reader

Great talk, but I still have a couple questions that I'm sure someone here can answer:

1. I didn't see what the smart pointer stuff had to do with C++17. Aren't these all available from C++11? Are these something new that I missed, or are they just comments on how to avoid bugs, based on Herb Sutter's personal experience?

2. Should I std::string_view everywhere I used to use std::string now? The examples given seemed to lean heavily towards using std::string_view as parameters instead of std::string, but should I use them as a drop-in replacement everywhere?

3. The std::optional example looked really clunky, relying on checking an exception. I see there are a bunch of nice operators and utility functions on std::optional that cover some use cases, like coalescing, but will we get something that allows for optional chaining?

View on HN

Smart pointers have been an evolution, C++11 deprecated auto_ptr (gone in C++14), make_unique only came up C++14 due to an oversight on C++11, C++17 constructor type deduction makes everything more productive.

Regarding memory and performance improvements std::string_view should better than using std::string, but don't go overboard replacing all code. It depends what kind of application you are writing, the age of existing code, or sometimes a plain old const reference might be enough.

There are some ongoing efforts for such chaining

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p079...

https://github.com/TartanLlama/optional

EDIT: corrected the make_unique/make_shared misinformation.

> ...make_shared only came up C++14 due to missing deadline on C++11...

You might have a typo here. make_shared was available in C++11. make_unique was left out from C++11 as an oversight and added in C++14.

Yes you are right, my mistake.

1. In the introduction, Herb Sutter mentions this talk is also for people that might not know about C++11 features.

2. Use std::string for when you need to own a string. Use std::string_view when you need to reference a string [a]. Generally you want std::string_view for parameters and std::string for member variables. Return values and local variables can be either, but if you're not sure, std::string is safer though slower.

3. You chain optional, but only with nested functions, and you code starts looking more and more like lisp. If you are a fan of a chained syntax, you might be interested in libraries that support "ranges". boost already has ranges and there are proposals to add them to C++20.

[a] If you want more specifics and detail, the CppCoreGuidelines have a section on when to use which string. https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

TIL about std::byte; I should have probably used it instead of char in a recent project of mine…

std::string_view is, as the name implies, a view into a std::string.

If you own the actual string, use std::string — there is no other string for you to view.

If somebody else owns it and you're working on the whole string `const std::string&` is probably your best bet — you're holding a reference to the string as a whole — but std::string_view also works and might make more sense in context.

If you're working with a substring of somebody else's string, std::string_view is the natural choice.

The key idea here is that you want to reference, rather than copy, some underlying string. If you're working on something where your code needs to own a deep copy of the original string for some reason, by all means continue using std::string!

> If somebody else owns it and you're working on the whole string `const std::string&` is probably your best bet

Actually string_view is more general. You can build one out of a string literal, a vector<char>, some memory from a memmap call, and an unbounded list of other things. If an interface uses a `const std::string&` and you don't have one, you have to, implicitly or explicitly, copy the data into a `std::string` to be able to use that interface.

Is it just me, or does it seem like std::string_view is just an alternative in semantics to a `char *` plus a size? It doesn't null-terminate (which would require copying or mutating). Is there some extra safety checking this provides?

Under the hood it's just "std::pair<const char, std::size_t>". It's like an abstract data type or a newtype in Haskell: construction of the aliased type is restricted to the functions that are provided.

You are correct, there is no safety --- you can call the constructor std::string_view(const char, size_t) and stuff anything you want in there. The main reason string_view is nice is the implicit conversions you get from the other string types. Pass in a "const char*", it finds the terminating null for you. Pass in a std::string, no problem. No boilerplate.

There are mild benefits to having one value that represents both a size and an address. So you're passing around a pair of things that go together instead of just using convention.

But the real benefit is in providing it as a "vocabulary type". Once C++ code starts using string_view everywhere, you don't need to massage your char sequences this way and that [1] to pass it from the top of your application all the way down into the low-level libraries the application relies on. And you don't incur the overhead (both in lines of code and in copies) of all that massaging.

[1] Maybe your request handler has to convert from char* and size to a string to call your business logic, then your string has to convert from a string to a char pointer and and int length to call saveName. saveName might actually use std::copy under the hood to put the data into a chunk of memory, so it turns the pointer and length into two pointers.

- It has range semantics, so you can use it with standard algos or range for.

- It encodes the invariant in a type (char * points to at least size bytes, no expectation of null termination, no ambiguous definition of an empty range)

- The size always travel with the pointer so no chance that it gets separated.

- syntactically simple conversion from string (or other string-like entities) to string view reduces clutter in the code.

I consider lack of null termination a plus.

This is true as long as your implementation doesn't call any functions that take a `const string&`. If you need to call such a function, then you first have to make a copy of your string_view into a new string object before you call it.

Is there a way to do this without involving the overhead of a full copy, though?

Not that I'm aware of - a const std::string& parameter needs to be a reference to a std::string object, and there's no guarantee that a given string_view object is pointing to a std::string.

Whenever I'm working with substrings, I'm always nervous about bugs resulting from different encodings. I'm never comfortable with search for substrings or applying regular expressions or iterating over a string.

Encodings in general a bit of a headache. I work on Windows and it wants UTF-16 internally and everything external wants UTF-8.

> 3. The std::optional example looked really clunky, relying on checking an exception. I see there are a bunch of nice operators and utility functions on std::optional that cover some use cases, like coalescing, but will we get something that allows for optional chaining?

Nope. It must be understood that std::optional is not an Option type, its purpose is not to have a way to express "missing" items in a type-safe manner but rather to have pointer-type semantics without needing to heap-allocate. So you can just deref' an std::optional, and it's UB if they're empty. Don't think of it as Haskell's Maybe, think of it as a stack-allocated version of std::unique_ptr.

> ...its purpose is not to have a way to express "missing" items in a type-safe manner...

Except that's exactly why you would take an `optional<int>` as a parameter. To avoid the ambiguity and possible bugs of taking an `int*`.

You mean int*, right?

Yes. Fixed! Thanks.

> Except that's exactly why you would take an `optional<int>` as a parameter.

Except for the type-safe part which is the important bit (hence the emphasis on it), and which std::optional does not provide.

> To avoid the ambiguity and possible bugs of taking an `int*`.

The only ambiguity and possible bug (singular) you're avoiding using std::optional is the question of ownership. Because as emphasised in the original comment std::optional is no more type-safe than a raw pointer.

Clarity about ownership is enough. But there's also ambiguity because pointers are sometimes used to pass around arrays, especially in the case of 'char*'. And a dev also has to go out of his way to create a dangling optional<int>.

Even if we consider just ambiguous ownership, there are a whole host of behaviors that could result from that single design mistake, including undefined behavior, which could include trashing your production database, firing the missiles, or behaving as expected until an unrelated piece of code changes a year later.

The purpose is exactly to express possibly missing return values, which is exactly why it is called "optional", rather than "pointer_type_semantics<T>".

I also don't see why you would ever use it in the way you're describing. Even if you had template code, either you manipulate objects/references, or pointers. And worst case, you usually try to handle references, rather than trying to risk UB.

> The purpose is exactly to express possibly missing return values

Operative word: type-safe. std::optional is not that.

> I also don't see why you would ever use it in the way you're describing.

I'm literally just describing the semantics of std::optional.

> It must be understood that std::optional is not an Option type, its purpose is not to have a way to express "missing" items in a type-safe manner but rather to have pointer-type semantics without needing to heap-allocate.

I don't understand what you mean here. I don't have to heap-allocate to get a pointer to something; I can just take the address of something on the stack…

Regarding 2., in general, if you have a function that takes a `const std::string&` as parameter, you can replace it by a `std::string_view`. If you have stuff like `constexpr const char* whatever = "blah blah blah";` you can also replace it by a `std::string_view`. If you have a `std::string` member in a class, then you must not replace it by a `std::string_view`.

Only if you don't need null-termination. I suppose, should you decide to make direct fwrite/write/memcpy calls using its size you can avoid even needing the null terminus, but a lot of code requires a null-terminated string. I think a std::string_view would bring in more opportunities to break code than make things easier.

2: You can't use them everywhere. They're a view so you can't use them to actually store a string.

3: Hopefully someday we'll get a proper monadic interface in C++. Until that day, I'll keep using exceptions.

For 3, std::optional has the has_value() method.

std::optional<int> a = foo(); if(!a.has_value()) { return; } bar(a);

is pretty standard.

Though, with exception handling you get function chaining which can be rather nice.

I'm look for something like Swift's optional chaining, á la:

  std::optional<std::string> a = foo();
  auto size = a?.size() // size is a std::optional<int>

re: string_view, this is a really good summary: https://abseil.io/tips/1

Reply on news.ycombinator.com