Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

youtube.com

Post reply on HN
Print view View original

11–20 of 124 posts

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

#11

Post by humanrebar »

pdpi wrote: post #7
saagarjha wrote: post #2

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…

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…

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

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

#12

Post by pjmlp »

humanrebar wrote: post #10
pjmlp wrote: post #5

Earlier quoted context omitted.

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.

Yes you are right, my mistake.

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

#13

Post by tzahola »

humanrebar wrote: post #9
masklinn wrote: post #6

Earlier quoted context omitted.

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

You mean int*, right?

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

#14

Post by svalorzen »

masklinn wrote: post #6
saagarjha wrote: post #2

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…

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

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

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.

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

#15

Post by humanrebar »

tzahola wrote: post #13
humanrebar wrote: post #9

Earlier quoted context omitted.

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

You mean int*, right?

Yes. Fixed! Thanks.

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

#16

Post by cominous »

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.

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

#17

Post by dvfjsdhgfv »

cominous wrote: post #16

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++…

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

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

#18

Post by criddell »

pdpi wrote: post #7
saagarjha wrote: post #2

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…

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…

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.

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

#19

Post by pjmlp »

dvfjsdhgfv wrote: post #17
cominous wrote: post #16

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++…

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

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.

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

#20

Post by snowAbstraction »

cominous wrote: post #16

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++…

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)?

Post reply on HN