Live data from Hacker News

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

youtube.com

81–90 of 124 posts

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

#81
post #57

::Somewhat tangential anecdote and plea for advice:: I just finished my third semester of using C++ (with Data structures 1) and we use NO modern stuff in class [1]. Raw pointers. New and delete. No Lambdas (although we learned about function pointers, though not function objects). I completely understand why (we're learning low level stuff and it's worked for the last 30 years so whatever), but now I'm trying to ram…

Bancila's Modern C++ Programming Cookbook is surprisingly good. There's also a video by Vittorio Romeo called "Mastering C++ Standard Library Features". Both of those are from Packt, which have a pretty poor reputation, but don't let that hold you back in this case.

Josuttis' The C++ Standard Library is the classic reference.

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

#82

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…

Safety critical software (or even mission critical software) should not be using dynamic allocation for a few reasons.

- Fragmentation.

- Non-deterministic runtime (in the real-time cases).

- Insufficient analysis of worst-case conditions (i.e. you haven't worked out what your worst case RAM usage is, otherwise you would have statically allocated it).

IMO, the worst is the final case as it shows a lack of thoroughness in the design as a whole and brings the rest of the code into suspicion. Fragmentation can be worked around, but not the others.

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

#83
post #62

Earlier quoted context omitted.

Effective Modern C++ is a great book designed for "I learned pre C++11, but now I want to get with the times, and specifically want to know the idiomatic ways to apply it".

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'd recommend Bancila's Modern C++ Cookbook instead, it takes you through the new features and explains how to use them.

Effective Modern C++ is part language tutorial, part series of tips, part philosophical discussion on how one should use various features. It's not appropriate as an intro to modern C++.

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

#84
post #83
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'd recommend Bancila's Modern C++ Cookbook instead, it takes you through the new features and explains how to use them. Effective Modern C++ is part language tutorial, part series of tips, part philosophical discussion on how one should use various features. It's not appropriate as an intro to modern C++.

> Effective Modern C++ is part language tutorial, part series of tips, part philosophical discussion on how one should use various features. It's not appropriate as an intro to modern C++.

See, I take the opposite stance. There's enough moving parts here that it's nice to get some background into what's actually happening, and then read more cookbook style stuff when you understand the underlying context.

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

#85

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…

When I was using C++ for embedded, which is admittedly over 15 years ago, I had to switch off RTTI and exception handling to get compact binaries. Basically just using classes and surface language features. We did use templates but only very selectively. Is it still possible today to pare down the compiler output like that? I imagine a lot of modern C++ just doesn't work unless everything is enabled.

Yes it is possible.

Check this talk about fitting C++17 on a C64.

CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”

https://www.youtube.com/watch?v=zBkNBP00wJE

Also be aware that embedded devices like Arduino and Cortex-M (with Mbed OS) do use C++ toolchains.

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

#86

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 do like playing with Rust, but it still does miss a few things from C++.

First of all, cargo does not understand binary dependencies, compiles everything from source.

Second, my only use case for C++ is for native code when integrating system code with Java, .NET, UWP, Swift, Objective-C.

Third, my C++ code can also be used on the GPGPU, with nice debugging tools from all vendors.

There Rust misses the integrated workflow and IDE debugging experience that I have with C++ on those environments.

No doubt Rust will get there, by then I would gladly use it as well, but it still needs to mature a bit more.

Today's Rust release also had many goodies.

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

#87

Earlier quoted context omitted.

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

You're overstating a bit but there's a kernel of truth. However, it depends on your viewpoint. If you have a functional codebase in C and size is an important factor you may be reluctant to trade up. Bloat avoidance is not trivial, in my opinion. Performance is probably less of a factor, most of the additional functionality generated by the C++ compiler has to be written by the C coder in the end.

> If you have a functional codebase in C

Rewriting something that already works would be silly of course.

> and size is an important factor you may be reluctant to trade up. Bloat avoidance is not trivial, in my opinion

I don't agree with this in comparison to C. C is still there, but you have destructors and ownership semantics on top of it. Even templates can be used for things like type checking in debug builds.

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

#88
post #39

Earlier quoted context omitted.

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!

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]

#89

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

I think visit is what you want ( http://en.cppreference.com/w/cpp/utility/variant/visit ), unless I misunderstand what you mean by "pattern match"

I used to keep pretty good track of what's been happening in c++, at least as C++11 was being formalized, and I've read a good fraction of Effective Modern C++, but...

I can't make heads or tails out of half of the code in that example. C++ has become extremely hard to grok.

I mean, take these two lines:

    template struct overloaded : Ts... { using Ts::operator()...; };
    template overloaded(Ts...) -> overloaded;
What's even going on there? Inheriting from a variadic list of classes? `using` a variadic list of parent functions, I guess? The second line looks like it's defining a constructor function for the overloaded() struct, but it's not implemented anywhere?

In the end there's magic code that looks like pattern matching, but I have no idea how they got there.

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

#90

Earlier quoted context omitted.

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

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 standard, just like T, U, and V do" it's a simpler argument than "we do this like Y. Lots of people do X, but here is how we have demonstrated Y is better for us...". But this can be fine too, just possibly more work.

Also worth noting (a) there is no industry-wide best practices agreement (b) there is no FDA wide agreement on what should be done (different device types are reviewed by different panels (c) the FDA doesn't understand software development deeply across it's panels, but it is catching up.

Post reply on HN