How to Adopt Modern C++17 into Your C++ Code [video]

https://www.youtube.com/watch?v=UsrHQAzSXkA

by pjmlp • 8 years ago

225 121 8 years ago

saagarjha5• 8 years ago

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?

beojan• 8 years ago

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.

jcelerier• 8 years ago

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`.

stochastic_monk3• 8 years ago

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.

pjmlp7• 8 years ago

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.

humanrebar7• 8 years ago

...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.

masklinn3• 8 years ago

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.

humanrebar7• 8 years ago

...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*`.

svalorzen• 8 years ago

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.

saagarjha5• 8 years ago

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…

pdpi• 8 years ago

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!

humanrebar7• 8 years ago

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.

criddell• 8 years ago

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.

humanrebar7• 8 years ago

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...

saagarjha5• 8 years ago

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

alexhutcheson3• 8 years ago

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

proverbialbunny2• 8 years ago

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.

saagarjha5• 8 years ago

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>

cominous4• 8 years ago

C++17 is definitely going in the right direction for most applications. But I have the feeling, that the compiler implementations cannot catch up with the modernization speed.

We are using C++ for embedded devices and recognize a steady code bloat with every release since C++11 (especially with C++17) without using any of the new features (with gcc/clang). This is a trust-killer and actually the reason we stay on C++11 for embedded development.

dvfjsdhgfv• 8 years ago

Just curious: why did you choose C++ instead of C for embedded? Most shops I know chose C just because of code bloat.

pjmlp7• 8 years ago

Modern C++ compilers do pretty well on a Commodore 64, let alone many of the typical embedded deployments outside pico-controllers.

CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”

https://www.youtube.com/watch?v=zBkNBP00wJE

Most of the time is either religion against C++ or lack of modern tooling, given that most embedded toolchains are stuck with C90 and C++98.

jack_pp• 8 years ago

Probably because it is much safer, faster to develop and easier to maintain.

CyberDildonics2• 8 years ago

If there is a modern C++ compiler available for a platform, it is almost irresponsible to use straight C. That doesn't mean that everything needs to be pure idiomatic C++17, but destructors, templates, iteration, operator overloading and move semantics are still indispensable in non trivial programs.

Avoiding bloat and performance hits are trivial in comparison to structural and architectural benefits in the modern language.

cominous4• 8 years ago

I have to admit, that C++ is still not the industry "Go-To" language for embedded. But if you apply modern C++ correctly, there is very few overhead compared to C and the software is much easier to maintain.

The performance of embedded MCU's are continuously rising over the years and that little overhead is buying development speed.

Not to mention smart pointers, templates and constexpr making my life easier.

The only real issue with C++ is, that as soon as you get into serious embedded applications, you have restrictions when it comes to heap usage e.g. in medical devices using the heap is forbidden. So you cant use the STL.

There is a promising embedded STL project, but it's not there yet: https://www.etlcpp.com

orbifold• 8 years ago

You can write modern C++ with no overhead on a system with just 16kB of scratchpad memory. It is much nicer to use than C (namespaces, auto, templates and lambdas alone).

snowAbstraction• 8 years ago

I would be really interested if you can shed a little light on the following related questions:

1. Do you see the bloat even if you don't use post C++11 features but compile using the C++17 standard?

2. Do you think it is mostly the compiler that is causing the bloat alone? Or is it stuff from the standard library header files that some how gets linked in (and are not used or needed by your software)?

bluGill3• 8 years ago

I haven't tried c++17 year, but c++98->c++11 did bring about code bloat. However even though we were building the same code base for two different systems, one without a C++11 compiler (thus we could not use c++11 features): it is incorrect to say we were not using C++11.

Just turning on C++11 in the compiler brings move to all standard library containers. The header files were not just "somehow" linked in and not used, the additional code was used in many places behind the scene. I haven't done benchmarks on my code, but the general report of those who have is that in exchange for the extra binary size the code runtime was 5% faster. For most people these days that expense is worth it.

cominous4• 8 years ago

1. Do you see the bloat even if you don't use post C++11 features but compile using the C++17 standard?

Yes, actually I tried using various C++ snippets and even reported that to the GCC compiler team. It happens with simple stuff like std::string and std::vector. The response was something like, that there really seems to be a bloat, but no performance impact and I guess most users outside of embedded don't care too much about the size of the compiled binary.

That's actually a very good question I cant give an answer to - meaning I haven't looked specifically into that.

As C++17 came to GCC I played with the compiler explorer and observed this by just switching gcc/clang version and -std flag. Actually, you can try it yourself: https://godbolt.org/

stochastic_monk3• 8 years ago

Which features do you see causing problems? If constexpr has been fantastic, and outside of that, I mostly benefit from broader metaprogramming power.

monocasa7• 8 years ago

Are you pulling in the standard library, or is this in just normal code?

w8rbt• 8 years ago

Good that you can specify -std=c++11 to prevent the bloat. The more recent 14 and 17 standards don't seem as groundbreaking and practical (both at the same time) as 11 was and, as you note, do seem to bring bloat.

