Live data from Hacker News

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

youtube.com

91–100 of 124 posts

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

#91
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…

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

Thanks for the recommendation! I’ve wanted to improve my C++11 and beyond knowledge. Just picked it up on kindle and started reading, really insightful so far.

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

#92

Earlier quoted context omitted.

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

Notice that I didn't say all cases. Just the most common ones. When you require shared ownership of an object, of course, you'd use an appropriate smart pointer (shared_ptr). But shared ownership is not very common (well, at least in the systems that I design). However before C++11/14, you had to use pointers and heap allocated objects in cases that have nothing to do with shared ownership because passing objects by value would incur a substantial overhead. Now that we have move, copy elision and library classes like std::optional (which I forgot to mention earlier) it's not the case any more.

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

#93
post #61
post #59

Earlier quoted context omitted.

> I completely understand why (we're learning low level stuff and it's worked for the last 30 years so whatever) Are you sure it's not just because your teachers are not (enough) aware of those new features ? Because I work in a University and know way too many colleagues that still use new/delete on a daily basis.

I believe you are correct, but even the textbook ignores the new stuff except for nullptr and briefly mentioning range based for loops. The professor who taught my Data Structures class (who is an exceptionally great teacher BTW) actually uses C in most of his own work, so we even learned a little bit about how to simulate recursive calls using a void* stack and goto. I hope my peers don't go out and write code like…

FWIW, I used to be the lead of a C++14 RTOS. You can be low level and still use a lot fo these techniques.

And that void*/goto hack sounds bad, even in C land. That's basically only acceptable in a byte code interpreter.

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

#94

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…

   Out of curiosity, what is the rationale for not using the heap with medical devices?
Avoiding heap allocation is not at all a general constraint for medical devices. For certain types of components (think safety-critical real-time sub systems, for example) they are going to be very interested in your hazard analysis and the mitigating approaches to possible issues.

So if there is a way to say: we don't have to worry about [class of error X] because we don't ever do Y, that's a straightforward way to sort out those components. If you have a compelling tech reason to do Y, better start thinking about all the controls you'll put on it.

Think about it this way: What's the worse thing that can happen if your code causes an OOM error? If the answer includes things like "somebody dies if it happens at the wrong time", you'll want to be really careful to prove (prove, not just test out) that can't happen.

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

#95
post #90

Earlier quoted context omitted.

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 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. That's... painful.

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

#96

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

Are you pulling in the standard library, or is this in just normal code?

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

#97

Earlier quoted context omitted.

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…

The key here is that a parameter pack T... can be actually unpack into expressions, for example:

    template
        void g(Args... args) {
            f(const_cast(&args)...); 
     // const_cast(&args) is the pattern, it expands two packs
     // (Args and args) simultaneously
     
            f(h(args...) + args...); // Nested pack expansion:
       // inner pack expansion is "args...", it is expanded first
       // outer pack expansion is h(E1, E2, E3) + args..., it is expanded
       // second (as h(E1,E2,E3) + E1, h(E1,E2,E3) + E2, h(E1,E2,E3) + E3)
    }
Taken from: http://en.cppreference.com/w/cpp/language/parameter_pack

So for

    template struct overloaded : Ts... { using Ts::operator()...; }
if you used this like

    overloaded foo;
it would expand to

    struct overloaded : X, Y, Z {
        using X::operator(), Y::operator(), Z::operator();
    } foo;
EDIT: Removed stuff about the function since I was only guessing and Alexeiz answered it. The only thing I’ll add is that you can construct structs like this:

    struct Foo { int x; float y; };
    Foo foo {1, 2.3};
overloaded is constructed from the three lambdas in the same way. I guess the deduction guide is needed because the compiler cannot deduce the template parameters from that initializer form, so the deduction guide tells it to use the types of the lambdas for the types of the template parameters.

More information on deduction guides: http://en.cppreference.com/w/cpp/language/class_template_arg... (specifically, look for “Class template argument deduction of aggregates typically requires deduction guide” in the notes section for an example very like the overloaded one)

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

#99

Earlier quoted context omitted.

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…

> What's even going on there?

The first line defines 'struct overloaded' derived from all of its template parameters. Template parameters are supposed to be functors (lambdas), so we use their operator()'s in 'overloaded'.

The second line defines a template deduction guide for the 'overloaded' constructor, which says: take types from the constructor arguments and use them as the class template parameters.

The idea is to be able to construct 'overloaded' like this:

    overloaded{[](ArgT1 arg){/*lambda1*/},
               [](ArgT2 arg){/*lambda2*/}, ...};

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

#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.
Post reply on HN