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

111–120 of 124 posts

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

#111

Post by saagarjha »

masklinn wrote: post #6
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…

> 3. The std::optional example looked really clunky, relying on checking an exception. I see there are a bunch of nice operators and utility functions on std::optional that cover some use cases, like coalescing, but will we get something that allows for optional chaining? Nope. It must be understood that std::optional is not an Option type, its purpose is not to have a way to express "missing" items in a type-safe ma…

> It must be understood that std::optional is not an Option type, its purpose is not to have a way to express "missing" items in a type-safe manner but rather to have pointer-type semantics without needing to heap-allocate.

I don't understand what you mean here. I don't have to heap-allocate to get a pointer to something; I can just take the address of something on the stack…

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

#112

Post by pjmlp »

baking wrote: post #45
jchb wrote: post #33

Earlier quoted context omitted.

Yes, but the final version of the C++17 standard was released as late as December 2017, so support may not be "production ready", neither in gcc nor in other compilers. You can the summary of the gcc c++ standard support here: https://gcc.gnu.org/projects/cxx-status.html#cxx17 . Full support for all features in the c++17 standard, but the support is declared "experimental". Similarly here for clang: https://clang.llv…

Maybe I'm missing something, but http://en.cppreference.com/w/cpp/compiler_support seems to have it all in one place.

It misses most of the compilers on the embedded space.

For example, TI still has some compilers stuck on C++98 and C++03.

http://processors.wiki.ti.com/index.php/TI_Compilers_and_Ind...

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

#113

Post by thekingofh »

alexeiz wrote: post #92
thekingofh wrote: post #80

Earlier quoted context omitted.

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…

Ah I'm following now. Transfer of stack references in cases where it's unnecessary to share objects. Actually interesting that it raises the bar for the need to allocate on the stack.

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

#114

Post by conradev »

cominous wrote: post #35
snowAbstraction wrote: post #20

Earlier quoted context omitted.

I would be really interested if you can shed a little light on the following related questions: 1. Do you see the bloat even if you don't use post C++11 features but compile using the C++17 standard? 2. Do you think it is mostly the compiler that is causing the bloat alone? Or is it stuff from the standard library header files that some how gets linked in (and are not used or needed by your software)?

1. Do you see the bloat even if you don't use post C++11 features but compile using the C++17 standard? Yes, actually I tried using various C++ snippets and even reported that to the GCC compiler team. It happens with simple stuff like std::string and std::vector. The response was something like, that there really seems to be a bloat, but no performance impact and I guess most users outside of embedded don't care too…

To answer #2, you can try enabling LTO and see if that helps with binary size

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

#115

Post by alexhutcheson »

saagarjha wrote: post #109
alexhutcheson wrote: post #64

Earlier quoted context omitted.

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.

Is there a way to do this without involving the overhead of a full copy, though?

Not that I'm aware of - a const std::string& parameter needs to be a reference to a std::string object, and there's no guarantee that a given string_view object is pointing to a std::string.

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

#116

Post by Retra »

alexeiz wrote: post #101
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.

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.

Linked lists are easy. People are struggling with safe linked lists, because they think they should be as easy to write as an unsafe ones.

But if you're already willing to use C or C++, you've got no reason to avoid unsafe.

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

#117

Post by gowld »

AnimalMuppet wrote: post #72
Const-me wrote: post #52

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.

Arenas/Pools/Planks have been industry best-practice for my entire career.

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

#118

Post by gpderetta »

msla wrote: post #105
alexeiz wrote: post #88

Earlier quoted context omitted.

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

In modern systems with caches and a typical penalty for going out to RAM, is it still possible for larger code to be faster?

Yes. Caches actually work. And work quite well for code. Of course there are pathological cases.

Also, static size does not mean anything. The only thing that matter is the dynamic size (i.e. the instructions that are actually fetched at runtime: code that isn't run or run rarely doesn't matter (then again, such code is a prime candidate to be compiled with -Os).

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

#119

Post by gpderetta »

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…

Also, STL is data structures + algorithms. Even if you can't use the datastructures out of the box you might be able to use the algos. Boost.Intrusive provides STL compatibe datastructures with full control of allocation (and more).

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

#120

Post by gpderetta »

monocasa wrote: post #93
zengid wrote: post #61

Earlier quoted context omitted.

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.

well, if you have to implement a non tail-recursive function and want to have control of the max recursion depth (i.e. not get killed because you have exhausted the stack) it is an option.
Post reply on HN