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

21–30 of 124 posts

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

#21

Post by jack_pp »

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.

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

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

#22

Post by masklinn »

svalorzen wrote: post #14
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…

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.

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

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

#23

Post by masklinn »

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

> Except that's exactly why you would take an `optional` 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.

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

#24

Post by CyberDildonics »

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.

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.

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

#26

Post by stochastic_monk »

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

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

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

#27

Post by stochastic_monk »

humanrebar wrote: post #11
pdpi wrote: post #7

Earlier quoted context omitted.

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…

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?

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

#28

Post by stochastic_monk »

jcelerier wrote: post #4
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…

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.

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

#30

Post by kdickens »

jack_pp wrote: post #21
dvfjsdhgfv wrote: post #17

Earlier quoted context omitted.

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

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

If a new feature does not play well with an entrenched object hierarchy, one can as well do a rewrite. This has happened at a shop where I worked and the rewrite was in C, which turned out to have a faster development time and the result was more flexible.

Now, I'm aware that you can restrict yourself to "almost C" in C++, but no one ever seems to be doing that. A litte str::string here, a tiny std::vector there, so exceptions are already in, so why not go all the way.

Post reply on HN