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

31–40 of 124 posts

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

#31

Post by humanrebar »

masklinn wrote: post #23
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*`.

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

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.

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.

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

#32

Post by bluGill »

snowAbstraction wrote: post #20
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)?

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.

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

#33

Post by jchb »

ddtaylor wrote: post #25

Sanity check, does gcc support all of these?

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

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

#34

Post by alexhutcheson »

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…

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

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

#35

Post by cominous »

snowAbstraction wrote: post #20
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)?

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.

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

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/

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

#37

Post by how_gauche »

stochastic_monk wrote: post #27
humanrebar wrote: post #11

Earlier quoted context omitted.

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

Under the hood it's just "std::pair, 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.

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

#38

Post by cominous »

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.

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

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

#39

Post by jchb »

cominous wrote: post #35
snowAbstraction wrote: post #20

Earlier quoted context omitted.

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

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…

Did you try with optimisations enabled? Here is a (trivial) program comparing gcc output between -std=c++14 and -std=c++17: https://godbolt.org/g/VLDhYf. Note that the output code size with -std=c++17 is significantly larger without optimisations (default), but it is identical with optimisations turned on!

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

#40

Post by how_gauche »

ddtaylor wrote: post #25

Sanity check, does gcc support all of these?

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.

Post reply on HN