Hacker News Reader

Comment by Taniwha | Hacker News Reader

exactly - it's that "system level" kernel point of view that's important - I write a lot of embedded/real time/kernel code and essentially the thing you have to avoid is "new" which is sort of the heart of the language ....

Why new? because you don't have a heap in the kernel, or practically on a system with 20k or ram, new is also bad in real time code because underneath it is malloc and (like printf/stdio) all the mutexes that protect code that is messing with the heap structure .... and that way lies priority inversions and heisenbugs and other dark beasties ...

(for a lot of real time code new is great at the beginning of time, but not on the fly while the world is running)

View on HN

The Linux kernel absolutely does have a heap, most memory the kernel deals with is kmalloced.

As for small memory systems, even MISRA and the NASA guidelines say no memory allocation after initialization; having a bump pointer heap is very nice. Global operator new overrides are really nice in embedded systems too, I had one for the RTOS I worked on that let you specify memory region, alignment, etc and it worked by default for allocating any C++ object for free. Obvs you have to leave code behind that new's after initialization, or frees, but that's nothing new to small systems.

yes but it's explicit, you have call special kernel routines and manage the memory yourself, it's not hidden in some library somewhere causing 500 new/deletes outside of your knowledge .... I've certainly met programmers in the past who have not internalised that new/malloc are a couple of orders of magnitude more expensive than other language primitives like + .... and had to show them how to profile .... and discover that 90% of the time our large multithreaded app was spending was in malloc .... inside their bespoke strings package .... and that statically allocated strings on the stack and strncpy were perfectly good for 90% of what they were doing with strings and didn't spend any time at all time in low level heap mutexes

I mean, the C standard library internally mallocs a bunch too, which is (one of many reasons) why the kernel has it's own modified version of a subset of the C library. If it were written in C++ the same rules would apply. When I was the lead for a C++14 RTOS that was MISRA compliant I had to write a custom collections library that's much more explicit. It's not that hard.

You can overload operator new to not use the heap. You can use allocators.

Overloading new (for the purpose, of e.g. adding a thread-local allocator) adds implicit global state that isn't always easy to manage.

Sure, but no more than the standard allocator. Explicit allocator objects are a superior solution most of the time anyway.

Good memory management is never easy on a system level, so if one is overloading new, they'd better be comfortable around the complexities involved.

if you decide to use new/new[], you are bound to use the same allocator everywhere. c++ did not give you a chance to customize your allocation.

Another potential problem is that "new" can throw an exception.

In practice they don't on a lot systems. Last time I checked glibc baked in Linux's overcommit by default nonsense, just throws up it's hands and says 'malloc never fails'.

That's not exactly correct. You can set ulimit and malloc will happily fail. And ulimit is pretty standard tool.

ulimit on the resident set size hasn't worked since the Linux 2.4 days

There are 4 options: 1) allocation can't fail for whatever reason. So new won't ever throw.

2) allocation can fail but you do not care to handle it. Your application will abort on an exception which is the best scenario.

3) allocation can fail and you want to handle it non locally (for example in a constructor). Exceptions work well in this scenario.

4) allocation can fail and you want to handle it locally: new(nothrow) is your friend. Remember to check for '!= nullptr'.

Exceptions require special stack-unwinding logic, which may not be adequate for a kernel (?)

Sure (although there is work ongoing to fix that), but that's only relevant for point 3 and in that case 4 is an option.

> essentially the thing you have to avoid is "new" which is sort of the heart of the language ...

You can use placement-new syntax and ~Object() (direct call to the destructor), together with malloc/free, or any other memory-allocation primitive, just like in C. You don't have to use the inbuilt new operator.

Still, C++ should be considered a near-legacy language these days. Rust (even in its no_std subset) is progressing rather quickly.

Reply on news.ycombinator.com