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

71–80 of 124 posts

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

#71

Post by pjmlp »

abiox wrote: post #55
pjmlp wrote: post #19

Earlier quoted context omitted.

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.

> religion against C++ possibly. but given the how often i've seen c++ users treat c users like idiot savages or heathens that need conversion ("have you heard the good word of our lord and savior, c++?"), i could understand a negative sentiment.

Maybe if C developers wouldn't be ignoring Lint since 1979, and better type systems, we would be having better conversations.

"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions."

Dennis M. Ritchie -- https://www.bell-labs.com/usr/dmr/www/chist.html

I would like the stack underlying my computing needs not to look like a Swiss cheese.

And yes, C++ is also not the ultimate solution for that as it is tainted by its C compatibility.

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

#72

Post by AnimalMuppet »

Const-me wrote: post #52
cominous wrote: post #38

Earlier quoted context omitted.

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…

> So you cant use the STL. std::array is in there since C++ 11 and it doesn’t use heap. And/or you can use STL with custom allocators that work without heap. We did something similar developing for Nintendo Wii console. There was a heap but we didn’t want to use it to avoid memory fragmentation. AFAIR we used two arenas (essentially stacks), one very small for temporary data cleaned up at the start of each frame, and…

The problem for medical devices isn't so much whether custom allocators will work. The problem is whether the FDA will freak out because you're not following industry-best-practice coding guidelines.

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

#73

Post by TomVDB »

monocasa wrote: post #66
TomVDB wrote: post #62

Earlier quoted context omitted.

Is Effective Modern C++ good enough for those who learned C++ in the early 2000, still use those idioms and never upgraded to C++11 ?

I'm not quite sure what you're asking. Is it a useful book if you plan on keeping a C++03/C++98 codebase? Probably not, Effective C++ is the better book for that world. Is it a useful book for migrating from premodern to modern C++, even iteratively? I'd say yes, that's one of the book's explicit design goals.

The second part: I want to bring my practical C++ knowledge up to date and I don't know C++ 11.

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

#74

Post by TillE »

wpdev_63 wrote: post #68

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.

Rust doesn't even have default arguments, a feature of C++ since forever. I've written actual code in both languages, and I still find C++ much more usable.

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

#75

Post by stephanimal »

paulirwin wrote: post #67
cominous wrote: post #38

Earlier quoted context omitted.

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…

Out of curiosity, what is the rationale for not using the heap with medical devices? Resource constraints are one thing but that is not limited to medical nor is that entirely solved with preventing heap use. If it's for runtime safety to avoid raw pointers, has anyone done an analysis to determine if smart pointers (unique_ptr, shared_ptr), combined with diligent static code analysis diagnostics to avoid the kinds o…

I have not worked in medical (my experience is in games) but my best guess is its more about reliability and predictability. Using a heap suffers from the fact that you can run out of memory to satisfy a malloc/new request (either due to system memory limit or due to fragmentation).

With static memory techniques you can "prove" the system has enough memory to work in all modes, i.e. device consumes 20 readings per second, keeps them in a ring buffer backed by a static fixed array, that buffer is large enough to satisfy processing rate.

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

#76

Post by proverbialbunny »

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…

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.

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

#77

Post by vvanders »

alexeiz wrote: post #51
thekingofh wrote: post #46

Earlier quoted context omitted.

You using smart pointers from C++11 or later?

Yes. But surprisingly not as often as I thought I would. Move semantics and guaranteed copy elision allows to avoid pointers in many common situations.

It's also better in that you can avoid cycle-leaking from your smart pointers.

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

#79

Post by nebgnahz »

I have struggled in the past to learn modern C++. I think the language is pretty cool, but couldn't find good guide in learning about them.

Having used Rust for a year or so, now I look back at these features and they seem quite natural. I have to say the documentations and tutorials from Rust community is great. It might be a detour, but now I feel much more comfortable reading modern C++ blogs and watch this video!

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

#80

Post by thekingofh »

vvanders wrote: post #77
alexeiz wrote: post #51

Earlier quoted context omitted.

Yes. But surprisingly not as often as I thought I would. Move semantics and guaranteed copy elision allows to avoid pointers in many common situations.

It's also better in that you can avoid cycle-leaking from your smart pointers.

I'm still having trouble seeing how move semantics and copy elision help me get rid of smart pointers. I read up on it after reading these comments and just still am not following. I see how move semantics avoid a copy, but if I'm dealing with cases where multiple objects need to use or hold a reference to the same object, how can move semantics help me do this? Seems good for ensuring only one object contains the reference.
Post reply on HN