Live data from Hacker News

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

youtube.com

101–110 of 124 posts

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

#101

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.

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.

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

#102
post #47

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

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

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!

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

#103

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.

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

Shameless plug: At EA we've open-sourced our C++ standard library implementation that focuses on games. While it's not necessarily focused on embedded development, you might be interested in checking it out - it provides a number of fixed_* containers (fixed_vector, fixed_set, etc) which can be configured to use stack allocations only, among some other things you might find interesting :)

https://github.com/electronicarts/EASTL

(In case it wasn't obvious, disclaimer: I work at EA, and frequently do work on EASTL, though I'm not the primary maintainer.)

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

#104
post #100

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

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.

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.

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

#105
post #88

Earlier quoted context omitted.

I used -Os as for any embedded code where I don't care too much about the performance and rather need a compact binary. I would love to post my code snippets from back then, but Im not home currently and the time Im back home I guess nobody will care about this anymore :D. Maybe I put it into an article.

-Os is pretty much useless. For comparison, I compiled my (reasonably sized) project with -Os and got a 12MB statically linked binary. But with -O3, the binary size is only 4.2MB. Not only -O3 produces faster code but it's also smaller.

In modern systems with caches and a typical penalty for going out to RAM, is it still possible for larger code to be faster?

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

#106

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.

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.

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.

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

#107
post #90

Earlier quoted context omitted.

That's really not how it works. The FDA is fundamentally concerned about two things, safety and efficacy. You need a plan to demonstrate the latter, and you need your quality system, SDP, etc. to demonstrate how you approach the former. This is about good engineering practices, not particular implementation techniques. So you can do things many different ways. If you do say "we do this like X, which is industry stand…

Sure, that's all true. I'm looking at the "simpler argument" part. It's especially true if you're saying "This new device is just like our previous device, with these few small changes". (I forget what that's called, but you can do a lot less paperwork if that's true.) But if you start doing memory allocations where you never did before, they're probably going to want to apply higher scrutiny to your entire software.…

You are possibly thinking about note-to-file (which isn’t quite the process any more, but similar)

But it is worth pointing out, FDA (or other national body) isn’t doing code reviews. They are mostly interested in process , and how you follow it. The place where this really interacts s is hazard analysis, and then it’s just up to you to demonstrate your checks and balances.

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

#108

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…

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

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

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

#109

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…

This is true as long as your implementation doesn't call any functions that take a `const string&`. If you need to call such a function, then you first have to make a copy of your string_view into a new string object before you call it.

Is there a way to do this without involving the overhead of a full copy, though?

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

#110

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…

For 3, std::optional has the has_value() method. std::optional 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.

I'm look for something like Swift's optional chaining, á la:

  std::optional a = foo();
  auto size = a?.size() // size is a std::optional
Post reply on HN