2

In his cpp con 2019 talk, Chandler Carruth argues that c++ std::unique_ptr is not a truly zero cost (runtime) abstraction: https://www.youtube.com/watch?v=rHIkrotSwcc&t=6s.

I work on an embedded system with a team which refuses to use smart pointers, even std::unique_ptr. The argument made against smart pointers by senior engineers is one about a supposedly inherent runtime overhead.

Despite claiming at cpp con 2019 that std::unique_ptr is not zero cost, Chandler Carruth still insists that it is better to use std::unique_ptr than raw pointers. As Chandler works on a server core, is there some qualification specific to embedded systems which would make Chandler's argument inapplicable to embedded development? Especially in a real time environment (RTOS), are raw pointers necessary?

I can't think of or find a qualification about embedded systems which could qualify anything claimed by Chandler at cpp 2019. Every resources I've consulted over the last few days advises use of smart pointers in embedded development.

bhishma at Kurukshetra
  • 21
  • 3
  • 2
    There's a google benchmark referenced here: https://libcxx.llvm.org/DesignDocs/UniquePtrTrivialAbi.html#performance-impact – Artyer Jun 23 '23 at 16:20
  • 2
    If there is a performance issue with a `unique_ptr`, you could fish out the raw pointer and use the raw pointer directly in a small scope for maximum performance. **Profiling** is key to determine if such extra instrumentation (which makes the code a bit messier and harder to maintain) is worth the trade off. – Eljay Jun 23 '23 at 16:22
  • 4
    What is the performance cost of running out of memory and crashing because allocated objects aren't getting deleted? – Pete Becker Jun 23 '23 at 16:47
  • 3
    On embedded it is probably not the smart pointers that are the problem, but the dynamic memory allocation by itself. In the end the tradeof between smartpointers vs. raw pointers (assuming dynamic memory allocation) should be "no memory leaks" vas. a proven (necessary) performance gain. – Pepijn Kramer Jun 23 '23 at 17:02
  • 2
    In an RTOS I would use resource managment by desing. So budget pieces of memory and reserve them for certain data. Dynamic memory allocation comes with indeterministic behavior up to a point (fragmentation/out of memory, allocation time) etc. In all other cases keep it simpel, use the standard library until you have a proven performance problem. – Pepijn Kramer Jun 23 '23 at 17:05
  • Without watching the video, if the author explains the "cost" surely you can extrapolate to whether that is an issue on your particular project? NASA is an organisation, not a software system. I am sure they have all kinds of embedded systems. They do have a coding standard https://nasa.github.io/fprime/UsersGuide/dev/code-style.html, for flight software that precludes the use of templates, and therefore `std::unique_ptr`. – Clifford Jun 24 '23 at 09:14
  • 1
    You would never use dynamic memory allocation in a hard real-time system anyway. As for what I remember from the so-called NASA coding standard, I believe it was written by some Ziggy Stardust character... but even the naive NASA rules ban dynamic allocation. See [this](https://stackoverflow.com/questions/66402881/safe-coding-practices) for example. – Lundin Jun 26 '23 at 14:27

1 Answers1

1

"Performance" needs qualification. In real-time systems, the critical aspect is determinism. If std::unique_ptr operations have deterministic (constant time) behaviour, then safety trumps raw speed. Thread safety and atomicity might be a consideration. The means of achieving that may cause non-deterministic behaviour.

The use of std::unique_ptr however suggests the use of dynamic memory, and the invocation of destructors whenever the pointer goes out if scope, and that is itself non-deterministic and not advised in many real-time and/or safety-critical systems.

I would suggest that if your project accepts dynamic object instantiation from heap (rather than placement-new, or some other deterministic solution), then the use of std::unique_ptr would be a mitigation of memory leak issues that then arise therefrom, but not issues of determinism or thread safety.

Of course you can define a custom deleter, and if using placement-new, then that could ensure that object destructors are called automatically on the pointer going out of scope.

Clifford
  • 88,407
  • 13
  • 85
  • 165