dkersten4• 8 years ago

I use C++17 in my toy code (which is for a mixture of fun and learning modern C++, so...) and the main reasons (besides to learn) I use C++17 over C++11 is std::variant and (from C++14) make_unique. C++11 has a lot of compelling stuff but 14 and 17 seem to be relatively minor improvements over 11. It’s a pity they introduce bloat... definitely makes them much less compelling for use cases where it matters.

Nested namespace definitions and structured binding declarations are also nice.

ddtaylor• 8 years ago

Sanity check, does gcc support all of these?

jchb2• 8 years ago

Yes, but the final version of the C++17 standard was released as late as December 2017, so support may not be "production ready", neither in gcc nor in other compilers.

You can the summary of the gcc c++ standard support here: https://gcc.gnu.org/projects/cxx-status.html#cxx17. Full support for all features in the c++17 standard, but the support is declared "experimental".

Similarly here for clang: https://clang.llvm.org/cxx_status.html

And Visual studio: https://blogs.msdn.microsoft.com/vcblog/2018/04/26/announcin... (link to latest blog post, perhaps there is a status page that gets updated, but could not find it).

baking• 8 years ago

Maybe I'm missing something, but http://en.cppreference.com/w/cpp/compiler_support seems to have it all in one place.

how_gauche2• 8 years ago

Martin Moene (my favorite C++ person in the entire universe right now) wrote a drop-in replacement for older standard versions: https://github.com/martinmoene/string-view-lite. He's also backported optional, variant, and expected, and wrote my favorite unit testing library called "lest".

This guy saved me so much hassle this year and it's causing a complete sea change in the way that we work. I really really want to live in a world of value-typedness and it's finally possible to do it. The simple and natural idioms are now MORE efficient than doing it the complicated way: the average function I'm writing in 2018 is significantly less convoluted and allocates on the heap far less than the same function I'd be writing five or six years ago.

geokon• 8 years ago

Link for those that can't use Youtube: https://channel9.msdn.com/Events/Build/2018/BRK2146

(also has download links)

rehemiau• 8 years ago

Can I cheaply "pattern match" on variant type without involving exceptions or dynamic cast etc?

en4bz• 8 years ago

Variant uses a compile time jump table when you use std::visit afaik.

dkersten4• 8 years ago

It looks like it essentially uses function overloading (multiple overloads of operator()) to do it. Since function overloading compiles to a call of a single function, based on the argument types, this results in a single runtime call. Nice trick!

mellery451• 8 years ago

