8 ms·

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

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)

atilaneves 8y ago
You can overload operator new to not use the heap. You can use allocators.
- heavenlyblue 8y ago
  Overloading new (for the purpose, of e.g. adding a thread-local allocator) adds implicit global state that isn't always easy to manage.
  - gpderetta 8y ago
    Sure, but no more than the standard allocator. Explicit allocator objects are a superior solution most of the time anyway.
  - martinlaz 8y ago
    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.
- altmind 8y ago
  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.
zozbot123 8y ago
> 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.
amelius 8y ago
Another potential problem is that "new" can throw an exception.
- monocasa 8y ago
  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'.
  - vbezhenar 8y ago
    That's not exactly correct. You can set ulimit and malloc will happily fail. And ulimit is pretty standard tool.
    - monocasa 8y ago
      ulimit on the resident set size hasn't worked since the Linux 2.4 days
- gpderetta 8y ago
  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'.
  - amelius 8y ago
    Exceptions require special stack-unwinding logic, which may not be adequate for a kernel (?)
    - gpderetta 8y ago
      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.
monocasa 8y ago
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.
- Taniwha 8y ago
  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
  - monocasa 8y ago
    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.

atilaneves 8y ago

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

heavenlyblue 8y ago
Overloading new (for the purpose, of e.g. adding a thread-local allocator) adds implicit global state that isn't always easy to manage.
- gpderetta 8y ago
  Sure, but no more than the standard allocator. Explicit allocator objects are a superior solution most of the time anyway.
- martinlaz 8y ago
  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.
altmind 8y ago
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.

zozbot123 8y ago

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

amelius 8y ago

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

monocasa 8y ago
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'.
- vbezhenar 8y ago
  That's not exactly correct. You can set ulimit and malloc will happily fail. And ulimit is pretty standard tool.
  - monocasa 8y ago
    ulimit on the resident set size hasn't worked since the Linux 2.4 days
gpderetta 8y ago
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'.
- amelius 8y ago
  Exceptions require special stack-unwinding logic, which may not be adequate for a kernel (?)
  - gpderetta 8y ago
    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.

monocasa 8y ago

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.

Taniwha 8y ago
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
- monocasa 8y ago
  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.