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.
How to Adopt Modern C++17 into Your C++ Code [video]
101–110 of 124 posts
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#102Can 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.
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#103Earlier 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…
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]
#104C++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.
Nested namespace definitions and structured binding declarations are also nice.
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#105Earlier 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.
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#106People 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.
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]
#107Earlier 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.…
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]
#108Great 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…
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#109Earlier 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.
Re: How to Adopt Modern C++17 into Your C++ Code [video]
#110Great 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.
std::optional a = foo();
auto size = a?.size() // size is a std::optional