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

61–70 of 124 posts

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

#61

Post by zengid »

sacado2 wrote: post #59
zengid wrote: 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…

> 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 that in the wild, but that's another story..

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

#62

Post by TomVDB »

monocasa wrote: post #60
zengid wrote: 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".

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 ?

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

#63

Post by bluGill »

zengid wrote: 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…

Herb and Bjarne's keynotes from 2011. They are always pushing what is new and exciting, while the rest of us are just catching up.

Don't forget the other information that you can get from speakers who are not as good. New and shiny is often easy to abuse simply because nobody is sure if it is a good idea or not. Not everything stands the test of time. Other things are great and critical in their niche but create an awful mess when abused to apply elsewhere.

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

#64

Post by alexhutcheson »

humanrebar wrote: post #11
pdpi wrote: post #7

Earlier quoted context omitted.

std::string_view is, as the name implies, a view into a std::string. If you own the actual string, use std::string — there is no other string for you to view. If somebody else owns it and you're working on the whole string `const std::string&` is probably your best bet — you're holding a reference to the string as a whole — but std::string_view also works and might make more sense in context. If you're working with a…

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

#65

Post by [deleted] »

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…

[deleted]

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

#66

Post by monocasa »

TomVDB wrote: post #62
monocasa wrote: post #60

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

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

#67

Post by paulirwin »

cominous wrote: post #38
dvfjsdhgfv wrote: post #17

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…

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 of issues Herb raises in the OP video, could reduce the risk to an acceptable level?

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

#70

Post by monocasa »

orbifold wrote: post #42
dvfjsdhgfv wrote: post #17

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.

You can write modern C++ with no overhead on a system with just 16kB of scratchpad memory. It is much nicer to use than C (namespaces, auto, templates and lambdas alone).

And RAII! That's so nice in an RTOS. Never again forget to drop priorities or reenable interrupts just because you went down a not as well trodden failure path. You can even return the lock_guard, and the caller can continue to do work in the same atomically locked context, but if they choose not to, they just drop the return value and everything works as expected.
Post reply on HN