I think visit is what you want (http://en.cppreference.com/w/cpp/utility/variant/visit), unless I misunderstand what you mean by "pattern match"

ninkendo• 8 years ago

I used to keep pretty good track of what's been happening in c++, at least as C++11 was being formalized, and I've read a good fraction of Effective Modern C++, but...

I can't make heads or tails out of half of the code in that example. C++ has become extremely hard to grok.

I mean, take these two lines:

    template<class... Ts> struct overloaded : Ts... { using Ts::operator()...; };
    template<class... Ts> overloaded(Ts...) -> overloaded<Ts...>;

What's even going on there? Inheriting from a variadic list of classes? `using` a variadic list of parent functions, I guess? The second line looks like it's defining a constructor function for the overloaded() struct, but it's not implemented anywhere?

In the end there's magic code that looks like pattern matching, but I have no idea how they got there.

alexeiz6• 8 years ago

I just checked how many times I use explicit delete in my moderately sized 7K LOC C++ project: just once. In code that interfaces with an old library. Modern C++ is not only practical. It's easy.

thekingofh4• 8 years ago

You using smart pointers from C++11 or later?

alexeiz6• 8 years ago

Yes. But surprisingly not as often as I thought I would. Move semantics and guaranteed copy elision allows to avoid pointers in many common situations.

zengid2• 8 years ago

::Somewhat tangential anecdote and plea for advice::

I just finished my third semester of using C++ (with Data structures 1) and we use NO modern stuff in class [1]. Raw pointers. New and delete. No Lambdas (although we learned about function pointers, though not function objects). I completely understand why (we're learning low level stuff and it's worked for the last 30 years so whatever), but now I'm trying to ramp up and learn modern C++ for a personal project I'd like to start working on (basically an audio plugin using JUCE).

Here's what I've been doing to try and catch up (I have two weeks off before my internship starts). I try to watch Bjarne and Herb's keynotes but they often are speaking to an audience already familiar to modern C++, so this posts video is great! I've discovered the brilliance of Sean Parent, so I'm watching all of his talks. I've ordered Scott Meyers Effective Modern C++ (and hopefully he uses the money for a new haircut /s). I've browsed through the C++ Core Guidelines [2]. I'm reading the JUCE tutorials (and source code) which is beautifully written.

What are other good resources? I'm particularly interested in developing GUI's. I'd like to see some tutorials written like Herbs talk here: for people new to C++ and new to modern C++.

[1] This is our textbook: https://www.amazon.com/Programming-Program-Design-Including-...

[2] http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#...

sacado2• 8 years ago

I completely understand why (we're learning low level stuff and it's worked for the last 30 years so whatever)

Are you sure it's not just because your teachers are not (enough) aware of those new features ? Because I work in a University and know way too many colleagues that still use new/delete on a daily basis.

zengid2• 8 years ago

I believe you are correct, but even the textbook ignores the new stuff except for nullptr and briefly mentioning range based for loops.

The professor who taught my Data Structures class (who is an exceptionally great teacher BTW) actually uses C in most of his own work, so we even learned a little bit about how to simulate recursive calls using a void* stack and goto. I hope my peers don't go out and write code like that in the wild, but that's another story..

monocasa7• 8 years ago

Effective Modern C++ is a great book designed for "I learned pre C++11, but now I want to get with the times, and specifically want to know the idiomatic ways to apply it".

TomVDB2• 8 years ago

Is Effective Modern C++ good enough for those who learned C++ in the early 2000, still use those idioms and never upgraded to C++11 ?

dkersten4• 8 years ago

Thanks for the recommendation! I’ve wanted to improve my C++11 and beyond knowledge. Just picked it up on kindle and started reading, really insightful so far.

bluGill3• 8 years ago

Herb and Bjarne's keynotes from 2011. They are always pushing what is new and exciting, while the rest of us are just catching up.

Don't forget the other information that you can get from speakers who are not as good. New and shiny is often easy to abuse simply because nobody is sure if it is a good idea or not. Not everything stands the test of time. Other things are great and critical in their niche but create an awful mess when abused to apply elsewhere.

blub2• 8 years ago

Bancila's Modern C++ Programming Cookbook is surprisingly good. There's also a video by Vittorio Romeo called "Mastering C++ Standard Library Features". Both of those are from Packt, which have a pretty poor reputation, but don't let that hold you back in this case.

Josuttis' The C++ Standard Library is the classic reference.

proverbialbunny2• 8 years ago

The largest change is ownership semantics. If you can learn or have learned ownership semantics in such a way that ties that abstract concept to concrete real life examples, most of your work will be done.

Modern day C++ has two ways to do most of the things you want to do: The C way, and the C++ way. eg, c array[] vs std::array<>, or char* vs std::string and the like. However, original C++ without C is still there and not updated. Eg, inheritance is a C++98 feature, not a C feature, so there is only one way to do inheritance for the most part.

It takes little time to identify what features are C features and what features are C++ features. From there you'll know when to look up alternatives and when not to, giving you an easy upgrade map.

Also, some C features are more powerful, so it is a matter of choosing the right tool for the job. For example, looping through a data structure and adding elements. Doing so invalidates iterators, but works will with an index, so it might be ideal to use the old C way in situations like that. This also adds explicitness to code. If you're working in a modern code base and in the rare spots where the C way is done, you can get an idea why and from that what the code is doing without having to read all of it. This makes reading code easier once both C and modern C++ have been learned.

wpdev_63• 8 years ago

People who are looking for a modern C++ should take a serious look at Rust. It has all the things you want in modern C++ while getting rid of the cruft of the language.

krona• 8 years ago

It has all the things you want in modern C++

Variadic templates?

TillE• 8 years ago

Rust doesn't even have default arguments, a feature of C++ since forever. I've written actual code in both languages, and I still find C++ much more usable.

con22• 8 years ago

Rust is your silver bullet?

pjmlp7• 8 years ago

I do like playing with Rust, but it still does miss a few things from C++.

First of all, cargo does not understand binary dependencies, compiles everything from source.

Second, my only use case for C++ is for native code when integrating system code with Java, .NET, UWP, Swift, Objective-C.

Third, my C++ code can also be used on the GPGPU, with nice debugging tools from all vendors.

There Rust misses the integrated workflow and IDE debugging experience that I have with C++ on those environments.

No doubt Rust will get there, by then I would gladly use it as well, but it still needs to mature a bit more.

Today's Rust release also had many goodies.

alexeiz6• 8 years ago

I'd love to. But seeing how Rust adopters struggle with something as trivial as a linked list (https://news.ycombinator.com/item?id=16442743), doesn't inspire me.

kllrnohj• 8 years ago

On the other hand should it be trivial to implement a linked list? They are an extremely bad data structure for modern CPUs, after all.

Worth noting that it's doubly linked lists specifically that are hard. So cyclic structures.

Retra• 8 years ago

Linked lists are easy. People are struggling with safe linked lists, because they think they should be as easy to write as an unsafe ones.

But if you're already willing to use C or C++, you've got no reason to avoid unsafe.

nebgnahz• 8 years ago

I have struggled in the past to learn modern C++. I think the language is pretty cool, but couldn't find good guide in learning about them.

Having used Rust for a year or so, now I look back at these features and they seem quite natural. I have to say the documentations and tutorials from Rust community is great. It might be a detour, but now I feel much more comfortable reading modern C++ blogs and watch this video!

partycoder• 8 years ago

I think it would be good to break backwards compatibility and start off clean with what we know now in the form of a new language.

How to Adopt Modern C++17 into Your C++ Code [video]

Related Stories