How to Adopt Modern C++17 into Your C++ Code [video]
1–10 of 124 posts
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#2Great 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?
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#3Great 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…
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.
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#4Great 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…
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`.
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#5Great 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…
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.
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#6Great 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…
> 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.
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#7Great 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…
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!
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#8Great 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…
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...
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#9Great 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…
> 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 ma…
> ...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` as a parameter. To avoid the ambiguity and possible bugs of taking an `int*`.
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#10Great 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…
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 ex…
> ...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.